Silicon Shecky

Have you every had a pentest or red team report that talks about DCSync? How much of it has been hair pulling? What is DCSync and what is the significance of it?

When securing Active Directory, there are a ton of moving parts, and even more rights available, especially when you add in extended rights. There is a set though, that can get assigned, which are used for synchronizing all of Active Directory. Two of them work together and allow for the copying of secret information, such as password hashes. This right is important when do certain types of sign on using AD credentials, such as Sharepoint, or synchronizing with Azure. It also allows for Domain Controllers to synchronize all the domain information between them. The rights, “Replicating Domain Changes” and “Replicating Domain Changes All”, have that much power, but to be able to get a full sync with password hashes you need both rights. The idea is to keep these rights, especially the All right, to a bare minimum of user/services accounts. This is important to prevent Mimikatz’s DCSync attack, which essentially makes a copy of all the AD information so one can crack passwords offline.

One would think this should not be a big deal, but it can get out of control very quickly. For starters, the only place that you can directly see these rights is at the root of the domain when using ADUC (Active Directory Users and Computers). Even when propagated down you cannot just see it as part of the advanced security section of the properties, to remove it. Second, you can get it by being granted full control, or part of a group that is granted full control, of a group that either has the right granted directly from the root, or from a group that already has the rights propagated down to it. You can see this sort of delegation of rights by using a tool such as BloodhoundAD to map out the relationships. Another way one can get this right is through being assigned it through delegation at the root of the domain. The end result of all of this is that, there should be little to no reason for normal, or even admin users to have the Replicating Domain Changes All right. Certain services account that are not allowed interactive logon may need it, such as a service account to replicate to Azure as mentioned before. Bottom line, this right should not be given out unless absolutely necessary.

So we have a tool in BloodhoundAD that can show us what accounts and groups have this right. It shows if they are getting it through a security assignment such as Full Control, or if it is because of being a member of a group with the right. The fear on removing the right is knowing if it will break anything. How do we know what accounts are actually using said right? Windows Logs come in handy on this instance, as long as you are getting them from Domain Controllers.

Finding the search string happened for me while learning about information I was getting from a search I found in the Blue Team Field Manual, which gives some nice searches using Powershell for event logs. The one that started everything for me was their Domain Service Access – Audit Directory Service Access. More specifically, Event ID 4662is the one to search for. From there, I started looking at what Access Masks meant what, finding that Access Mask 0x100  is the Control Access property. The actual rights that it uses are given in GUID format. Some searching on the GUIDs gave me the following that relate to the extended rights “Replicating Directory Changes” GUID:{19195a5b\-6da0\-11d0\-afd3\-00c04fd930c9\}  and “Replicating Directory Changes All” GUID:{1131f6aa\-9c07\-11d1\-f79f\-00c04fc2dcd2} . The big thing is that it shows Computer Accounts, such as Domain Controllers, using the rights to synchronize between themselves, and any user accounts that are actually using the rights, such as an Azure service account, that is using it. Filtering out the computer accounts will show what accounts are actually doing any synchronization. This allows for one to ask account owners why they might be synchronizing the domain with said account. Through that, one can easily get a good idea of what will happen if the Replicating Directory Changes All right is removed, and reassign accounts that actually need the right to have it directly from the root of the domain, thereby allowing removal the right from groups also. In Graylog the search if you are using NXLog into a GELF input to parse the Event Log information properly the search would like like this:

EventID:4662 AND AccessMask:0x100 AND ObjectType:"%\{19195a5b\-6da0\-11d0\-afd3\-00c04fd930c9\}" AND "{1131f6aa\-9c07\-11d1\-f79f\-00c04fc2dcd2}" AND NOT SubjectUserName:*$

Mind you that using *$ requires in Graylog that you have configured Graylog to accept wildcards as the start of a search string. If that is not configured you should be able to put the first character of your naming scheme then the wildcard and $. In Splunk the search would be similar, making sure you use the proper index and field name for EventIDs in Splunk.

This gives a basic way to search for an attacker attempting to make a copy of the domain. You could potentially remove the GUID for Replicating Domain Changes ALL from the search and see anyone trying to copy all the non-secret information from the domain, again a way for attachers to do searches through the domain offline, and thereby making less noise.

As always, if I have made any errors in this, feel free to let me know, and feel free to discuss all of this