Kerberoasting and AS-REP Roasting Explained

Kerberoasting is an Active Directory attack in which any authenticated domain user requests Kerberos service tickets for service accounts and then guesses those accounts’ passwords offline. It works against any account that has a service principal name (SPN), because part of each ticket is encrypted with a key derived from that account’s password. AS-REP roasting does the same to accounts set to “Do not require Kerberos preauthentication”, and needs only a username. Neither needs an exploit, admin rights or a failed logon, and the fix for both is in your account settings, not in a patch.

Our Active Directory security assessment tests for both from one ordinary user account, at a fixed $6,000 for one domain (the Small tier on the internal network penetration testing price page), with a free retest of what you fix.

How Kerberoasting works

Kerberos is the ticket-based sign-in protocol Active Directory uses: a user proves their password to a domain controller once and receives a ticket-granting ticket (TGT), then presents it to get a service ticket for each service they reach, such as SQL Server or an IIS application. The domain controller encrypts part of the service ticket with the long-term key of the account that owns the SPN, a key derived from that account’s password, and leaves the access decision to the service. As Microsoft’s Kerberoasting guidance says, any Active Directory user can request tickets for accounts with SPNs.

So an attacker holding any domain account, usually a phished employee’s or one captured on the internal network with a tool such as Responder, lists the user accounts with SPNs through ordinary directory queries, requests a ticket for each and takes the tickets away. The guessing then happens on the attacker’s own hardware, with no lockout, no failed-logon event and no limit. A guess that decrypts the ticket is the password.

MITRE ATT&CK tracks this as T1558.003 and records its use by Wizard Spider, FIN7 and APT29 (in the SolarWinds compromise). CISA’s Akira ransomware advisory lists it among that group’s post-exploitation techniques. Tim Medin presented it publicly in 2014, and it still works because the protocol is behaving as designed.

Computer accounts have SPNs too, but Windows gives them long random passwords. The exposure is user accounts with SPNs: service accounts created by hand, with passwords a person chose.

Why RC4 made it cheap, and what changed in 2026

Guessing speed depends on the ticket’s encryption type. Under RFC 4757, an RC4-HMAC key (encryption type 0x17) is the unsalted MD4 hash of the password, identical to the account’s NT hash, so deriving the key for each guess takes a single fast hash. Under RFC 3962, an AES key (types 0x11 and 0x12) comes from PBKDF2 with a salt built from the realm and principal name and 4,096 iterations by default, so deriving it takes thousands of hash operations.

Microsoft has now retired RC4 as the default. Under its CVE-2026-20833 rollout, January 13, 2026 updates added KDCSVC audit events 201 to 209, April 14, 2026 updates made AES the domain controller default for accounts with no explicit encryption setting, and updates from July 2026 removed the rollback option. Kerberoasting survives the change for three reasons:

1. AES slows guessing; it does not stop it. Attackers try likely passwords first, and Microsoft’s guidance notes that AES does not save a weak password.
2. Explicit settings are honored. An account whose msDS-SupportedEncryptionTypes attribute includes RC4 still gets RC4 tickets, and so does every default account if DefaultDomainSupportedEncTypes was set to include RC4, a configuration the domain controller flags with KDCSVC event 205 but does not block.
3. The rollout invites a bad fix. Accounts whose passwords were last set before the domain reached the Windows Server 2008 functional level have no AES keys (Microsoft’s event 4769 reference explains when they are created), so their services break under the new default, and the quick fix is to enable RC4 on them again. Resetting the password to a long random value creates the missing AES keys, so the service works without re-enabling RC4.

AS-REP roasting (asreproast)

Kerberos pre-authentication makes the first request to a domain controller carry a timestamp encrypted with the user’s key, proving the user knows the password. With it disabled, anyone who knows the username can request a ticket-granting ticket, and the reply contains data encrypted with that user’s password-derived key, open to the same offline guessing. MITRE tracks this as T1558.004; testers often call it asreproast, after the function name in common tooling.

It is rarer than Kerberoasting because someone has to switch pre-authentication off, usually for an old UNIX or Java client or during troubleshooting nobody undid. Research Semperis published in September 2022 showed that such an account can also be used to request service tickets for other accounts, so a single account without pre-authentication lets someone with no domain password, only a list of likely service-account names, Kerberoast the domain. Microsoft’s security response center called the behavior by design.

	Kerberoasting	AS-REP roasting
MITRE ATT&CK	T1558.003	T1558.004
Precondition	A user account with an SPN	An account with pre-authentication disabled
What the attacker needs	Any domain account (or an AS-REP roastable one)	Only a username
Domain controller event	4769, service ticket requested	4768 with Pre-Authentication Type 0
Primary fix	Managed service accounts or long random passwords, AES only	Require pre-authentication

Targeted Kerberoasting: when the attacker adds the SPN

An account that can write another user’s servicePrincipalName attribute can add an SPN, request a ticket and remove the SPN again, which makes any account kerberoastable, administrators included. BloodHound shows this right as the WriteSPN edge, and GenericWrite or GenericAll over a user grant it too. The same rights over userAccountControl let an attacker switch off pre-authentication on a chosen account and AS-REP roast it.

The SPN change is not logged by default: it produces Event ID 5136 only when directory service change auditing is on and the user objects carry an auditing entry for that attribute. Switching off pre-authentication shows in Event ID 4738 as “‘Don’t Require Preauth’ - Enabled”, a flag Microsoft says should not be enabled for user accounts.

Where Kerberoasting sits among Kerberos attacks

Attack	What the attacker needs	What it yields	Our guide
User enumeration and password spraying (T1110.003)	Network access to a domain controller	Valid usernames, then a weak password	Kerbrute
Kerberoasting and AS-REP roasting (T1558.003, T1558.004)	Any domain account, or only a username for AS-REP	Account passwords, guessed offline	This page
Pass-the-ticket (T1550.003)	A ticket stolen from memory	Access as that user, no password needed	Rubeus
Golden and silver tickets (T1558.001, T1558.002)	The krbtgt key or a service key	Forged access and persistence	Golden and silver tickets

What a successful roast says about your domain

When Kerberoasting or AS-REP roasting appears in a penetration test report, the finding usually bundles four problems:

• A user account carries an SPN it may not need. Legacy SQL Server, IIS, backup and ERP accounts are the usual owners, some for services retired years ago.
• A person chose the password, often at installation, with “password never expires” on because changing it might break something.
• The account has more rights than its job needs. Service accounts land in Domain Admins to make an installer work, so a cracked password becomes a direct privilege escalation path to the domain. MITRE’s mitigation M1026 says to keep them out of privileged groups.
• Nothing alerted when a workstation requested a batch of service tickets.

Impacket and Rubeus are the tool names that usually appear beside these findings, NetExec is often what listed the roastable accounts, and Hashcat is what does the guessing.

Kerberoasting detection: log sources, event IDs and what they mean

Enable “Audit Kerberos Service Ticket Operations” and “Audit Kerberos Authentication Service” for success and failure on every domain controller, and forward the Security log off the box. Since the January 14, 2025 cumulative update, Windows Server 2016 and later write expanded 4769 and 4768 events that include the account’s available keys and the encryption types the client advertised, so a downgrade shows in a single event.

Behavior	Log source and event	What to look for	Tuning notes
Bulk ticket requests	DC Security log, 4769	One account requesting tickets for many user-account SPNs within minutes	Exclude computer accounts and krbtgt; baseline scanners
RC4 service ticket	DC Security log, 4769	Ticket Encryption Type 0x17	Since the April 2026 updates, only accounts (or a domain default) set to allow RC4
Downgrade	4769 expanded fields; KDCSVC events	An RC4 ticket for an account with AES keys; bursts of KDCSVC 203 or 208 from one host	A legacy device or a tool forcing RC4
AS-REP roasting	DC Security log, 4768	Pre-Authentication Type 0	Every hit is an attack or a misconfiguration
Service ticket through the initial exchange	DC Security log, 4768	Service Name other than krbtgt	The no-password variant; genuine requests, password changes included, log krbtgt, so any other value is suspect
Decoy request	DC Security log, 4769	Any ticket for a honeytoken SPN account no service uses	Close to zero false positives
Targeted roasting setup	5136 (needs auditing entries), 4738	An SPN added to a user; “‘Don’t Require Preauth’ - Enabled”	Configure attribute auditing first

Microsoft Defender for Identity raises “Suspected Kerberos SPN exposure” (external ID 2410) and “Suspected AS-REP Roasting attack” (2412) for this activity.

Volume thresholds miss an attacker who requests one chosen ticket; the decoy and the RC4 rule do not. A decoy works only if it looks real: a plausible name, an SPN, a long random password, and no use, ever.

How to prevent Kerberoasting: a service-account decision table

You cannot stop users requesting service tickets; Kerberos depends on it. You can make the tickets worthless. Inventory every user account with an SPN, with its password age, encryption setting and group memberships (our Active Directory hardening checklist has the queries), then decide each one:

Situation	Do this	Why
The SPN belongs to a retired service	Remove the SPN, then disable the account	No SPN, no service ticket
The account is in Domain Admins or another privileged group	Remove it first; grant only the rights the service uses	A cracked admin is a breach
A Windows service, IIS app pool or scheduled task that supports managed accounts	Move it to a group managed service account (gMSA)	Windows sets and rotates a 120-character password
Migrating a legacy service account, with a Windows Server 2025 domain controller	Consider a delegated managed service account (dMSA), after patching CVE-2025-53779 (BadSuccessor) and limiting who can create dMSAs	Migration disables the old password; loose dMSA rights are an escalation path
A third-party or non-Windows app that needs a normal account	A generated password of 25 or more characters, vaulted, AES only, rotated on a schedule	Microsoft’s minimum is 14 characters; MITRE suggests 25+
An app that truly needs RC4	The longest random password it accepts, an alert on every 0x17 ticket for it, and a replacement plan	RC4 tickets crack fastest
An account with pre-authentication disabled	Re-enable it; fix or isolate any client that breaks	Closes AS-REP roasting and the no-password variant
People or groups that can write SPNs or userAccountControl on other users, or create dMSAs	Remove the rights nobody can justify	Stops targeted roasting

For AES only, set the account’s encryption types to AES and then reset the password so AES keys exist. Do not add service accounts to Protected Users; Microsoft warns against it.

How Invadel tests for Kerberoasting, and what it costs

Kerberoasting and AS-REP roasting are a standard part of our Active Directory security assessment. Starting from one standard domain user, the access a phishing email usually yields, a senior tester finds every account with an SPN or without pre-authentication and everyone who can change those settings on others, requests the tickets any user can request, tests offline whether each password holds, and follows each recovered account toward Domain Admin. Every step is mapped to MITRE ATT&CK, so your defenders can replay the timeline against the events and alerts above; the covert version that grades detection directly is a red team.

Requesting a service ticket is ordinary Kerberos traffic: it locks no one out and changes nothing on your domain controllers. Testing runs under written rules of engagement, and a recovered privileged password goes to your contact as soon as we have it rather than waiting for the report. Each finding comes with proof, the account-level fix and the event IDs your team should alert on.

Engagement	What it tells you about Kerberoasting	From
Active Directory security assessment	Which SPN and no-pre-authentication accounts crack, who can make other accounts roastable, and where each recovered password leads	$6,000 for one domain (multi-domain quoted)
Internal network penetration test	The same, plus the hosts and services where a recovered service-account password also works	$6,000 Small, $9,200 Medium, $14,500+ Large
Red team	Whether your SOC notices one quiet ticket request inside a covert operation	$12,500 (see red team assessment cost)
Purple team	The 4769, 4768 and decoy-account rules above, run against live roasting until they fire	Quoted

Fixes are ranked by how many attack paths each one breaks, so a crackable service account sitting in Domain Admins comes before one with no rights, and the free retest requests the same tickets again once you have fixed the accounts. The price is fixed in writing and includes an attestation letter. Send your domain details through the scoping questionnaire, or see a sample report and all penetration testing prices.

Frequently asked questions

Is Kerberoasting still a thing in 2026? Yes. Microsoft’s 2026 changes made AES the default, which slows cracking, but any domain user can still request service tickets and a human-chosen password still falls to a good wordlist. CISA’s Akira ransomware advisory, revised in November 2025, lists the technique.

Can you prevent Kerberoasting? You cannot stop the ticket requests, because Kerberos allows them by design. You prevent the damage with managed service accounts or long random passwords, AES only, no unneeded SPNs and no privileged service accounts.

How do you detect Kerberoasting? On domain controllers, watch Event ID 4769 for RC4 (0x17) tickets and bursts of requests from one account, 4768 with Pre-Authentication Type 0 for AS-REP roasting, and any ticket for a honeytoken SPN account.

What is the difference between Kerberoasting and AS-REP roasting? Kerberoasting needs a domain account and attacks accounts with an SPN; AS-REP roasting needs only a username and attacks accounts without pre-authentication. Both end in offline password guessing.

How long does it take to crack a Kerberoasted password? It depends on the password and the ticket’s encryption type, not on the attacker’s patience. A password a person chose can fall to a wordlist, and guessing is fastest against an RC4 ticket, which Microsoft’s guidance notes uses no salt or iterated hash. AES makes every guess cost thousands of hash operations but does not rescue a weak password. A long random password is a different case: Microsoft describes gMSA passwords as highly resistant to brute force using currently known methods, which is why the fix is the password, not the cipher.

Does MFA stop Kerberoasting? No. Domain controllers issue Kerberos tickets to anyone holding a valid password, hash or logon session, and most MFA for Windows protects only the interactive sign-in, so a phished workstation or a stolen password is enough. Service accounts rarely have a second factor at all.

How much does a Kerberoasting test cost? There is no separate price: every Active Directory security assessment ($6,000 for one domain of up to a few hundred hosts) and every internal network test (from $6,000) roasts the domain, and the free retest confirms the accounts you fixed no longer crack.

The short version

Kerberoasting lets any domain user take service tickets away and guess service-account passwords offline; AS-REP roasting does the same with only a username, against accounts without pre-authentication. Make the tickets worthless with managed service accounts, long random passwords, AES and least privilege, and watch 4769 and 4768 on every domain controller. To learn which of your accounts would crack, see our Active Directory security assessment, check the internal network testing prices, or scope your test.