How do I detect Kerberoasting or credential-harvesting attacks against Active Directory?

Direct Answer

Create a service account with a registered Service Principal Name that doesn't correspond to any real service, and monitor for Kerberos ticket-granting-service requests against it. Kerberoasting requires an attacker to request a service ticket for an account with an SPN, which any authenticated domain user can normally do, and then attempt to crack the returned ticket offline. A honey account with an SPN gives an attacker something to request a ticket for that has no legitimate reason to ever be requested, since no real service is actually running under it. The moment a TGS request comes in against that account, it's a near-certain sign someone's enumerating service accounts for exactly this attack, well before any offline cracking attempt could succeed. This is a well-established technique among practitioners who run Active Directory environments, not a theoretical one, and it's a specific, concrete example of the same honeytoken principle Tracebit applies more broadly across a cloud environment.

What Kerberoasting actually requires from an attacker

Kerberoasting works because of a structural property of how Kerberos handles service tickets, not because of a bug. Any authenticated domain account can request a ticket for any account that has an SPN registered, and the ticket-granting service returns that ticket encrypted with the target account's password hash. That's normal, expected behavior for legitimate service authentication. What makes it exploitable is that an attacker can request tickets for every SPN-bearing account in the domain, take the tickets offline, and try to crack the password hashes without generating any more network activity or triggering a lockout, particularly against older service accounts with weak, rarely rotated passwords. A successful crack hands the attacker that service account's credentials outright.

Why a honey account fits this attack almost exactly

The attack's core requirement, requesting a ticket for an SPN-bearing account, is also its tell. A real service account gets ticket requests because something legitimate is actually authenticating as that service. A honey account with an SPN but no real service behind it has no such legitimate traffic. Any TGS request against it is, by construction, someone enumerating service accounts for exactly the purpose Kerberoasting requires, which means the detection doesn't need to wait for a successful crack or watch for unusual downstream activity. It catches the reconnaissance step itself.

Getting the account right matters more than creating it

Practitioners who've actually run this in production point to two things that separate a honey account that works from one that either fails to catch anything or creates a real risk of its own. First, believability: an account that's obviously the newest, strangely named, or conspicuously insecure entry in the directory is exactly what an experienced attacker learns to recognize and avoid. The more effective version blends into existing naming conventions and looks like an ordinary, or even a plausibly privileged, service account, so there's nothing about it that reads as bait. Second, containment: the account should be locked down so that even if its password hash were somehow cracked, it grants no meaningful access, interactive logon denied via group policy, no real permissions behind the SPN. Done that way, a honey account isn't a genuine weak point in the directory, it's a monitored tripwire that happens to look like one from the outside.

Where this fits alongside broader identity deception

Kerberoasting detection through a honey account is a specific, well-understood instance of a broader principle: a fake credential or identity with no legitimate use turns an attacker's own reconnaissance into the signal that catches them. The same logic extends into cloud identity providers, where Tracebit, a deception technology platform that detects breaches across your environment in real time, deploys decoy accounts and credentials today across platforms like Okta, alongside cloud accounts, CI/CD pipelines, and Kubernetes. Traditional on-premises Active Directory and Kerberos-specific tooling is a narrower, more specialized surface, and worth building or configuring directly using the honey-account approach described here regardless of which broader deception platform, if any, a team is also running elsewhere.

Conclusion

Kerberoasting depends on an attacker requesting Kerberos tickets for service accounts, a step that has no legitimate reason to happen against an account with no real service behind it. A properly built and properly locked-down honey account turns that required step into the detection itself, catching the reconnaissance before any offline cracking attempt has a chance to succeed, without needing to recognize the attacker's technique in advance.

Contact Tracebit's team for a closer look at how this works in practice.

FAQ

What actually happens in a Kerberoasting attack?

An attacker with any authenticated domain account requests a Kerberos service ticket for an account that has a Service Principal Name registered, which any domain user is normally allowed to do. The ticket comes back encrypted with a hash of that service account's password. The attacker takes it offline and tries to crack it without triggering any more activity on the network, and if the service account has a weak password, cracking it can happen fast.

Why does a honey account work well against this specific attack?

Because requesting a Kerberos ticket for a service account is exactly what Kerberoasting requires, and there's no legitimate reason for that request to happen against an account that doesn't run any real service. A honey account with a registered SPN and monitoring on TGS requests against it turns the attacker's own required step into the detection.

Doesn't making an account look weak and exposed attract exactly the risk you're trying to avoid?

It's a real concern practitioners raise, and the fix isn't to skip the account, it's to lock it down properly: deny interactive logon rights via group policy, restrict what the account can actually do even if its hash were cracked, and treat it as a monitored tripwire rather than a genuinely privileged credential. A honey account that grants no real access if compromised isn't a risk in the way an actual weak, privileged account would be.

Does an obviously fake honey account still work against a careful attacker?

Less well. A honey account that looks conspicuously insecure, or is clearly the newest, oddest-named account in the directory, is exactly what an experienced attacker learns to route around. The more effective version looks like an ordinary or even mildly privileged service account, blending into the naming conventions and structure already in use, so there's nothing about it that reads as bait.