Kerberoasting and AD Credential Attacks: Detection and Defense

Kerberoasting is one of the most common techniques defenders see against Active Directory (AD), yet it remains widely misunderstood by the teams responsible for stopping it. This article takes a strictly defensive point of view: we explain what the technique is, how the underlying Kerberos protocol works, why certain accounts become exposed, and — most importantly — how blue teams detect, mitigate, and harden against it. The goal is understanding in order to defend. You will not find operational attack instructions here, only the telemetry, controls, and checklists a detection engineer or AD administrator needs to raise the cost of the attack and shrink the window in which it can succeed.

What Kerberoasting Is

Kerberoasting is a credential-access technique that abuses a legitimate feature of Kerberos: any authenticated domain user can request a service ticket for a service account that has a Service Principal Name (SPN) registered. Part of that ticket is encrypted with a key derived from the service account's password. Because the request itself is normal protocol behaviour, it generates little noise, and the offline nature of the subsequent password-cracking step means the domain controller (DC) never sees the guessing attempts. The risk is therefore concentrated in weak service-account passwords and legacy encryption. From a defender's perspective, the technique is best understood as a mismatch between an old convenience feature and modern password-cracking hardware. It is classified under MITRE ATT&CK as T1558.003 (Steal or Forge Kerberos Tickets: Kerberoasting), sitting inside the Credential Access tactic.

How Kerberos Authentication Works

To defend against the technique you need a working mental model of Kerberos. When a user logs in, they receive a Ticket-Granting Ticket (TGT) from the Key Distribution Center (KDC), which runs on the domain controller. When that user later wants to access a service — a SQL Server, a web application pool, a file share — they present the TGT and request a Ticket-Granting Service (TGS) ticket for the specific SPN. The KDC returns a TGS whose service portion is encrypted with the long-term key of the account that owns the SPN. Legitimately, the client forwards that ticket to the target service, which decrypts it to validate the request. The design assumption is that only the service (which knows its own password) can read the encrypted portion. That assumption breaks down when the account password is weak enough to be recovered offline, because anyone who can obtain the ticket can attempt to derive the key. Understanding this flow tells you exactly where to place your telemetry: at the KDC, on ticket-request events.

How the Attack Works at a High Level

At a high level, the technique has three conceptual stages that a defender should recognise. First, enumeration: identifying which accounts have SPNs registered, since only those are targetable. Second, ticket request: obtaining TGS tickets for those SPNs through ordinary, authenticated protocol calls that look like normal service access. Third, offline recovery: taking the encrypted portion away from the network entirely and attempting to recover the password on the adversary's own hardware, with no further contact with your domain. The crucial insight for the blue team is that only the first two stages are visible to you — the third happens off-network. This is why prevention (strong passwords, modern encryption, managed accounts) matters as much as detection: once a weak-password ticket has left the environment, no alert can call it back.

Attack Surface and Exposure

The exposed surface is the set of accounts carrying SPNs. In most environments this includes service accounts for databases (MSSQLSvc), web servers, custom line-of-business applications, and a range of vendor products that historically required a domain user to run under. Two categories deserve special scrutiny. The first is privileged service accounts — any SPN-bearing account that is also a member of Domain Admins, Enterprise Admins, or other high-tier groups. These are the highest-value exposures because recovering their password yields immediate privilege. The second is stale accounts: service accounts created years ago with a human-chosen password that has never rotated. Inventorying this surface is a defensive project in itself. You should be able to answer, at any time, how many SPN-bearing accounts exist, which are privileged, which use legacy encryption, and when each password last changed. If you cannot answer those questions, that gap is your first finding.

Detection: Logs, Event IDs, and Telemetry

Detection centres on Kerberos service-ticket events on the domain controllers. The key signal is Event ID 4769 ("A Kerberos service ticket was requested"). On its own this event is extremely high-volume and benign, so naive alerting is useless; the art is in the enrichment. Prioritise 4769 events where the Ticket Encryption Type is 0x17 (RC4-HMAC) rather than 0x12 (AES256), because a downgrade to RC4 on an account that should support AES is a strong indicator. Correlate on volume and diversity: a single principal requesting service tickets for an unusually large number of distinct SPNs in a short window is far more suspicious than the raw event count. Watch Event ID 4768 (TGT requested) for the initial authentication context, and pair 4769 with the requesting account, source host, and time-of-day baseline. Modern EDR and identity-threat-detection platforms (for example Microsoft Defender for Identity) ship dedicated Kerberoasting analytics that combine these signals; if you run one, tune and validate its alerts rather than assuming they are on. Finally, consider a honeypot service account: an SPN-bearing decoy with a long random password and no legitimate use, wired so that any 4769 request for it fires a high-fidelity alert, since no benign process should ever touch it.

Mitigation and Hardening

