www.alteredsecurity.com Open in urlscan Pro
34.149.87.45 Public Scan

Back to summary

URL:
https://www.alteredsecurity.com/post/a-primer-on-dcsync-attack-and-detection
Submission: On February 14 via api (February 14th 2024, 1:44:47 pm UTC) from DE — Scanned from DE

Form analysis
0 forms found in the DOM

Text Content

top of page
Skip to Main Content

Altered Security

* ONLINE LABS

* BOOTCAMPS

* CERTIFICATIONS

* TRAININGS

* BLOG

* RESOURCES

* TESTIMONIALS

* ABOUT US

* ABOUT
* SERVICES
* CAREERS

* NEWS

* CONTACT

* More

Use tab to navigate through the menu items.
*
*
*

* Chirag Savla
*
* * Feb 16, 2022
*
* 8 min read

A PRIMER ON DCSYNC ATTACK AND DETECTION

Updated: Feb 2, 2023

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, 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 : 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".

Logon Event

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.

Sysmon Event ID 10

This attack can also be detect via ATA as "Unusual protocol implementation"

ATA Alert for OverPass-The-Hash Attack

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.

DCSync Attack Detection

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"

DCSync Attack Detection using DCSYNCMonitor Tool

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

ATA alert for DCSync Attack

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

ACL Modification Detection

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.

SDDL String

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.

23,998 views0 comments
5 likes. Post not marked as liked5

www.alteredsecurity.com Open in urlscan Pro 34.149.87.45 Public Scan

Form analysis 0 forms found in the DOM

Text Content

www.alteredsecurity.com Open in urlscan Pro
34.149.87.45 Public Scan

Form analysis
0 forms found in the DOM