Detecting Kerberoasting, AS-REP Roasting, and Pass-the-Ticket Attacks: Rubeus Artifact Hunting and Defense
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Kerberoasting has remained in the top five Active Directory attack techniques for over a decade because the underlying Kerberos protocol mechanic — any authenticated user can request a TGS ticket for any SPN — is a feature, not a vulnerability. The ticket is encrypted with the service account's password hash, and that password hash becomes the cracking target. On a standard GPU rig, an RC4-encrypted TGS ticket from an account with a 12-character complex password cracks in hours. A 16-character complex AES-encrypted password takes years of GPU time — the same attack, completely different outcome.
The detection and defense strategy for Kerberoasting attacks operates on two parallel tracks: shrink the attack surface (replace static service account passwords with gMSAs, enforce AES encryption, audit and remove unnecessary SPNs) and improve detection specificity (monitor Event ID 4769 for RC4 tickets and burst patterns, deploy honey account SPNs for zero-false-positive alerting, enable Defender for Identity for automated anomaly detection). Both tracks are necessary — detection without attack surface reduction produces alerts you cannot act on quickly enough, and attack surface reduction without detection leaves you blind to the attacks that do happen.
Detection: Event ID 4769 analysis and honey account deployment
The raw material for Kerberoasting detection already exists in every Windows domain controller's Security event log — the challenge is extracting the signal from the background noise of legitimate TGS requests. A busy domain controller generates thousands of Event ID 4769 events per hour, and most of them are legitimate. The detection strategy requires specific field-level filters (encryption type 0x17, burst patterns, SPN target analysis) and honey accounts that make any TGS request a definitive attack signal with no false positive management required.
Build a SIEM detection rule for burst-pattern Kerberoasting: multiple SPN requests from one account within 60 seconds
A legitimate user requesting a TGS ticket for a specific service generates one or a small number of 4769 events in a short period. Kerberoasting tools like Rubeus kerberoast enumerate all SPNs and request tickets for all of them in a single operation, generating dozens to hundreds of 4769 events from the same source account and IP within 30-60 seconds. Write a SIEM rule that counts Event ID 4769 events grouped by SubjectUserName (the requesting account) and IpAddress within a 60-second sliding window, and alerts when the count exceeds 10 distinct ServiceName values. This burst detection catches automated Kerberoasting enumeration even when individual RC4 events might be whitelisted for legacy compatibility reasons. Tune the threshold based on your environment's legitimate peak TGS request volume for a single user account, which is typically 2-3 events per minute in a normal workflow.
Deploy Defender for Identity for automated Kerberos attack detection with cross-event correlation
Microsoft Defender for Identity analyzes domain controller traffic and event logs using behavioral baselines that detect Kerberos attack patterns including Kerberoasting (Suspected Kerberos SPN exposition), AS-REP roasting (Suspected AS-REP Roasting attack), golden ticket attacks (Suspected Golden Ticket usage), and pass-the-ticket (Suspected identity theft). Defender for Identity correlates across Event ID 4769 and network-captured Kerberos packets to detect patterns that event-log-only analysis misses, including Kerberos ticket anomalies visible in encrypted network traffic. The key operational advantage over custom SIEM rules is that Defender for Identity's machine learning baseline automatically adjusts for each domain's normal Kerberos behavior, reducing false positive rates compared to static threshold rules. Connect Defender for Identity to Microsoft Sentinel to centralize Kerberos attack alerts alongside other identity threat detections in a single investigation workspace.
Defense: attack surface reduction through SPN and encryption hygiene
Detection-only defense for Kerberoasting is operationally unsustainable in large Active Directory environments because the alert volume from legitimate RC4 TGS events creates a whack-a-mole false positive management problem. The sustainable defense combines detection with attack surface reduction: convert service accounts to gMSAs (eliminating the crackable password), audit and remove unnecessary SPNs, enforce AES encryption (making ticket cracking computationally infeasible), and apply fine-grained password policies (requiring 25+ character passwords for all remaining Kerberoastable accounts).
Audit all SPNs in the domain and remove unnecessary registrations to reduce the Kerberoasting target list
Run Get-ADUser -Filter * -Properties ServicePrincipalName | Where-Object {$_.ServicePrincipalName -ne $null} | Select-Object Name, SamAccountName, ServicePrincipalName | Export-Csv kerberoastable-accounts.csv to enumerate all user accounts with SPNs that are Kerberoasting targets. For each account in the list, verify that the SPN is actively used by a live service by checking whether the service was recently using the account (LastLogonDate within 30 days) and whether the SPN format matches a running application. SPNs registered on decommissioned service accounts or test accounts should be removed with Set-ADUser -Identity stale-account -ServicePrincipalNames @{Remove='HTTP/stale-server.domain.com'}. Decommissioned service accounts with SPNs are ideal Kerberoasting targets because they often have static passwords that have not been changed in years and the password crack is not detected as a login anomaly since the account is not being monitored for logon activity.
Apply fine-grained password policies requiring 25+ character passwords for all remaining Kerberoastable accounts
For service accounts that cannot immediately be converted to gMSAs (due to application limitations), apply a Fine-Grained Password Policy that requires a minimum password length of 25 characters with complexity requirements. Create the policy with New-ADFineGrainedPasswordPolicy -Name 'ServiceAccountPolicy' -Precedence 10 -MinPasswordLength 25 -ComplexityEnabled $true -MaxPasswordAge (New-TimeSpan -Days 90) and apply it to a group containing all Kerberoastable service accounts. A 25-character complex password as an AES-encrypted TGS ticket is computationally infeasible to crack with current GPU resources — even if the encryption downgrade to RC4 is somehow achieved, the password length makes the crack impractical. This fine-grained policy approach provides immediate protection for accounts that cannot be converted to gMSAs while the gMSA migration is in progress.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Kerberoasting, AS-REP roasting, and pass-the-ticket attacks exploit Active Directory Kerberos features rather than software vulnerabilities, making them resistant to patch-based remediation. Effective defense requires both attack surface reduction and detection. Reduce the attack surface by converting service accounts to gMSAs (240-character auto-rotating passwords make ticket cracking infeasible), enforcing AES-only Kerberos encryption (eliminating RC4 ticket cracking), auditing and removing unnecessary SPNs, and applying fine-grained password policies requiring 25+ character passwords for remaining Kerberoastable accounts. Improve detection with Event ID 4769 burst-pattern rules, honey account SPN deployments for zero-false-positive alerting, and Microsoft Defender for Identity for automated Kerberos anomaly detection. Together these controls shrink the attacker's target list and alert reliably on the attacks that still occur.
Frequently asked questions
How do I detect Kerberoasting using Windows Event ID 4769?
Detect Kerberoasting by monitoring Windows Event ID 4769 (Kerberos Service Ticket Requested) and filtering for the specific field values that indicate a Kerberoasting TGS request. A Kerberoasting attempt has Ticket Encryption Type = 0x17 (RC4-HMAC) in a modern Windows environment that should be using AES encryption, or it targets a service account with an SPN registered in Active Directory. Write a SIEM detection rule that alerts on Event ID 4769 where TicketEncryptionType is 0x17 AND the ServiceName is not krbtgt AND the ServiceName ends in a known service account pattern. To reduce false positives from legacy systems that legitimately use RC4, add a condition that excludes known legacy source machines by IP (from the IpAddress field in the event) and alert on 4769 events from the excluded list separately at lower priority. A single account requesting RC4 TGS tickets for multiple different SPNs within a short time window is the highest-fidelity Kerberoasting indicator and should trigger an immediate alert.
How do I detect AS-REP roasting attacks?
Detect AS-REP roasting by monitoring for Windows Event ID 4768 (Kerberos Authentication Ticket Requested) where the request was made for an account with the DONT_REQUIRE_PREAUTH flag set (also called UF_DONT_REQUIRE_PREAUTH). The event does not directly expose the account flag, but you can cross-reference 4768 events with an Active Directory query that returns all accounts with DONT_REQUIRE_PREAUTH enabled: Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth returns all vulnerable accounts. Create a watchlist of these accounts in your SIEM and alert on any 4768 event that references one of the watchlist accounts from an unusual source IP or during unusual hours. Proactively, audit and remediate DONT_REQUIRE_PREAUTH accounts: unless there is a specific legacy application requirement documented, the flag should be disabled on all accounts. Run monthly: Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties * | Select-Object SamAccountName, Description, LastLogonDate and review for accounts where the flag can be removed.
How do I deploy honey accounts to detect Kerberoasting with near-zero false positives?
Deploy honey accounts (also called honeytoken accounts) specifically designed to trigger Kerberoasting detection alerts with near-zero false positive rates. Create Active Directory accounts with names that resemble legitimate service accounts (svc-backup, svc-sql, svc-monitor) with SPNs registered to make them Kerberoastable, but ensure these accounts are never used by any legitimate application or service. Write a SIEM detection rule that fires on any Event ID 4769 where the ServiceName matches a honey account SPN — any TGS request for these accounts is definitively malicious since no legitimate system uses them. This approach provides a high-fidelity signal that requires no threshold tuning or false positive management, unlike generic RC4 TGS alerts. Store the honey account credentials as complex passwords that would fail cracking even if a ticket was obtained, so that even a detection failure (missed 4769 event) does not result in a usable credential.
How do I detect pass-the-ticket and golden ticket attacks?
Detect pass-the-ticket attacks by monitoring for Kerberos logon events (Event ID 4624 with Logon Type 3 and Authentication Package Kerberos) where the source workstation and the ticket-issuing domain controller do not match the user's normal logon patterns. Golden ticket attacks produce a specific anomaly: Event ID 4769 events where the ticket is requested for accounts that do not exist in Active Directory, or where the TGT was not issued by the domain's KDC within the expected time window (golden tickets can be created with custom timestamps that may fall outside normal business hours). Microsoft Defender for Identity detects golden ticket anomalies automatically using its machine learning baseline of normal Kerberos behavior and issues a Suspected identity theft (pass-the-ticket) alert. For environments without Defender for Identity, set up detection rules for Event ID 4769 events where the ticket's PAC validation fails (logged as an audit failure) or where the account's Kerberos activity shows a ticket that was issued outside normal hours with a custom encryption type combination.
How do I reduce the Kerberoasting attack surface using gMSAs?
Reduce Kerberoasting attack surface by replacing traditional service account passwords with Group Managed Service Accounts (gMSAs), which use 240-character randomly generated passwords rotated automatically every 30 days by Active Directory. Even if a gMSA TGS ticket is obtained and cracked offline (which requires GPU-accelerated cracking of a 240-character password — effectively impossible), the password rotates before the crack completes. Create a gMSA with New-ADServiceAccount -Name gMSA-SQLService -DNSHostName sql.domain.com -PrincipalsAllowedToRetrieveManagedPassword 'SQL-Servers-Group'. Install the gMSA on the SQL server with Install-ADServiceAccount -Identity gMSA-SQLService and configure the SQL Server service to use domain.com\gMSA-SQLService$ as the service logon account (with no password — Windows retrieves the password automatically). Audit all service accounts with SPNs quarterly using Get-ADUser -Filter * -Properties ServicePrincipalName | Where-Object {$_.ServicePrincipalName} and convert accounts with long-standing static passwords to gMSAs to progressively reduce the Kerberoastable attack surface.
What Rubeus indicators appear in Windows event logs that I can use for detection?
Rubeus generates several detectable indicators in Windows event logs that go beyond the Kerberos protocol events. In Sysmon Event ID 1 (Process Creation) or Event ID 4688, Rubeus execution appears as either rubeus.exe directly or as a renamed binary — look for command-line patterns containing kerberoast, asreproast, dump /nowrap, tgtdeleg, or s4u in the process command line, which are Rubeus subcommands that do not appear in legitimate administrative tools. In the Windows Security log, Rubeus's kerberoast function generates a burst of Event ID 4769 events in rapid succession for multiple different SPNs from the same source account and IP within seconds, which is the volume-based indicator. Rubeus dump generates Event ID 4624 Logon Type 9 events (NewCredentials) when it imports tickets into a new logon session, which combined with an unusual process parent (non-administrative tool spawning a network logon) is a pass-the-ticket indicator. Monitor for Event ID 10 (LSASS access) in Sysmon when the source process is not a known legitimate antivirus or EDR process, which indicates credential dumping that often accompanies Rubeus-based attacks.
How do I enforce AES-only Kerberos encryption to eliminate RC4 Kerberoasting?
Enforce AES-only Kerberos encryption by configuring the Network Security: Configure encryption types allowed for Kerberos Group Policy setting to allow only AES128_HMAC_SHA1 and AES256_HMAC_SHA1, removing RC4_HMAC_MD5 from the allowed list. Apply this policy to Domain Controllers and to all computers in the domain. Before enforcing AES-only, audit for legacy systems that require RC4: run Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes to find computers with RC4-only or no encryption type preference set, and Run Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object {$_.msDS-SupportedEncryptionTypes -band 4} to find service accounts that only support DES or RC4. Update or replace legacy systems that require RC4 before enforcing the policy. After enforcing AES-only, all TGS requests for Kerberoastable accounts return AES-encrypted tickets, which are computationally infeasible to crack offline compared to RC4 tickets — this does not eliminate Kerberoasting but makes it impractical against AES-encrypted tickets from accounts with complex passwords.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.