Kerberoasting has been sitting on the MITRE ATT&CK list since 2018, but 2026 is the year it finally forced Microsoft’s hand. In January 2026, Microsoft began shipping Kerberos protocol hardening updates tied to CVE-2026-20833, a Windows Kerberos information disclosure flaw (CVSS 5.5) that exists precisely because RC4-HMAC is still allowed as a fallback encryption type on most domain controllers. The April 2026 updates flipped the default so that accounts without an explicit encryption setting now get AES-SHA1 tickets instead of RC4, and full enforcement became permanent after July 2026. If your Active Directory environment still has service accounts issuing RC4 tickets, an attacker with nothing more than a standard domain user account can request a ticket, take it offsite, and crack the service account password without ever touching your logs in a way that looks unusual.
This tutorial walks through detecting and stopping Kerberoasting the way security teams are actually doing it in August 2026: auditing which service accounts are exposed, reading the right Windows Event IDs, migrating to AES-only Kerberos tickets, rotating exposed credentials to Group Managed Service Accounts, and wiring up detection rules in Microsoft Defender for Identity and a SIEM. By the end you’ll have a working PowerShell audit script, a Splunk/Sentinel detection query, and a hardened AD environment that no longer hands attackers crackable password hashes on request.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Kerberoasting Actually Is (and Why It Still Works in 2026)
Kerberoasting is a credential-theft technique cataloged as MITRE ATT&CK T1558.003 that abuses a completely legitimate feature of the Kerberos authentication protocol used by every Active Directory domain. Any authenticated domain user, even a low-privilege one, is allowed to request a Kerberos service ticket (a TGS, or ticket-granting service ticket) for any service that has a Service Principal Name (SPN) registered in AD. That ticket is encrypted with a key derived from the service account’s own password. The attacker doesn’t need to touch the domain controller’s memory or trigger an alert to get it, they just ask for it, which is a normal part of everyday Kerberos authentication.
Once the attacker has that ticket, they take it offline and try to crack the password hash with tools like Hashcat, completely outside the network where no defensive tooling can see it happening. If the service account was still using RC4-HMAC encryption, cracking is fast because RC4’s key derivation is comparatively weak and doesn’t include the salting that AES tickets get. If the service account has a short or dictionary-guessable password, even AES tickets eventually fall. According to Microsoft’s own guidance on mitigating Kerberoasting, “administrators can use the techniques described below to detect Kerberoasting cyberattacks in their network,” specifically recommending teams check for ticket requests with unusual Kerberos encryption types and repeated service ticket requests as the two clearest signals. That’s the foundation this entire tutorial is built on: encryption-type auditing plus request-volume monitoring.
What makes Kerberoasting dangerous rather than merely theoretical is what service accounts tend to have access to. They’re frequently over-privileged (sometimes with Domain Admin rights inherited from years of “just make it work” IT decisions), rarely rotated because rotating a service account password used to mean an outage, and often set up with static, human-typed passwords instead of the long random secrets a properly configured account should have. Crack one SQL service account password and an attacker can move laterally into a database server, a backup system, or in the worst case, escalate straight to domain-wide control.
Why Kerberoasting Keeps Showing Up in Ransomware Kill Chains
Kerberoasting rarely appears as the opening move in an attack. It shows up in the middle, after an attacker has already established a foothold through phishing, an exposed VPN credential, or exploitation of an internet-facing vulnerability, and needs a way to move from “one compromised laptop” to “control of the domain.” That middle-stage role is exactly what makes it so persistent: it doesn’t trigger endpoint antivirus, it doesn’t require malware, and from the domain controller’s point of view it looks like an ordinary Kerberos ticket request because, technically, it is one. Threat intelligence coverage through 2025 and into 2026 consistently places Kerberoasting alongside NTLM relay and Pass-the-Hash as one of the small set of credential-abuse techniques that repeatedly turns a single-endpoint compromise into a full domain compromise, particularly in ransomware intrusions where the attacker’s entire goal is reaching Domain Admin fast enough to disable backups and deploy the encryptor before the SOC can respond.
The reason RC4 specifically matters so much in that chain comes down to time. An AES256 ticket for a strong, randomly generated password is not meaningfully crackable with commodity hardware in the hours an attacker typically has before detection. An RC4 ticket for a service account with a human-chosen, 12-character password can fall in minutes on a single modern GPU. That gap between “minutes” and “computationally infeasible” is the entire reason Microsoft treated RC4 deprecation as urgent enough to force through CVE-2026-20833 rather than leaving it as an optional hardening recommendation buried in a best-practices document nobody reads. Every step in this tutorial exists to close that specific gap: remove RC4, remove weak static passwords, and reduce the standing privilege of the accounts an attacker would even bother targeting in the first place.
Prerequisites: Tools and Versions You’ll Need
This tutorial assumes you’re working in a Windows Server-based Active Directory environment. You don’t need every tool listed to follow along, but the audit and hardening steps assume access to a domain admin or delegated AD-auditor account. Here’s what to have ready before you start.
| Tool / Component | Minimum Version | Purpose in This Guide |
|---|---|---|
| Windows Server (domain controllers) | Windows Server 2019 or later (2025 preferred) | AES-only Kerberos ticket issuance, RC4 disablement |
| Active Directory PowerShell module (RSAT) | Included with Windows Server / RSAT for Windows 11 | SPN enumeration, encryption-type audit script |
| Microsoft Defender for Identity | Current sensor release, cloud-connected | Real-time Kerberoasting and SPN-exposure alerting |
| PingCastle | Latest release (community or Basic edition) | AD security posture scoring, weak-account discovery |
| Semperis Purple Knight | Latest free community edition | Independent AD/Entra ID indicator-of-exposure scan |
| SIEM (Splunk, Microsoft Sentinel, or Wazuh) | Any current build ingesting Windows Security logs | Event ID 4769/4768/4770 correlation and alerting |
| Rubeus (lab/red-team use only) | Latest GitHub release | Simulating Kerberoasting to validate detections |
A note on Rubeus and Impacket’s GetUserSPNs.py: both are legitimate, widely used offensive-security tools built for exactly this kind of testing, and you should only run them against systems you own or have written authorization to test. Every command in this guide that touches those tools is meant for a lab domain controller or an authorized penetration test, not production.
Step 1: Inventory Every Service Account With an SPN
You can’t protect what you haven’t found. The first step is a full inventory of every account in the domain that has a Service Principal Name registered, because every single one of those accounts is a valid Kerberoasting target. Run this from a domain-joined machine with the RSAT AD PowerShell module installed and an account that has read access to the domain.
Import-Module ActiveDirectory
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName, PasswordLastSet, msDS-SupportedEncryptionTypes, AdminCount |
Select-Object Name, SamAccountName, ServicePrincipalName, PasswordLastSet, `
@{N='EncryptionTypes';E={$_.'msDS-SupportedEncryptionTypes'}}, `
@{N='IsPrivileged';E={$_.AdminCount -eq 1}} |
Export-Csv -Path C:\Audit\spn-accounts.csv -NoTypeInformation
Write-Host "SPN-bearing accounts exported to C:\Audit\spn-accounts.csv"The msDS-SupportedEncryptionTypes column is the one to pay attention to first. A value of 0x18 (decimal 24) means the account is configured for AES128 and AES256 only, which is what you want. A blank value, a value of 0, or anything that still includes RC4 in the bitmask means that account is currently exposed to weak-encryption Kerberoasting. Sort the CSV by IsPrivileged = True first; those are the accounts an attacker will target for maximum blast radius, and they’re the ones you fix today, not next sprint.
Step 2: Understand the Windows Event IDs That Matter
Kerberoasting detection lives almost entirely inside three Windows Security event IDs generated on your domain controllers. Get familiar with all three before you write a single detection rule, because they correlate with each other and a Kerberoasting attempt usually shows up as a specific pattern across all of them, not just one isolated log line.
| Event ID | Name | What to Watch For |
|---|---|---|
| 4768 | A Kerberos authentication ticket (TGT) was requested | Correlate the requesting account with later 4769 activity to build a timeline |
| 4769 | A Kerberos service ticket was requested | The primary Kerberoasting signal; filter on encryption type (etype) and request volume per SPN |
| 4770 | A Kerberos service ticket was renewed | Long-lived or repeatedly renewed tickets for sensitive SPNs, a possible staging or persistence signal |
Event ID 4769 is where you’ll spend most of your time. Every time it fires, the log includes a Ticket Encryption Type field, and the values to know are 0x12 and 0x18 (AES256 and AES128, in the hex encoding most log tools display), versus 0x17, which is RC4-HMAC. A domain controller logging bursts of 4769 events with etype 0x17 against multiple distinct SPNs, from one user account, in a short window, is close to the textbook definition of a Kerberoasting attempt. Security researcher Will Schroeder, whose ADSecurity.org research effectively defined how the industry detects this technique, put it plainly: “Looking for TGS-REQ packets with RC4 encryption is probably the best method, though false positives are likely.” That caveat about false positives matters, because some legacy line-of-business applications still request RC4 tickets legitimately, which is exactly why Step 1’s inventory work has to happen before you turn on aggressive alerting.
Step 3: Enable the Right Audit Policy on Domain Controllers
None of the event-ID monitoring in Step 2 works if your domain controllers aren’t generating detailed Kerberos audit logs in the first place. Confirm the audit policy is enabled with this command, then push it through Group Policy if it isn’t already active domain-wide.
# Check current Kerberos Service Ticket Operations auditing
auditpol /get /subcategory:"Kerberos Service Ticket Operations"
# Enable success and failure auditing for Kerberos ticket operations
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enableApply this through a Group Policy Object linked to the Domain Controllers OU rather than setting it locally on each DC, so new domain controllers inherit the policy automatically. Once this is active, confirm events are actually landing in the Security log on a test DC before moving on, an empty log after enabling audit policy usually means the GPO hasn’t replicated yet or the policy is being overridden by a higher-precedence GPO.
Step 4: Build a SIEM Detection Query for Kerberoasting Patterns
With audit logging confirmed, the next step is turning raw 4769 events into an actual alert. The pattern you’re hunting for is one account requesting tickets for an unusual number of distinct SPNs in a short window, especially with RC4 encryption types mixed in. Here’s a Splunk search that implements Microsoft’s guidance on monitoring 4769 volume and encryption type together, adaptable to Microsoft Sentinel’s KQL with minor syntax changes.
index=wineventlog EventCode=4769
| where Ticket_Encryption_Type="0x17" OR Ticket_Encryption_Type="0x1"
| bucket _time span=10m
| stats dc(Service_Name) as distinct_spns, count as ticket_requests by _time, Account_Name, Client_Address
| where distinct_spns > 5 OR ticket_requests > 15
| sort - distinct_spns
| table _time, Account_Name, Client_Address, distinct_spns, ticket_requestsTune the thresholds (5 distinct SPNs, 15 requests in 10 minutes) against your own baseline before enabling this as a page-worthy alert; a batch job or monitoring tool that legitimately enumerates services can trip a poorly tuned rule. Run it in report-only mode for a week, review the accounts it flags, and add known-good service accounts to an allowlist before switching it to an active alert.
Step 5: Turn On Microsoft Defender for Identity Alerting
If your organization is already running Microsoft Defender for Identity, you get a meaningful chunk of Kerberoasting detection out of the box, but only if the sensor is deployed on every domain controller, not just the ones that seemed most important at rollout time. Defender for Identity raises alert ID 2410 for suspected Kerberos SPN exposure, and Defender XDR correlates that with wider identity telemetry to reduce false positives compared to a standalone SIEM rule.
If your organization is weighing Defender for Identity against other endpoint and identity detection stacks, see our breakdown of CrowdStrike Falcon vs. Microsoft Defender XDR for a fuller pricing and capability comparison. To confirm coverage, go to Microsoft Defender XDR, open Settings, then Identities, and check that every domain controller in your forest shows a “Healthy” sensor status. Any DC marked as unmonitored is a blind spot an attacker can exploit specifically because it isn’t watched. Once coverage is confirmed, review the Kerberos-related alert policies under Defender for Identity’s alert tuning settings and make sure “Suspected Kerberoasting attack” and “Suspected SPN exposure” (the underlying detections behind alert 2410) are both set to notify your SOC rather than being logged silently.
Step 6: Run PingCastle or Purple Knight for an Independent Posture Check
SIEM rules and Defender for Identity alerts catch attacks in progress. PingCastle and Semperis Purple Knight catch the exposure before an attack ever starts, by scoring your domain against known weak configurations, including SPN accounts with legacy encryption enabled, accounts with AdminCount set to 1 that also carry an SPN, and Kerberos pre-authentication disabled on accounts (a related technique called AS-REP Roasting, tracked separately as T1558.004).
# Run a standard PingCastle health check against the current domain
PingCastle.exe --healthcheck
# Output includes a "Kerberoasting" risk indicator and a scored HTML report
# Review the report at ad_hc_.html for the Stale Objects and
# Privileged Accounts sections specifically Run either tool quarterly at minimum, and immediately after any large service account provisioning push (a new ERP rollout, a new backup vendor, a new monitoring agent), since those are exactly the moments when a poorly configured SPN account with a weak password gets created and forgotten.
Comparing the Three Main Kerberoasting Detection Tools
Microsoft Defender for Identity, PingCastle, and Semperis Purple Knight all touch Kerberoasting detection, but they solve different halves of the problem, and most mature identity security programs end up running at least two of the three together rather than picking just one.
| Tool | Detection Style | Best Used For | Licensing |
|---|---|---|---|
| Microsoft Defender for Identity | Real-time, continuous sensor-based alerting (alert 2410) | Catching an active attack while it’s happening | Included in Microsoft 365 E5 / add-on license |
| PingCastle | Point-in-time domain health scan and risk scoring | Periodic posture audits, tracking hardening progress over time | Free community edition, paid Enterprise tier |
| Semperis Purple Knight | Point-in-time indicator-of-exposure scan across AD and Entra ID | Independent second opinion, hybrid identity coverage | Free community edition |
The practical pattern that works well: run Defender for Identity continuously as the real-time tripwire, and run PingCastle or Purple Knight quarterly (or after any major AD change) as the audit that catches exposure before it ever becomes an attack Defender for Identity has to alert on. Neither replaces the manual audit script from Step 1, since both tools score risk generically across many categories rather than giving you the specific, exportable, privilege-sorted list of every SPN account you need to actually work through the remediation backlog.
Step 7: Force AES-Only Kerberos Encryption Domain-Wide
This is the single highest-leverage hardening step in this entire tutorial. Microsoft’s current guidance for Windows Server 2025 domain controllers is explicit: DES and RC4 encryption suites should not be used for Kerberos. Set this through Group Policy under Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options, “Network security: Configure encryption types allowed for Kerberos,” and enable only AES128_HMAC_SHA1 and AES256_HMAC_SHA1.
Before you flip this switch domain-wide, audit which accounts actually have AES keys generated. An account that has never had its password reset since before AES support was enabled may only have RC4 key material, and forcing AES-only encryption without first generating AES keys will break authentication for that account, not just make it more secure.
# For each SPN account identified in Step 1, explicitly set AES-only
# encryption types (0x18 = AES128 + AES256, no RC4 fallback)
$accounts = Import-Csv C:\Audit\spn-accounts.csv
foreach ($acct in $accounts) {
Set-ADAccountControl -Identity $acct.SamAccountName -Enabled $true
Set-ADUser -Identity $acct.SamAccountName -Replace @{'msDS-SupportedEncryptionTypes' = 24}
Write-Host "Set AES-only encryption for $($acct.SamAccountName)"
}
# A password reset is required afterward so the account generates
# fresh AES key material; schedule this during a maintenance window
Microsoft’s own phased rollout illustrates why this matters as a 2026-specific action item: RC4 was quietly treated as an “assumed” fallback encryption type for years, meaning any account without explicit configuration silently got RC4 support. Starting in April 2026, that default changed to AES-SHA1, and after July 2026, the registry key that allowed reverting to the old assumed behavior (RC4DefaultDisablementPhase) stopped working entirely, so environments that never explicitly configured their service accounts are now the ones most exposed if they haven’t done the work in this step.
Step 8: Migrate High-Value Service Accounts to gMSAs
Encryption hardening protects tickets in transit and at rest, but it does nothing if the underlying password is short, static, and human-chosen. A Group Managed Service Account (gMSA) solves that by having Active Directory itself generate and automatically rotate a 240-byte random password, with no human ever knowing or typing it. That single property makes offline cracking of a Kerberoasted ticket practically infeasible, since brute-forcing a random 240-byte secret isn’t something Hashcat is going to finish in any usable timeframe.
# Create the KDS root key (one-time, per forest, if not already present)
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))
# Create a new gMSA for a SQL Server service, restricted to the
# specific member hosts allowed to retrieve its password
New-ADServiceAccount -Name "svc-sql-gmsa" `
-DNSHostName "svc-sql-gmsa.corp.example.com" `
-PrincipalsAllowedToRetrieveManagedPassword "SQLServers-OU-Group" `
-KerberosEncryptionType AES128,AES256
# Install and test on the target member server
Install-ADServiceAccount -Identity "svc-sql-gmsa"
Test-ADServiceAccount -Identity "svc-sql-gmsa"Not every legacy application supports gMSAs, especially older third-party software with hardcoded service-account logon assumptions. For those, fall back to a very long, randomly generated password (32+ characters, stored in a secrets manager like HashiCorp Vault rather than a spreadsheet) rotated on a fixed schedule, combined with strict AES-only encryption from Step 7. It’s not as strong as a gMSA, but it closes most of the practical attack window.
Step 9: Reduce Standing Privilege on Service Accounts
Even a perfectly hardened, AES-only, gMSA-backed service account is still worth attacking if it happens to sit in Domain Admins. Go back to the CSV from Step 1, filter for accounts where IsPrivileged = True, and challenge every single one: does a SQL service account actually need Domain Admin, or does it need db_owner on three specific databases? In the overwhelming majority of legacy environments, the answer is that someone added the account to a high-privilege group years ago to unblock a deployment and nobody ever walked it back.
Use delegated, scoped permissions through Active Directory Users and Computers’ Delegation of Control wizard, or better, through fine-grained group membership tied to exactly the resource the service needs. Document why each privileged service account has the access it has; if nobody can produce a reason within five minutes, that’s a strong signal the access should be removed, not preserved out of caution. This same over-privileging pattern is why a well-run vulnerability management program tracks identity risk alongside unpatched software, not as a separate workstream.
Step 10: Simulate an Attack to Validate Your Detections
A detection rule you haven’t tested is a detection rule you’re hoping works. In an isolated lab domain (never production), use Rubeus to simulate a Kerberoasting request and confirm your SIEM query from Step 4 and your Defender for Identity alert from Step 5 both fire as expected.
# Lab/authorized testing only. Requests a service ticket and outputs
# a crackable hash for the target SPN
Rubeus.exe kerberoast /outfile:hashes.txt
# Impacket equivalent from a Linux attack host, targeting a specific
# domain user with a known SPN
python3 GetUserSPNs.py corp.example.com/lowpriv-user:Password123! -dc-ip 10.0.0.10 -requestImmediately after running either command, pull the domain controller’s Security event log and confirm a 4769 event was generated with the expected encryption type and target SPN. If your SIEM alert doesn’t fire within the expected window, work backward through the audit policy in Step 3 and the query logic in Step 4 before assuming the attack technique itself failed, most detection gaps at this stage come from log forwarding or query threshold issues, not from Rubeus behaving unexpectedly.
Step 11: Set Up Continuous Monitoring for New SPN Accounts
A one-time audit goes stale the moment someone provisions a new application account next quarter. Schedule the inventory script from Step 1 as a weekly scheduled task, diff it against the previous week’s output, and alert your identity team whenever a new SPN-bearing account appears without going through the gMSA-first provisioning process you’ve now established.
# Scheduled weekly SPN drift check (save as a .ps1 and register via
# Task Scheduler on a management host)
$today = Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName |
Select-Object -ExpandProperty SamAccountName
$lastWeek = Get-Content C:\Audit\spn-baseline.txt
$new = Compare-Object -ReferenceObject $lastWeek -DifferenceObject $today |
Where-Object { $_.SideIndicator -eq "=>" }
if ($new) {
Send-MailMessage -To "[email protected]" `
-Subject "New SPN accounts detected" `
-Body ($new | Out-String) -SmtpServer "smtp.corp.example.com" -From "[email protected]"
}
$today | Out-File C:\Audit\spn-baseline.txtStep 12: Document the Program and Set a Review Cadence
The last step isn’t technical, it’s operational, and it’s the one most teams skip. Write down the encryption-type standard (AES-only, msDS-SupportedEncryptionTypes = 24), the gMSA-first provisioning policy for new service accounts, the SIEM alert thresholds from Step 4, and the quarterly PingCastle or Purple Knight review cadence in a short internal runbook. New hires on the identity team and auditors reviewing SOC 2 or ISO 27001 controls will both need this, and a program that lives only in one engineer’s head disappears the day that engineer changes teams. It’s worth cross-referencing this runbook against your organization’s broader incident response plan, since a confirmed Kerberoasting alert should trigger a defined escalation path rather than an ad hoc scramble.
Complete Working Project: A Kerberoasting Exposure Dashboard
Putting every step together, here’s a single PowerShell script that combines the SPN inventory, encryption-type audit, and privilege check into one report you can run on a schedule and email to your identity team. Save it as Get-KerberoastExposure.ps1.
Import-Module ActiveDirectory
$report = Get-ADUser -Filter {ServicePrincipalName -like "*"} `
-Properties ServicePrincipalName, PasswordLastSet, msDS-SupportedEncryptionTypes, AdminCount, Enabled |
ForEach-Object {
$encTypes = $_.'msDS-SupportedEncryptionTypes'
$isAesOnly = ($encTypes -eq 24)
$passwordAge = (New-TimeSpan -Start $_.PasswordLastSet -End (Get-Date)).Days
[PSCustomObject]@{
SamAccountName = $_.SamAccountName
Enabled = $_.Enabled
IsPrivileged = ($_.AdminCount -eq 1)
AesOnly = $isAesOnly
PasswordAgeDays = $passwordAge
RiskLevel = if (-not $isAesOnly -and $_.AdminCount -eq 1) { "CRITICAL" }
elseif (-not $isAesOnly -or $passwordAge -gt 365) { "HIGH" }
elseif ($passwordAge -gt 180) { "MEDIUM" }
else { "LOW" }
}
}
$report | Sort-Object RiskLevel, PasswordAgeDays -Descending |
Export-Csv -Path C:\Audit\kerberoast-exposure-report.csv -NoTypeInformation
$critical = ($report | Where-Object { $_.RiskLevel -eq "CRITICAL" }).Count
$high = ($report | Where-Object { $_.RiskLevel -eq "HIGH" }).Count
Write-Host "Kerberoasting exposure report complete: $critical critical, $high high-risk accounts found."Run this weekly through Task Scheduler, keep the CSVs in a versioned folder so you can track exposure trending down over time, and treat any CRITICAL row (a privileged account still on legacy encryption) as an incident-response-worthy finding, not a backlog ticket.
Sample Output: What a Clean vs. Exposed Environment Looks Like
Here’s what the exposure report from the previous step looks like in practice, comparing a domain that hasn’t done any hardening work against one that’s completed every step in this guide.
| Metric | Before Hardening | After Completing This Guide |
|---|---|---|
| SPN accounts on RC4/legacy encryption | 38 of 52 | 0 of 52 |
| Privileged (AdminCount=1) SPN accounts | 6 | 1 (justified and documented) |
| Service accounts migrated to gMSA | 0 | 41 |
| Average service account password age | 612 days | N/A (gMSA auto-rotates) / 45 days for non-gMSA |
| 4769 events with etype 0x17 (RC4) per week | ~1,200 | 0 (RC4 disabled domain-wide) |
5 Common Pitfalls When Hardening Against Kerberoasting
1. Forcing AES-only encryption before confirming AES keys exist. If an account’s password hasn’t been reset since AES support was introduced to the environment, it may only have RC4 key material. Flipping the encryption policy without a password reset breaks authentication instead of securing it.
2. Treating gMSA migration as all-or-nothing. Some legacy applications genuinely can’t use gMSAs. Trying to force every account through the same migration path on the same timeline stalls the whole project. Prioritize privileged and internet-facing service accounts first, and accept a longer timeline for the rest.
3. Setting SIEM alert thresholds without a baseline period. A rule that fires on any account requesting tickets for more than one SPN will drown your SOC in false positives from legitimate monitoring tools and batch jobs. Run new rules in report-only mode for at least a week before enabling paging alerts.
4. Forgetting AS-REP Roasting during a Kerberoasting-only audit. AS-REP Roasting (T1558.004) targets accounts with Kerberos pre-authentication disabled and is a close cousin of Kerberoasting that uses a different event pattern. An audit that only checks SPN accounts misses this entirely; PingCastle and Purple Knight both flag pre-auth-disabled accounts separately, so review that section of their reports too.
5. Not testing detections against a real attack simulation. A SIEM query that looks correct on paper can silently fail because of a field name mismatch, a log-forwarding gap, or a case-sensitivity issue in the encryption-type filter. Step 10’s Rubeus/Impacket validation isn’t optional if you actually want to trust the alert when a real attacker shows up.
Troubleshooting Common Issues
Authentication starts failing after enabling AES-only Kerberos policy. This almost always means one or more accounts never had a password reset after AES support was introduced and only have RC4 key material. Reset the affected account’s password to force new AES key generation, then retest.
4769 events aren’t appearing in the Security log at all. Confirm audit policy from Step 3 is actually applied with auditpol /get /category:* on the domain controller itself, not just in the GPO editor, since a conflicting GPO or local policy override can silently block the setting from taking effect.
gMSA installation fails with “Access is denied” on the target server. The computer account of the target server needs to be a member of the group specified in PrincipalsAllowedToRetrieveManagedPassword, and AD replication needs time to propagate that membership change, typically a few minutes in a healthy environment but longer across sites.
PingCastle report shows a high Kerberoasting risk score even after hardening. Re-run the scan after confirming replication has completed across all domain controllers; a stale read from a DC that hasn’t received the latest GPO or account changes will show outdated results.
Defender for Identity alert 2410 isn’t firing during test simulations. Check sensor health status first; an unhealthy or outdated sensor on the domain controller handling the test traffic won’t generate the telemetry Defender for Identity needs, regardless of how correctly the alert policy itself is configured.
SIEM query returns zero results even though test tickets were requested. Confirm the field name for encryption type matches what your specific log forwarder outputs; Splunk’s Windows TA, Sentinel’s native connector, and generic Syslog-CEF forwarders all format the Ticket_Encryption_Type field slightly differently, and a mismatch here is the most common reason a correct-looking query returns nothing.
Legacy application breaks after migrating its service account to a gMSA. Some older software reads credentials from a configuration file or expects to authenticate interactively rather than through the Windows service control manager’s native gMSA support. Check the vendor’s documentation for gMSA compatibility before migrating, and keep the old account disabled but not deleted for a rollback window.
Password reset on an SPN account doesn’t reduce PasswordAgeDays in the exposure report. Confirm the reset was performed on the account object itself and not a linked or duplicate account; environments with legacy migration history sometimes have orphaned accounts sharing similar names that get confused during manual resets.
PowerShell script from Step 1 returns an incomplete account list. The default Get-ADUser -Filter query only covers the domain you’re connected to; in a multi-domain forest, run the script against each domain separately, or use Get-ADForest to enumerate all domains first and loop through them.
Advanced Tips for Mature Identity Security Programs
Once the baseline hardening in this guide is complete, a few advanced moves push detection maturity further. Honeypot SPN accounts, deliberately created fake service accounts with enticing names like “svc-backup-admin” that have no real function and no legitimate reason to ever be queried, turn any Kerberoasting attempt against them into a near-zero-false-positive alert, since nothing legitimate should ever request that ticket. Pair that with User and Entity Behavior Analytics (UEBA) tooling that baselines normal SPN request volume per user over 30 to 90 days, which catches slow, low-and-slow Kerberoasting attempts that stay under a fixed-threshold SIEM rule but still deviate meaningfully from that specific user’s historical pattern.
For organizations running hybrid Entra ID/on-prem AD environments, extend this audit to Entra ID Connect service accounts specifically, since those often carry elevated on-prem privileges to support directory synchronization and are an underappreciated Kerberoasting target precisely because they’re treated as infrastructure rather than as identities that need the same scrutiny as a privileged human admin account. If you’re standardizing identity providers across a hybrid estate, our comparison of Entra ID, Okta, and Auth0 covers how each handles service-account governance at the directory level.
Frequently Asked Questions
Does disabling RC4 for Kerberos break anything by default?
It can, if any account or application in the environment still depends on RC4 tickets. Audit RC4 usage with Microsoft’s RC4 detection and remediation guidance before enforcing AES-only policy domain-wide, and address legacy dependencies first.
Is Kerberoasting only a Windows/Active Directory problem?
Yes, specifically. Kerberoasting targets Kerberos ticket-granting service tickets in AD environments. Linux systems joined to AD via SSSD or similar can theoretically have SPN-bearing accounts too, but the vast majority of real-world Kerberoasting targets Windows domain service accounts.
What’s the difference between Kerberoasting and AS-REP Roasting?
Kerberoasting (T1558.003) targets any SPN-bearing account by requesting a legitimate service ticket. AS-REP Roasting (T1558.004) targets accounts specifically configured with Kerberos pre-authentication disabled, requesting an AS-REP response that can also be cracked offline. Both should be audited together.
Can Group Managed Service Accounts be Kerberoasted?
Technically an attacker can still request a ticket for a gMSA’s SPN, but the automatically generated 240-byte random password makes offline cracking practically infeasible with current computing resources, which is why gMSA migration is one of the highest-value steps in this guide.
How often should service account passwords be rotated if they can’t use gMSA?
For non-gMSA accounts that must keep static passwords due to application constraints, rotate on a fixed schedule (commonly every 60 to 90 days) with a minimum length of 32 characters generated randomly, and store the credential in a secrets manager rather than documentation or scripts.
Does Microsoft Defender for Identity replace the need for SIEM detection rules?
No. Defender for Identity provides strong out-of-the-box Kerberoasting detection through alert ID 2410, but layering a custom SIEM rule on raw 4769 events adds coverage for encryption-type patterns and organization-specific baselines that a generic vendor alert may not fully capture.
What CVE is driving the 2026 push toward AES-only Kerberos?
CVE-2026-20833, a Windows Kerberos information disclosure vulnerability tied to continued RC4-HMAC use in ticket issuance. Microsoft’s hardening updates, shipped starting January 2026 with full enforcement after July 2026, directly address the conditions that make Kerberoasting easier when RC4 remains enabled. See Microsoft’s Active Directory threat mitigation guidance for the full rollout timeline.
Is it safe to run Rubeus or Impacket’s GetUserSPNs.py against a production domain?
Only with explicit written authorization, ideally as part of a scoped penetration test or red-team engagement. These are legitimate security tools, but running them without authorization against systems you don’t own or have permission to test is both a policy violation in most organizations and, depending on jurisdiction, potentially illegal.
Related Coverage
- How to Detect Phishing Emails: 12 Steps, 90 Min [2026]
- Network Segmentation Against Ransomware: 13 Steps [2026]
- Kubernetes Security Hardening: 13 Steps, 90 Min [2026]
- SOC 2 Compliance Audit Prep: 13 Steps, $150K Cost [2026]
- How to Prevent Prompt Injection Attacks: 12 Steps, 90 Min [2026]
