Kerberos Attack Lab: AS-REP Roasting and Detection

AS-REP roasting is one of the most practical Kerberos attacks because it does not require domain admin rights. If a user account has preauthentication disabled, an attacker can request an AS-REP and crack the encrypted response offline. In a lab, this is a perfect exercise because you can see both the offensive technique and the detection signals.

This post walks through a lab setup, how to trigger AS-REP roasting with Impacket, and how to detect it using Windows logs.

Lab setup

You need a domain controller and a domain-joined client. Create a test user and disable preauthentication. In Active Directory Users and Computers, open the user properties, go to the Account tab, and check “Do not require Kerberos preauthentication”.

This setting is intentionally risky, which is why it is a common misconfiguration exploited in real networks.

Offensive step: request AS-REP

From a domain-joined host or a Kali box with network access, use Impacket. The GetNPUsers.py tool requests an AS-REP for any account with preauth disabled.

python3 GetNPUsers.py LAB.LOCAL/user1 -no-pass -dc-ip 192.168.56.10

The output is a hash in a format suitable for cracking with Hashcat or John. The attacker can now attempt to crack the password offline.

Detection signal: Event ID 4768

On the domain controller, AS-REQ messages are logged as Event ID 4768. When preauth is disabled, the Pre-Authentication Type field is 0. That is the key signal.

A simple filter in Event Viewer:

• Log: Security
• Event ID: 4768
• Pre-Authentication Type: 0

Why preauth matters

Kerberos preauthentication proves that the client knows the password by encrypting a timestamp with the user’s key. If preauth is disabled, the KDC will return an AS-REP encrypted with the user’s key without that proof. That is what makes offline cracking possible. Attackers can request AS-REPs for many users and crack the hashes at their own pace.

In practice, this makes weak passwords very risky. A single user with preauth disabled and a weak password can be enough to gain a foothold in the domain.

PowerShell query

To find these events quickly, use PowerShell on the DC:

Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4768} | 
  Where-Object { $_.Properties[8].Value -eq 0 } | 
  Select-Object TimeCreated, @{n="User";e={$_.Properties[0].Value}}, @{n="Client";e={$_.Properties[9].Value}}

The property indices can vary by Windows version, so verify them once on your system and update the script accordingly.

SIEM query example

If you ingest Security logs into a SIEM, create a saved search for 4768 with Pre-Authentication Type = 0. Add a threshold so that multiple requests from the same client within 5 minutes generate a high priority alert. This helps you catch bulk AS-REP harvesting.

In OpenSearch or Elastic, the query can be as simple as:

EventID:4768 AND PreAuthType:0

Then add a terms aggregation on ClientAddress to see which host is doing the requests.

Correlation and enrichment

To reduce false positives, correlate the AS-REP event with:

• Unusual source IPs or hosts that are not domain members
• Multiple AS-REP requests in a short time window
• Accounts that should never be used interactively

If you have Sysmon or EDR, correlate with process creation on the source host to identify the tool used.

Attack chain context

AS-REP roasting is often preceded by account enumeration. Attackers will query for users that do not require preauth, either by abusing LDAP or by using tools like GetNPUsers.py with a user list. If you monitor LDAP queries or DC security logs for unusual account enumeration patterns, you can catch the recon phase before the AS-REP requests start.

In a lab, simulate this by querying LDAP with a large list and observing the DC logs. Pair that with the 4768 events to build a multi-step detection that is stronger than a single signal.

Mitigations beyond preauth

If you cannot enable preauth due to legacy constraints, reduce the blast radius. Use long random passwords for service accounts, mark them as "Account is sensitive and cannot be delegated", and restrict them to specific hosts with authentication policies. Also consider setting up an alert for any change to the preauth flag so you can catch accidental misconfigurations.

Monitor for password spray attempts against these accounts. Even if an attacker cannot get a valid AS-REP, they may still try online guessing.

Lab validation

Run GetNPUsers.py and confirm the 4768 event appears. Then attempt a hash crack with a small wordlist to see how quickly weak passwords fall.

hashcat -m 18200 asrep.hashes rockyou.txt

Do this only in your lab with a test account. The goal is to understand the risk, not to attack real systems.

Cracking considerations

AS-REP hashes are slower to crack than NTLM, but weak passwords still fall quickly. Use this lab to benchmark your password policy. If a short wordlist cracks the test account in minutes, your policy is not strong enough.

Also note that GPU acceleration can drastically reduce cracking time. Even a consumer GPU can test millions of guesses per second. This is why strong, unique passwords and enforced complexity matter for any account with preauth disabled.

Honey accounts and alerting

A useful lab exercise is to create a decoy account with preauth disabled and a strong random password. Any AS-REP request for that account should be suspicious. Alert on it immediately and use it as a canary for enumeration or roasting attempts.

Document who knows about the decoy and ensure it is not used for legitimate access. This keeps the signal clean and gives you a high confidence alert when it triggers.

Defensive remediation

The fix is simple: do not disable Kerberos preauthentication unless there is a strong legacy requirement. If you must, enforce strong passwords and monitor 4768 events with preauth type 0.

Lab checklist

Use this checklist to validate your lab detection:

• Create a test user with preauth disabled and verify the setting in AD.
• Run GetNPUsers.py and confirm Event ID 4768 with preauth type 0.
• Add a SIEM alert with a threshold and verify it triggers on repeated requests.
• Restore preauth or reset the password and confirm the alert stops.

Takeaways

AS-REP roasting is a classic example of a single misconfiguration enabling offline password attacks. The detection signal is clear and reliable. If your lab can detect it, you can scale that detection to production. Use it as a training exercise for both red and blue team skills.