Kerberoasting targets service accounts by requesting Kerberos service tickets and trying to crack the ticket offline, while AS-REP Roasting targets user accounts that do not require pre-authentication and extracts their responses for offline cracking. Both abuse weak passwords, so defenders should enforce strong secrets and monitor unusual ticket requests.
How Kerberoasting and AS-REP Roasting differ in attack path
Both attacks target Kerberos, but they abuse different parts of the protocol. kerberoasting goes after service accounts by requesting service tickets and then cracking the returned material offline. AS-REP Roasting goes after user accounts that do not require pre-authentication, so the attacker can request an AS-REP response and crack that offline instead.
The practical difference is the account type and the condition that makes the attack possible. Kerberoasting depends on service principal name exposure, while AS-REP Roasting depends on weak or disabled pre-authentication on a user account. In both cases, the attacker is not trying to break Kerberos itself, but to capture reusable cryptographic material for password guessing.
For a deeper treatment of the protocol behavior and the detection points that matter, the Kerberos Security Guide is the best match, and it also covers the surrounding controls that separate these two techniques in practice.
Why the two techniques matter to defenders
These attacks are effective because they shift the problem offline. Once the attacker has the ticket or response material, password cracking can happen away from the target environment, which reduces the chance of immediate detection. That makes password strength, account hygiene, and Kerberos configuration more important than simply watching for failed logons.
Kerberoasting is often attractive because service accounts are frequently long-lived and may have stronger operational privileges than their password quality suggests. AS-REP Roasting is often easier to overlook because the risky setting can sit on an ordinary user account and remain invisible until someone checks whether pre-authentication is required.
For teams that want the control angle rather than only the attack description, the Service Account Security Guide is useful for Kerberoasting, while the Identity Threat Detection and Response Guide helps place both techniques in a broader identity-attack detection and response workflow.
What good detection and hardening look like
Defenders should treat these as two related but distinct review queues. Kerberoasting calls for service account inventory, strong and rotated secrets, and scrutiny of unusual service ticket requests. AS-REP Roasting calls for confirming which accounts have pre-authentication disabled and removing that exception unless there is a documented reason it must remain.
Detection is most useful when it looks for the pattern, not just the outcome. A spike in ticket requests, requests for services that do not fit the requesting host, or repeated activity around rarely used accounts is more actionable than waiting for a confirmed crack or later misuse. In mature environments, those signals should feed identity-focused monitoring and incident triage together.
Current guidance also aligns with the NIST SP 800-53 Rev 5 Security and Privacy Controls, especially the controls for identification and authentication, access enforcement, audit, and account management, because both attacks exploit weak account configuration and weak secret quality.
Risk and Threat Considerations
These techniques are dangerous because they turn ordinary directory misconfiguration into offline credential exposure. If service accounts use weak passwords or users are allowed to skip pre-authentication, an attacker can harvest crackable material without immediately triggering the kind of interactive authentication controls defenders usually watch.
Failure mechanism: Kerberoasting succeeds when service accounts are discoverable and their secrets are weak enough to crack offline, while AS-REP Roasting succeeds when pre-authentication is disabled and the returned response can be attacked offline.
Impact: Successful cracking can reveal usable credentials for privileged or persistent accounts, creating access reuse, lateral movement, and repeated compromise risk until the exposed secrets are changed and the account posture is corrected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1558 — Steal or Forge Kerberos Tickets | Kerberoasting and AS-REP Roasting are Kerberos credential-access techniques. |
| Recommendation — Map observed Kerberos abuse to T1558 and hunt for ticket-request anomalies. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Both attacks depend on weak secret quality and lifecycle management for exposed accounts. |
| AC-2 — Account Management | Disabled pre-authentication and long-lived service accounts are account-governance failures. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Unusual ticket requests and identity abuse need monitoring and triage. | |
| Recommendation — Enforce IA-5 rotation and strength requirements for service and user account secrets. Review account settings to remove unnecessary exceptions and stale identities. Correlate ticket-request anomalies and escalate suspicious Kerberos activity. | ||
| CIS Controls v8 | CIS-5 — Account Management | The topic is fundamentally about account hygiene, service accounts, and risky settings. |
| CIS-8 — Audit Log Management | Detection relies on seeing unusual Kerberos request patterns in logs. | |
| Recommendation — Inventory accounts, remove unnecessary exceptions, and enforce strong credential handling. Centralize and review Kerberos-related logs for abnormal request patterns. | ||
Practitioner Guidance
What to verify: Confirm which accounts have SPNs, which user accounts have pre-authentication disabled, and whether any of those identities carry privileges that would materially expand blast radius if cracked. Weak passwords on low-value accounts still matter if the account can reach sensitive systems.
Decision rule: If the account can authenticate to important systems, treat it as a password-strength and lifecycle problem first, not just a detection problem. If patching or configuration change must wait, prioritize rotation, narrowing access, and compensating monitoring over assuming the attack is harmless because it is offline.
Practitioner takeaway: The key distinction is not just the Kerberos message involved, but which account type is exposed and why the protocol lets the attacker extract crackable material in the first place.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org