ADPRIV-023: krbtgt Account Exposure Assessment
- Platform
- Active Directory
- Category
- AD Privileged Account Security
- Severity
- Critical
- Zero Trust pillar
- Identity (weight 2)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
The check binds to the default naming context and resolves the krbtgt object via LDAP filter (&(objectClass=user)(sAMAccountName=krbtgt)) plus every read-only DC partner key via (sAMAccountName=krbtgt_*). For each result it captures the full attribute set [sAMAccountName, distinguishedName, userAccountControl, msDS-SupportedEncryptionTypes, msDS-KeyVersionNumber, servicePrincipalName, pwdLastSet, lastLogonTimestamp, memberOf, msDS-AllowedToDelegateTo, msDS-AllowedToActOnBehalfOfOtherIdentity, description, whenChanged] and tests four conditions. First, encryption posture: msDS-SupportedEncryptionTypes must equal 0x18 (24 = AES128 + AES256) or 0x10 (16 = AES256 only); any value that permits DES (0x1, 0x2) or RC4_HMAC_MD5 (0x4) is flagged because RC4 golden tickets remain forgeable from any historic NTHash extract. Second, delegation: the TRUSTED_FOR_DELEGATION (0x80000) and TRUSTED_TO_AUTH_FOR_DELEGATION (0x1000000) bits in userAccountControl must be clear, and msDS-AllowedToDelegateTo and msDS-AllowedToActOnBehalfOfOtherIdentity must be null. Third, SPN surface: servicePrincipalName must contain only the well-known default kadmin/changepw entry (and on RODC krbtgt accounts the per-RODC kadmin/changepw and the RODC-bound TGT SPN); any additional SPN is treated as either misconfiguration or a persistence indicator. Fourth, key freshness: pwdLastSet older than 180 days is surfaced as advisory and older than 365 days as a hard finding, because Microsoft documents the krbtgt password history value as 2, which means two consecutive resets (spaced at least 10 hours apart for replication) are required to evict a stolen hash from the history and invalidate previously forged TGTs.
Why it matters
The krbtgt hash is the single most valuable secret in an Active Directory forest. With it, an attacker generates a Golden Ticket: a self-signed TGT with arbitrary group membership (typically Domain Admins, Enterprise Admins, Schema Admins, plus SID History for cross-domain reach), an arbitrary lifetime up to ten years, and arbitrary user identity including non-existent accounts. The forged TGT is mathematically valid because it carries the correct PAC signatures generated with the genuine krbtgt key. Domain controllers will accept it for the lifetime of the key, which means until the krbtgt password is reset twice. If msDS-SupportedEncryptionTypes still permits RC4, any historic extraction of the krbtgt hash (from an old DC backup, an unrotated DSRM snapshot, an NTDS.dit copy, an exposed VM disk, or a prior breach) remains weaponizable forever, because RC4 keys are derived directly from the NT hash and do not change unless the password changes. Delegation on krbtgt is anomalous and indicates either a misconfiguration that hands TGT issuance authority to other principals or a deliberate persistence implant. Extra SPNs on krbtgt expose the account to Kerberoasting (TGS-REQ for any principal with an SPN), and although the auto-generated krbtgt password is 128 characters of random data, the presence of an unexpected SPN is itself a strong tampering signal. A single missed reset cycle after a confirmed DC compromise leaves a usable golden-ticket path open indefinitely; this is the canonical failure mode behind nearly every "we thought we evicted them" incident response postmortem.
Attack path
Step 1: Domain controller compromise. The attacker reaches SYSTEM on any domain controller via an unpatched CVE (PrintNightmare, Zerologon, NoPac, ProxyShell pivoting to a DC), a stolen Domain Admin credential, a backup file with NTDS.dit, or an SCCM / Veeam relay path. The bar for this step is lower than commonly assumed because NTDS.dit copies live on backup tapes, in cloud snapshots, and in DR runbooks across many environments. Step 2: Hash extraction. The attacker pulls the krbtgt NT hash via DCSync (mimikatz lsadump::dcsync /user:krbtgt, Impacket secretsdump.py -just-dc-user krbtgt CONTOSO/admin@dc01), via direct NTDS.dit parse (ntdsutil, secretsdump.py -ntds NTDS.dit -system SYSTEM LOCAL), or via a Volume Shadow Copy snapshot of the SYSTEM hive plus ntds.dit. The attack maps to MITRE T1003.006 (OS Credential Dumping: DCSync). Step 3: Forgery. The attacker creates a Golden Ticket: mimikatz kerberos::golden /user:Administrator /domain:contoso.local /sid:S-1-5-21-... /krbtgt:<NTHash> /id:500 /groups:512,513,518,519,520 /ptt, or Impacket ticketer.py -nthash <hash> -domain-sid <sid> -domain contoso.local Administrator. The ticket is injected into the current logon session and presented to any DC as a normal TGT. The KDC does not contact any other system to validate it because the PAC signatures verify with the genuine krbtgt key the KDC itself holds. Step 4: Persistence and lateral movement. The attacker uses the forged TGT to perform any action allowed by the embedded group membership: DCSync of every account hash, creation of new Domain Admins, modification of Group Policy, AdminSDHolder ACL implants, DSRM admin sync, certificate template manipulation, and direct RDP / WinRM / SMB to any system. Because the TGT is signed by krbtgt, it bypasses MFA, account lockout, password expiry, and the entire interactive logon pipeline. Step 5: Long-tail. The forged ticket lifetime is attacker-chosen. The default mimikatz lifetime is ten years. Even after the responder rotates Domain Admin passwords, reimages DCs, and rebuilds workstations, the golden ticket remains valid until krbtgt is reset twice. Many organizations reset krbtgt once and consider it resolved, leaving the history slot open and the prior hash usable for the next replication cycle. Step 6: Adjacent abuse. If msDS-SupportedEncryptionTypes on krbtgt permits RC4, even hashes extracted years earlier remain valid. If delegation flags are set on krbtgt (rare but observed in tampered environments), the attacker can configure constrained or resource-based delegation paths that issue TGTs to arbitrary services without ever needing the hash again. Extra SPNs on krbtgt are abused as Kerberoasting targets and as PAC injection markers.
How Guerrilla assesses it
Guerrilla executes an LDAP search against the default naming context with filter (&(objectClass=user)(|(sAMAccountName=krbtgt)(sAMAccountName=krbtgt_*))) and the attribute set [sAMAccountName, distinguishedName, objectSid, userAccountControl, msDS-SupportedEncryptionTypes, msDS-KeyVersionNumber, servicePrincipalName, pwdLastSet, lastLogonTimestamp, memberOf, msDS-AllowedToDelegateTo, msDS-AllowedToActOnBehalfOfOtherIdentity, nTSecurityDescriptor, whenChanged, description]. msDS-SupportedEncryptionTypes is decoded against the SupportedEncryptionTypes bit table (0x1 DES_CBC_CRC, 0x2 DES_CBC_MD5, 0x4 RC4_HMAC_MD5, 0x8 AES128_CTS_HMAC_SHA1_96, 0x10 AES256_CTS_HMAC_SHA1_96, 0x20 FAST, 0x40 CompoundIdentity, 0x80 ClaimsSupported, 0x200 ResourceSIDCompression) and any value that omits both AES bits or that includes either DES bit or the RC4 bit is flagged. userAccountControl is decoded bit-wise and the TRUSTED_FOR_DELEGATION (0x80000) and TRUSTED_TO_AUTH_FOR_DELEGATION (0x1000000) bits are tested. servicePrincipalName is diff-checked against the expected baseline (kadmin/changepw on the primary krbtgt; per-RODC kadmin/changepw and the RODC TGT SPN on each krbtgt_<number>); any addition is surfaced. pwdLastSet is converted from Windows FileTime to days, with thresholds at 180 and 365 days, and msDS-KeyVersionNumber is captured to correlate against suspected DCSync events. The check also reads the nTSecurityDescriptor to confirm that only Domain Controllers and the built-in privileged groups hold any write or replication-extended rights on the object, which detects ACL implants. For runtime detection Guerrilla emits paired recommendations to alert on Event ID 4769 where Service Name = krbtgt and Ticket Encryption Type = 0x17 (RC4 golden ticket marker), Event ID 4624 logons that reference a TGT older than the configured Maximum Lifetime for User Ticket (default 10 hours), and Event ID 4662 with Properties containing the DS-Replication-Get-Changes-All GUID (1131f6ad-9c07-11d1-f79f-00c04fc2dcd2) sourced from any non-DC principal.
Recommended value
krbtgt account configured with AES256 encryption only, no delegation, and no additional SPNs beyond the default kadmin/changepw
Remediation
Review the krbtgt account properties including msDS-SupportedEncryptionTypes, delegation settings, and SPNs. Ensure AES256 is the primary encryption type. Verify no delegation flags are set. Check for unexpected SPNs that could indicate compromise or misconfiguration
Fixture-proven verdicts
Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.
| Scenario | Expected verdict |
|---|---|
| clean | PASS |
| known-bad | WARN |
| throttled | Not Assessed |
Framework mappings
- NIST SP 800-53
- SC-12, SC-13
- ANSSI
- R39
- CIS AD Benchmark
- 4.8.2
- MITRE ATT&CK
- T1558.001, T1550.003