Ariovis

Active Directory attack technique

Kerberoasting: understand, detect and break the attack path

Kerberoasting abuses a perfectly normal property of Kerberos: an already authenticated user can request a service ticket for a service identified by an SPN (Service Principal Name). Nothing unusual so far — this is how authentication is meant to work in an Active Directory domain.

The problem appears when the account behind that service relies on a weak or poorly governed secret. An attacker can then collect material tied to the ticket and try to recover that secret offline, quietly and without any attempt limit on the directory side.

Kerberos is not broken. The problem is that a legitimate mechanism becomes an exploitable step in an attack path when service accounts, their secrets and their privileges are not under control.
Back to the use case: secure Active Directory and reduce attack paths

How does Kerberoasting work?

The mechanism comes down to a few steps. There is nothing exotic about it: it only uses legitimate directory operations, which is precisely why it is discreet.

  1. 01Identity already authenticated in the domain
  2. 02Discovery of a service associated with an SPN
  3. 03Normal Kerberos service ticket request
  4. 04Collection of material that can be attacked offline
  5. 05Attempt to recover the service account secret
  6. 06If successful: use of that account's rights
  7. 07A possible next step in the attack path
  • The attacker generally needs authenticated access to the domain beforehand: Kerberoasting is rarely the entry point, it is a progression step.
  • Requesting a service ticket is in itself a normal operation, performed constantly by legitimate users and applications.
  • The real risk depends on the strength of the targeted account's secret and on the privileges attached to it: a long, truly random secret makes the offline attempt impractical.
  • A compromise only matters to the attacker if it then opens up new resources or new privileges.

Why are service accounts such an attractive target?

In most environments, the issue is not the Kerberos mechanism but the actual state of service accounts. They often accumulate several weaknesses inherited from the history of the information system.

  • Old password, sometimes unchanged since go-live.
  • Rare or non-existent rotation, with no owner to trigger it.
  • Secret historically chosen by a human, therefore guessable.
  • Privileges far beyond the real application need.
  • Poorly documented application dependencies.
  • An assumed inability to change the password “because nobody knows what would break”.
  • Account shared across several services or several teams.
  • Rights accumulated over the years and never reviewed.
  • Unclear owner, sometimes someone who has left the company.
Kerberoasting is as much a governance problem for technical identities as it is a Kerberos security problem. As long as service accounts have no owner, no documented usage and no secret policy, the technique stays exploitable whatever the cryptographic settings.

When Kerberoasting becomes an attack path

On its own, Kerberoasting does not compromise Active Directory. It becomes dangerous when it fits into a chain that brings the attacker closer to a critical resource.

  1. 01Compromised user account
  2. 02Kerberoasting
  3. 03Compromised service account
  4. 04Additional privileges or application access
  5. 05Lateral movement
  6. 06Access to a more critical resource

A second scenario can look completely different

With the same technique, what follows depends entirely on what the compromised account actually allows in your environment:

  • the groups the account belongs to;
  • the ACLs set on directory objects;
  • the delegations it benefits from;
  • local rights on the servers involved;
  • applications and databases reachable with that identity;
  • secrets held or reachable from the servers where it runs;
  • relationships towards other resources, domains or environments.

The real risk of a kerberoastable account is therefore not measured by the existence of an SPN, but by what its compromise would allow next. That is exactly the attack-path reading of the parent use case.

Back to the use case: secure Active Directory and reduce attack paths

How do you detect the risk?

Two distinct topics are often mixed up: measuring exposure (inventory and analysis work) and detecting suspicious activity (monitoring work). Both are needed, but they are not addressed the same way.

1. Identify the exposure

The goal is to know which accounts are genuinely attackable and what they would grant.

  • Inventory accounts carrying one or several SPNs.
  • Identify their business and technical owners.
  • Understand their real application usage.
  • Assess their privilege level, direct and inherited.
  • Spot legacy and unused accounts.
  • Look for secrets that do not follow an acceptable rotation policy.
  • Analyse where these accounts sit in the directory's attack paths.

2. Detect suspicious activity

Monitoring relies in particular on Kerberos events related to service ticket requests, including Windows Event ID 4769 where it is available and properly collected. A service ticket request is perfectly normal Kerberos activity: event 4769 is never equivalent to an attack. Detection must therefore look for behavioural deviations and combinations of signals.

  • Unusual volume of requests over a short period.
  • Abnormally high number of distinct services targeted.
  • Unusual source account or workstation for such requests.
  • Request sequence inconsistent with the expected application usage.
  • Unexpected encryption types in that specific context.
  • Correlation with other reconnaissance or lateral movement activity.

The same caution applies to RC4: its use is not proof of Kerberoasting. It can be a useful signal in some environments, but it must be interpreted with knowledge of the legacy applications still in production.

How do you break the attack path?

The measures that work are rarely spectacular. They start with regaining control over service accounts, then reducing what a compromise would allow.

  • 01

    Govern service accounts

    • Maintain an up-to-date inventory.
    • Assign a named owner to every account.
    • Document application usage and dependencies.
    • Remove unused accounts and orphaned SPNs.
    • Avoid accounts shared across several services where possible.

  • 02

    Strengthen secrets

    • Secrets that are long enough and genuinely random.
    • Rotation aligned with the criticality of the account.
    • Automated rotation wherever the application allows it.
    • Use of gMSA where they fit the use case and are supported by the application.
    • Vaulting for the secrets that cannot be automated.

  • 03

    Reduce privileges

    • Remove groups and rights that are no longer needed.
    • Prevent application service accounts from holding administrative privileges without justification.
    • Analyse indirect access obtained through groups, ACLs, delegations or resources.
    • Separate accounts by environment and sensitivity level.

  • 04

    Harden Kerberos and the environment

    • Inventory dependencies before any cryptographic change.
    • Test application compatibility on a limited scope first.
    • Roll out progressively, environment by environment.
    • Address in parallel the other legacy mechanisms that give the attacker alternatives.

  • 05

    Monitor

    • Centralise the relevant domain controller events.
    • Build usage baselines per account and per service.
    • Favour behavioural analysis over a single detection rule.
    • Correlate with other identity and lateral movement signals.

What an Ariovis audit looks at

A useful assessment does not stop at producing the list of accounts carrying an SPN. That list is easy to obtain and says nothing about where to act first.

  • Which accounts are genuinely exposed, and from which perimeters.
  • Which ones show weak secrets or insufficient management practices.
  • Which privileges they hold, directly and through inheritance.
  • Which resources and applications they give access to.
  • Which relationships would allow progression towards a critical asset.
  • Which fixes break several attack paths at once.
  • Which fixes can be applied quickly, without risk of outage.
  • Which fixes require a more structural transformation.
We prioritise by risk and by genuinely exploitable paths, not by the raw number of findings. A 400-line report helps nobody decide; ten fixes that remove the paths to Tier 0 do.

Go further

Ariovis content that directly extends this topic.

Do you know which service accounts open a path to your critical resources?

Ariovis analyses your service accounts, their secrets, their privileges and their position in your directory's attack paths, then delivers a prioritised remediation plan.

Assess your Active Directory attack pathsSee the Active Directory security offer