Kerberoasting

Plain-language definition

Kerberoasting is an attack technique in which an authenticated domain user requests Kerberos service tickets for service principal names and attempts to crack the ticket material offline to recover weak service-account passwords.

Kerberoasting is best understood as part of a larger security system rather than an isolated feature. Threat analysis connects an adversary or failure condition to the techniques, prerequisites, affected assets, observable evidence, and consequences involved.

How it works

A practical explanation of kerberoasting begins with the actors, components, trust decisions, and state changes involved. Reviewers should distinguish initial access, execution, persistence, privilege, credential access, movement, collection, command and control, impact, and recovery because controls differ by stage.

The following elements form the working model a learner should be able to identify in an architecture, configuration review, or incident timeline.

• Any authenticated user may normally request a service ticket for an advertised service, even without permission to use the application itself.
• The service ticket is protected with key material derived from the service account secret, allowing offline password guessing against captured ticket data.
• Human-managed service accounts with long-lived, predictable passwords create the greatest exposure.
• Encryption type influences cracking cost, but strong random secrets remain the central defense.
• A recovered service credential has the value of that account’s local, application, database, or directory privileges.

Why it matters

Weaknesses involving kerberoasting can turn a local configuration error into broader compromise, unreliable evidence, unauthorized access, or unsafe behavior. The business consequence depends on the assets and decisions that rely on the affected trust path.

The educational goal is to connect the technical mechanism to prevention, detection, response, recovery, governance, and measurable assurance. A control is not complete merely because a product setting exists; the organization must show that the intended behavior is deployed, observed, and maintained.

Common attack paths and failure modes

Adversaries and ordinary operational failures often exploit the assumptions surrounding kerberoasting rather than attacking the most visible component directly. Review the complete path from initial input or identity through authorization, execution, logging, and recovery.

Risk analysis should distinguish design flaws, insecure defaults, deployment gaps, stale exceptions, missing telemetry, and recovery weaknesses because each requires a different corrective action.

• Service accounts often accumulate broad rights because changing their passwords or dependencies is operationally difficult.
• Dormant SPNs can expose accounts for services that no longer exist.
• Attackers can request tickets from ordinary workstations and perform cracking elsewhere, reducing obvious on-host activity.
• High-volume detections alone may miss targeted requests for one valuable account.
• Rotating a password without finding the original intrusion and downstream use may leave the environment compromised.

Defensive design and controls

Defending kerberoasting requires layered controls selected for the actual environment, threat model, and consequence of failure. Preventive settings should be paired with independent evidence and an owned response process.

Controls are strongest when they use secure defaults, narrow privileges and interfaces, protect secrets, validate state transitions, record meaningful events, and support safe rollback or recovery.

• Use gMSAs or long, random, automatically rotated secrets for service accounts.
• Inventory SPNs and remove stale, duplicate, or unnecessary registrations.
• Grant each service account only the permissions required by its workload and deny interactive logon.
• Prefer supported strong Kerberos encryption and remediate legacy dependencies.
• Detect unusual service-ticket requests by user, host, volume, service sensitivity, and encryption type.
• After suspected exposure, rotate the account, review downstream access, investigate the requesting identity and host, and validate service continuity.

Detection, evidence, and validation

Validation for kerberoasting should combine configuration inspection, controlled functional testing, and operational evidence. No single log source or scanner proves continuing effectiveness.

Evidence should be time-bounded, attributable to the component that made the decision, and rich enough to distinguish expected use from error, abuse, and administrative override.

• Domain-controller events for service-ticket requests, including requester, service name, source address, and encryption type.
• SPN inventory mapped to account type, password management, privilege, host, application, and owner.
• Identity analytics showing a user requesting tickets for services outside normal behavior.
• Endpoint telemetry identifying the process and session associated with suspicious requests where available.
• Post-incident evidence that affected service credentials and dependent secrets were rotated.

Practical scenario

A SOC detects a workstation requesting service tickets for several high-value service accounts that the user has never accessed. The team isolates the host, confirms one service account uses a human-managed password, rotates it through a controlled outage, reviews its privileges, and investigates possible downstream use.

The team documents the expected result, the evidence observed, any residual risk, the owner of corrective work, and the conditions that require the test to be repeated. This converts a technical observation into an accountable security decision.

Safe practitioner lab

Perform this exercise only in an isolated lab, test tenant, disposable virtual machine, or intentionally vulnerable training application that you own or are authorized to assess. The objective is to observe and validate kerberoasting without affecting production systems.

Capture the starting configuration and create a rollback point before making changes. Record commands, screenshots, event identifiers, timestamps, and expected outcomes so the exercise can be reproduced.

• Use only a purpose-built lab domain and precreated low-privilege test service account; do not export or crack real organizational ticket material.
• Review a sanitized service-ticket event and identify requester, service principal, source, encryption type, and time.
• Compare the risk of a human-managed service password with a gMSA-generated secret.
• Write a detection hypothesis that uses service sensitivity and user baseline instead of relying only on ticket volume.
• Compare the observed result with the expected security outcome and explain any difference.
• Restore the original state, remove test accounts or data, and retain only sanitized learning notes.

Common misconceptions

• Deploying a product associated with Kerberoasting automatically makes the environment secure. Architecture, configuration, identity, operations, and maintenance still determine the result.
• A successful one-time test proves continuous effectiveness. Software, identities, policies, dependencies, and attacker behavior change over time.
• More logging is always better. Useful evidence must be relevant, timely, interpretable, protected, and connected to an owned response.
• A framework supplies one universal implementation. Guidance must be adapted to mission, system design, legal obligations, and risk tolerance.

Knowledge check

• What actors, components, and trust decisions define Kerberoasting?
• Which assumptions must remain true for the mechanism to be trustworthy?
• What failure modes create the greatest business or mission consequence?
• Which preventive and detective controls provide independent layers of protection?
• What evidence would demonstrate normal behavior, attempted abuse, and successful recovery?

Certification relevance

This subject appears in or supports the following certification bodies of knowledge:

Authoritative sources

• Microsoft Windows security documentation
• Microsoft Active Directory Domain Services documentation
• MITRE ATT&CK — Enterprise techniques