In my previous blog post regarding ATA, we looked at setting up ATA in a lab to walk through the process end-to-end, and show some basic functionality, namely installing, configuration and logging in with the ‘honeytoken’ user account to trigger an alert.
In this blog post I will demonstrate the detection and alerting capabilities of ATA in more detail by walking through Microsoft’s ATA Play Book. My intention in this blog is to quickly summarise the preparation/requirements detailed in the guide and get straight into the simulation and alerting. I have aimed to provide some guidance on any difficulties or anomalies I found in following the guide, but also I thought it would be good to run through the playbook in detail and just document my experience for those who are just interested to have a read. If you need more of an explanation on the playbook scenario refer to the playbook above.
If you want to run the simulation yourself, I am assuming that you have a working implementation of ATA in your lab ready, similar to what I blogged about in my previous post, i.e. a lab environment, with 1 x domain controller, 1 x ATA Centre and 1 x ATA Gateway or Lightweight Gateway.
The ATA Playbook demonstrates a security breach by simulating an attacker performing initial reconnaissance/discovery activities which lead to credential theft, lateral movement and domain escalation. On top of the ATA requirements, the playbook requires that you set up the following:
NOTE: These tools are for research purposes only. Microsoft does not own these tools nor can it guarantee their behaviour. These tools should only be run in a test lab environment.
*NOTE: For Mimikatz, I had to play around with download to get it working. From https://github.com/gentilkiwi/mimikatz/releases, firstly download and extract the “Source code (zip)” of the latest release (which is a Visual Studio project/solution). In my lab this was extracted into a folder named \mimikatz-2.1.1-20170608\. I then download “mimikatz_trunk.zip” and extracted it into the existing Mimikatz folder under the root folder of the first download extracted (in my lab \mimikatz-2.1.1-20170608\mimikatz\). My lab environment was X64 so when I need to run the mimikatz.exe binary, it is from the x64 folder, i.e. under \mimikatz-2.1.1-20170608\mimikatz\x64\.
NOTE: If your client systems for are Windows 8.1 or greater, add the following registry key to enable storing of clear text passwords in memory to facilitate the simulation (I have only tested this on 8.1). For more information on WDigest, refer https://blogs.technet.microsoft.com/kfalde/2014/11/01/kb2871997-and-wdigest-part-1/
reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1
The assumption for the playbook is that a normal user account, JeffV, has already been compromised. The playbook scenario creates a situation where a help desk technician assists JeffV and then finishes assisting them without logging out of the computer (a mistake obviously, remember, this is a playbook). From there, the attacker starts their reconnaissance activities leading to further credential theft and domain escalation/dominance.
So, to begin the simulation, log onto JeffV’s machine as JeffV, switch users to RonHD and then switch back to JeffV. Do not log out or restart to machine. The purpose of this exercise is to leave RonHD’s credentials in memory on the machine for the following simulation.
One of the first learning activities an attacker may try is to receive all contents of DNS.
On JeffV’s machine (and logged in as JeffV), the PC and user whom (in theory) the adversary just compromised, run the following commands:
Below, a DNS Reconnaissance alert is generated in ATA. Notice the options available in the alert (which is the general format of all alerts). You can:
Knowing the relationship between users, groups and privileges will be something an attacker will obviously want to learn.
From a command prompt on JeffV’s machine, run the following commands:
net user /domain
net group /domain
Below is the alert generated in ATA for directory services enumeration. Notice the alert display the user and the data they were able to access.
Furthermore, the attacker can run the below command to find members of the Domain Admins or any other administrative group, and target these users, i.e. NuckC as shown below!
The attacker now knows who they want to compromise to get the highest privileges. SMB enumeration can provide a precise location for where these accounts are exposed. And all users must connect to a domain controller to process Group Policy (against SYSVOL), making SMB enumeration a valuable tool for attackers.
Log onto NuckC’s machine as NuckC.
The NetSess tool you downloaded can perform this enumeration. Still on JeffV’s machine, open a command prompt and browse to where you downloaded the tool and run the below command against your domain controller:
The attacker knows that NuckC is a Domain Admin, and now they know his IP address. A simple ‘ping -a 192.168.0.172’ will return the computer name also, although in the below screen-grab you can see that computer name also, ‘WIN10-01’ (in my lab, in the playbook it is Admin-PC).
And below is the alert that is generated in ATA.
The next logical step for the attacker, is to get access to NuckC’c computer IP address.
The method that the playbook scenario uses to start achieving this is to enumerate all the in-memory credentials on JeffV’s machine, to see if they can find anything here to help their cause. The Mimikatz tool that was downloaded can achieve this.
From an elevated command prompt on JeffV’s machine, browse to the directory containing the Mimikatz.exe application, which if you followed my directions in the prerequisite section, should be in the folder you extracted it to under “\Mimikatz-<version-number>\Mimikatz\x64”, and run the following:
mimikatz.exe “privilege::debug” “sekurlsa::logonpasswords” “exit” >> “c:\temp\victim-pc.txt”
From the text file output, we can now see that because RonHD is still logged onto this machine, his credentials are now compromised.
NOTE: This activity did not invoke an alert in ATA. Also, if you didn’t add the registry key in the prerequisite section above, the password field may show as Null.
An attacker, having discovered these new credentials, might decide to find out a bit more about this account by running the below command:
net user RonHD /domain
By doing this he discovers that RonHD is a member of a domain group called “Helpdesk”.
NOTE: This activity did not invoke an alert in ATA.
The attacker still needs to know more about RonHD’s account to see if it will be useful to them. The PowerSploit tool downloaded will be able to assist them with this.
Remember that the attacker knows the IP address of NuckC’s machine. Using this IP address, they can enumerate the machines local group memberships to see if they can find anything of value in relation to RonHD’s account.
Open an elevated powershell prompt, browse to the directory you downloaded PowerSploit to, and run the below 2 commands:
NOTE: Following the instructions in the playbook, the below didn’t work in my lab. I had to add JeffV to the local Administrators group on the second client machine also to get the output below.
NOTE: This activity did not invoke an alert in ATA.
By running the above command, the attacker can now see that the Helpdesk group is a member of the local Administrators group on NuckC’s machine. And RonHD, whose credentials the attacker now has, is a member of that group and therefore a local Administrator on NuckC’s machine. At this point, the attacker can access NuckC’s machine, and probably any client machine in the environment. But to demonstrate ATA further, the playbook assumes the attacker does not have the plain text password.
By using this method, the attacker can obtain the NTLM hash of RonHD and use it to obtain a Ticket Granting Ticket (TGT) via Kerberos\Active Directory. With a TGT you can masquerade as RonHD and access any domain resource that RonHD has access to.
The attacker already has the NTLM hash for RonHD, obtained earlier from Mimikatz.
Using Mimikatz again, the attacker can run the Mimikatz command shown below, substituting in the NTLM hash:
NOTE: In the playbook, the ‘path’ parameter is spelt as such and didn’t work in my testing. The correct format I found, as shown below, is ‘pth’.
mimikatz.exe “privilege::debug” “sekurlsa::pth /user:RonHD /ntlm:1a487454f08d2c89f47b7fc62fb3a3ac /domain:yourdomain.local” “exit”
This will open a new command prompt window, into which RonHD’s credentials have been injected.
NOTE: At this point no alert has been generated in ATA.
As can be seen below, from this command prompt, the attacker can browse the directory of NuckC machine’s C drive.
And when a klist command is run as shown below, it displays the Kerberos tickets for RonHD, validating that the attacker is using his legitimate credential.
And now in ATA, an alert is generated for an unusual protocol implementation, and the alert suggests Pass-the-Hash or brute force as a possible source of the alert.
NOTE: In addition to the above alert, in my lab, presumably because I had ATA installed for over a month and ATA’s machine-learning based behaviour analytics was able to detect abnormal behaviour, I also received the below alert, which specifically suggests that the encryption type from machine WIN8-02 is weaker than previous (‘learned’) encryption types from that machine, and that credential theft using ‘Overpass-the-Hash’ may be the cause, which is exactly what was happening in this instance.
So, at this point, the attacker now has access to NuckC’s (a Domain Admin) machine. A logical step for them now is to escalate their privileges within the domain via NuckC’s account. To do this, a ‘Pass-the-Hash’ attack can facilitate a move to NuckC’s machine.
To achieve this Mimikatz files need to be copied over to NuckC’s machine so it can be executed to get a dump of existing Kerberos tickets on that machine. Run the commands below from the elevated command prompt opened with RonHD’s credentials in the previous step.
NOTE: I copied the entire directory across (as detailed in the prerequisites section), which is different to the instructions in the ATA Playbook.
xcopy mimikatz-2.1.1-20170608 \\NuckC’s-Machine\c$\temp\mimikatz\ /EH
Run Mimikatz on NuckC’s machine by using PsExec (remember to browse to the directory containing the PsExec.exe first).
psexec.exe \\NuckC’s-Machine -accepteula cmd /c (cd c:\temp\mimikatz\mimikatz\x64 ^& mimikatz.exe “privilege::debug” “sekurlsa::tickets /export” ^& “exit”)
NOTE: In my lab, the above command dumped the Kerberos tickets in the directory Mimikatz was run from (i.e. x64). So, to copy them back from NuckC’s machine to JeffV’s machine, run the below command.
xcopy \\NuckC’s-Machine\c$\temp\mimikatz\mimikatz\x64 c:\temp\tickets
Below is a screenshot of NuckC’s Kerberos tickets copied across to JeffV’s machine.
NOTE: All other files and tickets have been removed so just the ‘kirbi’ files with NuckC’s name in the title remain.
The attacker now has NuckC’s credentials without having to exploit his machine further. The next step is to import the tickets into a session on JeffV’s machine.
NOTE: The above actions did not invoke an alert in ATA.
The attacker can now import these tickets into JeffV’s machine’s memory, to get the credentials to access sensitive resources on the domain.
From the same elevated command prompt on JeffV’s machine, run the below command to load the Kerberos tickets for NuckC into memory.
mimikatz.exe “privilege::debug” “Kerberos::ptt c:\temp\tickets” “exit”
NOTE: What I found in my lab was that I had to run the below command for each Kerberos (krbtgt) ticket that I received from the export in the previous step. If I tried to import them all at once it only imported 1 ticket. So, run the import once, then removed the ticket that was imported (identified below in the red square) from the directory and run the command again to import the next ticket and keep repeating. For my lab, I repeated this once to import 2 tickets.
Run a klist command and you will see the Kerberos tickets for NuckC are now loaded into memory on JeffV’s machine.
And now the attacker can browse the root directory of a domain controller with NuckC’s Domain Admin credentials by browsing executing dir \\your-dc\c$
And an alert has been generated in ATA as shown below, indicating all the resources that were involved in the Pass-the-Ticket attack, which helps you know where to start your investigation.
You can click on the resources icon to see more information as shown below, for example the CIFS protocol used to access directory.
Moving onto the next potential step in the attack, now that the Domain Admin credentials of NuckC have been compromised, the attacker is away! To decrease the chances of their detection, they may decide to create extra identities to carry out subsequent activities. This is what the next step is based on to illustrate remote code execution.
Use PsExec to connect to the domain controller and create a new user and add them to the domain Administrators group by running the below commands.
psexec \\your-DC -accepteula net user /add InsertedUser UserPassword1
psexec \\your-DC -accepteula net localgroup “Administrators” InsertedUser /add
As can be seen above by using PsExec, the attacker was able to create a user and add them to the domain Administrators group. ATA detected the remote execution of PsExec as shown in the alert below.
NOTE: This alert was generated with a severity of ‘Low’, whereas all the other alerts so far have been ‘Medium’ or ‘High’ severity. But it was generated well into the attacker’s kill-chain.
To ensure the persistency of domain dominance, backdoors and other mechanisms are put in place as insurance policies by attackers, in case the original method of attack was discovered or a credential randomly reset.
A Skeleton Key is a way to instantly create privileged users and maintain a backdoor to the DC/domain.
From the elevated command prompt on JeffV’s machine (using NuckC’s credentials), run the below command to copy the Mimikatz files over to the domain controller.
xcopy mimikatz-2.1.1-20170608 \\your-DC\c$\temp\mimikatz\ /EH
Then run PsExec as shown below to patch the LSASS.exe binary with the Skeleton Key. (the following steps will show what this allows the attacker to do).
psexec.exe \\your-DC -accepteula cmd /c (cd c:\temp\mimikatz\mimikatz\x64 ^& mimikatz.exe “privilege::debug” “misc::skeleton”
To demonstrate what this now allows the attacker to do, open a command prompt as JeffV on JeffV’s machine and run the below commands.
net use k: \\your-DC\c$ wrongpassword /user:email@example.com
net use k: \\your-DC\c$ mimikatz /user:firstname.lastname@example.org
The first command confirms that only JeffV’s credentials are available in the command prompt session.
The second command tries to map the domain controller’s C drive with obviously incorrect credentials and it fails as expected.
The last command uses the Mimikatz master key that was created in the previous step. Which works! So essentially every account in the domain now has 2 passwords, their own, and the skeleton key created by the attacker via Mimikatz.
ATA detects this activity and suggests that the profile of this event matches a potential Skeleton Key attack.
This is the final attack the ATA Playbook demonstrates. It is based on getting the credentials of the KRBTGT account so that they can sign their own tickets. Leveraging the KRBTGT to sign fake tickets is known as a Golden Ticket attack, which is also detected by ATA but is not included in the ATA Playbook because of it’s scope.
From the command prompt with NuckC’s credentials on JeffV’s machine, run the below command, which will replicate the KRBTGT account’s credentials back to JeffV’s machine.
mimikatz.exe “lsadump::dcsync /domain:your.domain /user:krbtgt” “exit” >> krbtgt-export.txt
From the exported information in the text file, the below information is all that is needed to sign any TGT for any resource using the stolen NTLM hash without ever going back to the Domain Controller. With this, the attacker can become anyone at any time they desire (until the KRBTGT account itself is reset, twice).
And in ATA, an alert is created flagging malicious replication of directory services as shown below.
NOTE: I have also noticed a similar alert for the Azure AD Connect server if you have this installed in your environment, which is a false alert and can be dismissed obviously.
That concludes the demonstration. I think the ATA Playbook does well in terms of demonstrating some of its capabilities, and really well in terms of the activities that an attacker may undertake, reminding us again how easy it is for an attacker once they have a gained a foothold. Based on my experience in a test lab, perhaps be prepared to spend some time getting things working as illustrated in the ATA Playbook if you want to replicate this yourself. Hope you found this article helpful.