A primer on DCSync attack and detection
Updated: Feb 2
Hello All,
Active directory is a backbone of almost all the organizations. It helps the IT team to manage the systems, users, policies etc, centrally across the complete network. Since it is integral part of the organization, it open's multiple opportunity for the attackers to leverage the features of active directory and abuse them for malicious intent. We will look at one such feature known as Active Directory Replication in this post.
In this post we will look at few approach that we can use to detect the DCSync attack and gain understand about the attack. DCSync attack and detection is already explained by Sean Metcalf & Will Schroeder in their blog post.
About Active Directory Replication
Domain Controllers (DC) are the pillars of Active Directory (AD) environment. Organizations often have multiple Domain Controllers for it's Active Directory as a backup or they have different Domain Controllers for each location so that the authentication and other policies can be made available locally on the site location. Now as there are multiple Domain Controllers in the organization it is important that every Domain Controller is aware of every changes made in the environment. This changes are sync with each Domain Controller via Microsoft Directory Replication Service Remote Protocol (MS-DRSR). AD uses several counters and tables to ensure that every DC has the most current information for each attribute and object and to prevent any endless replication loops. AD uses naming contexts (NCs), also known as directory partitions, to segment replication. Every forest has a minimum of three NCs: the domain NC, the configuration NC, and the schema NC. AD also supports special NCs, often known as application partitions or non-domain naming contexts (NDNCs). DNS uses NDNCs (e.g., DomainDnsZones, ForestDnsZones). Each NC or NDNC replicates independently of one another.
About DCSync Attack
DCSync is a technique used to extract credentials from the Domain Controllers. In this we mimic a Domain Controller and leverage the (MS-DRSR) protocol and request for replication using GetNCChanges function. In response to this the Domain Controller will return the replication data that includes password hashes. This technique was added in Mimikatz tool in August 2015 by Benjamin Delpy and Vincent Le Toux.
To perform DCSync attack we need the following rights on the Domain Object:
1) Replicating Directory Changes (DS-Replication-Get-Changes)
2) Replicating Directory Changes All (DS-Replication-Get-Changes-All)
3) Replicating Directory Changes In Filtered Set (DS-Replication-Get-Changes-In-Filtered-Set) (this one isn’t always needed but we can add it just in case)
Generally members of Administrators, Domain Admins, or Enterprise Admins as well as Domain Controller computer accounts by default have the above rights.
DCSync Attack Scenario
We will look at 2 Scenarios in this blog post:
Note: There can be many more scenario that you can think of to perform DCSync attack.
1) We assume that we have User account hash that is the member of Domain Admins group
2) We assume that we have User credentials that has WriteDACL rights on the Domain Object
1) First Scenario
So let's assume that we have already compromised the user account that is the member of Domain Admins group. In our Lab we have a user named storagesvc that is a member of the Domain Admins group as we can see in the below screenshot.
So we can now perform the OverPass-The-Hash attack using Invoke-Mimikatz PowerShell script and start a new PowerShell console with the privileges of the storagesvc user.
In the New PowerShell console we can load the Invoke-Mimikatz PowerShell script and perform the DCSync attack.
As we can see in the above screenshot we were able to perform DCSync attack successfully and retrieve the KRBTGT account hash.
2) Second Scenario
So let's assume that we have already found the clear text credential of the user that has WriteDACL privileges on the Domain Object. In our Lab we have a user named sharepointmaster that has WriteDACL rights on the Domain Object as we can see in the below screenshot.
We will leverage the PowerView script to grant the DCSync rights to another user(adversary) that we own.
Note:- We can also grant DCSync rights to sharepointmaster user.
We will enumerate and confirm if adversary user has DCSync rights.
As we can see in the above screenshot we were able to grant the DCSync rights to the adversary user successfully.
Now, We will load the Invoke-Mimikatz PowerShell script and perform the DCSync attack.
As we can see in the above screenshot we were able to perform DCSync attack successfully and retrieve the KRBTGT account hash. Note: There are other tools that can also perform DCSync attacks such as Impacket Library & DSInternals etc.
Detection
To detect the OverPass-The-Hash attack, ACL based attacks & DCSync attack we need to enable few logs on the Domain Controller before emulating the attack. In our Lab we have already enabled those logs. But you can follow the below mentioned steps to enable the logs in your environment. We have also deployed the Sysmon in our lab for additional logging. You can use also deploy Sysmon with Sysmon Modular config in your environment.
To Capture the Logon Events we need to enable the "Audit Logon" logs. Follow the below steps to enable the Logs:
1) Login to Domain Controller
2) Open Group Policy Management Console
3) Expand the Domain Object
4) Expand the Group Policy Objects
5) Right click on the Default Domain Policy and click on Edit (The policy that is applied to all the domain computers. It may differ in your environment)
6) Follow the below path to enable Audit Logon events.
Computer Configuration --> Windows Settings --> Security Settings --> Advanced Audit Policy Configuration --> Audit Policies --> Logon/Logoff --> Audit Logon
7) Select "Configure the following audit events:" Checkbox
8) Select Success & Failure Checkbox
To Capture the Directory Service Access Events we need to enable the "Audit Directory Service Access" logs. Follow the below steps to enable the Logs:
1) Login to Domain Controller
2) Open Group Policy Management Console
3) Expand the Domain Object
4) Expand the Group Policy Objects
5) Right click on the Default Domain Policy and click on Edit (The policy that is applied to all the domain computers. It may differ in your environment)
6) Follow the below path to enable Audit Logon events.
Computer Configuration --> Windows Settings --> Security Settings --> Advanced Audit Policy Configuration --> Audit Policies --> DS Access --> Audit Directory Service Access
7) Select "Configure the following audit events:", "Success" & "Failure" Checkbox
To Capture the Directory Service Change Events we need to enable the "Audit Directory Service Changes" logs. Follow the below steps to enable the Logs.
1) Login to Domain Controller
2) Open Group Policy Management Console
3) Expand the Domain Object
4) Expand the Group Policy Objects
5) Right click on the Default Domain Policy and click on Edit (The policy that is applied to all the domain computers. It may differ in your environment)
6) Follow the below path to enable Audit Logon events.
Computer Configuration --> Windows Settings --> Security Settings --> Advanced Audit Policy Configuration --> Audit Policies --> DS Access --> Audit Directory Service Changes
7) Select "Configure the following audit events:", "Success" & "Failure" Checkbox After we published the blog @TactiKoolSec highlighted us that 4662 event won't be generated if the DCSync attack is performed by Computer Accounts.
Later @4ndr3w6S shared a tweet from @cnotin where @cnotin & @exploitph discussed about this behavior and mentioned that we need to add additional SACLs on the Domain Object for detecting DCSync attack performed by Computer Accounts and Domain Controllers.
To add the Domain Computers SACL on the Domain Object. Follow the below steps:
1) Login to Domain Controller
2) Open Active Directory Users and Computers Console.
3) Right click on the Domain Object and click on Properties.
4) Click on Security" tab in the Properties dialog box and then click on Advanced button.
5) Click on Auditing" tab in the Advanced Security Settings dialog box and click on Add button.
6) Click on "Select a principal" and enter "Domain Computers" in the text box and click on "Check Names" button and then click on "OK" button.
7) Select "Success" from the drop-down list of "Type".
8) Select "This object only" from the drop-down list of "Applies to".
9) Select "All extended rights" checkbox and click on "OK" button.
10) Click on "Apply" button and then click on "OK" button.
To add the Domain Controllers SACL on the Domain Object. Follow the below steps:
1) Login to Domain Controller
2) Open Active Directory Users and Computers Console.
3) Right click on the Domain Object and click on Properties.
4) Click on Security" tab in the Properties dialog box and then click on Advanced button.
5) Click on Auditing" tab in the Advanced Security Settings dialog box and click on Add button.
6) Click on "Select a principal" and enter "Domain Controllers" in the text box and click on "Check Names" button and then click on "OK" button.
7) Select "Success" from the drop-down list of "Type".
8) Select "This object only" from the drop-down list of "Applies to".
9) Select "All extended rights" checkbox and click on "OK" button.
10) Click on "Apply" button and then click on "OK" button.
Note about false positive: Some false positive DCSync alerts will be generated when we add the SACL for Domain Controllers on Domain Object. Since the Domain Controllers regularly sync data between themselves. Other applications would also generate false positive DCSync alerts like Azure AD Connect or any AD Backup Solution.
In our lab we are using HELK setup to parse and query the logs and winlogbeat to push the logs from the individual systems to the HELK instance.
Detect OverPass-The-Hash
Now let's run the below query to detect the Logon event that is generated while performing OverPass-The-Hash attack.
event_id:4624 and logon_type : 9 and logon_process_name : seclogoIn the above query we are searching for Event ID 4624 logs that contains logon_type 9 and logon_process_name seclogo.
Event ID 4624 - This event is generated when a logon session is created.
Logon Type 9 - A caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections .When we perform OverPass-The-Hash attack a Logon Type is 9.
Logon Process - The name of the trusted logon process that was used for the logon. When we perform OverPass-The-Hash attack a Logon Process with the name is "seclogo".
While performing the OverPass-The-Hash attack Mimikatz tries to access the LSASS process. Run the below query to detect if LSASS process is accessed with certain privileges that are common while running Mimikatz on the machine to extract the credentials or perform OverPass-The-Hash attack.
host_name : "oil-attacker.oil.crude.corp" and event_id: 10 and process_granted_access_orig: ("0x1010" or "0x1038")In the above query we are searching for Event ID 10 logs on "oil-attacker" machine that has granted certain access to LSASS process. We can look for process-specific access rights here.
This attack can also be detect via ATA as "Unusual protocol implementation"
Detect DCSync
We can run the below query to identify if DCSync attack was performed.
event_id: 4662 and log_name: "Security" and object_properties: ("1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" or "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" or "89e95b76-444d-4c62-991a-0facbeda640c")The GUIDs mentioned in the above queries are the GUIDs of the Replication rights needed to perform DCSync attack.
We can also leverage network traffic to detect DCSync attack. There is a tool DCSYNCMonitor that needs to be installed on the Domain Controller to monitor for the Network Traffic. This tool triggers an alert when there is any Replication performed over the network. This can trigger false positive alerts when a Genuine Domain Controller request for an replication. Hence it is recommended to use DCSYNCMonitor tool with configuration file where we specify the IP address of the Domain Controllers in the network to avoid false positive alerts.
We can run the below query to identify the alert triggered by DCSYNCMonitor tool.
event_id: 1 and source_name : "DCSYNCALERT"
In the above screenshot we can see a false positive alert for 172.16.1.2 IP address as it is a valid Domain Controller. This is to highlight the importance of the config file while using DCSYNCMonitor tool.
This attack can also be detect via ATA as "Malicious replication of Directory Services".
Detect ACL Modification
We can run the below query to identify the ACL modification where we granted adversary user the DCSync rights.
event_id: 5136 and log_name: "Security" and dsobject_class: "domainDNS"There are multiple events that are generated while modifying the ACLs.
The event log count will always be in even number as there are always 2 event for single ACL modification. The same can be verified by filtering using the "Correlation ID". One event is "Value Deleted"(ACL deleted / removed) and the second is "Value Added" (ACL Added / Modified).
We can also Convert the "nTSecurityDescriptor" value using "ConvertFrom-SddlString" PowerShell command to get more detail about what changes are done.
Notes:- This command can't retrieve the value of the DCSync rights, we will always see the value as "WriteAttributes" and we need to run this command from Domain Joined machine.
Recommendation
It is recommended to audit risky ACL based misconfiguration regularly as those could lead to compromise of the complete domain environment.
Reference
https://adsecurity.org/?p=1729
https://www.harmj0y.net/blog/redteaming/abusing-active-directory-permissions-with-powerview/
https://www.harmj0y.net/blog/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/
https://attack.stealthbits.com/privilege-escalation-using-mimikatz-dcsync https://gist.github.com/gentilkiwi/dcc132457408cf11ad2061340dcb53c2 https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772673(v=ws.10) Feel free to provide me the feedback on twitter @chiragsavla94
Thanks for reading the post.
Special thanks to all my friends who help / supported / motivated me for writing blogs. 🙏
Posted by:
Chirag Savla
Senior Security Researcher at AlteredSecurity
Also published at 3xpl01tc0d3r.