← All walkthroughs

Kerberoasting to a privileged service account

Any domain user can request service tickets for accounts that run under a Service Principal Name; those tickets are encrypted with the service account's password hash, so they can be cracked offline — and service accounts are too often over-privileged.

On-prem Windows / Active Directory Intermediate Active DirectoryCredential AccessOffline Cracking
Authorized testing only. This is a conceptual, defensive-aware walkthrough that maps an attack path to MITRE ATT&CK, detection and mitigation, and links to references for the detail. It is not a copy-paste playbook. Use it only against systems you own or are explicitly permitted to test.

Scenario

An authorized internal engagement where you already hold one ordinary domain account (from a prior phase or a provided low-privilege user). The objective is to show whether weak service-account passwords and excessive service-account rights let a standard user escalate.

  1. 1

    Discovery

    Find accounts with an SPN

    As an authenticated user, enumerate domain accounts that have a servicePrincipalName set — these are the roastable targets. Note which look privileged (admin-sounding names, membership in sensitive groups) so cracking effort is spent where it matters.

    Detection

    LDAP queries that filter specifically for servicePrincipalName from a workstation are an early, catchable signal.

    Mitigation

    Minimise the number of SPN accounts, review their group membership, and alert on broad SPN enumeration.

  2. 2

    Credential Access

    Request and extract service tickets

    Request Kerberos service tickets (TGS-REP) for the chosen SPNs. The ticket is encrypted with the service account's password-derived key, so you receive crackable material without ever touching the service host — document which accounts yielded roastable tickets.

    Detection

    A burst of TGS requests (event 4769), especially for RC4 (0x17) encryption, from one account is a high-fidelity Kerberoasting signal.

    Mitigation

    Use group Managed Service Accounts (gMSA) with 120-character machine-managed passwords, and disable RC4 so tickets use AES.

  3. 3

    Credential Access

    Crack the ticket offline

    Crack the extracted tickets offline against a wordlist and rules. A service account with a weak or never-rotated password falls quickly; a strong or gMSA-managed one does not — the finding is the weak password policy on service accounts, not the protocol.

    Detection

    Offline cracking is invisible to the domain; detection relies on the request-side signals above and on honeypot SPN accounts that should never be roasted.

    Mitigation

    Enforce long, rotated service-account passwords (or gMSA), and plant a honeypot SPN account that alerts the moment it is requested.

  4. 4

    Privilege Escalation / Lateral Movement

    Use the recovered account

    Authenticate as the cracked service account and demonstrate the access its rights actually grant — often local admin on several hosts, or a path toward higher privilege. Report the specific over-permissioning, and stay within scope.

    Detection

    The service account logging on interactively or from unusual hosts, and new admin sessions, are detectable with logon auditing and tiering.

    Mitigation

    Apply least privilege to service accounts, keep them out of Domain Admins, and tier administration so one cracked account is contained.

    References crackmapexec · mimikatz

Key takeaways

  • Kerberoasting needs nothing more than one ordinary domain account — the crack happens entirely offline.
  • gMSA or long, rotated passwords plus AES-only tickets make the recovered material uncrackable in practice.
  • The real damage is over-privileged service accounts: least privilege and tiering turn a cracked account into a dead end.