ADKERB-002: Kerberoastable with Weak Encryption
- Platform
- Active Directory
- Category
- AD Kerberos Security
- Severity
- Critical
- 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 issues an LDAP query for (&(objectCategory=person)(objectClass=user)(servicePrincipalName=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) against the domain naming context and pulls msDS-SupportedEncryptionTypes, userAccountControl, pwdLastSet, memberOf, and servicePrincipalName for each result. The msDS-SupportedEncryptionTypes value is interpreted as the 32-bit little-endian bitmask defined in [MS-KILE] section 2.2.7: bit 0 (0x01) DES-CBC-CRC, bit 1 (0x02) DES-CBC-MD5, bit 2 (0x04) RC4-HMAC, bit 3 (0x08) AES128-CTS-HMAC-SHA1-96, bit 4 (0x10) AES256-CTS-HMAC-SHA1-96. An account is flagged when any of the following is true: (a) msDS-SupportedEncryptionTypes is null or 0, which causes Windows to default to RC4 unless the domain-wide DefaultDomainSupportedEncTypes registry value on the DCs has been explicitly raised, (b) the value contains only DES or RC4 bits with no AES bits set, (c) userAccountControl has the USE_DES_KEY_ONLY flag (0x200000), or (d) the account password has not been rotated since AES support was enabled in the domain (no AES keys exist in the KDS even if the attribute advertises AES). The check also captures the SPN list, group memberships, and pwdLastSet so the operator can prioritize Tier 0 service accounts and stale passwords first.
Why it matters
Kerberoasting is a post-authentication attack that requires only a valid domain user. Any authenticated principal can request a TGS for any registered SPN, and the resulting ticket is encrypted with a key derived from the target service account password. When that key is RC4-HMAC-MD5, the derivation is a single unsalted NT hash (MD4 of the UTF-16LE password), which hashcat mode 13100 cracks at hundreds of millions to billions of guesses per second on commodity GPUs. AES256 tickets (hashcat mode 19700) are roughly four orders of magnitude slower per guess and use a per-realm salt, making dictionary and rule-based attacks impractical for passwords of reasonable length and entropy. Service accounts are uniquely high-value because they typically have non-expiring passwords, broad delegation, membership in privileged groups (Domain Admins, Exchange Trusted Subsystem, SQL service groups), and are rarely rotated. A single RC4-roastable Tier 0 service account compromise yields silver tickets and frequently a path to Domain Admin. Even after enabling AES in the domain via msDS-SupportedEncryptionTypes, accounts that have not had their password rotated since the change have no AES keys in the KDS database, and the KDC will fall back to RC4 regardless of what the attribute advertises.
Attack path
Step 1: Foothold. The attacker holds any authenticated domain user context, obtained via phishing, password spray, or compromise of a low-tier workstation. No special privileges are required. Step 2: SPN enumeration. The attacker runs GetUserSPNs.py (Impacket), Rubeus kerberoast /stats, or PowerView Get-DomainUser -SPN to list every user account with a populated servicePrincipalName. Guerrilla output, BloodHound (Kerberoastable edge), and ldapsearch all surface the same set. Step 3: Target selection. The attacker filters for accounts that will return RC4 tickets. Rubeus kerberoast /rc4opsec restricts requests to accounts whose msDS-SupportedEncryptionTypes does not include AES, avoiding noisy AES requests that would otherwise be downgraded. Without /rc4opsec, the attacker explicitly requests etype 23 in the TGS-REQ and the KDC will issue an RC4 ticket if the account has an RC4 key in the KDS, which is the default for any account that has not been rotated since AES was enabled. Step 4: Ticket request. The attacker calls TGS-REQ for each target SPN. The KDC, which does not require the requester to actually use the service, returns a TGS-REP containing the service ticket encrypted with the service account password-derived key. Rubeus and Impacket both extract the encrypted portion and format it as a hashcat-compatible string ($krb5tgs$23$* for RC4, $krb5tgs$18$* for AES256). Step 5: Offline cracking. The attacker runs hashcat -m 13100 (RC4) against a wordlist with rules. Cracking rates on a single RTX 4090 exceed 6 billion guesses per second for RC4 Kerberos hashes, sufficient to brute-force any password up to roughly 9 mixed-case alphanumeric characters and to defeat virtually any wordlist-and-rules combination for service account passwords under 14 characters. Step 6: Credential use. The cleartext password is used to authenticate as the service account, request a TGT, and pivot via group memberships (often Domain Admins, Backup Operators, or Tier 0 application rights) or via constrained or unconstrained delegation configured on the account. Recovered service account credentials also unlock silver ticket forgery against the affected service for long-term persistence.
How Guerrilla assesses it
Guerrilla connects to the closest domain controller via LDAP over port 389 (or 636 when LDAPS is required by policy) and issues a paged search rooted at the default naming context with filter (&(samAccountType=805306368)(servicePrincipalName=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) and attribute set msDS-SupportedEncryptionTypes, userAccountControl, servicePrincipalName, pwdLastSet, lastLogonTimestamp, memberOf, adminCount. For each user it computes an effective encryption flag by combining msDS-SupportedEncryptionTypes with the USE_DES_KEY_ONLY bit in userAccountControl. A finding is raised when the effective flag is missing AES128 (0x08) and AES256 (0x10), when the attribute is null or zero, or when the account is a member of a Tier 0 group (Domain Admins, Enterprise Admins, Schema Admins, BUILTIN\Administrators, krbtgt parents) regardless of encryption type because the blast radius justifies a finding on its own. The check also surfaces pwdLastSet relative to the domain functional level upgrade or the documented date AES was enabled, so the operator can identify accounts that advertise AES but have no AES key material because the password predates AES support. Output is enriched with the SPN list and member-of groups to support triage.
Recommended value
All SPN-bearing accounts support AES256 encryption. No accounts restricted to RC4 or DES encryption types. msDS-SupportedEncryptionTypes includes AES flags on all service accounts
Remediation
Query SPN-bearing user accounts and check their msDS-SupportedEncryptionTypes attribute. Accounts with value 0 (not set) default to RC4. Accounts with only RC4 (0x4) or DES (0x1, 0x2, 0x3) flags are vulnerable. Rotate passwords on all affected accounts after enabling AES support in the domain to generate AES keys. Set msDS-SupportedEncryptionTypes to include AES128 (0x8) and AES256 (0x10) flags
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 |
| throttled | Not Assessed |
Framework mappings
- NIST SP 800-53
- IA-5(1), SC-12
- ANSSI
- R36, R37
- CIS AD Benchmark
- 7.1.2
- MITRE ATT&CK
- T1558.003