Gemini drew this in one take and it’s pretty good so I went with it
This is part 2 of the Detection Researcher Mindset series. If you have not seen the first post where I discuss the process then start there. In this post I will walk through an example where we will develop a detection for a Remote DCSync attack following those steps.
As a refresher here is the process from the previous post.
Understand the attack
1. What is the goal of the attack technique?
Obtain password hashes from a domain controller. From there an adversary can impersonate that user and even create a golden ticket if they replicate the krbtgt password hash.
2. Why does it work?
If an attacker has control of an account with replication permissions they can instruct a domain controller to sync password hashes to their system using special tools.
3. At what phase of the attack would it be leveraged?
This is the credential access phase of Mitre ATT&CK so generally an attacker would have a foothold within the environment and has elevated their privileges significantly.
If they have the account privileges to perform a DCSync attack they have quite a bit of access within an environment already. A successful DCSync would allow them to have even more resilient access into the environment depending on the sensitive data they replicate from the Domain Controller. Let’s assume they would go for the gold since they may not get that shot again. The DCSync as we will see later, regardless of what they request will generate the same logging evidence to detect them.
After successfully grabbing the krbtgt account password hash they would be able to forge tickets and move laterally pretty quickly within the environment. They would still want to evade detection since their mission is not yet complete.
4. What artifacts would an adversary require to perform this attack?
- They would need access to a domain controller from a host they could run specific attack tools from.
- They would need an account with replication rights which is generally but not always domain admin level credentials.
5. Does this attack work in our organization?
Yes, we have 2 domain controllers in the lab that perform replication. As you can see below the attack worked just fine and we were able to grab the krbtgt hashes.
Mimikatz performing a DCSync for the krbtgt account hash from the Win10 systemThis was run from a Windows 10 VM in the lab with defender services disabled. Remember, we are not trying to detect mimikatz. We do not want to focus on the tool that is used by the adversary since we are detecting the malicious DCSync technique itself. If the detection is limited to the specific tool then an adversary could run a custom attack tool that we would likely not detect. We want to be at the top of the pyramid.
Simple lab designUnderstand normal system and user behavior
1. How is this service used normally? What is it used for?
Domain controllers will replicate directory changes to each other constantly (new groups, password updates, etc). Typically an enterprise will have a few to hundreds of domain controllers in different regions to ensure redundancy and good response times. Larger enterprises will even have multiple domains. A distributed infrastructure is important so logins to your workstation in the morning don’t take forever while you authenticate to the domain controller on the other side of the world. Below is a very basic architecture showing domain controllers in different regions.
2. Is this “exploited” feature needed in the enterprise? And why?
DCSync is a critical function if an organization has more than 1 domain controller. If you’re in the rare situation where there is only 1 Domain Controller then any DCSync activity would be suspicious!
3. Is this behavior outside of a standard process?
For our DCSync example knowing what’s normal will be critical to creating a detection that is not noisy as DCSync’s occur regularly in healthy environments. It may not be a standard process since it’s a windows function but there is a way to identify typical DCSync’s. That is, it will always originate from a Domain Controller!
4. Do administrators or power users perform this operation?
Very high privileges (domain admin+) are required to perform this operation.
The permissions specifically required to perform a DCSync are these [reference1, reference 2]:
Extended RightsHere’s a great post with a script on how to query which users/computers in your environment have these rights. In my lab here are the users/computers that can perform a DCSync.
It’s important to limit the amount of users/computers that can perform a DCSync but that will not affect the final detection. Controlling these privileges is beneficial and will make it more difficult for an adversary to compromise an account that can perform a DCSync.
Visibility into the attack
1. Which steps from the attack can we see within telemetry?
We’d start by looking at which events occur when there’s a DCSync. It’s not clearly apparent from the logs however the internet has the answer to at least get started.
Mitre: Detection of Unauthorized DCSync Operations via Replication API Abuse
Threat Hunter Playbook: Active Directory Replication
Per these sources it’s pretty clear that the event we need to start with is Event Code 4662.
Lets look in our lab environment to see what happens when a DCSync occurs then break down all details of the event. The Microsoft link and the few others posted above help to describe the event. Red team blogs also are very helpful when digging into the details of events and specific objects within AD.
Event Code 4662Section 1 Event:
Event Code 4662 — An operation was performed on an object.
ComputerName — where the event occurred, it is important to know which DC fulfilled the DCSync request.
Section 2 Subject:
The operations were performed by accounts with the privileges to do so which makes sense. That does not tell us however if the action was authorized.
Summary of accounts performing 4662 activity in the labSection 3 Object:
The object server is always DS per the Microsoft documentation. I suspect it stands for Domain Services.
Object type is the SchemaGUID for the DomainDNS class.
Object name is the objectGUID for the domain.
Object NameSection 4 Operation:
The type of access will be important. The Microsoft 4662 documentation lists the different access masks. The statement below also makes sense since we know DC replication is an Extended right.
Control Access MaskThen finally the access right we saw earlier is in the event! Below is a LDAP query you could run to grab them. These are critical to incorporate into the detection.
Extended RightsAs you have noticed nothing in this event shows the system where the DCSync request came from. This is why it’s important to break down every part of a log. There is however the Login ID which is used to map different windows events to the same session. What if we look within the analytics platform to find other events associated with that Login ID?
Associated 4624 Logon EventSo this log shows the network address the logon came from which is very interesting. Also remember that Logon IDs are unique to each host system so there could be collisions across many domain controllers.
2. Does this telemetry exist in your organization?
Lets recap what important artifacts we have collected so far.
- Event Code 4662 from Domain Controllers — shows a DCSync has occurred
- Event Code 4624 from Domain Controllers — correlated by the Logon ID it shows the source IP address of the DCSync request.
All of these events are within our lab and very likely available within large enterprises. Yay!
Is prevention possible?
In this case we cannot prevent this attack. There will always be accounts with replication privileges within an organization. These can be limited and guarded (and should be) however they do need to exist.
Endpoints need access to domain controllers so that opens the possibility for an attacker to compromise a system to access a domain controller. If we could lock a DC in a closet without network access it may be safe but also it wouldn’t be useful to the organization.
Isolate malicious behavior
At this point after digging into these events it may be very apparent how we plan on isolating malicious behavior from normal.
- Domain controllers sync between each other.
- A DCSync from an IP address that isn’t a domain controller would be a concern!
Let’s update our list of requirements for a detection.
- Event Code 4662 from Domain Controllers — shows a DCSync has occurred
- Event Code 4624 from Domain Controllers — correlated by the Logon ID/host it shows the source IP address of the DCSync request.
- List of the IP Addresses of all Domain Controllers per Domain
Document
Documentation is very important but that will double the size of this blog post so I have the luxury of skipping that here (but a good Detection Researcher does not!). Refer to the first post on a template that can be used. Our notes up until this point would be the majority of what is needed anyway.
Development
All of the details and requirements from the research phase will feed into the development phase which allows for a modular detection engineering process which enables flexibility in fast paced environments. Also, the developer does not need to be the same resource as the researcher since the skill sets for each are slightly different.
We have the 3 requirements from above so lets break the query into 3 parts. In my lab I use Splunk so if you use something else then you can likely translate this to your platform.
Event Code 4662
This is straight forward since we are looking for the 4662 event codes that apply to the fields we identified above.
Splunk query for 4662 Event CodeNOTE: The LIKE in the query looking for the rightsGuid in the entire Message field is not efficient. I’d recommend extracting the rightsGuid field from the event properly in Production.
Event Code 4624
This next step needs to be a bit fancier. We need to take all of the Logon_IDs from these 4662 events and look back through the events and correlate them to 4624 events. To do this in Splunk we need to use a sub-search.
Splunk query for 4662 correlated with 4624 Logon ID/HostDomain Controller IP Address List Lookup
There are many ways to grab a Domain controller list. I chose to use this neat ldapsearch app from Splunk. I can query LDAP for the configuration parameters for a Domain Controller. Then we will plug the output into a lookup to be used in the search logic for the detection.
DC Lookup ListLet’s first break down the LDAP query. I used this presentation for the DCShadow attack heavily. That presentation outlined research by Benjamin Delpy and Vincent Le Toux identifying core SPNs for a DC to have.
In addition to that the Domain Controllers reside within the Domain Controllers group which has the primaryGroupID of 516. As you can see above the LDAP query checks those parameters. This detection is not meant to discover a DCShadow attack so if a rogue DC is added to the domain this detection would not fire. I will add some notes about that at the end of this post.
LDAP returns the dNSHostName so we then instruct Splunk to query DNS for the client IP address as well.
That info is added to a lookup table dc.csv within Splunk. More details could be added to the lookup to make this more robust such as time added and time removed (DC is decommissioned).
Finally, this should be scheduled as a report that can run prior to the alert running. If the alert runs every hour on the hour then this report can run every hour at 55mins so the lookup has the most up to date data.
Detection Query including the DC IP Lookup
Now we’ve added the lookup and you can see on the right hand column the IP address is matching the DC hostname from the lookup.
Detection Query Filtering out known Domain Controllers — Remote DCSync Detection
All that’s left is to remove known DCs and the suspicious DCSyncs from my Win10 (192.168.1.139) system where I ran mimikatz from will remain.
PANIC!Final Thoughts
We’ve built a query that will identify Suspicious Remote DCSync events leveraging generally available logs within a large enterprise. There is still more that could be done to make this even better but I think this is a good walk through for applying a Research Mindset to discover innovative detections.
I had mentioned that to identify a Domain Controller I used documentation from a DCShadow Attack. This detection is not meant to detect a DCShadow Attack so does that mean this is all useless? NOPE! With this detection we’ve successfully raised the bar for an attacker to go unnoticed. Adversaries and red teams have tight timelines too and forcing them to fit more in makes it less likely they will succeed in their mission. And we can add the DCShadow attack to the Detection Research backlog to dig into next!
There are 2 other more rare but feasible scenarios (if an adversary gains access to a DC) that should be added to the backlog as well since at some point I have to end this post!
- Running a DCSync from the DC itself against itself
- Running a DCSync from the DC itself against a different DC.
Sources and Additional Reading
https://threathunterplaybook.com/library/windows/active_directory_replication.html
https://fintech.global/cybertechforum/wp-content/uploads/2020/11/ALSID-ACADEMY-EPI-8-DCShadow.pdf
https://learn.microsoft.com/en-us/windows/win32/adschema/c-domaindns
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4662
https://adsecurity.org/?p=3377
https://center-for-threat-informed-defense.github.io/summiting-the-pyramid/
https://attack.mitre.org/techniques/T1207/
https://attack.mitre.org/techniques/T1003/006/
https://happycamper84.medium.com/who-can-execute-dcsync-in-your-ad-environment-495f704eded0
https://evilsaint.com/article/dsquery.html
https://blog.joeware.net/2018/05/25/5824/
https://github.com/gentilkiwi/mimikatz
https://www.huntress.com/cybersecurity-101/topic/what-is-golden-ticket-attack
https://www.zeropointsecurity.co.uk/course/red-team-ops
https://tools.thehacker.recipes/mimikatz/modules/lsadump/dcsync
A Detection Researcher Mindset — DCSYNC T1003.006 was originally published in Detect FYI on Medium, where people are continuing the conversation by highlighting and responding to this story.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.
Article Link: https://detect.fyi/a-detection-researcher-mindset-dcsync-t1003-006-2532bddefbf5?source=rss----d5fd8f494f6a---4