How Kerberoasting Works
Kerberoasting exploits a design feature of the Kerberos authentication protocol, not a software vulnerability. In Active Directory environments, any authenticated domain user can request a Kerberos service ticket (TGS — Ticket Granting Service) for any account that has a Service Principal Name (SPN) registered. The Domain Controller issues the ticket encrypted with the service account's NTLM password hash.
The attacker does not need to be an administrator. They do not need access to the target service. They simply request the ticket — a normal, expected Kerberos operation — and take it offline for password cracking. The ticket is encrypted with the service account password, so the attack's success depends entirely on whether the password can be cracked.
Why Service Accounts Are the Target
Service accounts are disproportionately vulnerable to Kerberoasting for a set of compounding reasons. First, they typically have SPNs registered — that is a prerequisite for Kerberoasting to work, and SPNs are necessary for Kerberos authentication to services. Second, service account passwords are frequently short, simple, or have never been changed since initial deployment. Third, because service accounts are non-interactive, no one notices when a password has been compromised and is being used for lateral movement. Fourth, service accounts often carry elevated privileges — domain admin, local admin on multiple systems, or read access to file shares — making them high-value targets.
The combination of easy to request, easy to crack, and high privilege on compromise makes Kerberoasting one of the most operationally reliable lateral movement techniques in Active Directory environments.
AS-REP Roasting: The Related Attack
AS-REP Roasting is a related technique targeting accounts with Kerberos pre-authentication disabled. When pre-authentication is disabled on an account, any unauthenticated user can request an AS-REP response from the DC — without needing a valid password at all. The response includes material encrypted with the account's password hash that can be taken offline for cracking. The conditions are different from Kerberoasting (disabled pre-auth vs registered SPN) but the offline cracking approach and impact are identical. Both are enumerated by the same AD assessment tooling.
Detecting Kerberoasting in Windows Event Logs
Kerberoasting leaves traces in Windows security event logs, but the signal is low-fidelity by default and requires tuned collection to be useful.
Event ID 4769 — Kerberos Service Ticket Requested
Every TGS request generates Event ID 4769 on the Domain Controller. The event includes the requesting account, the service name, the ticket encryption type, and the failure code. On its own, 4769 is too high-volume to be actionable — in any active directory, thousands of these events fire every hour. The signal is in the details:
- Ticket Encryption Type 0x17 (RC4-HMAC). Modern Kerberos uses AES-256 by default. A TGS request that uses RC4-HMAC encryption — particularly for a service account with a long-established password — is anomalous in environments that have been migrated to AES. Kerberoasting tools default to requesting RC4 because RC4 hashes crack faster. A spike in RC4 TGS requests across multiple service accounts from a single workstation is a strong indicator.
- Multiple SPN requests from one account in a short window. Legitimate Kerberos clients request tickets for specific services they are connecting to. An account requesting TGS tickets for ten different SPNs in two minutes has a different pattern to legitimate use. The tool Rubeus, commonly used for Kerberoasting, requests all Kerberoastable SPNs in a single sweep.
- Requesting account is a standard user accessing high-privilege service SPNs. A standard user requesting a TGS for an SQL Server service account with domain admin rights is a low-probability legitimate event.
Event ID 4768 — AS-REP Roasting Detection
For AS-REP Roasting, the relevant event is 4768 (Kerberos Authentication Service request). An AS-REP Roasting attempt generates a 4768 event with a failure code of 0x6 (username does not exist) or succeeds against accounts with pre-auth disabled. The indicator is 4768 events for accounts with DONT_REQ_PREAUTH set, particularly from workstations that do not normally request authentication for those accounts.
SIEM Detection Patterns
Effective detection requires forwarding DC security logs (4769, 4768) to a SIEM and building correlation rules. The most reliable patterns are: (1) count of unique SPNs requested by a single account within a sliding 5-minute window exceeding a threshold (4–6 for most environments); (2) percentage of 4769 events using encryption type 0x17 from an account that normally generates 0x12 (AES) requests; (3) any AS-REP request for an account where DONT_REQ_PREAUTH is set in AD. Microsoft Defender for Identity (MDI) has pre-built detections for both attacks, but these require appropriate licensing and deployment of the MDI sensor on domain controllers.
Prevention: Active Directory Configuration Controls
Detection is useful but prevention is better. The following controls directly reduce Kerberoasting risk, ordered by impact.
1. Use Group Managed Service Accounts (gMSAs)
Group Managed Service Accounts are the primary defence against Kerberoasting for service account credentials. The Active Directory domain automatically manages gMSA passwords — they are 240-character random strings rotated every 30 days by default. The password is never known to any human administrator. Even if an attacker obtains the Kerberos ticket, the password cannot be cracked within any operationally useful timeframe.
gMSAs are supported by most Windows services and IIS application pools. They require Windows Server 2012 domain functional level or higher, which is now universal in maintained environments. The migration from traditional service accounts to gMSAs is the single highest-impact Kerberoasting mitigation available.
2. Enforce AES Encryption for Service Accounts
Where gMSAs are not yet deployed, forcing AES-256 encryption on service accounts makes offline cracking significantly harder. Set the msDS-SupportedEncryptionTypes attribute to require AES128/AES256 and disable RC4 by configuring the account's encryption type via Group Policy (Network Security: Configure encryption types allowed for Kerberos). This does not make the hash uncrackable, but it changes the attack from RC4 (fast crack) to AES256 (computationally impractical for strong passwords). This only protects accounts with passwords of sufficient length and entropy — it does not replace the need for strong passwords.
3. Set Long, Random Passwords on Legacy Service Accounts
For service accounts that cannot yet be migrated to gMSAs, password length is the primary defence against offline cracking. A 25+ character random password with full character set entropy makes RC4 cracking computationally infeasible with current hardware. The trade-off is operational: managing long random passwords for accounts that may need to be entered manually in application configuration is administratively burdensome. This is an interim measure — gMSA migration is the correct long-term solution.
4. Audit and Reduce SPN Registrations
SPNs are a prerequisite for Kerberoasting. Accounts with SPNs that are not actively used for service authentication should have those SPNs removed. This is particularly relevant for decommissioned applications where the service account remains in AD. Enumerate all SPN-bearing accounts with setspn -T yourdomain -Q */* and cross-reference against active services. Remove SPNs for inactive services and remove or disable accounts where the service has been decommissioned.
5. Disable Kerberos Pre-Authentication Selectively
The DONT_REQ_PREAUTH flag should only be set when a specific application requires it — it is not a default setting and is almost never legitimately required. Enumerate accounts with this flag set using Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} and review each one. Unless there is an active justification, enable pre-authentication. This directly closes AS-REP Roasting exposure.
6. Apply Least Privilege to Service Accounts
If a service account is compromised via Kerberoasting, the impact is determined by what the account can access. Service accounts with domain admin rights represent a full domain compromise on successful crack. Audit service account group memberships — particularly Domain Admins, Enterprise Admins, and local administrator groups on servers — and scope them down to the minimum required for the application to function. This does not prevent the attack but limits the blast radius.
Framework and Regulatory Mapping
Kerberoasting controls map directly to requirements across the major security frameworks applied to UK organisations.
NCSC CAF (Cyber Assessment Framework)
CAF Objective B2 (Identity and Access Control) includes Indicator of Good Practice B2.b — "Privileged accounts are carefully managed and controlled." Kerberoastable service accounts with elevated privileges, particularly without managed passwords, represent a direct gap against this indicator. CAF B2.c (Authentication) covers the use of strong authentication mechanisms; gMSA-based service accounts with system-managed 240-character passwords satisfy this indicator for service-to-service authentication.
CIS Controls v8
Control 5 (Account Management) and Control 6 (Access Control Management) both apply. Safeguard 5.3 (Disable Dormant Accounts) covers service accounts for decommissioned services. Safeguard 5.4 (Restrict Administrator Privileges) addresses the over-privileged service account problem. Safeguard 6.8 (Establish and Maintain a Secure Password Policy) covers minimum password requirements — 15+ characters for service accounts under CIS IG1.
DORA and NIS2
DORA Article 9(4) requires ICT security policies covering "authentication and access rights management including privileged access management." A Kerberoastable service account with domain admin rights represents a failure of privileged access management. NIS2 Article 21(2)(j) requires "access control policies and asset management" — unmanaged service accounts with excessive privileges are a direct gap.
What an Active Directory Assessment Produces
A thorough AD assessment enumerates every Kerberoasting-relevant condition in the environment:
- All accounts with SPNs registered, including the SPN value, account type, and last password change date
- Kerberoastable accounts scored by crackability (RC4 only vs AES, password age and complexity policy)
- All accounts with pre-authentication disabled (AS-REP Roasting exposure)
- Service accounts with Domain Admin, Enterprise Admin, or local admin group memberships
- SPNs registered on decommissioned or stale accounts
- Accounts eligible for migration to gMSA or Managed Service Account
The output is audit-grade evidence suitable for a remediation plan, a compliance assessment, or a DORA/NIS2 gap analysis. It maps each finding to the specific control that addresses it and prioritises by privilege level of the account exposed.
Identify Your Kerberoastable Accounts
IdentityFirstMRI enumerates all SPN-bearing accounts, scores them for Kerberoasting risk based on encryption type and password age, flags pre-auth disabled accounts, and maps findings to the specific remediation steps above. Read-only, no agents required, results in hours.
Active Directory Security Assessment