Kerberoasting

Kerberoasting abuses a legitimate, everyday part of how Active Directory works. Any domain user can request a Kerberos "service ticket" for any service account registered with a Service Principal Name (SPN). That's normal, expected traffic, not a vulnerability by itself. The problem is what that ticket contains: a piece of it is encrypted with the service account's own password hash. If an attacker can request that ticket, they can take it home and try to crack the password offline, with no further contact with the domain controller and nothing that looks unusual in the moment.

Service accounts make this especially attractive. They're often provisioned once and forgotten: long-lived, sometimes over-privileged, and rarely subject to the same password rotation discipline as a human user's login.

This is a staple of the "quiet middle" of an Active Directory intrusion: after initial access, before the adversary has domain admin. A single authenticated foothold, even a low-privileged one, is enough to request tickets for every SPN-registered account in the domain. From there it's an offline cracking problem: weak or reused service account passwords fall, and a cracked service account often carries far more access than the low-privileged user the attacker started as.

It's popular specifically because it's cheap and quiet. Tools like Rubeus or Impacket's GetUserSPNs.py automate the whole request-and-extract step in seconds, and because the initial request is legitimate Kerberos traffic, there's no exploit, no malware signature, nothing an antivirus product is likely to flag.

Data source: Domain controller's Windows Security event log, Kerberos service-ticket requests (Event 4769) -- high-volume, so filter to RC4 (type 0x17) on a service-account SPN

{
  "host": {
    "name": "DC01"
  },
  "event": {
    "code": "4769",
    "action": "Kerberos Service Ticket Requested"
  },
  "winlog": {
    "event_data": {
      "IpAddress": "10.1.10.21",
      "ServiceName": "svc_sql",
      "TargetUserName": "jdoe",
      "TicketEncryptionType": "0x17"
    }
  }
}

Prebuilt Elastic rule: Suspicious Kerberos Authentication Ticket Request

One request is nothing, since event 4769 fires constantly under normal use. What's worth hunting for:

Encryption type: legitimate modern clients request AES (0x12/0x18). Kerberoasting tools frequently request the weaker, crackable RC4 (0x17), and some environments barely see RC4 requests at all outside an attack.

Volume and breadth: a single account requesting service tickets for many different SPNs in a short window is the actual attack pattern. One request is background noise; a burst across the whole SPN list isn't.

Hunting manually: filter event.code: "4769", group by requesting account, and look for either the RC4 encryption-type pattern or a high SPN-request count from a single principal in a short window. Both are stronger signals than either alone.

RC4 in a 4769 event isn't proof of an attack by itself. It shows up legitimately more often than you'd expect:

Legacy accounts and applications. Older service accounts, network appliances, or line-of-business apps that predate AES support (or were never reconfigured) can still request or be issued RC4 tickets. This is especially common in domains with a long history of accumulated legacy infrastructure.

Misconfigured or default msDS-SupportedEncryptionTypes. If a service account's supported-encryption-types attribute was never explicitly set to require AES, the KDC may fall back to offering RC4. That's a configuration gap, not an attack, though worth fixing either way.

Non-Windows or third-party Kerberos clients. Some NAS devices, older Unix/Linux Kerberos implementations, and legacy network gear only speak RC4.

The encryption type alone is a weak signal. What separates a real Kerberoasting attempt from routine legacy noise is the pattern, not a single event: a known legacy service requesting RC4 for the same SPN it always has, from its usual host, is very different from one account suddenly requesting tickets for many different SPNs in a short window. If you're triaging an RC4 alert, check whether the account/host combination has a consistent history of doing exactly this. If it does, you're probably looking at a legacy system, not an intrusion. If it doesn't, or if it's paired with the volume/breadth pattern above, treat it as real.

• MITRE ATT&CK T1558.003: Kerberoasting
• Microsoft Event 4769: A Kerberos service ticket was requested
• Elastic Security: Suspicious Kerberos Authentication Ticket Request

1 scenario in this catalog covers T1558.003. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →