Unlike Kerberoasting, which targets service tickets associated with Service Principal Names (SPNs), AS-REP Roasting targets the initial Kerberos authentication process and accounts with a specific configuration weakness.

• Primary risk: Offline password cracking against authentication material for accounts without Kerberos pre-authentication.

• Common targets: Misconfigured Active Directory user accounts.

• Potential impact: Account compromise, privilege escalation and lateral movement.

• Key investigation evidence: Windows Security Event ID 4768, account configuration, authentication patterns and endpoint telemetry.

• Primary defences: Enforce Kerberos pre-authentication, strengthen passwords and monitor vulnerable account configurations.

1. When Authentication Skips an Important Check

Imagine an organisation using Active Directory to manage employee identities, application accounts and access to internal resources.

During normal Kerberos authentication, a client must demonstrate knowledge of the account's secret through the pre-authentication process before the Key Distribution Center (KDC) issues a Ticket Granting Ticket (TGT).

However, Active Directory includes an account setting that allows Kerberos pre-authentication to be disabled. This setting exists for compatibility with certain specialised authentication requirements, but it weakens the protection provided by the normal authentication flow.

If an account has this setting enabled, an attacker may be able to request an AS-REP response without first proving knowledge of the account's password.

The response can contain encrypted material that the attacker may attempt to crack offline.

This technique is known as AS-REP Roasting.

The danger is not simply that an authentication request succeeds. It is that the configuration may allow an attacker to obtain password-guessing material without completing the usual pre-authentication step.

2. Understanding Kerberos Pre-Authentication

Kerberos is a network authentication protocol commonly used in Windows Active Directory environments. It allows users and services to authenticate through a trusted Key Distribution Center, typically hosted on domain controllers.

The initial exchange involves two important concepts.

Authentication Service Request (AS-REQ)

The client sends an Authentication Service Request to the KDC to request a Ticket Granting Ticket.

In a typical Active Directory configuration, the request includes pre-authentication data demonstrating knowledge of the account's secret. The KDC validates the pre-authentication information before issuing the TGT.

Authentication Service Response (AS-REP)

When the KDC accepts the request, it returns an Authentication Service Response containing ticket and authentication-related information.

Some of this information is encrypted using key material associated with the account.

When pre-authentication is disabled, the KDC can return an AS-REP without requiring the normal proof of password knowledge first. This creates the opportunity for offline password guessing against the relevant encrypted material.

Normal authentication versus AS-REP Roasting

<box border radius="lg" padding={3} gap={3}> <box gap={2}> <title size="md">Normal Kerberos authentication</title> <box background="surface-secondary" radius="md" padding={3} align="center"> **Client requests a TGT** </box> <box align="center"> <icon name="arrow-down" color="secondary" size="lg" /> </box> <box background="surface" border radius="md" padding={3} align="center"> **KDC requires pre-authentication** </box> <box align="center"> <icon name="arrow-down" color="secondary" size="lg" /> </box> <box background="surface-secondary" radius="md" padding={3} align="center"> **TGT issued after validation** </box> </box> <divider /> <box gap={2}> <title size="md">AS-REP Roasting exposure</title> <box background="surface-secondary" radius="md" padding={3} align="center"> **Client requests authentication** </box> <box align="center"> <icon name="arrow-down" color="secondary" size="lg" /> </box> <box background="surface" border radius="md" padding={3} align="center" gap={1}> **Pre-authentication is disabled** <text color="secondary" size="sm">The usual proof of password knowledge is not required first</text> </box> <box align="center"> <icon name="arrow-down" color="secondary" size="lg" /> </box> <box background="surface-secondary" radius="md" padding={3} align="center"> **AS-REP material may be obtained for offline cracking** </box> </box> </box>

The second flow illustrates the exposure created by the misconfiguration. Obtaining the response does not mean the attacker has already recovered the password.

3. How an AS-REP Roasting Attack Unfolds

Stage 1: Initial access or account discovery

An attacker may already have access to a low-privileged domain account, or may be able to identify account names through another permitted or exposed source.

The ability to identify a username does not automatically provide access to the account.

Stage 2: Identify accounts without pre-authentication

The attacker identifies Active Directory accounts configured with the Do not require Kerberos preauthentication setting.

The setting is associated with the DONT_REQUIRE_PREAUTH user-account control flag.

Stage 3: Request authentication data

The attacker requests Kerberos authentication data for a vulnerable account.

Because the account does not require pre-authentication, the KDC may return an AS-REP response without the usual initial proof of password knowledge.

Stage 4: Collect encrypted material

The attacker obtains the relevant encrypted material from the response.

The material can be used for offline password guessing, subject to the account's encryption configuration and the applicable cracking method.

Stage 5: Attempt offline password cracking

The attacker tests candidate passwords against the captured material without repeatedly submitting guesses to the domain controller.

If the password is weak or predictable, it may be recovered. Strong, randomly generated passwords make successful cracking substantially more difficult.

Stage 6: Use recovered credentials

If the password is recovered, the attacker may attempt to authenticate as the account through supported authentication methods.

The resulting access depends on account permissions, password validity, authentication policies and the services available to that identity.

Stage 7: Potential privilege escalation or lateral movement

If the compromised account has access to sensitive applications, administrative systems or other resources, the attacker may attempt to expand their access.

AS-REP Roasting does not automatically grant domain administrator privileges. Any subsequent escalation requires a viable additional attack path.

4. Why Accounts Without Pre-Authentication Are Vulnerable

The account setting that permits AS-REP Roasting is the key exposure, but the practical risk varies by account.

Legacy compatibility requirements

Some accounts may have been configured without pre-authentication to support older or specialised systems. The setting can remain enabled long after its original purpose has disappeared.

Weak passwords

The encrypted authentication material can be tested offline. Weak passwords, predictable patterns and reused credentials can therefore increase the chance of successful recovery.

Privileged accounts

If a vulnerable account belongs to a privileged user or has broad access to sensitive systems, a recovered password may have serious consequences.

Service and application accounts

Some application identities may have elevated permissions or access to databases and internal services. Their configuration should be reviewed carefully rather than assuming that non-interactive accounts are low risk.

Limited authentication monitoring

Offline password guessing does not generate a separate domain-controller event for every candidate password tested. As a result, traditional monitoring for repeated failed logons may not detect the cracking phase itself.

5. AS-REP Roasting vs. Kerberoasting

These attacks both involve Kerberos authentication material and offline password cracking, but they target different stages of the protocol.

FeatureAS-REP RoastingKerberoastingPrimary targetAccounts without Kerberos pre-authenticationAccounts associated with service principal namesMain prerequisitePre-authentication disabled on the target accountA suitable service ticket can be requestedRelevant ticket materialAS-REP responseKerberos service ticket (TGS)Main weaknessMisconfigured account authenticationWeak service account password or credential managementCommon event to investigateEvent ID 4768Event ID 4769Main defenceRequire pre-authenticationStrong service account credentials and managed identities

Both attacks can permit offline password guessing, but a successful investigation must establish which authentication mechanism was involved.

6. Investigating AS-REP Roasting in a SOC

Consider a hypothetical alert in which a domain controller records unusual Kerberos authentication requests for several user accounts. One account is not expected to be accessed from the originating workstation, and Active Directory records show that pre-authentication is disabled for that account.

The SOC analyst must determine whether the activity reflects a legitimate application, an authorised assessment or an attempted AS-REP Roasting attack.

Step 1: Review Windows Security Event ID 4768

Event ID 4768 — A Kerberos authentication ticket (TGT) was requested is a key source of evidence for AS-REP Roasting investigations.

Review available fields such as:

• Target account name.

• Client IP address.

• Ticket encryption type.

• Status or failure information.

• Timestamp.

• Other fields available in the Windows event schema.

Investigate unusual requests involving accounts known to have pre-authentication disabled.

However, Event ID 4768 is also generated during legitimate Kerberos authentication. A successful event does not, by itself, establish that AS-REP Roasting occurred.

Step 2: Check the account configuration

