Kerberoasting and AS-REP Roasting Defence Guide

Any authenticated domain user can ask a domain controller for ticket material encrypted with a service account's password, and if that password is weak the account falls to offline cracking without a single failed logon. That is Kerberoasting (MITRE ATT&CK T1558.003); its sibling AS-REP roasting (T1558.004) needs no authentication at all against accounts with Kerberos pre-authentication turned off. Both target service accounts and other non-human identities more than people. This guide goes deeper than the Kerberos Security Guide: exposure inventory, the 2026 RC4 changes, gMSA and dMSA migration, event fields worth alerting on, and a phased plan. It is for AD engineers, identity owners and detection teams, and it contains no attack tooling or procedures.

Key takeaways

The weakness is the password, not the protocol. Issuing a service ticket on request is normal Kerberos; the risk is a human-set password on an account with a service principal name (SPN).
Managed accounts close the hole. gMSA passwords are 120 random characters and rotate automatically; Windows Server 2025 dMSAs bind the secret to the machine and keep it only on domain controllers.
AES helps but does not fix weak passwords. Microsoft is explicit that AES alone does not stop brute force; move off RC4 for detection value and cost, then fix the password.
2026 changed the defaults. CVE-2026-20833 updates moved domain controllers to AES-only defaults for accounts without explicit encryption types, with Kdcsvc events 201 to 209 showing what would break.
Pre-authentication off is a finding, every time. Event 4768 with Pre-Authentication Type 0 should be rare enough to alert on; the fix is a checkbox.

How the attack works

At concept level only. In Kerberos, a client holding a ticket-granting ticket (TGT) asks the Key Distribution Center (KDC) on a domain controller for a service ticket for an SPN. Part of that ticket is encrypted with a key derived from the password of the account that owns the SPN. The KDC does not check whether the requester is entitled to use the service; that is the service's job. ATT&CK describes adversaries requesting tickets "for any SPN" and attacking the RC4-encrypted portion offline (T1110.002 Password Cracking). Nothing touches the service itself and no failed logon is generated.

AS-REP roasting targets the first exchange instead. Normally the client proves knowledge of its password by encrypting a timestamp (pre-authentication). If an account has "Do not require Kerberos preauthentication" set, the KDC answers an unauthenticated request with material protected by the account's key, which can likewise be cracked offline. Microsoft's event documentation calls that setting a security risk.

	Kerberoasting (T1558.003)	AS-REP roasting (T1558.004)
Target accounts	User accounts with an SPN (computer accounts have long random passwords)	Accounts with pre-authentication disabled
Prerequisite	Any valid domain credential	Network reach to a DC and a username
DC event	4769, service ticket requested	4768, TGT requested, Pre-Authentication Type 0
Weakest case	Ticket Encryption Type 0x17 (RC4-HMAC), old human password	RC4 reply, old human password
Root fix	gMSA or dMSA, or long random password with AES	Require pre-authentication
Variant to watch	Targeted Kerberoasting: an SPN added to an account someone can write to	Pre-authentication flag switched off on an account someone can write to

Where it shows up

Legacy service accounts: SQL Server, IIS application pools, backup, scanning and middleware accounts created years ago with passwords set by a person and marked never to expire. Microsoft notes that accounts created before Windows Server 2003 support, and never reset since, have no AES keys at all.
Privileged service accounts: an SPN account in Domain Admins or with rights on tier 0 turns one cracked password into domain compromise. See the BloodHound and Active Directory Attack Path Guide.
Accounts with leftover SPNs: user accounts that once ran a service and kept the SPN after the service moved.
Interop accounts: accounts used by Linux, Java or appliance services through exported keytabs, which is also where RC4-only keys linger. See the Linux Service Accounts and Keytab Management Guide.
Pre-authentication exceptions: usually set for an old UNIX or vendor integration and never removed.
Writable user objects: where helpdesk or delegated groups hold write rights over accounts, targeted Kerberoasting can create exposure that did not exist. See the Active Directory ACL and Delegation Hygiene Guide.

Impact

