Campfire-2

Scenario

In this very easy Sherlock, players will go through Security logs from the Domain controller. We will work through what to look for to properly identify ASREP Roasting attack activity and to avoid false positives due to the complexity of Active Directory.

Executive Summary

An internal workstation sent the Domain Controller a Kerberos TGT request for a domain account that has pre-authentication disabled. The KDC answered without asking for proof of the password and handed back an AS-REP encrypted with weak RC4, which is the material an attacker cracks offline. The request stood out from normal logon traffic on three fields at once. Pivoting on the workstation’s address in the same log showed a second domain account requesting service tickets and touching a network share about a minute later, which identifies the account to contain alongside the roasted one. Everything came from a single Security.evtx, with no host artifacts from the source machine.

Artifacts

• Security event log: Security.evtx from the Domain Controller → parse with EvtxECmd, then filter the CSV

Timestamp note: The EvtxECmd CSV timestamps are UTC and match the required YYYY-MM-DD HH:MM:SS format as printed.

Credential Access

Parse the log to CSV first so it can be filtered instead of read event by event. ASREP Roasting shows on the DC as event 4768 (TGT requested) with PreAuthType 0, ticket encryption type 0x17 (RC4) and status 0x0. Any one of those alone matches ordinary traffic, but all three together leave a single event, and its TimeCreated is the answer.

EvtxECmd -f evidence/Security.evtx --csv work/evtx --csvf sec.csv

grep ',4768,' work/evtx/sec.csv | grep -E '0x17' | grep -E '0x0'

Gotcha: Filter on PreAuthType 0 and RC4 together. Either one alone is common in a domain, which is the false-positive trap the scenario warns about.

The same 4768 event names the roasted account in TargetUserName. The format hint is user.name, which matches the field as logged.

grep ',4768,' work/evtx/sec.csv | grep -E '0x17' | grep -E '0x0'

The SID is in TargetSid on the same event, so no second lookup is needed. The final -1601 is the RID of the targeted account.

grep ',4768,' work/evtx/sec.csv | grep -E '0x17' | grep -E '0x0'

IpAddress on the roasted 4768 is the client that sent the request, an internal address. That address is the pivot for the next question.

grep ',4768,' work/evtx/sec.csv | grep -E '0x17' | grep -E '0x0'

From Q4 we know the source address, so search the whole log for it. About a minute after the roast, at 06:37:49, that address produced a 4769 (service ticket request) and a 5140 (network share access) under a different account. The roast needs no credentials, so the account active from that host right afterwards is the one the attacker was working as.

grep '172.17.79.129' work/evtx/sec.csv | grep -E ',(4769|5140),'

Tip: This attribution rests on the shared source IP and tight timing in the DC log, not on host evidence. Contain the roasted account as well.

Attack Summary

IOCs

MITRE ATT&CK

Defender Takeaways

Alert on 4768 with PreAuthType 0. Legitimate logons almost never skip pre-authentication, so a hit is a strong signal, stronger still when paired with encryption type 0x17 and a success status. Alerting on either field alone would drown in normal Kerberos traffic.

Find and fix accounts with pre-authentication disabled. Re-enable “Require Kerberos preauthentication” on every account that has it off, or give those accounts long random passwords so the offline crack fails.

Prefer AES over RC4 for Kerberos where the environment allows it. RC4 tickets are what cracking tools prefer, and removing the option makes the offline step slower.

Pivot on the source IP. The DC log alone was enough to move from the roasted user to the workstation and then to the account active from it. Treat both accounts as compromised, since the attacker may hold credentials for the second one outside this log.

Conclusion

A single unauthenticated AS-REP request was the whole attack visible in this log, and it was distinguishable from normal traffic only by combining three event fields. The detection value sat in the DC’s 4768 events, and the source IP tied the roast to the account the attacker was actually using.