Review the account's user-account control settings in Active Directory.

Determine whether the Do not require Kerberos preauthentication option is enabled and whether the configuration has an approved business justification.

Also examine:

• Account owner.

• Business purpose.

• Privileged group membership.

• Password-management practices.

• Last password change.

• Recent configuration changes.

• Whether the account is still required.

Prioritise accounts that have no documented reason for the setting or possess elevated permissions.

Step 3: Establish the authentication baseline

Compare the request pattern with normal activity for the source host and account.

Questions to investigate include:

• Did the source request authentication data for multiple unrelated accounts?

• Was the activity initiated from an expected administrative or application system?

• Did the requests occur during an authorised security assessment?

• Was the account normally used from that source?

• Were there other suspicious Active Directory discovery events?

The number of requests alone is not sufficient to determine malicious intent.

Step 4: Review encryption and response information

Inspect available ticket encryption details and relevant authentication status fields.

Different encryption types can affect how captured material is handled during offline password guessing. However, encryption type alone does not establish that an attack occurred or that the password is recoverable.

The absence of an obvious encryption anomaly does not rule out AS-REP Roasting.

Step 5: Correlate endpoint telemetry

Review EDR alerts and process activity from the requesting system.

Look for suspicious account enumeration, Active Directory discovery, unusual administrative tools or other behaviour that could explain how the target account was identified.

Determine whether the requests were part of a broader credential-access sequence.

Step 6: Investigate potential credential compromise

Offline cracking may occur on another machine and may not be visible in domain-controller logs.

Instead, investigate subsequent activity that could indicate the account's password was recovered:

• Successful logons from unfamiliar hosts.

• Access to sensitive applications outside normal working patterns.

• Unexpected remote administration.

• Changes to account permissions or group membership.

• Unusual access to files, databases or other internal resources.

Correlate these events with the original authentication requests.

Step 7: Determine the incident classification

Use evidence to distinguish between:

• Misconfiguration identified: An account does not require pre-authentication, but no suspicious use has been established.

• Suspected AS-REP Roasting: Authentication patterns and context indicate targeted requests against vulnerable accounts.

• Confirmed credential exposure: Evidence establishes that the account password was recovered or compromised.

• Confirmed account abuse: The compromised account was used for unauthorised access or activity.

A vulnerable configuration is a security finding even when exploitation cannot be confirmed. Conversely, unusual Kerberos activity alone does not prove that an attacker cracked a password.

7. Evidence and Indicators to Review

AS-REP Roasting does not have a single definitive indicator of compromise. The investigation should combine authentication records, account configuration and subsequent identity activity.

Evidence sourceWhat to investigateWindows Security Event 4768TGT requests, client addresses, account names and ticket informationActive Directory account settingsAccounts with pre-authentication disabledAccount change auditingChanges to user-account control settingsWindows Security Event 4624Successful logons that may follow suspected credential recoveryWindows Security Event 4625Failed logons associated with possible account misuseEDR telemetryAccount discovery, suspicious tools and credential-access behaviourDomain controller logsUnusual authentication request patternsIdentity monitoringUnexpected account use, privilege changes and unusual accessAsset and account inventoriesAccount owners, business purpose and privilege level

Patterns that may warrant investigation

• Authentication requests involving accounts configured without pre-authentication.

• One source requesting authentication data for multiple unrelated accounts.

• Requests for accounts that are not normally used from the source system.

• A vulnerable account with excessive privileges or weak credential management.

• Successful authentication from a new system following suspicious requests.

• Account or privilege changes after suspected credential compromise.

These patterns are investigation leads, not proof of successful password cracking.

8. Detection Engineering and MITRE ATT&CK

A practical detection strategy combines Kerberos authentication telemetry with account configuration and identity behaviour.

Example detection logic

1. Maintain an inventory of accounts that do not require Kerberos pre-authentication.

2. Monitor Event ID 4768 activity involving those accounts.

3. Identify unusual requests from unfamiliar systems or requests involving multiple unrelated accounts.

4. Enrich the activity with account privilege, password-management status and configuration history.

