During our client assessments of Active Directory, we are frequently asked to examine potentially risky elements within the Active Directory and provide their corresponding status. Initially, I was hesitant to address this request since Microsoft does not provide a comprehensive list of risky items on their website. When it comes to assessing the security of Active Directory, two crucial aspects demand attention: the possibility of an ongoing attack and the likelihood of a previous compromise. When evaluating the status of risky items in Active Directory, it is essential to consider both perspectives: investigating for signs of a potential compromise and determining if an active attack is underway. Drawing from my experience working with Active Directory and referencing both ANSSI and MITRE frameworks, I have managed to compile a list of risky items as listed below (included in free version of SmartProfiler-Active Directory Security Console). “Checking Status of Risky Items in Active Directory – Part 1” provides a series of articles written by our Active Directory team.
In the initial segment of this article series, we will explain ”Critical/Protected Objects/Containers which are not visible to normal users” and explain the reasons behind safeguarding these specialized containers.
In Active Directory, certain objects remain hidden from regular users but can be recognized and examined by Active Directory experts or potential attackers. Though there are many objects/containers, but I would like to focus on AdminSDHolder container which directly impacts the privileged groups and admin accounts. AdminSDHolder container is intentionally not visible to normal users as non-domain users typically do not interact with the AdminSDHolder container. This container serves as a critical component within Active Directory as it contains essential permissions for privileged accounts and groups.
Every domain in Active Directory possesses an AdminSDHolder container, which signifies to the system that the permissions assigned to the AdminSDHolder object hold authority over the entire domain. The default permissions assigned to the AdminSDHolder object are designed to safeguard the domain from unauthorized access and malicious intruders. If any alterations are detected on the AdminSDHolder container’s permissions, it indicates that either a compromise has already occurred, or an attack is underway. When inspecting AdminSDHolder container you must inspect following aspects:
Active Directory won’t change the AdminSDHolder permissions, even if a new domain controller is implemented. It is so because a new domain controller that has been implemented in the same domain doesn’t need anything to be added to the AdminSDHolder container. Execute the PowerShell commands below to see if the AdminSDHolder object has been modified or not in the last 30 days:
$ThisDomain = “DynamicPacks.net”
$DomainDN = (Get-ADDomain -Server $ThisDomain).SystemsContainer
$AdminSDDN = "CN=AdminSDHolder," + $DomainDN
$AllPerms = Get-ADObject -Identity "$AdminSDDN" -Server $ThisDomain -Properties WhenChanged, Name
$AllPerms.WhenChangedIn the provided output, verify the most recent modification date of the AdminSDHolder container. If the reported date aligns with the initial deployment of the Active Directory domain, then everything is in order. However, if the reported date does not correspond to the Active Directory domain deployment, it is crucial to proceed with checking the next item on the list. If you see AdminSDHolder container was modified, then an attack has already taken place or is being attacked.
Note: Note that above PowerShell code is for a single domain. You need to check in all Active Directory domains to ensure AdminSDHolder has not been modified.
When checking the permissions on the AdminSDHolder you’re going to make sure that the user:
The user you checked on the AdminSDHolder object is a Domain Admin if it doesn’t match any of the above criteria.
IMPORTANT: The permissions assigned to the AdminSDHolder container can always be accessed by an attacker (an authenticated user). Therefore, an attacker can query permissions using a non-domain user account if you forgot to fix permissions on the AdminSDHolder container.
To get the list of permissions assigned on AdminSDHolder object you can run below PowerShell script against an Active Directory domain:
$ThisDomain = "DynamicPacks.net"
$DomainDN = (Get-ADDomain -Server $ThisDomain).SystemsContainer
$AdminSDDN = "CN=AdminSDHolder," + $DomainDN
$AllPerm = Get-ADObject -Identity "$AdminSDDN" -Server $ThisDomain | %{ (Get-ACL "AD:$($_.distinguishedname)").access }
foreach ($Item in $AllPerm)
{
$AccountName = $Item.IdentityReference
$CurPerm = $Item.ActiveDirectoryRights
IF ($AccountName -match "SYSTEM")
{
}
else
{
IF ($CurPerm -eq "GenericAll" -or $CurPerm -match "Write")
{
$STR = $ThisDomain + "," + $AccountName + ", GenericAll"
$STR
}
}
}Note: An Active Directory forest’s domains aren’t all checked by the script above. You must examine each domain and obtain the AdminSDHolder permissions from each Active Directory domain.
If you remove a user from a protected group, AdminCount=1 is still set for that user. The user won’t get inherited permissions because AdminSDHolder’s default inheritance setting is disabled. The term “Orphaned Admins or Orphaned AdminSDHolder Objects” refers to users with AdminCount=1 who have been removed from protected groups. There isn’t an automatic procedure to correct such objects in Active Directory. Those items must be manually removed from the AdminSDHolder container.
Note: Keep in mind that a user account with AdminCount=1 cannot have its attributes changed by a regular user or a non-domain admin. There may be a procedure in place in large Active Directory environments that calls for the use of a service account to modify certain user attributes. A service account cannot change the attributes for users with AdminCount set to 1 because it is not fundamentally a domain admin.
The members of privileged groups must be examined in order to find such objects, and the permissions on the AdminSDHolder container must then be examined. Use the commands below to find all users with AdminCount=1 set:
$ThisDomain = “DynamicPacks.net”
Get-ADUser -LDAPFilter "(adminCount=1)" -Server $ThisDomain
Get-ADGroup -LDAPFilter "(adminCount=1)" -Server $ThisDomain
Protected groups and accounts do not inherit permissions from their new parent objects since permissions inheritance is disallowed for these objects, regardless of where they are relocated within the directory. Because inheritance is by default disabled on the AdminSDHolder object, changes to the permissions of the parent objects will not affect AdminSDHolder’s permissions. Make that the AdminSDHolder container’s inheritance is turned off.
Make that the SDProp (Security Descriptor Propagator) procedure never excludes any groups when it runs periodically. The AdminSDHolder container’s defined permissions are compared to those on protected objects by the SDProp. The protected accounts and groups’ permissions are reset to match those of the AdminSDHolder container if any of the protected accounts and groups’ permissions do not match. ACLs, Owner, inheritance, and other rights on the excluded groups will not change because inheritance on AdminSDHolder is by default disabled and SDProp procedure won’t affect the excluded groups. Exclusions can be abused by attackers to keep long-term access to privileged groups. For this particular situation, MITRE specifies a strategy called Persistence.
However, it is advised that we omit the following groups from the SDProp process during the initial deployment of the Active Directory domain. In our client engagements and new installations, we omit the following groups:
The primary responsibility of SDProp is to retrieve permissions from protected groups and replace them with those specified on the AdminSDHolder container. Every 60 minutes, the domain controller with the PDC Emulator role executes a background process. To ensure that the process runs more quickly and resets the rights on the AdminSDHolder container, you would want to reduce the default frequency. However, doing so is not advised in in large Active Directory environments due to potential LSASS performance issues. By going to the following registry branch and altering/creating the “AdminSDProtectFrequency” registry key, you could alter the interval.
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters Keep in mind that the above registry entry is not there by default. Deleting the AdminSDProtectFrequency key will make SDProp restore to the 60-minute interval.
All of the above AdminSDHolder container elements, as well as other Active Directory Risky items and their status, can be checked using the Free version of SmartProfiler for Active Directory Security Console. Each Active Directory domain needs to check more than 28 risky items. You may set up the scheduler that comes with SmartProfiler for Active Directory Security Console to run every day or every hour, and can configure scheduling profiles to receive an email with a report on the status of each test.
Note that with its robust scheduler, SmartProfiler – Active Directory Security Console can run any test as part of a scheduling profile and then notify you via email if the test’s severity is critical, high, or user-defined.
SmartProfiler can quickly perform a health and security assessment of multiple Active Directory forests and generate an actionable report. Learn AD checks suggested by ANSSI and MITRE. Checking Status of Risky Items in Active Directory as part of Active Directory Security Assessment is required for all Active Directory environments. SmartProfiler for Active Directory is capable of checking status of all risky items.
Try SmartProfiler, a unified tool to help with security evaluation across many Microsoft technologies.