A primer on DCSync attack and detection

Written by on

 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. 

Replication 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.

Domain Admins Group

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.

OverPass-The-Hash Attack

In the New PowerShell console we can load the Invoke-Mimikatz PowerShell script and perform the DCSync attack.

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.

WriteDACL Rights

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.

DCSync Rights

We will enumerate and confirm if adversary user has DCSync rights.

ACL Enumeration

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.

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 & 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 DCSync 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


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 : seclogo

In 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


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. 🙏  


Comments

Post a Comment

Popular posts from this blog

Process Injection - Part I

Written by on
Image
Hello All, After publishing the post about Dumping Process Memory with Custom C# Code my friend Himanshu suggested me to write a tool & a blog post about Process Injection for learning and he referenced his post about Code Injection which covers the concept about the vanilla process injection technique. It was quite interesting to learn and understand the core concepts about Process Injection techniques and as a learning path to code in c# leveraging Windows API I started writing the tool for Process Injection. What is Process Injection ? Process injection is a method of executing arbitrary code in the address space of a separate live process. Running code in the context of another process may allow access to the process's memory, system/network resources, and possibly elevated privileges. Execution via process injection may also evade detection from security products since the execution is masked under a legitimate process. Why Process Injection ?
Read more

Introduction to Callidus

Written by on
Image
Hello All, Performing Red Team assessments are becoming challenging day by day. In mature environments we see a lot of custom tool development and new techniques are getting discovered by the community to overcome various challenges. While thinking about such challenges, I came up with the idea of creating a tool that can leverage legitimate services for establishing command & control communication channel which is likely to be whitelisted or are less monitored due to the nature of services used by the corporate environments. This is not a new technique, we have already seen similar projects that were developed to leverage legitimate services for command & control. Communication channels such as Slackor for Slack C2, DaaC2 for Discord C2 or  Domain Fronting techniques etc. In this post I will introduce you to a tool called "Callidus" which I created to learn & to improve my knowledge about developing custom toolset in C# and learning how to leverage
Read more

Exploring the Dark Side of Package Files and Storage Account Abuse

Written by on
Image
 Hello All, In this blog, we dive into the dark side of package files and Storage Account abuse within the Azure Function App service. We explore how package files can be leveraged to enhance the functionality of the Functions Apps, shedding light on the potential abuse of package files. By examining the connection between the Function App and Storage Account, we uncover how attackers can abuse the Storage Account's connection string to gain unauthorized access to the Function Apps. We will provide step-by-step insights into replacing binary files and deploying custom code, enabling attackers to take control of the Function App.  The research was jointly done by  Raunak and myself . What are Function Apps? Function Apps (Lambda in AWS) are serverless computing services provided by Azure Cloud. They allow developers to build and deploy small, functions that can be triggered by events such as simple HTTP request. Function Apps provide an environment for executing our code without th
Read more