Credential theft at scale and in silence: every SPN account can be tried, and the cracking happens off your network.
Privilege escalation: service accounts frequently hold local admin on many servers, database owner rights or directory permissions.
Long-lived access: service account passwords are rarely rotated, so a cracked one can stay valid for years and is hard to tell apart from normal service logons. See the Service Account Security Guide.

Detection

Enable Audit Kerberos Service Ticket Operations and Audit Kerberos Authentication Service on all domain controllers and forward the Security and System logs. From the January 2025 cumulative updates, 4768 and 4769 carry new fields that make encryption analysis much easier: MSDS-SupportedEncryptionTypes and Available Keys for both the account and the service, Advertized Etypes from the client, and Session Encryption Type alongside Ticket Encryption Type.

Event or signal	Field and value	Why it matters
4769 service ticket	Ticket Encryption Type not 0x11 or 0x12 (Microsoft's own recommendation); 0x17 is RC4-HMAC	RC4 tickets are the cheap ones to crack and are often requested deliberately
4769 volume	One Account Name requesting tickets for many distinct Service IDs in a short window	Microsoft lists a single user requesting many tickets for vulnerable accounts as a Kerberoasting indicator
4769 honey SPN	Any request for a decoy SPN on an unused account with a long random password	No legitimate client should ever ask for it, so it gives a high-fidelity alert. See the Honeytokens and Canary Credentials Guide
4769 Client Address	Requests for sensitive Service IDs from outside an allow list of hosts	Microsoft suggests allow-listing which accounts and addresses request which services
4768 TGT	Pre-Authentication Type 0	Logon without pre-authentication: AS-REP roasting exposure or activity
Kdcsvc 201 to 209 (System log)	RC4 usage warnings, blocks and denials	Shows accounts and clients still relying on RC4
Directory change auditing	servicePrincipalName or userAccountControl changes on user accounts (Audit Directory Service Changes)	Catches targeted Kerberoasting and pre-authentication being switched off
Defender for Identity	Alert external ID 2410, suspected Kerberos SPN exposure	Vendor detection Microsoft points to in its Kerberoasting guidance

Expect false positives from vulnerability scanners, monitoring tools and some admin consoles that enumerate SPNs; allow-list them by source host and account, and review the allow list quarterly. See the Active Directory Security Monitoring and Event IDs Guide.

Prevention and hardening

Remove exposure first

Inventory SPN accounts: list every user object (not computer) with a servicePrincipalName, its group memberships, password age, msDS-SupportedEncryptionTypes and owner. Treat this as part of the service account register. See the Service Account Inventory Template.
Delete SPNs that are not used: Microsoft recommends auditing user accounts with SPNs and removing SPNs from accounts that do not need them.
Take SPN accounts out of privileged groups: grant the specific rights a service needs instead.
Require pre-authentication: clear "Do not require Kerberos preauthentication" on every account (the DONT_REQ_PREAUTH bit in userAccountControl). Where a vendor claims to need it, get that in writing and give the account a long random password.

Replace human passwords

Option	Secret	Roasting resistance	Constraints
gMSA	120 random characters, rotated by AD	Cracking is not practical	Host must support gMSA; password readable by authorised hosts, so it can still be stolen from them
dMSA (Windows Server 2025)	Random, machine-bound, retrievable only from the DC	Strongest; Microsoft states it helps prevent Kerberoasting	All hosts using it must support dMSA; cannot migrate from gMSA; unconstrained delegation stops working
Standard account, vaulted random password	Long random password, rotated by a PAM tool	Good if length is high and rotation works	Microsoft's floor is 14 characters, longer preferred; at least 30 random characters is a sensible house standard
Standard account, human password	Whatever someone chose	Poor	Retire

dMSA migration runs in two steps, Start-ADServiceAccountMigration and Complete-ADServiceAccountMigration. Microsoft asks for at least two ticket lifetimes (14 days) between them and recommends 28 days, healthy replication, and Credential Guard on the hosts. Completion copies SPNs and delegation settings to the dMSA and disables the original account. See the Windows Services and Service Account Security Guide and the gMSA Guide.

Move off RC4 without an outage

Know the defaults: since the November 2022 updates (CVE-2022-37966), accounts without an explicit encryption type default to AES. The CVE-2026-20833 changes went further: audit from 13 January 2026, enforcement with manual rollback from 14 April 2026, and the RC4DefaultDisablementPhase rollback value removed in updates from July 2026. Microsoft's own article is inconsistent about whether automatic enforcement began in April or July, so check the build on your DCs rather than the calendar.
Find RC4 users: Microsoft's Kerberos-Crypto scripts (List-AccountKeys.ps1, Get-KerbEncryptionUsage.ps1 -Encryption RC4) read the new event fields. Accounts with no AES keys need a password reset to generate them.
Set types explicitly on SPN accounts: msDS-SupportedEncryptionTypes 24 (0x18) means AES128 and AES256 only. Change the password after changing the value so AES keys exist.
Avoid the domain-wide override: Microsoft calls setting DefaultDomainSupportedEncTypes to 0x24 on all KDCs a last resort that leaves the domain exposed; scope RC4 exceptions to the named account instead.
Remember Server 2025: Windows Server 2025 domain controllers do not issue RC4 TGTs, so RC4-only devices fail there.

Rollout and rollback

Weeks 1 to 2: turn on auditing, build the SPN and pre-authentication inventory, deploy honey SPNs.
Weeks 2 to 6: remove unused SPNs and pre-authentication exceptions, reset passwords on accounts lacking AES keys.
Weeks 4 to 12: migrate services to gMSA or dMSA, highest privilege first, one service per change with the old account disabled (not deleted) for rollback.
Ongoing: set explicit AES types, clear Kdcsvc warnings, then enforce. Rollback for a single failing service is a scoped RC4 exception on that account, logged with an expiry date.

Lessons from incidents

Kerberoasting rarely appears by name in public breach write-ups because it happens after initial access and before the impact that makes the news. The recurring pattern in ransomware and intrusion reporting is the same: a phished or sprayed user credential, ticket requests for service accounts, a cracked password on an over-privileged account, then lateral movement. The defensive lesson is that the service account register, not the perimeter, decides how far that chain runs. See the Lateral Movement Guide and the Active Directory Domain Compromise Response Playbook.

Measuring progress

SPN exposure: number of user accounts with an SPN and a password older than one year, trending to zero.
Managed coverage: percentage of SPN services running as gMSA or dMSA.
RC4 tickets: daily count of 4769 events with Ticket Encryption Type 0x17, and Kdcsvc 201 to 209 events.
Pre-authentication exceptions: count of accounts with DONT_REQ_PREAUTH, target zero or a named, approved few.
Privileged SPN accounts: SPN accounts in tier 0 groups, target zero.
Detection test: honey SPN alert fires within your response SLA in a quarterly purple-team test.

Framework mapping

Framework	Reference
MITRE ATT&CK	T1558.003 Kerberoasting; T1558.004 AS-REP Roasting; T1110.002 Password Cracking; T1087.002 Domain Account discovery
ATT&CK mitigations	M1027 Password Policies; M1041 Encrypt Sensitive Information; M1026 Privileged Account Management; M1047 Audit
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management; AC-2 Account Management; AC-6 Least Privilege; SC-13 Cryptographic Protection; AU-12 Audit Record Generation
NIST CSF 2.0	PR.AA-01 identities and credentials managed; PR.AA-05 least privilege; DE.CM-01 monitoring
CIS Controls v8.1	Control 5 Account Management (including service accounts); Control 8 Audit Log Management

Practitioner checklist

Export every user account with an SPN, with owner, groups, password age and encryption types.
Remove unused SPNs and take SPN accounts out of privileged groups.
Clear "Do not require Kerberos preauthentication" everywhere and alert on 4768 Pre-Authentication Type 0.
Migrate SPN services to gMSA, or dMSA on Windows Server 2025, privileged services first.
Give any remaining standard service account a vaulted random password of at least 30 characters.
Set msDS-SupportedEncryptionTypes to AES on SPN accounts and reset their passwords.
Confirm DCs carry the CVE-2026-20833 updates and Kdcsvc events 201 to 209 are cleared.
Alert on 4769 with non-AES encryption, burst requests across many SPNs and any honey SPN request.
Audit servicePrincipalName and userAccountControl changes on user objects.

Kerberoasting and AS-REP Roasting Defence Guide: Hardening and Detecting Ticket Attacks