Defending Against Kerberoasting And AS-REP Roasting In Active Directory

📅 October 21, 2026  |  🏷 Cyber Security  |  Cyber Security, Information Security, Threat Management

A single misconfigured service account in Active Directory can hand an attacker the keys to your entire domain — and they never need to touch a domain controller to do it. Kerberoasting and AS-REP Roasting are two credential-harvesting techniques that exploit the design of the Kerberos authentication protocol itself, meaning no vulnerability patch will ever fully eliminate the risk. According to the 2025 Verizon Data Breach Investigations Report, credential abuse remains the leading attack vector in enterprise breaches, with Active Directory environments targeted in over 80% of ransomware intrusions. If your organization runs Windows infrastructure — and statistically, it does — these attacks are not hypothetical. They are happening in your sector right now.

Understanding the Attack Mechanics: How Kerberoasting and AS-REP Roasting Work

Before you can defend against these attacks, you need a precise understanding of what they actually do at the protocol level. Both techniques exploit legitimate Kerberos functionality, which is what makes them so difficult to detect and so dangerous in practice.

Kerberoasting: Abusing Service Ticket Encryption

Kerberos assigns Service Principal Names (SPNs) to accounts that run network services — SQL Server, IIS, custom applications, and others. When any authenticated domain user requests a service ticket for an SPN, the Key Distribution Center (KDC) issues that ticket encrypted with the service account’s NTLM password hash. The critical flaw: the requesting user receives the encrypted ticket and can take it offline. No further interaction with the domain is needed. The attacker then runs offline dictionary or brute-force attacks against the ticket using tools like Hashcat or John the Ripper.

The attack requires only a valid domain user credential — not an administrator. A phished intern’s credentials are sufficient to enumerate all SPNs in the domain and request service tickets for every single one. Tools like Impacket’s GetUserSPNs.py, Rubeus, and PowerView automate this enumeration and extraction in seconds. The weaker the service account password, the faster it cracks. RC4 encryption (etype 23) is particularly vulnerable because it uses the raw NTLM hash without salting, making it orders of magnitude faster to crack than AES-encrypted tickets.

AS-REP Roasting: Exploiting Pre-Authentication Bypass

AS-REP Roasting targets a different weakness. Kerberos pre-authentication is enabled by default and requires a user to prove knowledge of their password before the KDC issues an Authentication Server Reply (AS-REP). However, if an administrator has disabled pre-authentication on a user account — a setting that exists for legacy compatibility reasons — the KDC will issue an AS-REP to anyone who simply asks for one, no password required. That AS-REP contains a portion encrypted with the target account’s password hash, which can again be taken offline for cracking.

This is subtly but critically different from Kerberoasting: AS-REP Roasting does not require the attacker to be authenticated at all. An unauthenticated attacker with network access can enumerate accounts with pre-authentication disabled using tools like Kerbrute or Impacket’s GetNPUsers.py and immediately begin offline cracking. In penetration tests conducted by firms including Mandiant and CrowdStrike, AS-REP Roastable accounts are found in the majority of mid-to-large enterprise Active Directory environments — often legacy service accounts or developer accounts that were “temporarily” configured years ago and never remediated.

Mapping the Threat Landscape: Who Is Exploiting These Techniques

These are not niche tactics used only by nation-state actors. They have become standard procedure in the ransomware kill chain. The Black Basta, LockBit 3.0, and Scattered Spider threat groups have all documented use of Kerberoasting as a privilege escalation step following initial access. MITRE ATT&CK catalogs both techniques under T1558 — Steal or Forge Kerberos Tickets — and lists them as commonly observed in intrusions targeting financial services, healthcare, and critical infrastructure.

Real-World Impact: The Colonial Pipeline Context

While the Colonial Pipeline attack in 2021 is primarily associated with a compromised VPN credential, post-incident forensic analysis by CISA revealed that lateral movement within the network relied heavily on credential harvesting from Active Directory. Active Directory-based credential attacks, including Kerberos ticket abuse, were identified as key enablers. More recently, the 2024 Change Healthcare breach — which caused an estimated $872 million in operational losses for UnitedHealth Group — involved attackers who spent weeks performing lateral movement through Microsoft environments using harvested credentials before deploying ransomware. The pattern is consistent: initial access is cheap; the real damage happens during the Active Directory exploitation phase.

The democratization of attack tooling has lowered the skill floor dramatically. A junior threat actor with a Kali Linux VM and a YouTube tutorial can execute a Kerberoasting attack against an enterprise environment within an hour. Your defenses cannot assume a sophisticated adversary is required to exploit these weaknesses.

Hardening Service Accounts: The First Line of Defense

