Reaper Write-up

Sherlock in Hack The Box

Challenge Information

Category: Sherlock Difficulty: Very Easy Challenge: Reaper

Challenge Overview

Reaper is a Sherlock-style DFIR challenge focused on investigating a suspicious authentication event detected by the organization’s SIEM. The alert indicated a mismatch between the source workstation name and the associated IP address, suggesting possible credential theft or relay activity.

The challenge provides two evidence files:

• Security.evtx
• ntlmrelay.pcap

The objective is to correlate network traffic with Windows event logs to determine how the attacker intercepted credentials and used them to authenticate within the environment.

For this investigation, I used:

• Wireshark for packet analysis
• Event Viewer for Windows Security Log analysis

Initial Network Enumeration

The first task was identifying the legitimate workstation IP addresses within the network.

Since Windows environments commonly use NBNS (NetBIOS Name Service) for hostname resolution, I filtered for NBNS traffic inside Wireshark.

NBNS packets revealed hostname-to-IP mappings for the organization’s workstations.

From the captured traffic, I identified:

• FORELA-WKSTN001 → 172.17.79.129
• FORELA-WKSTN002 → 172.17.79.136

These values established the baseline of legitimate hosts on the network.

Flags

• 172.17.79.129
• 172.17.79.136

Identifying the Victim Account

The challenge hinted that a user’s credentials had been intercepted.

While reviewing the network traffic, an additional device appeared on the network:

172.17.79.135

This address did not correspond to any known workstation identified earlier.

Since NTLM relay attacks commonly involve SMB authentication, I filtered traffic using:

smb2 && ip.addr == 172.17.79.135

Reviewing the SMB session setup requests revealed:

NTLMSSP_AUTH
User: FORELA\arthur.kyle

This clearly identified the victim account whose NTLM authentication was captured by the attacker.

Flag

arthur.kyle

Discovering the Attacker System

The unidentified system involved in the authentication flow repeatedly appeared during SMB negotiations and credential exchanges.

Since neither workstation mapping matched this IP address, it became evident that this host was operating as the attacker’s machine.

The suspicious device was:

172.17.79.135

This system was likely performing a Man-in-the-Middle (MITM) attack and relaying NTLM authentication requests.

Flag

172.17.79.135

Determining the Target Share

To understand what resource the victim attempted to access, I examined SMB traffic further.

Searching for SMB errors using:

BAD_NETWORK_NAME

revealed a failed share access attempt.

The packet details showed the requested share as:

\\DC01\Trip

This was the network share the victim attempted to access, triggering the authentication process that ultimately exposed their credentials.

Flag

\\DC01\Trip

Correlating Authentication Events

After identifying the victim and attacker systems, I moved to the Security Event Logs to determine how the stolen credentials were used.

The challenge hint pointed toward:

Event ID 4624

with the following characteristics:

• Security ID = NULL SID
• Logon Type = 3
• Authentication Package = NTLM
• Logon Process = NtLmSsp

Searching for these indicators revealed the malicious authentication event.

Within the event details, the source port used during the network logon was:

40252

Flag

40252

Identifying the Malicious Session

The same Event ID 4624 contained the Logon ID associated with the suspicious session.

The value recorded was:

0x64A799

This Logon ID would later be useful for correlating additional activity performed by the attacker.

Flag

0x64A799

Confirming the Hostname Mismatch

The SIEM alert was generated because the hostname reported during authentication did not match the IP address assigned to that workstation.

Within the suspicious Event ID 4624 entry, the following values were observed:

Workstation Name

FORELA-WKSTN002

Source Network Address

172.17.79.135

Earlier analysis established that FORELA-WKSTN002 actually belongs to:

172.17.79.136

This mismatch confirms that the attacker spoofed or relayed authentication while presenting themselves as FORELA-WKSTN002.

Flag

FORELA-WKSTN002, 172.17.79.135

Determining the Time of Compromise

To establish the timeline of the incident, I reviewed the event metadata associated with the malicious logon.

Under:

Details → System → Time Created

the event timestamp was recorded as:

2024-07-31T04:55:16.2405897Z

Converting to the format requested by the challenge:

2024-07-31 04:55:16 UTC

Flag

2024-07-31 04:55:16

Identifying the Share Accessed by the Relay Tool

The final step was determining which share the attacker’s relay tool accessed after successfully authenticating.

The challenge hint pointed toward:

Event ID 5140

which records network share access events.

Using the previously discovered Logon ID (0x64A799) to correlate activity, I located the corresponding share access event.

The share name recorded was:

\\*\IPC$

The IPC$ share is commonly used by NTLM relay tools for remote authentication and service interactions, making it a strong indicator of relay-based activity.

Flag

\\*\IPC$

Attack Timeline Reconstruction

The investigation reveals the following attack chain:

1. Victim attempts to access \\DC01\Trip
2. Attacker machine (172.17.79.135) intercepts authentication traffic
3. Victim account arthur.kyle performs NTLM authentication
4. Attacker captures and relays the authentication request
5. Malicious logon occurs using spoofed workstation name FORELA-WKSTN002
6. Authentication succeeds via NTLM
7. Attacker accesses the IPC$ administrative share
8. SIEM detects a hostname-to-IP mismatch and generates an alert

Conclusion

Reaper demonstrates a classic NTLM relay attack in which an attacker positions a rogue device on the network to intercept and relay authentication attempts from legitimate users.

By correlating SMB traffic within the PCAP file and authentication events inside the Windows Security Logs, it was possible to identify the victim account, the attacker’s machine, the compromised session, and the exact authentication event that triggered the SIEM alert.

The key indicator that exposed the attack was the mismatch between the workstation name and its assigned IP address, ultimately revealing the relay activity and allowing the attack to be reconstructed successfully.