Advanced threat hunting within Active Directory Domain Services - Knowledge is power!

MVP

 

Dear Microsoft Active Directory friends,

 

What is this article about? Showing attacks, compromising domain controllers or even introducing and showing hacking tools? NO. It is about giving you a jump start on how to gather targeted information about attacks and threats in your Active Directory. Is this also a complete and accomplished listing, again no. But my goal is to give you a solid foundation to build on.

 

Let's start with the different event ID's from the event viewer. This assumes, of course, that extended logging has been configured on your domain controllers. If not, this should definitely be done immediately.

 

Event logs are best examined in a SIEM (Security Information and Event Management). Such a tool is not always available, which makes finding information somewhat more difficult.

AD_sync.JPG

 

Event ID 4769
Search for attacks from user accounts used as service accounts (search for service accounts - with a login on a client system - IP address).
https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4769

 

Search for computer with "Trusted for Delegation":

Get-ADComputer -Filter {TrustedforDelegation -eq $true} (Domaincontroller's are not interesting)

 

Best practices:

There's no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts. It's only relevant on domain controllers and stand-alone devices

https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/enable...

 

Event ID 4624
Successful logins (search for users/service accounts that have logged in to systems that are TrustedforDelegation).
https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4624

 

In ADUC (Active Directory Users and Computers) search in the properties of a user account in the Account tab, for "Account is sensitive and cannot be delegated". Not even the administrator has this configured by default. Sensitive accounts should be configured with this option.

 

Event ID 4624 Type 3 - Network Logon (searching for logons from remote systems)

 

Event ID 4611 (often generated by mimikatz) A trusted logon process has been registered with the local System authority.
https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4611

 

Event ID 4673 (often generated by mimikatz) When the tool tries to assign itself missing permissions.
https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4673

 

Event ID 4675 - SIDs were filtered
https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4675

 

Note: If you have a SIEM at your disposal, just search for "mimikatz or rebeus" maybe the names of the tools were not changed because the attacker was too lazy.

 

Note: Install Sysinternals "sysmon" for detailed information
https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon

 

Protected Accounts and Groups in Active Directory

 

Adminsdholder:
The purpose of the AdminSDHolder object is to provide "template" permissions for the protected accounts and groups in the domain. AdminSDHolder is automatically created as an object in the System container of every Active Directory domain. Its path is: CN=AdminSDHolder,CN=System,DC=<domain_component>,DC=<domain_component>?.
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendi...

 

SDProp:
SDProp is a process that runs every 60 minutes (by default) on the domain controller that holds the domain's PDC Emulator (PDCE). SDProp compares the permissions on the domain's AdminSDHolder object with the permissions on the protected accounts and groups in the domain. If the permissions on any of the protected accounts and groups do not match the permissions on the AdminSDHolder object, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object.
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendi...

 

Securable objects use an access mask format in which the four high-order bits specify generic access rights. Each type of securable object maps these bits to a set of its standard and object-specific access rights.

GenericAll - Full rights to the object (add users to a group or reset user's password)
https://learn.microsoft.com/en-us/windows/win32/secauthz/generic-access-rights

 

Let's let pictures do the talking at this point. Take a closer look at the "Dom" user account. This account has no elevated privileges, BUT a "GenericAll" connection.

AD_Bloodhound_01.JPGAD_Bloodhound_02.JPGAD_Bloodhound_03.JPG

 

Now please take a close look at the following pictures.

 

Dom_01.JPGDom_01a.JPGDom_02.JPGDom_03.JPGDom_04.JPG

 

net group "domain admins" dom /add /domain

 

Add-ADGroupMember -Identity "domain admins" -Members dom

 

Using powerview:
Get-ObjectAcl -SamAccountName delegate -ResolveGUIDs | ? {$_.ActiveDirectoryRights -eq "GenericAll"}

 

Event ID 5136 (However, domain controllers must be configured to record this event.)

A directory service object was modified
https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5136

 

In ADUC and ADSI Edit under System, examine the AdminSDHolder object. If necessary, you should restore the permissions. The user "Dom" could add himself to the group "Domain Admins" because the security properties of AdminSDHolder were manipulated.

 

Another topic is group policies. Examine the group policies in particular the permissions of the group policies.

 

Get-GPO -All

 

Get-GPPermission „nameofgpo“ -All

 

How to give users access to Group Policy Objects:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/give-users-access-group-p...

 

The next topic is SID History. Security assessment: Unsecure SID History attributes

 

SID History:
Get-ADUser -Filter * -Properties cn,memberof,sidhistory

 

Get-ADUser -Properties sidhistory,memberof -Filter {sidhistory -like '*'}

 

https://learn.microsoft.com/en-us/defender-for-identity/security-assessment-unsecure-sid-history-att...

 

DCSync is a legitimate Active Directory feature that domain controllers only use for replicating changes, but illegitimate security principals can also use it.

 

Event ID 4662 An operation was performed on an object.
https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662

 

Domain controller synchronization, looking for the following GUIDs:
("1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" or "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" or "89e95b76-444d-4c62-991a-0facbeda640c")

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/1522b774-6464-41a3-87a5-1e5633...

 

Do you know all your domain controllers? If yes, no synchronization should have been started that does not originate from a domain controller. The synchronization should be executed only between the DC's you know. (The exception may be Azure AD Connect - this service generates similar events). Look for a synchronization that was not started by a domain controller.

 

I hope that this information is helpful to you and that you have received a good "little" foundation. This is certainly not an exhaustive list. But I still hope that this information is helpful for you.

 

Thank you for taking the time to read the article.

 

Happy Hunting, Tom Wechsler

 

P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechsler

 

0 Replies