The fundamental reason Kerberoasting succeeds at scale is that organizations tolerate weak, infrequently rotated passwords on service accounts. A 25+ character random password on a service account makes Kerberoasting computationally infeasible — even with RC4 encryption. Cracking a truly random 25-character password using modern GPU clusters would take longer than the operational lifetime of most organizations. The attack doesn’t disappear, but it becomes practically non-exploitable.

Group Managed Service Accounts (gMSAs): The Right Answer

Microsoft introduced Group Managed Service Accounts (gMSAs) specifically to address this problem. gMSAs automatically rotate their passwords every 30 days with 240-character randomly generated values managed entirely by Active Directory. No human knows the password. No human can configure a weak password. The KDC issues the password to authorized hosts on demand, eliminating the credential management burden entirely.

Migration to gMSAs should be treated as a security-critical infrastructure project, not a maintenance task. Audit your current SPN landscape using the following PowerShell command to identify all service accounts with SPNs:

Get-ADUser -Filter {ServicePrincipalName -ne “$null”} -Properties ServicePrincipalName, PasswordLastSet | Select-Object Name, PasswordLastSet, ServicePrincipalName

Any account with a PasswordLastSet value older than 180 days and a human-manageable password should be considered an immediate remediation priority. Additionally, audit whether each SPN is actually still in use — orphaned SPNs from decommissioned services are a common finding and should be removed immediately to reduce attack surface.

For accounts that cannot be migrated to gMSAs, enforce a minimum 25-character random password policy, rotate passwords quarterly, and implement fine-grained password policies (FGPPs) to apply stricter controls to service accounts than to standard user accounts.

Enforcing AES Encryption and Eliminating RC4

One of the most impactful technical controls you can implement is forcing Kerberos to use AES-256 encryption instead of RC4 for service ticket issuance. RC4 Kerberos tickets (etype 23) are crackable at rates exceeding 1 billion hashes per second on modern GPU hardware. AES-256 tickets (etype 18) use salted encryption that dramatically increases cracking difficulty and time.

Configuring AES Enforcement in Active Directory

To enforce AES for a service account, navigate to the account’s properties in Active Directory Users and Computers and ensure “This account supports Kerberos AES 128-bit encryption” and “This account supports Kerberos AES 256-bit encryption” are checked, while ensuring the account does not have “Use DES encryption types for this account” enabled. Through Group Policy, configure Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network Security: Configure Encryption Types Allowed for Kerberos to permit only AES128 and AES256, explicitly excluding RC4_HMAC_MD5.

Be aware that disabling RC4 across the environment requires thorough compatibility testing. Legacy applications and some NAS devices still negotiate RC4. A phased approach — audit, test in staging, pilot in low-risk OUs, then broad rollout — is the recommended path. Microsoft’s own guidance recommends completing this migration before enabling Protected Users Security Group membership for service accounts, as Protected Users enforces AES-only Kerberos by design.

According to data from SpecterOps researchers, environments that have successfully eliminated RC4 Kerberos authentication see a dramatic reduction in successful Kerberoasting outcomes during red team engagements, even when tickets are successfully requested and extracted.

Remediating AS-REP Roastable Accounts and Enabling Pre-Authentication

Re-enabling Kerberos pre-authentication on all accounts is the definitive fix for AS-REP Roasting. In the vast majority of environments, there is no legitimate technical reason for pre-authentication to be disabled on any account. Identify all accounts with this setting using:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth | Select-Object Name, DoesNotRequirePreAuth

Every account returned by this query is currently AS-REP Roastable. The remediation is a single attribute change — enable pre-authentication — but this should be done with appropriate change management, as some very old LDAP integrations may rely on pre-authentication being disabled.

Privileged Account Protection with the Protected Users Group

Adding sensitive accounts — particularly privileged users like Domain Admins, Enterprise Admins, and high-value service accounts — to the Protected Users Security Group provides a defense-in-depth layer. Members of this group cannot use NTLM authentication, cannot use DES or RC4 for Kerberos, cannot have credentials cached on devices, and have Kerberos tickets expire after 4 hours rather than the default 10 hours. This significantly limits the post-exploitation utility of any Kerberos tickets obtained through roasting attacks, even if the tickets are successfully cracked.

The Protected Users group has been available since Windows Server 2012 R2 and is dramatically underutilized. A 2024 survey by the SANS Institute found that fewer than 35% of organizations with Active Directory environments had configured Protected Users group membership for their privileged accounts — a striking gap given how long the control has been available.

Detection, Monitoring, and Threat Hunting in Active Directory

