Campfire-2

Sherlock Description

Forela’s Network is constantly under attack. The security system raised an alert about an old admin account requesting a ticket from KDC on a domain controller. Inventory shows that this user account is not used as of now so you are tasked to take a look at this. This may be an AsREP roasting attack as anyone can request any user’s ticket which has preauthentication disabled.

Sherlock	Campfire-2
Category	DFIR
Difficulty	Very Easy
Creator	CyberJunkie
Released	27th June, 2024

Research

Active Directory is the backbone of most enterprise environments and for that reason, it is also one of the most targeted systems in modern cyber attacks. Kerberos, the authentication protocol, was designed to be secure, but misconfigurations and legacy settings can turn it into an attacker’s best friend. Two of the most commonly abused techniques: AS-REP Roasting and Kerberoasting exploit weaknesses in how Kerberos handles ticket requests, allowing adversaries to extract encrypted material from the network and crack credentials entirely offline, without ever triggering an account lockout.

This is exactly the situation Forela’s security team found themselves in.

This post documents the investigation that followed, walking through how I approached this scenario , diving into Windows Security Event Logs and hunting through Event IDs 4768, 4769, and 4771 to reconstruct the full attack timeline from a single .evtx file. No EDR, no SIEM. Just logs and an understanding of where Kerberos leaves its fingerprints when something goes wrong.

The methodology and detection scripts developed through this investigation are applicable well beyond this specific challenge. Whether you are triaging an alert in a production environment or working through a Sherlock of your own, the patterns are the same. 😎

Let’s get into what to hunt, and why it matters.

What to Hunt for in AS-REP Roasting

The Key Event IDs

Event ID	Name	Why It Matters
4768	Kerberos Authentication Ticket (TGT) Requested	The core AS-REP event (this is where you catch AS-REP roasting activity)
4769	Kerberos Service Ticket Requested	Shows post-authentication activity from the compromised account
4771	Kerberos Pre-Auth Failed	Shows failed login attempts before success
4624	Successful Logon	Confirms a session was established from the attacker’s machine

The Critical Field:

PreAuthType: 0

In Event ID 4768, the PreAuthType field is what you should focus on:

• PreAuthType: 2 indicates normal, secure authentication (pre-auth enabled)
• PreAuthType: 0 indicates **No pre-authentication required 🚩

When pre-auth is disabled on an account, anyone on the network can ask the KDC for that user’s TGT without proving they know the password first. The KDC hands back a ticket encrypted with the user’s password hash which the attacker then cracks offline.

TicketEncryptionType: 0x17

• 0x00000012 = AES256 - strong, modern encryption (normal)
• 0x00000017 = RC4-HMAC - weak, legacy encryption which is what attackers request because RC4 is far faster to crack offline 🚩

A combination of PreAuthType: 0 + EncryptionType: 0x17 on a 4768 event is a clear indicating of ASREP-Roasting Activity.

Recommended Reading — Campfire-1 Walkthrough

If you want to go deeper on Kerberoasting detection beyond Security Event Logs, I covered a closely related HTB Sherlock — Campfire-1

👉 Read the Campfire-1 walkthrough here →

Solution

Question 1

When did the ASREP Roasting attack occur, and when did the attacker request the Kerberos ticket for the vulnerable user?

When loading the SECURITY-DC log into Windows Event Viewer, timestamps are automatically converted to the local system timezone. In my case, this is GMT+3, so all times displayed are 3 hours ahead of UTC. To normalize to UTC - the standard for forensic reporting - simply subtract 3 hours from any timestamp shown.

2024-05-29 at 06:36:40 UTC

This is the only 4768 event with PreAuthType: 0 and EncryptionType: 0x17 (RC4). Everything else in the log shows PreAuthType: 2 (normal auth).

Question 2 - 4

Please confirm the User Account that was targeted by the attacker.

All three answers come from the same event 4768 highlighted above.

arthur.kyle

What was the SID of the account?

S-1-5-21-3239415629-1862073780-2394361899-1601

It is crucial to identify the compromised user account and the workstation responsible for this attack. Please list the internal IP address of the compromised asset to assist our threat-hunting team.

172.17.79.129

Question 5

We do not have any artifacts from the source machine yet. Using the same DC Security logs, can you confirm the user account used to perform the ASREP Roasting attack so we can contain the compromised account/s?

Filter for Event ID 4769 at 06:37:49 (just ~69 seconds after the AS-REP roast) where happy.grunwald@FORELA.LOCAL requests a service ticket from the same source IP (172.17.79.129). This tells you the attacker cracked arthur.kyle’s hash very quickly (or already had it), then moved laterally using happy.grunwald. It’s the only non-machine account making authenticated Kerberos requests from that attacking IP.

happy.grunwald