How to Tell if Active Directory is Compromised

eSecurity Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Active Directory is one of the most critically important IT assets and a frequent target of hackers, so securing it is a top priority for IT and security teams. And part of that job is checking to make sure that Active Directory hasn’t been compromised.

Between Active Directory for Windows and Azure, Microsoft dominates the market for identity and access management (IAM) tools with a greater than 50% market share, including about 95% of the Fortune 1000, so there are few targets for hackers that deliver richer results.

Here we’ll look at how to check several critical Active Directory components for signs of compromise, important steps to add to your Active Directory security best practices.

See the Top Active Directory Security Tools

Looking to improve AD compromise detection? This article’s sponsor, Semperis, developed Purple Knight and Forest Druid to discover indicators of exposure and indicators of compromise in AD, Azure AD/Entra ID, Okta, and the tier 0 perimeter. Learn how these free tools make the whole audit easier!

Looking for Signs of an Attacker

Threat actors with the savvy to reach your Active Directory environment may also be savvy enough to do so without leaving any evidence, making it impossible to determine whether Active Directory was compromised.

An attacker could, for instance, join the Domain Admins group, engage in hacking activities, and then leave the group. If monitoring is enabled, you can check the membership of privileged groups by monitoring them. If you discover a member who belongs to a privileged group but is not on the list of designated admins, you can either remove the admin or investigate how that user came to be a member of the privileged group.

Much depends on the attacker’s speed and ability. It is possible for an attacker to employ attack strategies that would prevent any events from being recorded in the event logs. To look for signs of an attack, you can’t keep checking the event logs on every domain-joined computer or domain controller. Checking the status of crucial Active Directory components should be the first step in your strategy for determining whether or not Active Directory has been compromised.

Note that adversaries will try to attack Active Directory components that are not easily known and touched by Active Directory administrators. You must verify that each of these components is in its default state and determine whether any of them have been changed from that state. Despite the fact that there are a lot of components you should examine, this article only focuses on the “critical” ones. We will examine AdminSDHolder, Default Group Policy Objects, PrimaryGroupIDs, and Domain Controllers. Although the list in this article isn’t sufficient to determine whether your Active Directory has been compromised or not, the items mentioned above are typical things that an attacker would try to touch in order to access Active Directory.

AdminSDHolder Object and Privileged Accounts

Every Active Directory domain contains a unique container called AdminSDHolder under the System container. When an Active Directory domain’s first domain controller is deployed, the AdminSDHolder container is also created. Maintaining permissions that will be used by privileged accounts is the responsibility of the AdminSDHolder container.

The SDProp process copies the permissions from the AdminSDHolder container to all the privileged accounts after verifying the permissions that have been applied to the container. An ordinary user won’t interact with the AdminSDHolder object. However, an attacker who has enough privileges can change the permissions set for AdminSDHolder and gain access to Active Directory.

To check whether the AdminSDHolder container was modified by someone you can check its “WhenChanged” attribute by going to the Attribute Editor as shown in the screenshot below:

The AdminSDHolder container was created on 3/23/2023 (when the domain controller was deployed) and modified on 5/28/2023, as seen in the screenshot above. When someone modified it, they most likely added permissions to the Security Tab, which you can check and then remove if they are no longer required. Administrators do not need to touch the AdminSDHolder object after the Active Directory domain has been deployed.

Group Policy Objects: A Major Target for Hackers

You should be aware that attackers now primarily target GPO (Group Policy Objects). GPO is a powerful Active Directory object. Because GPO has so many settings, once a hacker has access to it, he or she can change them and apply them to the target computer or run a malicious code via a scheduled task on the target computers. Your target computers could be users’ accounts, domain controllers, or computer accounts.

Note that Active Directory implements two default Group Policy Objects: Default Domain Policy and Default Domain Controllers Policy. These two GPOs are untouched after deployments except Default Domain Policy. Your company’s password policy requirements may require you to modify the Account Policies in the Default Domain Policy, but that change will also be made permanently.