Preventive controls are necessary but not sufficient. Threat actors who gain access before your hardening is complete, or who find edge cases your controls missed, must be detected quickly. The average dwell time for Active Directory attacks remains alarmingly high — often exceeding 14 days before discovery — giving attackers ample time to escalate privileges and establish persistence.

Key Event IDs and SIEM Detection Logic

Windows Security Event logging provides the raw material for Kerberoasting and AS-REP Roasting detection. The critical Event IDs to monitor are:

• Event ID 4769 — Kerberos Service Ticket Request. Alert on requests using etype 0x17 (RC4-HMAC), particularly when a single account requests tickets for multiple SPNs in rapid succession. A single user requesting more than 5 service tickets within 60 seconds is a high-confidence indicator of Kerberoasting activity.
• Event ID 4768 — Kerberos Authentication Ticket Request. Filter for requests where pre-authentication type is 0 (no pre-authentication), which indicates an AS-REP Roasting attempt or a misconfigured account being targeted.
• Event ID 4771 — Kerberos Pre-Authentication Failed. Useful for detecting enumeration and brute-force activity against accounts.

Correlate these events with the source IP address and requesting user account. Service ticket requests originating from workstations rather than servers, or from accounts that do not typically request those specific services, are strong anomaly signals. Modern SIEM platforms including Microsoft Sentinel, Splunk Enterprise Security, and Elastic SIEM include pre-built detection rules for these patterns — ensure they are enabled and tuned to your environment’s baseline.

Honey Accounts: Deception-Based Detection

Deploy dedicated honeypot service accounts — accounts with SPNs that have no legitimate service associated with them. Any Kerberos ticket request for these accounts’ SPNs is definitionally suspicious, as no legitimate application or user should ever request them. Configure an immediate, high-priority alert in your SIEM for Event ID 4769 targeting these honey SPNs. This provides near-zero false positive detection for Kerberoasting activity and can catch attackers who successfully evade behavioral anomaly detection by moving slowly.

Similarly, create honey user accounts with pre-authentication disabled (DoesNotRequirePreAuth = True) that serve as AS-REP Roasting canaries. Any AS-REP request for these accounts triggers an alert. This technique was formalized by Sean Metcalf of TrimarcSecurity and remains one of the highest-signal, lowest-effort detection mechanisms available.

Key Takeaways

• Migrate service accounts to gMSAs immediately. Group Managed Service Accounts eliminate the weak-password problem entirely by automating 240-character random password rotation. This is the single highest-impact control for preventing Kerberoasting.
• Enforce AES-256 Kerberos encryption and disable RC4. RC4 Kerberos tickets are crackable at billions of hashes per second with commodity hardware. Eliminating RC4 makes successful offline cracking of extracted tickets computationally impractical.
• Audit and re-enable pre-authentication on all accounts. Zero accounts in your environment should have DoesNotRequirePreAuth enabled unless there is a documented, approved technical necessity. Run the audit query monthly as part of your Active Directory hygiene process.
• Add privileged accounts to the Protected Users Security Group. This enforces AES-only Kerberos, disables NTLM fallback, and restricts credential caching — significantly reducing attacker options even if credentials are partially compromised.
• Deploy honey SPNs and monitor Event ID 4769 with etype filtering. Deception-based detection combined with SIEM alerting on RC4 service ticket requests provides high-confidence, low-false-positive detection of active Kerberoasting campaigns in your environment.

Conclusion: Treat Active Directory Security as a Continuous Discipline

Kerberoasting and AS-REP Roasting persist as dominant attack techniques not because they are technically novel — they have been publicly documented since 2014 — but because the underlying misconfigurations that enable them are extraordinarily common and frequently deprioritized. Every day a service account runs with a weak password and an SPN is another day your environment is one phished credential away from a significant compromise.

The controls described in this post are not theoretical. They are documented, tested, and deployable in any Active Directory environment running Windows Server 2012 R2 or later. The technical work is well-understood. What separates organizations that successfully defend against these attacks from those that do not is execution — the operational discipline to audit continuously, migrate service accounts systematically, enforce encryption standards, and treat Active Directory security as a living program rather than a one-time project.

Your immediate action: Run the three PowerShell audit queries referenced in this post — SPN enumeration, DoesNotRequirePreAuth accounts, and PasswordLastSet age on service accounts — and bring the results to your next security review meeting. If your environment has never been assessed specifically for Kerberoasting exposure, engage a qualified Active Directory security assessment within the next 90 days. The cost of that assessment is a fraction of the cost of a single ransomware incident enabled by a cracked service account password.

{
“title”: “Defending Against Kerberoasting in Active Directory”,
“excerpt”: “Learn how to defend Active Directory against Kerberoasting and AS-REP Roasting with g