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
Kerberoasting (ATT&CK T1558.003) and AS-REP roasting (T1558.004) are the two most common offline-crackable Kerberos ticket attacks against Active Directory, and both remain prevalent years after being publicized because they require no elevated privilege to attempt and no interactive logon on the target — an attacker with any valid domain credential can request a service ticket for any Service Principal Name, and an attacker with a target username can request a TGT for any account configured without Kerberos pre-authentication. Both attacks move the actual password-cracking step entirely offline, away from any authentication-failure telemetry.
They stay effective because the underlying weakness is rarely the Kerberos protocol itself but AD hygiene: service accounts with long-lived, weak, or reused passwords, and legacy or misconfigured accounts with pre-authentication disabled. Detection for both hinges on the same Kerberos authentication event log — Event ID 4768 (TGT requests) and Event ID 4769 (service ticket requests) — which makes this a good case study in getting one log source’s field semantics exactly right.
Attack Prerequisites
What must be true for each attack to work:
- Kerberoasting — any valid, authenticated domain credential (no special privilege required); knowledge of registered SPNs, enumerable via
setspn -Q */*or Impacket’sGetUserSPNs.py; and a weak or crackable password on at least one SPN-bearing service account. - AS-REP roasting — a list of candidate usernames, and at least one target account with the
userAccountControlflagDONT_REQUIRE_PREAUTH(bit0x400000) set, i.e. “Do not require Kerberos preauthentication” enabled in its AD object. - Offline cracking capability for both — hashcat mode
13100(Kerberoasting, TGS-REP) or18200(AS-REP roasting, AS-REP), plus compute time proportional to password strength and the ticket’s encryption type.
How It Works
Kerberoasting: any authenticated user can request a service ticket (TGS-REQ/TGS-REP) for any SPN in the domain — this is normal Kerberos behavior, since the KDC has no way to know in advance whether the requester is authorized to use the service. The TGS-REP’s service-ticket portion is encrypted with a key derived from the target service account’s password. The attacker requests tickets for every SPN of interest, extracts the encrypted portion, and cracks it offline against a wordlist/mask — no further contact with the KDC is needed, so cracking generates zero authentication failures or alerts.
AS-REP roasting: normal Kerberos requires pre-authentication — the client must first prove knowledge of the password by sending an encrypted timestamp (PA-ENC-TIMESTAMP) before the KDC will issue a TGT. This prevents an attacker who only knows a username from getting anything crackable. Accounts with DONT_REQUIRE_PREAUTH set skip that step entirely: the attacker sends a bare AS-REQ for the target username, and the KDC returns an AS-REP whose encrypted portion is derived from that account’s password, crackable offline exactly like a Kerberoasted TGS.
Encryption type matters to both: RC4-HMAC (etype 0x17 / 23 decimal) derives its key directly from the NTLM hash and is dramatically faster to brute-force than AES-128/256 (etypes 0x11/0x12). An account that supports AES will still get an RC4 ticket if the requester asks for RC4 specifically (tools like Rubeus can request RC4 explicitly), or by default if the account’s msDS-SupportedEncryptionTypes attribute hasn’t been set to prefer AES — which is common on older service accounts. Because of this, a burst of RC4-encrypted 4769 events for non-computer SPNs, in an environment where AES is otherwise the norm, is itself a downgrade indicator worth alerting on independent of volume.
Practical Example / Configuration
Sigma rule for Kerberoasting: Event 4769, RC4 encryption, excluding computer accounts (which legitimately request RC4 tickets for machine authentication) and the krbtgt account itself:
title: Potential Kerberoasting via RC4 TGS Requests
id: 5b7cba5e-8c9c-4b6f-9d1e-2a6f7c8b9d10
status: test
description: >
Detects TGS requests (4769) using RC4 encryption for non-machine,
non-krbtgt SPNs -- consistent with Kerberoasting via GetUserSPNs.py
or Rubeus.
logsource:
product: windows
service: security
detection:
selection:
EventID: 4769
TicketEncryptionType: '0x17'
TicketOptions: '0x40810000'
filter_machine:
ServiceName|endswith: '$'
filter_krbtgt:
ServiceName: 'krbtgt'
condition: selection and not (filter_machine or filter_krbtgt)
falsepositives:
- Legacy applications explicitly configured for RC4 compatibility
level: medium
tags:
- attack.credential_access
- attack.t1558.003
Sigma rule for AS-REP roasting: Event 4768 with no pre-authentication performed, which manifests as a PreAuthType of 0 (or the field absent) instead of the normal 2 (PA-ENC-TIMESTAMP):
title: Potential AS-REP Roasting (Kerberos Pre-Auth Not Required)
id: 9d3e2f10-4a5b-4c6d-8e7f-1a2b3c4d5e6f
status: test
description: >
Detects TGT requests (4768) with PreAuthType 0, indicating the target
account has 'Do not require Kerberos preauthentication' set --
consistent with AS-REP roasting via Rubeus or GetNPUsers.py.
logsource:
product: windows
service: security
detection:
selection:
EventID: 4768
PreAuthType: '0'
TicketEncryptionType: '0x17'
filter_machine:
TargetUserName|endswith: '$'
condition: selection and not filter_machine
falsepositives:
- Intentionally-configured legacy service accounts (should be rare
and explicitly allow-listed, not treated as routine noise)
level: high
tags:
- attack.credential_access
- attack.t1558.004
Walkthrough / Exploitation
Standing up detection for both attacks end to end:
1. Enable auditing: Advanced Audit Policy > Account Logon > 'Audit
Kerberos Authentication Service' and 'Audit Kerberos Service Ticket
Operations', applied via GPO to all Domain Controllers, so 4768/4769/
4771 are actually generated (they are not on by default).
2. Deploy both Sigma rules above against the Security log stream from
every DC.
3. Enrich with AD hygiene data: run
Get-ADUser -LDAPFilter \
"(userAccountControl:1.2.840.113556.1.4.803:=4194304)"
to enumerate accounts with DONT_REQUIRE_PREAUTH set, and cross-check
any 4768/PreAuthType=0 hit against that list -- a hit for an account
NOT on the list is even higher-signal (possible attribute tampering).
4. Stack-count 4769 by TargetUserName: a single account requesting many
distinct SPNs within seconds (GetUserSPNs.py -request pulls every SPN
in one burst) is a stronger signal than any single RC4 ticket alone.
5. Correlate source workstation/IP: one workstation touching many SPNs
across many accounts in a short window is a mass-roasting tool
signature, not normal application behavior.
6. Tune: allow-list known legacy service accounts that legitimately use
RC4, documented and reviewed periodically rather than silently
suppressed.
Note: RC4 alone is not proof of an attack — plenty of legacy applications still negotiate it for compatibility. The high-signal combination is RC4 plus burst volume (many distinct SPNs from one account in seconds) or RC4 for an account whose
msDS-SupportedEncryptionTypesindicates it should be using AES.
Opsec: Rubeus’s
/rc4opsecoption deliberately requests tickets only for accounts already known to support RC4 (avoiding an anomalous downgrade on an AES-only account) specifically to blend into legitimate traffic patterns and reduce the encryption-type anomaly signal — a reminder that etype-based detection alone is evadable and should be one signal among several, not the sole trigger.
Detection and Defense
Beyond the log-based detections above, structural mitigations reduce or eliminate the underlying weakness:
- Enforce AES for service accounts — set
msDS-SupportedEncryptionTypesto AES-only where the service supports it, and disable RC4 domain-wide via theNetwork security: Configure encryption types allowed for KerberosGPO once compatibility is confirmed. - Use gMSA/dMSA for service accounts — group Managed Service Accounts have long, randomized, automatically rotated passwords, making offline cracking practically infeasible even if a ticket is captured.
- Audit and remediate DONT_REQUIRE_PREAUTH — the LDAP filter above should run on a recurring schedule; any unexpected result is a finding, not background noise.
- Deploy honey SPNs / honey accounts — a decoy service account with a registered SPN that no legitimate application ever queries turns any 4769 against it into a near-zero-false-positive, high-confidence alert.
- Least privilege for service accounts — minimizes the impact if a password is eventually cracked, independent of whether the roasting attempt itself was detected.
Real-World Impact
Kerberoasting and AS-REP roasting are staples of nearly every Active Directory-focused penetration test and red-team engagement, implemented in widely used tooling including Impacket’s GetUserSPNs.py and GetNPUsers.py, Rubeus, and PowerView, and are documented extensively in public incident-response and AD-security write-ups (Mandiant, CrowdStrike, and numerous conference talks on AD attack paths) as a common route from an initial low-privilege foothold to a cracked service-account password with broader access. Their prevalence is a direct consequence of how common weak or stale service-account passwords remain in real environments, not a flaw in Kerberos itself.
Conclusion
Both attacks abuse legitimate Kerberos behavior rather than a vulnerability, which is why detection depends on precise event-field semantics — TicketEncryptionType 0x17 on 4769 and PreAuthType 0 on 4768 — combined with volume and account-context enrichment rather than a single indicator. The most durable fix is structural: eliminate crackable passwords on service accounts via gMSA and AES enforcement, and audit DONT_REQUIRE_PREAUTH proactively, so that even an undetected roasting attempt yields nothing useful to the attacker.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments