Detecting AS-REP roasting in Active Directory authentication logs

AS-REP roasting is one of those identity attacks that can sit quietly in the background until an attacker has already gained useful foothold. For defenders, the challenge is not understanding the offensive technique in detail, but knowing what telemetry exists, what patterns matter, and how to turn that into a reliable detection. In a UK SME environment, that usually means making the most of domain controller logs, a SIEM such as Microsoft Sentinel, and a clear process for triage and remediation.

The good news is that AS-REP roasting leaves enough traceable behaviour to build practical detections, provided your logging is in place and you know which accounts are exposed. The technique depends on user accounts that do not require Kerberos pre-authentication, which is uncommon in well-managed environments but still appears in legacy configurations, service accounts, and forgotten test accounts. If you already have centralised logging in place, this is a good example of where identity telemetry can deliver high-value detection without needing complex tooling. If you are still maturing your log estate, it is worth revisiting the basics in what security logs you actually need and why and retaining evidence and logs for investigations.

What AS-REP roasting is and why it matters for defenders

AS-REP roasting is an abuse of Kerberos authentication where an attacker requests authentication material for an account that has pre-authentication disabled. In normal Kerberos flows, the client proves knowledge of the account secret before the Key Distribution Centre returns an encrypted response. If pre-authentication is disabled, the response can be requested without that proof, and the returned data can be used offline against a password guess. From a defender’s point of view, the important point is that the attack is low-noise compared with many other identity attacks, and it often targets accounts that have been left in an insecure state for operational convenience.

In the Kerberos attack chain, AS-REP roasting sits earlier than lateral movement and privilege escalation. It is typically an initial credential access step, not the final objective. That means a successful detection can prevent a broader compromise if you act quickly enough. It also means you should treat the alert as a sign of exposure as well as possible malicious activity. Even if the request came from a legitimate admin tool or a misconfigured service, the underlying issue is still that an account is unnecessarily exposed.

The key risk is not only the attack itself, but the presence of accounts with pre-authentication disabled. Those accounts are often overlooked because they may not be interactive user accounts. In practice, they can include service identities, old application accounts, or accounts created during migration work and never revisited. A detection programme should therefore combine event-based hunting with periodic directory review.

What to look for in Active Directory and domain controller logs

For most environments, the primary source is the Windows Security log on domain controllers. The most relevant event is Event ID 4768, which records a Kerberos authentication ticket request. When pre-authentication is disabled, the event can show a failure or a request pattern that is unusual for the account. The exact fields available depend on your Windows version and audit configuration, but analysts should pay attention to the account name, client address, failure code, and the encryption type where present.

It is also useful to correlate with Event ID 4738 for user account changes, because that can reveal when the pre-authentication setting was altered. If an account suddenly becomes roastable, that is a configuration change worth investigating in its own right. In some environments, Event ID 4720 for account creation and Event ID 4722 for account enabling can help establish whether the account is new or recently reactivated. For a broader view of identity abuse, the article on detecting fileless malware and living-off-the-land attacks is also relevant because identity compromise often pairs with post-authentication execution on endpoints.

Normal Kerberos activity is usually repetitive and predictable. Users authenticate from familiar subnets, at familiar times, and against a stable set of services. Suspicious activity tends to stand out in one or more of the following ways:

• Repeated ticket requests for the same account from a source that has not previously used it.
• Requests for multiple accounts from a single workstation or server in a short period.
• Activity outside normal business hours, especially where the account is not expected to be used interactively.
• Requests associated with accounts that should never need pre-authentication disabled.
• Changes to account attributes shortly before the suspicious requests.

Do not rely on a single event field. In many SIEMs, the best signal comes from combining the account, source IP, and timing rather than trying to match one exact event signature.

Building a practical detection approach

A useful detection strategy starts with two questions. First, which accounts in your directory have pre-authentication disabled? Second, which sources are requesting Kerberos material for those accounts in a way that does not match normal behaviour? If you can answer both, you can build a detection that is more robust than a simple threshold alert.

At the directory level, you can identify exposed accounts by querying the relevant userAccountControl flag or by using PowerShell against Active Directory. The precise method depends on your tooling, but the principle is the same: maintain a list of accounts where pre-authentication is disabled, then monitor those accounts continuously. That list should be reviewed alongside service account inventories and privileged account registers, because the operational context matters. A service account with a known exception is different from an ordinary user account that should never have that setting.

At the event level, look for repeated AS-REQ style activity against those accounts. In practice, this means building logic around repeated 4768 events or equivalent Kerberos request telemetry, grouped by account and source. If you see a burst of requests from a single host for several roastable accounts, that is more suspicious than a single request. Likewise, if the same account is queried from multiple sources in a short period, it may indicate automated collection rather than a human user.

Correlation is where the detection becomes useful. A simple pattern might be: a user account with pre-authentication disabled, followed by multiple Kerberos ticket requests from a source IP that has not historically used that account, within a short time window. If your SIEM supports entity mapping, map the user, host, and IP as separate entities so you can pivot quickly during triage. If you are designing detections more broadly, the approach is similar to other identity-focused rules described in mapping detections and controls to MITRE ATT&CK.

How to hunt for AS-REP roasting in SIEM and log platforms

In Microsoft Sentinel, a practical hunting query usually starts with the SecurityEvent table if you are ingesting Windows event logs, or with a normalised identity table if you have one. The goal is to identify 4768 events for accounts known to have pre-authentication disabled, then group by account, source address, and time window. A simple hunting approach might look like this in KQL:

SecurityEvent
| where EventID == 4768
| where Account has_any ("svc_", "test_", "legacy_")
| summarize RequestCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Account, IpAddress, Computer
| where RequestCount > 3

This is only a starting point. In a real environment, you would replace the placeholder account filters with a maintained watchlist of roastable accounts, then enrich the results with asset context and recent account changes. If you already use Sentinel, it is worth aligning this with the techniques in KQL threat hunting with Microsoft Sentinel.

For platform-agnostic detection engineering, Sigma-style logic is a good way to express the intent of the rule. The detection should not hard-code one event source if you can avoid it. Instead, define the behaviour: Kerberos ticket request activity against accounts with pre-authentication disabled, repeated from the same source or across a short time window, with optional enrichment from directory change events. That makes it easier to port the rule between SIEMs and to maintain it as your logging estate changes.

A useful pattern is to split the detection into two layers. The first layer is a low-noise analytic that flags requests against known exposed accounts. The second layer is a hunting query that looks for broader anomalies, such as bursts of Kerberos requests from a single host or requests from unusual subnets. This gives you both precision and coverage. In small teams, that balance matters more than trying to build one perfect rule.

Reducing false positives and improving fidelity

False positives are usually driven by legitimate but unusual authentication patterns. Service accounts are the most common example. Some older applications still use accounts with pre-authentication disabled, particularly where the application was built around a legacy authentication flow. Scheduled tasks, batch jobs, and migration tooling can also generate repeated requests that look noisy if you do not have the surrounding context.

To reduce false positives, maintain an allow list for known service accounts and known management hosts, but keep that list tight and reviewed. An allow list should not become a hiding place for poor hygiene. If an account is exempted, record why, who approved it, and when it will be reviewed again. That is useful operationally and helps if you need to explain the control later as part of broader assurance work.

Baselining is equally important. Before you alert aggressively, measure what normal looks like for your environment. How many 4768 events do you see for the relevant accounts? Which hosts normally talk to domain controllers? Which times of day are expected? A week or two of baseline data can save a lot of unnecessary noise. This is especially true in smaller organisations where a single admin workstation may legitimately touch many identities. The same principle applies to broader monitoring maturity, as discussed in what security logs you actually need and why.

Another useful tactic is to enrich alerts with directory metadata. If the account is disabled, stale, or not associated with a current business owner, the alert should be treated differently from a live service identity with a documented purpose. If the source host is a jump server or admin workstation, that may be expected. If it is a user laptop in a different subnet, the alert deserves more attention.

Validation and response workflow for analysts

When an alert fires, the first task is to validate whether the account is actually roastable. Check the directory attribute, confirm whether pre-authentication is disabled, and verify whether that is intentional. Then inspect the source of the requests. Is it a known management host, a service server, or an endpoint that has no obvious reason to query the account?

Next, determine whether the activity is isolated or part of a wider pattern. Look for multiple accounts queried from the same source, or the same account queried from multiple sources. Check whether the source host has other suspicious activity, such as unusual logons, remote service creation, or PowerShell execution. If you need a broader incident workflow, the article on incident triage and escalation workflows in SOC operations is a useful companion.

Containment priorities should be pragmatic. If the account is not required, disable it or remove the pre-authentication exception. If the account is required, reset the password, review where it is used, and consider moving it to a managed service account model where possible. If the source host appears suspicious, isolate it according to your endpoint containment process and preserve relevant logs before making changes. Do not forget to capture the timeline, because the sequence of account changes and requests is often what makes the case clear.

Follow-up investigation should include a review of related authentication events, recent account changes, and any privileged actions performed by the same user or host. If the account was used to reach a server or administrative interface, check for evidence of lateral movement. If the alert came from a service account, verify whether the application owner understands why the account exists and whether the configuration can be removed safely.

Hardening measures that reduce exposure

The most effective way to reduce AS-REP roasting risk is to eliminate unnecessary accounts with pre-authentication disabled. Start by inventorying those accounts, then classify them into three groups: no longer needed, needed but misconfigured, and needed for a documented technical reason. In many SMEs, the first two groups are larger than expected.

For accounts that are no longer needed, disable or remove them. For accounts that are needed, enable pre-authentication unless there is a clear and documented exception. If an application cannot function without the setting, treat that as a design issue to be remediated rather than a permanent state. Where possible, replace traditional service accounts with managed service accounts or group managed service accounts, which reduce password handling and make governance easier.

Monitoring directory changes is also important. Alert on changes to userAccountControl and related attributes, especially for privileged or service identities. A change to pre-authentication settings should be visible to the team that owns identity operations. If you already monitor other identity abuse patterns, such as those covered in detecting credential theft and misuse patterns, you can often reuse the same enrichment and escalation logic.

Finally, keep privileged account hygiene tight. AS-REP roasting is often more dangerous when the exposed account has access beyond its apparent role. Review group membership, delegated rights, and any service dependencies. A low-privilege account with a weak password is still a problem, but a privileged account with pre-authentication disabled is a much more serious exposure.

Operationalising the detection in a small security team

For small teams, the main challenge is not writing the detection once. It is keeping it useful over time. That means making sure the logs are retained long enough to support investigation, the rule is version-controlled, and the tuning decisions are documented. If you are using a SIEM, store the detection logic alongside your other content so changes can be reviewed and rolled back if needed.

Logging prerequisites matter. You need domain controller Security logs, consistent time synchronisation, and enough retention to compare current activity with historical baselines. If the logs are only kept for a few days, you may miss the context needed to tell whether an account is genuinely unusual. This is one reason centralised visibility across identity, endpoint, and network telemetry is so valuable in practice.

It is also worth mapping the detection to MITRE ATT&CK so you can track coverage and prioritise adjacent gaps. AS-REP roasting maps to credential access behaviour in the Kerberos space, and it sits naturally alongside other identity detections such as Kerberoasting and DCSync monitoring. That mapping helps when you are planning improvements or explaining coverage to stakeholders. It also makes it easier to see where one detection can feed another, for example when a suspicious authentication pattern is followed by endpoint execution or network beaconing.

In an ISO 27001-aligned environment, this kind of detection supports a broader risk-based approach to identity security, but the value is operational first. You are reducing the chance that a forgotten account becomes a foothold. You are also creating a repeatable process for finding and fixing weak directory settings before they become incidents. If you want help shaping that into a practical monitoring and hardening plan, speak to a consultant.

Common questions about AS-REP roasting detection

Can you detect AS-REP roasting from logs alone? In many cases, yes, provided you have the right domain controller logs and enough context to identify roastable accounts. The strongest detections combine authentication events with directory attribute data and source correlation. Logs alone may not prove malicious intent, but they are usually enough to identify suspicious activity and exposed accounts.

What logs and event IDs are most useful? Start with Windows Security Event ID 4768 on domain controllers, then add account change events such as 4738, and account lifecycle events such as 4720 and 4722 where relevant. The exact mix depends on your environment, but those events give you the best chance of spotting both the exposure and the activity that follows.

What is the difference between AS-REP roasting and Kerberoasting? Both are Kerberos-related credential access techniques, but they target different parts of the authentication flow. AS-REP roasting relies on accounts with pre-authentication disabled, while Kerberoasting targets service tickets for service accounts. From a defender’s perspective, both are identity exposure problems, but the telemetry and remediation steps are different.

For teams that want to improve detection maturity without overcomplicating the stack, AS-REP roasting is a good place to start. The telemetry is available, the risk is understandable, and the remediation is usually straightforward once the exposed accounts are identified. The key is to turn the detection into an operational process, not just a one-off query.

Frequently asked questions

Can you detect AS-REP roasting from Active Directory logs alone?

Often yes, but the quality of the detection depends on what you log and retain. Domain controller Security logs can show the relevant Kerberos request activity, but the best results come from combining those events with directory data that tells you which accounts have pre-authentication disabled.

What logs and event IDs are most useful for spotting AS-REP roasting activity?

Start with Windows Security Event ID 4768 on domain controllers. Add account change events such as 4738, and account lifecycle events such as 4720 and 4722 where they help with context. In a SIEM, correlate those events with source IP, host, and account metadata.

How do I reduce false positives in an AS-REP roasting detection?

Baseline normal authentication behaviour first, then keep a tight allow list for known service accounts and management hosts. Enrich alerts with directory ownership, account purpose, and source context so you can distinguish expected activity from unusual requests.

What is the main remediation step if an account is exposed?

Remove the pre-authentication exception unless there is a documented technical reason not to. If the account is required, review whether it can be replaced with a managed service account or otherwise redesigned to avoid the exposure.