Typically, you will create a new GPO if you want to apply organization-specific or security settings to users and computer accounts in your environment. By visiting Attribute Editor or by using the PowerShell command below, you can always check the modification time for both the default domain policy and the default domain controllers policy. This PowerShell command will list all GPOs in the domain and their modification time:

• $AllGPOs = Get-GPO -All -Server $ThisDomain | Select-Object DisplayName, ModificationTime

• $AllGPOs

If the Active Directory deployment date and the modification time for the default domain policy and default domain controller policy differ, someone may have altered these GPOs to gain access to Active Directory.

PrimaryGroupID: An Easier Target

These days, the PrimaryGroupID attack is increasingly common because it requires less work before an attacker can take over Active Directory.

All Active Directory user accounts are initially assigned to the “Domain Users” default security group, which becomes the user’s PrimaryGroupID. The PrimaryGroupIDs for the user accounts are 513, the PrimaryGroupIDs for the computer accounts are 515, and the PrimaryGroupID for the domain controller is 516.

A user’s or computer’s PrimaryGroupID can be changed by an attacker, who can then change Active Directory’s default behavior. For instance, altering a user’s PrimaryGroupID so that they belong to the Domain Admins group would grant the attacker privileged access to the Active Directory.

You must use a PowerShell script to check all user, computer, and domain controller accounts to make sure their PrimaryGroupIDs haven’t been changed. If you notice any changes, it means that someone attempted to alter the objects’ default membership in order to access Active Directory.

Domain Controllers and Their Default Location

Once implemented, domain controllers will continue to be located in their default location, “OU=Domain Controllers, DC=Domain>, DC=local>”.

Due to its default location in Active Directory, the domain controller is guaranteed to receive the group policy settings from the Default Domain Controllers Group Policy, which are intended specifically for protecting domain controllers.

Domain controllers will not receive those settings if they are moved from their default locations; instead, they may receive settings that are coming from a different Group Policy Object. For example, if they have the right permissions, an attacker could transfer one or more domain controllers to a different organizational unit with a different GPO applied to it, and that GPO could contain a scheduled task that would execute malicious code. You should always run a quick PowerShell script or make use of the security assessment tools to verify that each domain controller is located in their default organizational unit.

Here’s a small PowerShell script that can help you check the location of all domain controllers in an Active Directory forest. The script gets all domain controllers from the Active Directory forest and then checks their computer account location one by one in Active Directory. The result will be displayed on the screen if any of the domain controllers is not located in its default organizational unit.

$ComputersList = "C:\Temp\DCList.TXT"
Remove-Item $ComputersList -ErrorAction SilentlyContinue
$R = (Get-ADForest).Domains | % { Get-ADDomainController -Discover -DomainName $_ } | % { Get-ADDomainController -server $_.Name -filter * } | Select HostName
foreach ($Item in $R)
{
   $ThisDC = $Item.HostName
   Add-Content $ComputersList $ThisDC
}
Foreach ($ComputerItem in Get-Content "$ComputersList")
{
   $NameOne, $NameTwo = $ComputerItem.Split(".")
   $Error.Clear()
   $RNow = Get-ADComputer $NameOne -Server $ComputerItem
   $DCName = $RNow.DistinguishedName
   $CurLocName = $DCName
   $RemovedComma = $CurLocName.replace(",", " ")
   $DCT1, $DCT2, $DCT3 = $DCName.split(",")
   IF ($DCT2 -eq "OU=Domain Controllers")
   {
   }
   else
      {
         Write-Host "WARNING: Domain Controller is not located in its default OU"
      }
}

Bottom Line: Securing Active Directory from Hackers

Checking the status of critical Active Directory components to look for signs of a compromise should be a regular best practice for admins. We discussed the default location of the computer account for the domain controller, the AdminSDHolder container, Default Group Policy Objects, and PrimaryGroupID, along with techniques for detecting compromise, but there are additional components and Active Directory best practices that we’ll cover in future articles.

Also read:

• Cybersecurity Agencies Release Guidance for PowerShell Security
• Living Off the Land Attacks: LOTL Definition & Prevention