← All posts

Kerberoasting and AS-REP Roasting: Cracking Active Directory From a Single Foothold

Two of the quietest ways attackers turn one compromised Windows box into domain-wide credential theft — how Kerberoasting and AS-REP roasting work, and the host-level misconfigurations WinSentinel flags to shut them down.

Most lateral-movement war stories involve something loud: a dumped LSASS process, a Pass-the-Hash, an EDR alert that fired at 3 a.m. Kerberoasting is the opposite. It is one of the few post-exploitation techniques where an attacker who owns nothing more than a single unprivileged domain account can walk away with a crackable service-account password — and the domain controller will happily hand over the material to do it, because from Kerberos's point of view nothing abnormal happened at all.

That combination — high impact, near-zero noise, no admin rights required — is why Kerberoasting and its sibling AS-REP roasting show up in almost every real-world Active Directory compromise. The good news: both are enabled by concrete, auditable misconfigurations sitting on your machines and in your directory, and closing them is boring, mechanical hardening.

How Kerberoasting works

In Kerberos, any authenticated user can request a service ticket (a TGS) for any account that has a Service Principal Name (SPN) registered. That is not a bug; it is how a workstation asks "give me a ticket to talk to SQL." The catch is that part of the returned ticket is encrypted with the service account's own password hash. Request the ticket, pull it out of memory, and you now hold ciphertext you can grind offline until the plaintext password falls out.

Two things make this practical. First, service accounts are frequently human-managed accounts with weak, rarely-rotated passwords. Second, attackers can force the DC to issue the ticket using legacy RC4 (etype 23) encryption, which is orders of magnitude faster to crack than AES. Enumerating and requesting every SPN in the domain takes seconds:

# From any domain-joined host, no special rights needed
setspn -T corp.local -Q */*          # native: list every SPN

# Or with an offensive toolkit that also grabs the tickets
Rubeus.exe kerberoast /outfile:hashes.txt
python3 GetUserSPNs.py corp.local/lowpriv:Password1 -request

The output is a $krb5tgs$ hash per service account. Those go straight into a cracker — hashcat -m 13100 for RC4 TGS tickets — and a service account with a dictionary-strength password falls in minutes on commodity hardware. If that account happens to be a member of Domain Admins (still depressingly common for SQL and backup service accounts), the attacker just went from one foothold to owning the forest.

AS-REP roasting: the pre-auth variant

AS-REP roasting targets a different weakness: accounts with Kerberos pre-authentication disabled (the DONT_REQ_PREAUTH flag). Normally, before the DC issues an authentication reply it demands proof you know the password. Turn pre-auth off — often done years ago for a legacy Unix or appliance integration nobody remembers — and any unauthenticated attacker can request an AS-REP for that user and receive a blob encrypted with the user's password hash.

Unlike Kerberoasting, this needs no valid domain credential at all — just a username list. The resulting $krb5asrep$ hashes crack with hashcat -m 18200. Finding the vulnerable accounts is a one-liner against the directory:

# List every account with pre-auth disabled
Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol |
  Select-Object SamAccountName

Where a host-level audit fits

These are directory attacks, but the conditions that make them possible are exactly the kind of thing that rots quietly on the endpoints and accounts most tools never look at. WinSentinel runs locally with full power on a single machine — every module, no limits, free — and its Kerberos and credential checks surface the local half of the problem before an attacker weaponizes it:

You still fix the SPN and pre-auth issues in the directory — a host agent cannot rewrite your AD schema — but you close the encryption downgrade and cached-credential doors on the machines themselves, which is where an intruder actually lands.

The fixes that actually kill it

Detection matters, but both techniques have durable structural mitigations. Prioritize these:

  1. Move service accounts to gMSAs. Group Managed Service Accounts use 120-character, randomly generated passwords that the OS rotates automatically every 30 days. A Kerberoast hash from a gMSA is computationally uncrackable — this is the single highest-leverage change you can make.
  2. Where a gMSA is impossible, enforce 25+ character passwords on any account with an SPN. Length, not complexity, is what defeats offline cracking. Audit for SPNs on regular user accounts and question every one.
  3. Disable RC4 and DES; require AES. Set msDS-SupportedEncryptionTypes to AES-only across the domain so an attacker cannot request the cheap-to-crack RC4 ticket even if they wanted to.
  4. Turn pre-authentication back on for every account that has it disabled, then keep it that way. Treat DONT_REQ_PREAUTH as an incident-worthy misconfiguration, not a supported setting.
  5. Plant a honeypot SPN. Register an SPN on a decoy account with a long random password and no real service. Legitimate users never request its ticket, so a TGS request for it (Event ID 4769) is a high-fidelity Kerberoasting alarm.
Kerberoasting is not an exploit — it is Kerberos working exactly as designed against passwords that were never strong enough to survive offline cracking. You do not patch it; you remove the weak passwords and the fast-crack encryption it feeds on.

Scaling the check across a fleet

On one machine, the free WinSentinel agent already tells you whether that host permits weak Kerberos encryption or is leaking credentials — no ceiling on what a single box can inspect. The hard part in a real environment is answering the same question across hundreds of endpoints at once: which of my 300 machines still allow RC4, and did any drift back after last month's GPO change?

That fleet-wide rollup is what the Pro tier's central node is for — aggregating each agent's local findings into one view, tracking Kerberos-encryption and credential-hygiene posture across the whole estate, and firing a drift alert the moment a host regresses. The single-machine audit stays free and complete; Pro is the orchestration layer that lets a small team hold the line on every box without logging into each one.

Kerberoasting and AS-REP roasting will keep working as long as weak service-account passwords and RC4 tickets exist in a domain. Neither is exotic, and neither needs elevation — which is precisely why they belong on your standing hardening checklist, not your incident-response runbook. Audit for the local preconditions today, migrate your service accounts to gMSAs, and turn a domain-wide catastrophe back into a non-event.