What makes an Active Directory account 'roastable', and what does roasting one actually hand an attacker?
answer
- a property, not an exploit
- any ordinary account can ask
- two doors: an SPN or pre-auth off
- the grind happens offline
- you get a password, not a ticket
basics
~20 sAn account is roastable if it carries a Service Principal Name or has Kerberos pre-authentication disabled. Either lets any ordinary user request material sealed with the account's password-derived key, which the attacker then cracks offline to recover the cleartext password.
solid answer
~50 sTwo properties make an account roastable. If it carries a Service Principal Name, any authenticated domain user can ask the directory for a service ticket for it, and part of that ticket is sealed with a key derived from the account's password. If it has 'do not require pre-authentication' set, an attacker can pull a similar sealed blob without even holding a valid account. Neither request is an exploit — each is a normal, authorized directory operation — so the attacker's cost of asking is essentially zero. The real work is offline: with no lockout and no rate limit, he grinds password guesses against the sealed material until a weak, human-chosen password falls. What he walks away with is the cleartext password itself, not a ticket to replay, so roasting only pays off when a person picked that password.
go deeper
Be ready to name the two properties — an SPN, or pre-authentication disabled — and to say the payoff is a cleartext password recovered offline, not a reusable ticket.
Explain why the request is a normal authorized operation with no special privilege, and why moving the guessing offline removes lockout and rate limits.
Show you would triage which roastable accounts are worth the compute rather than roasting everything, and connect the payoff to how the account's password was set.
Frame roasting as a standing property of any estate that runs human-chosen service passwords, and own the decision of whether to accept the risk or engineer it away.
## What 'roastable' means In an **Active Directory** domain, authentication is brokered by a ticketing service. When it issues authentication material, part of that material is encrypted with a key derived from the target account's password. That is fine as long as an attacker cannot obtain the material without already being that account — but two configurations break that assumption, and an account in either state is called *roastable*. ## Door one: a Service Principal Name (SPN) An **SPN** is a label that says 'this account runs a network service' (a database, a web app, a reporting service). - Any *authenticated* domain user — a single ordinary account, a student, a contractor — is allowed to request a service ticket for any SPN, because requesting a ticket to talk to a service is exactly what the protocol is for. - Part of that ticket is sealed with the service account's password key. - The attacker never talks to the service; he just extracts that sealed blob. This is ***Kerberoasting***. ## Door two: pre-authentication disabled Normally an account must prove it knows its password before the directory hands back material sealed with that password's key. An account flagged 'do not require pre-authentication' skips that proof, so an attacker can request the sealed material for that account **without holding any valid account at all** — he only needs the username. This is ***AS-REP roasting***. ## Why it is not an exploit, and not patchable - Nothing is broken here. The requests are ordinary, **authorized directory operations**. - There is no software flaw and therefore no patch — roastability is a *standing property* of how the account is configured plus how its password was chosen. - A domain can be fully current on updates and still be full of roastable accounts. ## What the attacker gets The product of roasting is the account's **cleartext password**, recovered by cracking — not a ticket he replays and not any elevated right by itself. That distinction matters: replaying a stolen ticket is a different technique with different requirements; roasting converts to a real compromise only when the sealed material's password is weak enough to crack, and only insofar as that password is worth something (it opens other systems, or the account is privileged). ## Why the grind happens offline Once the attacker holds the sealed blob, every guess is computed locally: 1. derive a candidate key from a guessed password, 2. test it against the blob, 3. repeat. Nothing further touches the domain, so there is no account lockout, no rate limit, and no throttle but the attacker's own compute. That is why the payoff hinges entirely on whether a human chose a **crackable password** — an account whose password is a long, machine-generated key is roastable in the mechanical sense and worthless in the economic one. ## The one-line takeaway for an interview Roastable = 'an SPN or pre-auth off' *plus* 'a human-chosen password.' - The request is free and authorized. - The cost and the payoff both live in the **offline crack**.
- Does requesting the sealed material require any special privilege in the domain?No. Any single valid domain account can request a service ticket for any SPN, and AS-REP roasting a pre-auth-disabled account needs no authenticated account at all — just the username. The barrier is never access to the request; it is whether the password behind the account is weak enough to crack afterward.
- Why is roasting called an offline attack when the initial request goes to the directory?Only that first request touches the directory, and it is an ordinary authorized operation. Once the attacker holds the sealed blob, every password guess is computed locally against it, with no further contact with the domain — so no lockout, no rate limit, and nothing throttles him but his own compute.
- If a service account uses a machine-generated password, is it still roastable?Mechanically yes — the attacker can still request the material — but it is worthless. Roasting only becomes a real compromise when the recovered password is crackable, and a long random machine-generated key is not, so those accounts are roastable in name only and a competent attacker ignores them.
It is like a locked box whose key is stamped from a phrase: anyone may take a photo of the box, and if the phrase was 'summer2019' they will reproduce the key at their kitchen table. A random 120-character phrase leaves the same photographable box, but the key is never reproduced.
saying these in an interview costs you the question
- Claiming you need admin rights to roast an account
- Saying roasting yields a ticket you replay rather than a password
- Treating it as a vulnerability you patch
- Believing the domain controller stops the attack once it starts