Checking Status of Risky Items in Active Directory - Part 1

During my client assessments of Active Directory, I am 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).

Table Of Contents

• Critical/Protected Objects/Containers which are not visible to normal users.
• Key attributes associated with Domain Controllers, Privileged Users, Privileged Groups, and tier 1 objects such as PrimaryGroupID, UserAccountControl, ManagedBy, and other attributes
• Sensitive Objects that are modified/created.
• Objects which are defined as system critical objects.
• Relationship of normal users with Active Directory critical and system objects – Very Important
• Relationship of computer accounts with Active Directory critical and system objects
• Legacy authentication protocols and security descriptors.
• Ownership and Management of Active Directory Objects.
• Privileged Groups and Admins.

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.

Critical/Protected Objects/Containers which are not visible to normal users

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:

• Ensure AdminSDHolder object was not modified in last 30 days or recently.
• Ensure no “Full Control” or “Write” Permission on AdminSDHolder to “non-domain User” accounts.
• Ensure there are no orphaned Admins on the AdminSDHolder container.
• Ensure there are no excluded groups by SDProp process.
• Ensure Inheritance on AdminSDHolder is disabled.
• Ensure SDProp (Security Descriptor Propagator) Interval was not modified.

Ensure AdminSDHolder object was not modified in last 30 days

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.WhenChanged        

In 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.

Ensure no “Full Control” or “Write” Permission on AdminSDHolder to “Normal User” accounts.

When checking the permissions on the AdminSDHolder you’re going to make sure that the user:

• Is part of AdminCount=1 set
• Is member of privileged groups
• Is maintained as a designated administrator in operational procedures.

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 or query user accounts with "GenericAll" or "Write" permissions.

ANSSI has a test case created for permissions on AdminSDHolder:

• Framework: ANSSI
• ANSSI IDs: vuln1_permissions_adminsdholder?and vuln2_permissions_adminsdholder?
• ANSSI Test: Dangerous permissions on the adminSDHolder object
• Severity: Critical

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.

Ensure there are no orphaned Admins on the AdminSDHolder container.

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        

Ensure Inheritance on AdminSDHolder is disabled.

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.

Ensure there are no excluded groups by AdminSDHolder and SDProp process.

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:

• Framework: MITRE ATT&CK
• Tactic: Name: Persistence
• ID: TA0003
• Reference: https://attack.mitre.org/tactics/TA0003/

However, it is advised that we omit the following groups from the SDProp process during the initial deployment of the Active Directory domain. In my client engagements and new installations, I omit the following groups:

• Account Operators
• Server Operators
• Print Operators
• Backup Operators

Ensure SDProp Interval was not modified.

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.

Checking AdminSDHolder status Items using SmartProfiler – Active Directory Security Console for all Active Directory domains

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 35 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.

It is possible to create multiple scheduling profiles, and each scheduling profile can have one or more AD Tests that need to be run as well as an email template for use when sending notifications.

If you need help in setting up / executing SmartProfiler for Active Directory Security Console, please DM me.

In Part 2, we will focus on “Sensitive Objects Modification/Creation (PrimaryGroupIDs and GPO Modifications are growing threat to Active Directory”.

Thanks for reading.