AS-REP Roasting

Plain-language definition

AS-REP roasting targets Active Directory accounts that do not require Kerberos preauthentication, allowing an attacker to request an authentication response containing password-derived material and attempt offline password guessing.

AS-REP Roasting is best understood as part of a larger security system rather than an isolated feature. Threat analysis connects an adversary or failure condition to the techniques, prerequisites, affected assets, observable evidence, and consequences involved.

How it works

A practical explanation of as-rep roasting begins with the actors, components, trust decisions, and state changes involved. Reviewers should distinguish initial access, execution, persistence, privilege, credential access, movement, collection, command and control, impact, and recovery because controls differ by stage.

The following elements form the working model a learner should be able to identify in an architecture, configuration review, or incident timeline.

• Kerberos preauthentication normally requires the client to prove knowledge of the account key before the key distribution center returns ticket material.
• When the “do not require Kerberos preauthentication” setting is enabled, the initial response can be obtained without that proof.
• The response includes data encrypted with the user’s password-derived key, which can be tested offline against guesses.
• The technique does not require an existing password for the targeted account, but the attacker must identify a valid account with the insecure setting.
• If the password is recovered, the attacker gains the actual account privileges and may establish ordinary authentication sessions.

Why it matters

Weaknesses involving as-rep roasting can turn a local configuration error into broader compromise, unreliable evidence, unauthorized access, or unsafe behavior. The business consequence depends on the assets and decisions that rely on the affected trust path.

The educational goal is to connect the technical mechanism to prevention, detection, response, recovery, governance, and measurable assurance. A control is not complete merely because a product setting exists; the organization must show that the intended behavior is deployed, observed, and maintained.

Common attack paths and failure modes

Adversaries and ordinary operational failures often exploit the assumptions surrounding as-rep roasting rather than attacking the most visible component directly. Review the complete path from initial input or identity through authorization, execution, logging, and recovery.

Risk analysis should distinguish design flaws, insecure defaults, deployment gaps, stale exceptions, missing telemetry, and recovery weaknesses because each requires a different corrective action.

• Legacy application requirements may leave preauthentication disabled long after the original need disappears.
• Service and user accounts with weak or nonexpiring passwords are particularly exposed.
• Account enumeration and roasting may originate from systems that have little other domain activity.
• An account with modest direct permissions may still have access to sensitive applications, shares, or delegation paths.
• Enabling preauthentication without testing can break a remaining legacy dependency and prompt unsafe rollback.

Defensive design and controls

Defending as-rep roasting requires layered controls selected for the actual environment, threat model, and consequence of failure. Preventive settings should be paired with independent evidence and an owned response process.

Controls are strongest when they use secure defaults, narrow privileges and interfaces, protect secrets, validate state transitions, record meaningful events, and support safe rollback or recovery.

• Require Kerberos preauthentication for all accounts unless a current, approved, and tested exception exists.
• Find accounts with the setting disabled and assign each exception to an application and owner.
• Use strong, unique, managed passwords and minimize the privileges of unavoidable exception accounts.
• Monitor unusual authentication-service requests and account-enumeration activity.
• Protect exception accounts with network restrictions, service logon rights, and enhanced monitoring.
• Remediate dependencies in stages and verify that preauthentication remains enabled after migrations and account changes.

Detection, evidence, and validation

Validation for as-rep roasting should combine configuration inspection, controlled functional testing, and operational evidence. No single log source or scanner proves continuing effectiveness.

Evidence should be time-bounded, attributable to the component that made the decision, and rich enough to distinguish expected use from error, abuse, and administrative override.

• Directory queries and configuration reports identifying accounts that do not require preauthentication.
• Domain-controller authentication-service events showing requester, target account, source, and result.
• Password-age, account-use, privilege, and owner records for each exception.
• Application test evidence demonstrating whether preauthentication can be enabled safely.
• Alerts for requests targeting many usernames or high-value exception accounts.

Practical scenario

A directory assessment finds two service accounts with preauthentication disabled. One application was retired years earlier; the other can now support standard Kerberos. The team removes the stale account, enables preauthentication on the remaining account after testing, and closes the exception.

The team documents the expected result, the evidence observed, any residual risk, the owner of corrective work, and the conditions that require the test to be repeated. This converts a technical observation into an accountable security decision.

Safe practitioner lab

Perform this exercise only in an isolated lab, test tenant, disposable virtual machine, or intentionally vulnerable training application that you own or are authorized to assess. The objective is to observe and validate as-rep roasting without affecting production systems.

Capture the starting configuration and create a rollback point before making changes. Record commands, screenshots, event identifiers, timestamps, and expected outcomes so the exercise can be reproduced.

• In a lab or with sanitized directory data, list accounts configured without Kerberos preauthentication.
• For each account, document owner, purpose, last use, password age, privileges, and reachable services.
• Review a prepared authentication event and identify the fields that would support a detection.
• Create a remediation test plan that verifies application behavior before and after preauthentication is enabled.
• Compare the observed result with the expected security outcome and explain any difference.
• Restore the original state, remove test accounts or data, and retain only sanitized learning notes.

Common misconceptions

• Deploying a product associated with AS-REP Roasting automatically makes the environment secure. Architecture, configuration, identity, operations, and maintenance still determine the result.
• A successful one-time test proves continuous effectiveness. Software, identities, policies, dependencies, and attacker behavior change over time.
• More logging is always better. Useful evidence must be relevant, timely, interpretable, protected, and connected to an owned response.
• A framework supplies one universal implementation. Guidance must be adapted to mission, system design, legal obligations, and risk tolerance.

Knowledge check

• What actors, components, and trust decisions define AS-REP Roasting?
• Which assumptions must remain true for the mechanism to be trustworthy?
• What failure modes create the greatest business or mission consequence?
• Which preventive and detective controls provide independent layers of protection?
• What evidence would demonstrate normal behavior, attempted abuse, and successful recovery?

Certification relevance

This subject appears in or supports the following certification bodies of knowledge:

Authoritative sources

• Microsoft Windows security documentation
• Microsoft Active Directory Domain Services documentation
• MITRE ATT&CK — Enterprise techniques