ADKERB-009: Kerberos Encryption Types
- Platform
- Active Directory
- Category
- AD Kerberos Security
- Severity
- High
- Zero Trust pillar
- Identity (weight 3)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
The check performs four parallel evaluations. First, it reads the registry value HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes on every domain controller, which is populated by the GPO "Network security: Configure encryption types allowed for Kerberos" (Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options). The expected bitmask is 0x18 (AES128_HMAC_SHA1 0x08 + AES256_HMAC_SHA1 0x10) plus 0x20 (Future encryption types). Values that retain 0x04 (RC4_HMAC_MD5), 0x01 (DES_CBC_CRC), or 0x02 (DES_CBC_MD5) are flagged. Second, it queries every user and computer object for msDS-SupportedEncryptionTypes and surfaces any account whose effective mask permits RC4 or DES. Service accounts with the attribute unset or set to 0 inherit the domain default and are evaluated against the DC registry value. Third, it enumerates trustedDomain objects under CN=System,DC=<domain> and reads msDS-SupportedEncryptionTypes plus the TRUST_ATTRIBUTE flags; trusts that have not been re-keyed with AES (TRUST_ATTRIBUTE_USES_AES_KEYS bit set and msDS-SupportedEncryptionTypes including 0x18) are flagged. Fourth, it reads the domain root (DC=<domain>) object for msDS-SupportedEncryptionTypes (set on Server 2008+) and validates the domain functional level via msDS-Behavior-Version is at least 4 (Server 2008) so AES keys can be generated. The check also samples a service principal Get-ADUser <svc> -Properties msDS-KeyVersionNumber to confirm AES keys were generated by a password rotation after the AES-capable functional level was reached.
Why it matters
Kerberoasting and AS-REP Roasting do not require local admin or even an authenticated session beyond a single low-privilege domain user (for SPN ticket requests) or no session at all (for AS-REP when DONT_REQ_PREAUTH is set). The cracking time gap between RC4 and AES is the entire game. RC4-HMAC service tickets are encrypted with the NTLM hash of the service account password, which is an unsalted MD4 derivative; hashcat mode 13100 cracks RC4 Kerberos tickets at 6 to 12 billion candidates per second on a single RTX 4090. AES256-CTS-HMAC-SHA1-96 (hashcat mode 19700) runs at roughly 400 to 800 thousand candidates per second on the same hardware, a 15,000x to 30,000x slowdown driven by the 4096-iteration PBKDF2 key derivation. A password that falls in 4 hours under RC4 takes roughly 7 years under AES256 with the same dictionary and rules. Beyond Kerberoasting, RC4 enables ticket forgery refinements (silver and golden tickets encrypted under RC4 remain forgeable when an attacker has only the NT hash rather than the AES256 key) and exposes the domain to downgrade attacks where the attacker influences etype negotiation. Microsoft hardened the KDC against unconstrained RC4 with KB5021131 (CVE-2022-37966 / CVE-2022-37967) in November 2022; environments that explicitly re-enabled RC4 to bypass that update or that have stale msDS-SupportedEncryptionTypes values on service accounts inherit the same exposure. The blast radius is every Kerberoastable service account, which in real estates often includes SQL service accounts, SCCM accounts, and unconstrained-delegation servers that pivot directly to Tier 0.
Attack path
Step 1: Reconnaissance. From any authenticated domain context the attacker enumerates accounts with SPNs and AS-REP-roastable flags. Rubeus.exe kerberoast /nowrap /outfile:hashes.txt for SPN accounts. Rubeus.exe asreproast /nopreauth /outfile:asrep.txt for accounts with DONT_REQ_PREAUTH (UserAccountControl bit 0x400000). Step 2: Etype selection. The attacker requests service tickets specifying etype RC4_HMAC (23) in the AS-REQ / TGS-REQ. Rubeus, Impacket GetUserSPNs.py, and Certipy all default to or support requesting RC4 explicitly: GetUserSPNs.py contoso.local/lowpriv:Password -request -outputfile spns.kirbi. If the target service account has msDS-SupportedEncryptionTypes set to 0 (or with RC4 allowed), the KDC returns the TGS encrypted under the RC4 key derived from the NT hash of the account password. If the attribute is set to AES-only the KDC returns AES and the offline attack slows by four orders of magnitude. Step 3: Offline cracking. The attacker formats the captured blob as a hashcat $krb5tgs$23$ or $krb5asrep$23$ string and runs hashcat -m 13100 hashes.txt rockyou.txt -r OneRuleToRuleThemAll.rule against the service ticket, or -m 18200 against the AS-REP. Modern GPU rigs (8x RTX 4090) clear 96-bit RC4 keyspace for any service account with a password under 12 characters and a moderate ruleset within hours. Step 4: Lateral movement. With the cleartext password the attacker authenticates as the service account, frequently a SQL or SCCM service identity with unconstrained delegation, replication rights, or local administrator on Tier 1 hosts. From there they pivot to a DC and run DCSync (T1003.006) or extract the krbtgt hash for Golden Ticket persistence. Step 5: Optional golden / silver ticket forging. With the krbtgt hash extracted, an attacker who wants to evade modern detections can forge tickets specifying etype 23 (RC4) because RC4 tickets remain accepted by KDCs that have not enforced AES via msDS-SupportedEncryptionTypes on krbtgt. Mimikatz kerberos::golden /user:Administrator /domain:contoso.local /sid:S-1-5-21-... /krbtgt:<hash> /rc4 forges an RC4 ticket; the AES equivalent requires the AES256 key, which Mimikatz can extract only from a DC that has already generated it after a password rotation post-functional-level-upgrade.
How Guerrilla assesses it
Guerrilla binds to the domain naming context via LDAP and reads msDS-SupportedEncryptionTypes from (1) the domain root object DC=<domain>, (2) every user object with a servicePrincipalName, every gMSA (objectClass=msDS-GroupManagedServiceAccount), and every account flagged with DONT_REQ_PREAUTH, (3) every computer object, and (4) every trustedDomain object under CN=System,DC=<domain>. The attribute is a bitmask: 0x01 DES_CBC_CRC, 0x02 DES_CBC_MD5, 0x04 RC4_HMAC_MD5, 0x08 AES128_HMAC_SHA1, 0x10 AES256_HMAC_SHA1, 0x20 Future. Any account where (value -band 0x07) is non-zero is flagged. Accounts where the attribute is null or 0 inherit the DC default, so the check then reads HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes on each domain controller over remote registry or PowerShell remoting; a value below 0x18 (AES only) or that includes the RC4 / DES bits constitutes a domain-wide finding. The check also reads HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\DefaultDomainSupportedEncTypes (the post-KB5021131 KDC default override) and msDS-Behavior-Version on the domain root to confirm functional level is sufficient for AES key generation (DFL 4 / Server 2008 or later). For each Kerberoastable account, the check captures pwdLastSet and msDS-KeyVersionNumber so the operator can confirm whether an AES key has actually been generated (the password must be rotated after AES support is enabled before AES keys exist for that account).
Recommended value
AES256_HMAC_SHA1 and AES128_HMAC_SHA1 as the only supported encryption types. DES and RC4 disabled via Group Policy and domain functional level
Remediation
Configure via Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > 'Network security: Configure encryption types allowed for Kerberos' = AES128_HMAC_SHA1, AES256_HMAC_SHA1, Future encryption types. Audit accounts with msDS-SupportedEncryptionTypes to identify those restricted to RC4. Ensure all service accounts have AES keys generated by rotating passwords after AES support is enabled at the domain level
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 | FAIL |
| no-data | Not Assessed |
Framework mappings
- NIST SP 800-53
- SC-12, SC-13
- ANSSI
- R37
- CIS AD Benchmark
- 7.4.1
- MITRE ATT&CK
- T1558