Kerberos Attacks (Kerberoasting, AS-REP Roasting)

MITRE ATT&CK

Security Relevance

Kerberos attacks are exceptionally dangerous because they operate entirely within legitimate Windows authentication protocols — generating traffic that is indistinguishable from normal domain activity at the packet level. Kerberoasting in particular requires only a standard domain user account and produces no logon failures, making it invisible to failed-logon monitoring. If a service account with Domain Admin membership or broad access rights is Kerberoasted, the attacker gains those privileges within hours via offline cracking.

Indicators of Malicious Use

• ⚑Event 4769: single source account requesting TGS tickets for 5+ different SPNs within minutes
• ⚑Event 4769: TicketEncryptionType 0x17 (RC4-HMAC) for service accounts — attackers request RC4 because it cracks faster than AES
• ⚑Event 4768: PreAuthType 0 (no pre-authentication) — identifies AS-REP Roastable accounts
• ⚑Event 4771: failure code 0x18 (wrong password) in high volume — Kerberos brute-force or stuffing
• ⚑TGS requests for accounts with service principal names (SPNs) set — especially high-privilege service accounts like SQL service accounts, backup agents, or custom application accounts
• ⚑Tool signatures in Event 4688: Rubeus.exe, GetUserSPNs.py, Invoke-Kerberoast, impacket

Example Log Entry

Log Name: Security
Event ID:  4769
Level:     Information

A Kerberos service ticket was requested.

Account Information:
  Account Name:     jsmith@CORP.LOCAL
  Account Domain:   CORP.LOCAL

Service Information:
  Service Name:     MSSQL/sqlserver01.corp.local
  Service ID:       CORP\svc_sql

Network Information:
  Client Address:   192.168.1.47

Additional Information:
  Ticket Options:   0x40810010
  Ticket Encryption Type: 0x17   ← RC4-HMAC (attacker-requested for offline cracking)
  Failure Code:     0x0

[Repeated 12 times in 30 seconds for different Service Names from the same Account and Client Address]

Investigation Steps

1. 1.Query for accounts with SPNs set in Active Directory — these are the Kerberoasting targets: Get-ADUser -Filter {ServicePrincipalName -ne '$null'} -Properties ServicePrincipalName | Select Name,ServicePrincipalName. Review each one for privilege level.
2. 2.Check the ticket encryption type in Event 4769 — RC4 (0x17) requests from modern Windows clients are suspicious. Legitimate clients on Windows 10/Server 2016+ prefer AES (0x12, 0x11).
3. 3.Identify AS-REP Roastable accounts — run Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth. These accounts expose their credentials without any initial credential.
4. 4.Look for Kerberoasting tool signatures in Event 4688 (process creation): Rubeus, GetUserSPNs, Invoke-Kerberoast, PowerSploit, impacket. Also check for unusual Python or Java processes on non-developer machines.
5. 5.Correlate the requesting account with lateral movement indicators — an attacker performing Kerberoasting has already achieved initial access. Trace back to the compromised account's logon history.
6. 6.Check for Golden/Silver Ticket indicators: Event 4769 with Service Name that doesn't exist in AD, unusual logon hours for service accounts, or Event 4624 logon type 3 with no corresponding Kerberos pre-authentication event.
7. 7.Review KRBTGT account password age — if a Golden Ticket attack is suspected, the KRBTGT password must be reset twice (the account maintains two passwords) to invalidate all existing TGTs.

Common False Positives

• ◎Legitimate service ticket requests — normal domain operation generates many 4769 events. The key differentiators are volume from a single account, RC4 encryption type, and requests across many different services.
• ◎Application servers requesting tickets for multiple services — app servers (SharePoint, SQL, IIS) legitimately request TGS for connected services. Baseline the normal request volume per server.
• ◎Security scanning tools — vulnerability scanners and AD health-check tools may enumerate SPNs. Coordinate with the security team to identify expected scan windows.
• ◎Legacy applications requiring RC4 — some older applications cannot negotiate AES Kerberos. If RC4 is required by a known legacy app, document it as a baseline exception.

Remediation

• ✓Set strong, long, random passwords on all service accounts with SPNs (25+ characters) — even with the hash, offline cracking becomes computationally infeasible.
• ✓Use Group Managed Service Accounts (gMSA) for service accounts where possible — Windows auto-rotates the password every 30 days and it's 120 characters by default, making Kerberoasting useless.
• ✓Disable 'Do not require Kerberos preauthentication' on all accounts that have it set — this eliminates AS-REP Roasting for those accounts. Audit with Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}.
• ✓Enable AES encryption for service accounts and disable RC4: set msDS-SupportedEncryptionTypes = 24 (AES128+AES256) on service accounts. This won't stop Kerberoasting but makes the resulting hash much harder to crack.
• ✓Reset the KRBTGT account password twice if a domain controller credential dump is suspected — this invalidates all existing TGTs including Golden Tickets. Plan for disruption: all Kerberos sessions will need to re-authenticate.
• ✓Deploy a honeypot SPN — create a service account with a strong random password and an SPN, then alert on any TGS request for it. Any request is an instant IOC since no legitimate service uses it.

Related Event IDs

Related Detection Guides

Frequently Asked Questions

How do I detect a Golden Ticket attack?

Golden Tickets are difficult to detect from event logs alone because the forged ticket bypasses normal TGT issuance. Indicators include: Event ID 4769 with RC4 encryption type (0x17) on an account that should use AES256, TGT lifetimes exceeding your domain policy (default 10 hours), and accounts appearing in 4769 events that don't exist in Active Directory. Microsoft Defender for Identity detects Golden Tickets via DC replication traffic analysis. Resetting the krbtgt password twice (with a delay) invalidates all issued tickets.

What is the difference between a Golden Ticket and a Silver Ticket?

A Golden Ticket forges a Kerberos TGT using the krbtgt account hash, granting access to any service in the domain. It requires compromising the krbtgt hash, typically via DCSync or NTDS.dit dumping. A Silver Ticket forges a service ticket (TGS) using a specific service account's hash, granting access only to that one service — and it generates no events on the domain controller because no TGT validation occurs. Silver Tickets are stealthier but more limited in scope.

What causes Event ID 4771 — Kerberos pre-authentication failure?

Event ID 4771 fires when a user's password is incorrect during the initial TGT request (AS-REQ phase). High volumes of 4771 targeting many accounts from a single source indicates AS-REP roasting or Kerberos password spray. A single account generating 4771 is a standard failed logon (similar to 4625 but for Kerberos). Accounts with 'Do not require Kerberos preauthentication' enabled are AS-REP roastable — their hashes can be captured offline without authentication.

Can Kerberos attacks be detected without Sysmon?

Yes. Event IDs 4768 (TGT request), 4769 (service ticket request), 4770 (ticket renewal), and 4771 (pre-auth failure) are all logged in the Windows Security log on domain controllers. No Sysmon required. The key is enabling 'Audit Kerberos Service Ticket Operations' and 'Audit Kerberos Authentication Service' in Group Policy, and then baselining encryption types and ticket volumes to detect anomalies.