5. Correlate the events with endpoint discovery and subsequent authentication activity.

6. Prioritise vulnerable privileged accounts and evidence of follow-on misuse.

Avoid alerting solely because an account has the setting enabled. Some environments may have documented compatibility requirements, but those accounts should still be reviewed and monitored.

MITRE ATT&CK mapping

• T1558.004 — AS-REP Roasting: The specific technique involving Kerberos accounts that do not require pre-authentication and offline password cracking.

• T1087.002 — Domain Account Discovery: Relevant when evidence indicates discovery of domain accounts.

• T1078 — Valid Accounts: Potentially relevant if recovered credentials are subsequently used for unauthorised access.

• T1098 — Account Manipulation: Relevant only if evidence shows that an attacker modified an account to maintain or expand access.

Do not assign all these techniques to every AS-REP Roasting alert. Map only the behaviours supported by evidence.

9. Preventing AS-REP Roasting

The primary defence is to require Kerberos pre-authentication for accounts that do not have a documented requirement to disable it.

Enable Kerberos pre-authentication

Review accounts with the Do not require Kerberos preauthentication setting enabled.

Where no legitimate requirement exists, restore the normal pre-authentication requirement through an approved Active Directory change.

Before changing legacy application accounts, validate compatibility and coordinate with the application owner.

Strengthen account passwords

Use long, unique and randomly generated passwords for accounts that require passwords.

Strong passwords reduce the feasibility of offline guessing, but they do not replace fixing the pre-authentication misconfiguration.

Apply least privilege

Remove unnecessary administrative rights and restrict access to sensitive resources.

A compromised low-privilege account should not automatically provide a route to domain-wide access.

Protect privileged identities

Avoid using highly privileged accounts for routine application functions. Review the configuration of administrative and service accounts, and restrict where privileged identities can authenticate.

Monitor configuration changes

Alert when an account is configured not to require pre-authentication, particularly if the change is unexpected or involves a privileged identity.

Maintain an inventory of approved exceptions, their owners and their review dates.

Improve authentication visibility

Collect relevant Kerberos events from domain controllers and correlate them with identity and endpoint telemetry.

Use account context and normal behaviour to prioritise investigations rather than relying on a single event or fixed request threshold.

10. Incident Response Checklist

When AS-REP Roasting is suspected:

1. Preserve evidence: Collect Event ID 4768 records, relevant account settings and endpoint telemetry.

2. Identify vulnerable accounts: Determine which accounts do not require Kerberos pre-authentication and establish why.

3. Assess account risk: Review password strength practices, privileges and access to sensitive resources.

4. Investigate follow-on activity: Check for successful logons, unusual access and privilege changes.

5. Contain confirmed compromise: Disable or restrict affected accounts when warranted and coordinate with service owners.

6. Rotate exposed credentials: Change compromised passwords and investigate possible reuse elsewhere.

7. Fix the configuration: Require pre-authentication unless a documented, validated requirement prevents it.

8. Validate recovery: Confirm that the setting is corrected, affected credentials are secured and suspicious activity has stopped.

Conclusion

AS-REP Roasting demonstrates how an Active Directory configuration intended for specialised compatibility can create an opportunity for offline password cracking.

When Kerberos pre-authentication is disabled, an attacker may obtain authentication material without first proving knowledge of the account's password. If that password is weak, it may be recovered and used to access resources available to the account.

For SOC analysts, the priority is to identify vulnerable account configurations, correlate Event ID 4768 with the source system and investigate subsequent account activity. For defenders, the strongest measures are to require pre-authentication, strengthen account credentials and minimise the privileges of every identity.

The key lesson: A Kerberos account that skips pre-authentication can expose password-guessing material before the attacker has authenticated.

Further Reading

• MITRE ATT&CK — T1558.004: AS-REP Roasting

• Microsoft Learn — Kerberos authentication overview

• Microsoft Learn — Windows Security auditing and Event ID 4768

• Microsoft Learn — Active Directory user-account control attributes

• Microsoft Learn — Active Directory security best practices