Prevention is where you win. The single most effective control is to eliminate human-chosen service-account passwords: migrate to Group Managed Service Accounts (gMSA) or delegated Managed Service Accounts, whose passwords are 120+ character random values rotated automatically by AD and never known to a human. A gMSA password is computationally infeasible to recover offline, which removes the account from the risk entirely. Where a gMSA is not yet possible, enforce long, random passwords (25+ characters) on every SPN-bearing account, since password length is the direct lever against offline cracking. Disable RC4 and require AES encryption for Kerberos, both at the domain policy level and on individual account attributes (msDS-SupportedEncryptionTypes), while testing for legacy dependencies first. Apply tiering: no service account should be both SPN-bearing and a member of a highly privileged group — separate the roles. Enforce a rotation schedule for any remaining manual accounts, and remove SPNs from accounts that no longer need them. Each of these controls raises the attacker's cost independently, so implement them in defence-in-depth rather than choosing one.

Related AD Credential Attacks

Kerberoasting rarely stands alone; it belongs to a family of AD credential techniques a defender should treat together. AS-REP Roasting (T1558.004) targets accounts that have Kerberos pre-authentication disabled, yielding crackable material without even needing a valid domain account — so audit for the DONT_REQ_PREAUTH flag and clear it wherever it is not strictly required. Pass-the-Ticket and Pass-the-Hash techniques reuse stolen authenticators rather than cracking them, which is why credential-hygiene controls such as Credential Guard, LSASS protection, and restricting where privileged accounts log in matter. Golden and Silver Ticket forgeries abuse the KRBTGT and service-account keys respectively, which is one more reason to rotate KRBTGT regularly and to protect service-account secrets. Viewing these as a connected surface, rather than isolated alerts, helps you prioritise the controls — strong secrets, modern encryption, tiering, and privileged-access management — that reduce several of them at once.

Common Pitfalls

Several recurring mistakes undermine otherwise-good programmes. The first is alerting on raw 4769 volume: without encryption-type and diversity enrichment, the noise buries the signal and the rule is disabled within a week. The second is assuming AES is enforced when a single legacy application silently forces RC4 for the whole account — always verify the negotiated encryption type in real events, not just in policy. The third is the privileged service account left in place because "the app needs it" — this is precisely the exposure that turns a low-severity finding into a domain-compromise path. The fourth is treating a gMSA migration as finished when a handful of stubborn legacy services still run under manual accounts; those exceptions are exactly where the risk concentrates. The fifth is disabling pre-authentication for troubleshooting and forgetting to re-enable it, silently opening AS-REP Roasting. Track each of these as a standing hygiene item rather than a one-time fix.

Defender Checklist

Use this checklist as a recurring review. Inventory: maintain a live list of all SPN-bearing accounts, flagging privileged and legacy-encryption ones. Encryption: require AES and disable RC4 where dependencies allow, verified against real 4769 events. Managed accounts: migrate service accounts to gMSA/dMSA; set a target date to retire remaining manual ones. Passwords: for any manual account, enforce 25+ character random secrets and a rotation schedule. Tiering: ensure no SPN account holds high-tier group membership. Detection: deploy enriched 4769 analytics (encryption-type + SPN diversity + baseline) and validate they fire in a controlled test. Honeypot: stand up a decoy SPN account with high-fidelity alerting. Adjacent flags: audit and clear unnecessary DONT_REQ_PREAUTH, and confirm KRBTGT rotation is scheduled. Response: document the playbook for a confirmed detection — rotate the affected secret, hunt for onward use, and review privileged-access exposure.

Frequently Asked Questions

Can Kerberoasting be fully prevented, or only detected? It can be effectively prevented as a practical threat. Migrating SPN-bearing accounts to gMSA/dMSA, or enforcing very long random passwords with AES-only encryption, makes offline recovery computationally infeasible. Detection remains valuable as defence-in-depth and to catch misconfigured exceptions, but strong secrets are what remove the underlying risk.

Why is Event ID 4769 so noisy, and how do I make it useful? Every normal service access generates a 4769, so raw counts are meaningless. It becomes useful through enrichment: filter for RC4 (0x17) requests on AES-capable accounts, correlate a single requester hitting many distinct SPNs quickly, baseline per-account behaviour, and reserve high-fidelity alerting for honeypot SPNs that no legitimate process should ever request.

Conclusion

Kerberoasting endures not because it is sophisticated but because so many environments still carry weak service-account passwords and legacy RC4 encryption. For defenders, the path is clear and durable: inventory your SPN-bearing accounts, move them to managed accounts, enforce AES, separate privilege from service identity, and build enriched detection on Kerberos ticket events with a honeypot as a tripwire. Treat it alongside its cousins — AS-REP Roasting, ticket forgery, and credential reuse — as one connected identity-security surface. Do that, and you convert a reliable attacker favourite into a technique that is loud when attempted and worthless when it succeeds. Understand it, and you can defend against it.