Introduction
In this post we will look at the DCSync OS Credential Dumping technique targeting domain controllers (T1003.006), the shortcoming of logs to efficiently detect and investigate this attack, and how network data provides a better approach.
Active Directory
Active Directory is at the centre of most organizations to help centrally manage users, privileges, policies … across the network. Due to its critical role, Active Directory is often one of the 1st targets threat actors go after once they get initial access to a network, and it is therefore critical to have the required tools, visibility, and capabilities to detect and investigate attacks targeting domain controllers.
Domain Replication
Active Directory supports the option of having multiple domain controllers, both for backup and high availability, as well as for geographic distribution to serve sites locally. A necessary capability is therefore to ensure that all domain controllers and accounts are synchronized whenever changes are made to make sure that they all have the latest account information. This is done using MS-DRSR (Microsoft Directory Replication Service Remote Protocol), which is an RPC protocol that allows a domain controller to request the synchronization of resources using the GetNCChanges function. For example, requesting the replication for a specific user would provide the data of that user, which includes the user’s password hashes, to the domain controller requesting the information.
The Attack
DCSync
It is possible for a threat actor to impersonate a domain controller and generate a request to synchronize a user account. With the correct privileges, the legitimate domain controller would respond with the information, including the requested user’s password hashes. These could include password hashes of key user accounts, such as Administrator and KRBTGT accounts, which would then allow the threat actor to generate golden tickets and perform pass the hash attacks. DCSync is part of mimikatz, allowing to easily perform this attack.
Privilege Requirements
For the attack to be successful, the threat actor must use an account that has the following privileges:
- Replicating Directory Changes
- Replicating Directory Changes All
By default, members of the Domain and Enterprise Admin groups, as well as computer accounts have these privileges.
If the attacker was able to compromise one of these accounts (through phishing, bruteforcing, password re-use, data leak …), he would be able to successfully execute this attack.
In addition, some vulnerabilities such as Zerologon (CVE-2020-1472) would allow the threat actor to set an empty password for the computer account of the domain controller and use this account to successfully use DCSync.
Attack Process
The following are sample steps to demonstrate a successful execution of DCSync to obtain the password hashes of the “Administrator” account.
Execution of Zerologon
This is an optional step to gain access to the domain controller’s computer account that has enough privileges to launch the DCSync attack.
Execution of DCSync
In this step we execute DCSync using the computer account that was compromised in the previous step to request the details of the “Administrator” account from the legitimate domain controller.
The computer account having enough privileges, the domain controller accepts the request and sends the “Administrator” details, including password hashes.
Detection
The Problem with Logs
Most recommendations to detect domain replication using logs revolve around the Windows Event ID 4662 from the domain controller, which Active Directory logs when a user accesses an AD object. Since normal and legitimate operations would generate this event, it is then recommended to specifically filter on Event ID 4662 where the properties contain "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" (when a user uses his “Replication Directory Changes All” privilegs mentioned in the previous section) and look for requests that originated from an unexpected source (such as not from another domain controller).
But the problem is that this event ID doesn’t get generated when the action is done by a computer account (such as accounts that end with “$”). Enabling logging for these accounts requires additional configuration on the domain controller, and some sources actually recommend keeping it disabled to reduce noise, because it is expected that domain controllers use computer accounts when doing replications, and this is considered as normal behaviour.
The problem with this is that, as seen in the above attack example, DCSync can be chained with Zerologon, which gives us access to the computer account of the domain controller. This means that in this or any similar case where the computer account is used by a threat actor, Event ID 4662 wouldn’t be logged, and therefore the DCSync attack would remain undetected with no trace of it.
This is just 1 example of the challenges with logs, where we rely on what is configured and enabled, and rely on the expected default behaviour of which logs are generated and under which conditions.
Detection with Network Data
A better and more consistent approach would be to leverage network data from/to the domain controller. This is typically more fool proof since it doesn’t rely on how things are configured and when things are logged or not logged: all traffic, independently of good, bad, or unknown, is continuously captured, analysed and stored.
As shown in the below screenshot, NetWitness can capture and extract all the information needed to detect and investigate the DCSync attack, without relying on any required custom configurations on the domain controllers:
- The service is identified as RPC (as described in the “Introduction” section)
- The traffic is flowing from the users’ subnet to the domain controllers’ subnet (business context can be used to enrich data at capture time by using custom feeds or by configuring the “traffic_flow_options.lua” file under the decoder’s configuration)
- The involved source and destination hostnames are identified
- The use of the “GetNCChanges” function is identified (as described in the “Introduction” section)
Further Investigation using Endpoint Data
If we go one step further by having the NetWitness EDR agent installed on the user workstation and domain controller, we can identify which user account and process caused the captured network session to be generated.
In the below screenshot, we can see that this RPC session has been generated by a process named “svchost.exe”, which appears to be a valid Microsoft process.
By drilling into the details of this “svchost.exe” process we can easily confirm that:
- The file hash is known to be malicious
- Independently of the filename, it is identified as “Win64.Hacktool.Mimikatz”
- It is not actually signed by Microsoft
Based on the above, we can quickly and easily reach the conclusion that this specific file is actually Mimikatz renamed to a familiar process name, is not actually a valid Micorosft process, and the network traffic generated by this process is therefore also confirmed to be malicious.
IOCs
Sample IOCs for techniques and behaviours mentioned in this article.
Zerologon: ioc = 'zerologon attempt'
DCSync: action = ‘drsgetncchanges’ && ip.src != <include list of approved IP addresses>
