HackTheBox Reaper Writeup | NTLM Relay Attack Detection
Introduction
HackTheBox Reaper involves analyzing an NTLM relay attack, where an attacker operates within the network to exploit an LLMNR response caused by a typo in the host of a share path. This leads the victim to authenticate with the attacker, who then relays the authentication to another workstation to gain access. I’ll demonstrate the entire process using the provided PCAP file and Windows Security Log.
HackTheBox Reaper Description
Our SIEM alerted us to a suspicious logon event which needs to be looked at immediately . The alert details were that the IP Address and the Source Workstation name were a mismatch .You are provided a network capture and event logs from the surrounding time around the incident timeframe. Corelate the given evidence and report back to your SOC Manager.
What is NTLM Relay Attack
An NTLM relay attack occurs when an attacker tricks a target into authenticating to a system under their control. The attacker can either capture the target’s authentication hash (commonly a NetNTLMv2) or relay it to another system.
The NetNTLMv2 hash isn’t a traditional hash but rather a cryptographic challenge-response. In this process, the server sends the client a nonce (a unique, single-use dummy value) to encrypt using their NTLM hash. The client performs the encryption and sends the response back. If an attacker intercepts this response, they can perform a brute force attack, testing potential passwords by generating corresponding NTLM hashes and decrypting the nonce. If successful, they’ve identified the correct password.
However, relaying bypasses the need for cracking the challenge. Instead, the attacker intercepts an authentication attempt by the victim and uses it to authenticate to a different server. When the second server issues a nonce for encryption, the attacker forwards it to the victim, who unknowingly completes the process, believing they’re communicating with a legitimate server. The attacker then forwards the victim’s response back to the target server, effectively authenticating themselves as the victim.
A common method used in attacks is poisoning LLMNR (Link-Local Multicast Name Resolution). When a Windows domain host attempts to resolve a DNS name, it initially queries DNS servers. However, if the DNS resolution fails, the host falls back to LLMNR to resolve the name via multicast communication within the local network.
Windows Event Logs Analysis
I’ll use evtx_dump (available in Omer Ben Amram’s evtx repository, downloadable as a binary from the Releases page) to convert event logs into JSON format and utilize jq to query them directly from the Linux command line.
motasem@kali$ file Security.evtx
Security.evtx: MS Windows Vista Event Logmotasem@kali$ evtx_dump -o jsonl -t 1 -f Security.json Security.evtxWe can use jq to get the event ID for each log
motasem@kali$ cat Security.json | jq '.Event.System.EventID' | sort | uniq -c | sort -nr
38 4702
11 4624
1 5140
1 4662For reference:
- 4702 — A scheduled task was updated
- 4624 — An account was successfully logged on
- 5140 — A network share object was accessed
- 4662 — An operation was performed on an object
Packet Analysis with Wireshark
After loading the PCAP file in Wireshark, the bottom-right corner of the window indicates that there are 1,654 packets in the capture.
Under Statistics → Endpoints, it shows a total of 19 IPv4 addresses.
Nine of these addresses are within the 172.17.79.0/24 subnet, which is likely the private network associated with Forela in this scenario.
On the TCP tab, the observed low ports include 80, 88, 135, 389, 443, and 445. Based on this, I would identify 172.17.79.4 as the domain controller because it uses Kerberos (TCP 88) in addition to other standard Windows ports such as LDAP (389), RPC (135), and SMB (445). It’s worth noting that it’s somewhat unusual for a domain controller to listen on port 80, though this port only accounts for 5 packets with no data transfer.
Additionally, 172.17.79.135 appears to function as some kind of web server, as it shows bidirectional traffic on port 80.
Digging deeper, the initial two tasks require determining the IP addresses of two workstations. The PCAP contains NetBIOS (NBNS) refresh packets. By applying a filter for “nbns,” you can view all NetBIOS-related traffic.
The refresh packets originate from a host announcing its workstation name on the network. As a result, Forela-Wkstn001 is associated with 172.17.79.129 (Task 1), and Forela-Wkstn002 is associated with 172.17.79.136 (Task 2).
We can also see that the IP address 172.17.79.136 attempts to connect to the “D” computer. Initially, a DNS query is sent (packet 1149), but the response indicates that no such name exists. Following this, the host broadcasts LLMNR queries over both IPv4 and IPv6 (packet 1162).
At this point, 172.17.79.135 responds with its own IP address as the answer, which raises suspicion (Task 4).
It’s likely that the victim mistyped a UNC path intended for the domain controller, entering \\D\ instead of \\DC\. The attacker took advantage of this by claiming the IP address in the response.
At step 1, WKSTN002 (.136) is broadcasting LLMNR requests, which are being intercepted and poisoned by the attacker’s machine (.135) to impersonate its own identity. This results in WKSTN002 establishing a TCP connection with the attacker on port 445 in step 2 and initiating SMB authentication to access \D\IPC$ in step 3.
In step 4, the attacker initiates a TCP connection on port 445 to WKSTN001 (.129) and begins the SMB handshake in step 5.
Step 6 involves the relay attack. The attacker informs WKSTN002 that its session has expired, prompting WKSTN002 to reauthenticate. Any packets WKSTN002 sends to the attacker are then relayed to WKSTN001, allowing the attacker to authenticate as the user arthur.kyle (Task 3). By the end, WKSTN002 is attempting to access \D\IPC$ (as SMB often queries IPC$ before reaching the intended share), while the attacker simultaneously requests access to the same share on the victim machine. The string \172.17.19.129\IPC$ appears relevant to Task 10 but ultimately is not the correct answer.
Correlating The Analysis
If we pivot back to the event logs, a 5140 share access event has occurred. This indicates that the user arthur.kyle accessed \\*\IPC$ (Task 10) on WKSTN001 from the IP address 172.17.79.135. It’s unclear why it is logged this way, using * instead of the actual IP, as the PCAP shows the IP address. However, it is confirmed to be the same event.
motasem@kali$ cat Security.json | jq 'select(.Event.System.EventID==5140)'
{
"Event": {
...[snip]...
"EventData": {
"AccessList": "%%4416\r\n\t\t\t\t",
"AccessMask": "0x1",
"IpAddress": "172.17.79.135",
"IpPort": "40252",
"ObjectType": "File",
"ShareLocalPath": "",
"ShareName": "\\\\*\\IPC$",
"SubjectDomainName": "FORELA",
"SubjectLogonId": "0x64a799",
"SubjectUserName": "arthur.kyle",
"SubjectUserSid": "S-1-5-21-3239415629-1862073780-2394361899-1601"
},
"System": {
"Channel": "Security",
"Computer": "Forela-Wkstn001.forela.local",
...[snip]...
}Event 4624 indicates a successful login. To analyze this further and identify the relevant activity, I will use jq to filter these specific events and extract the IpAddress field.
motasem@kali$ cat Security.json | jq 'select(.Event.System.EventID==4624) | .Event.EventData.IpAddress' -r
::1
::1
172.17.79.135There’s only one event originating from the attacker’s machine. I’ll retrieve that specific event and use jq to extract the relevant data fields for closer analysis.
motasem@kali$ cat Security.json | jq 'select(.Event.System.EventID==4624 and .Event.EventData.IpAddress=="172.17.79.135") | .Event | {"Time": .System.TimeCreated["#attributes"].SystemTime, "SrcIP": .EventData.IpAddress, "SrcPort": .EventData.IpPort, "SrcHost": .EventData.WorkstationName, "Username": .EventData.TargetUserName, "LogonID": .EventData.TargetLogonId, "TargetHost": .System.Computer, "AuthPackage": .EventData.LmPackageName}'{
"SrcIP": "172.17.79.135",
"SrcPort": "40252",
"SrcHost": "FORELA-WKSTN002",
"Username": "arthur.kyle",
"LogonID": "0x64a799",
"TargetHost": "Forela-Wkstn001.forela.local",
"AuthPackage": "NTLM V2"
}This event represents an authentication attempt on WKSTN001 from WKSTN002 but originating from the attacker’s IP as arthur.kyle. The output includes key details such as the source port (Task 6), the logon ID (Task 7), and the timestamp (Task 9). Additionally, it reveals the workstation name and IP, which differ from the information uncovered in earlier tasks (Task 8).
Approximately 15 seconds after encountering the relaying issue due to mistyping the server’s name, the user on WKSTN002 successfully connects to the domain controller, DC01 (172.17.79.4), and requests access to the share \DC01\Trip (Task 5). It appears this is the share the user intended to connect to when they mistakenly entered “D” as the hostname instead of “DC01.”
This attempt also fails because, although the user is now connected to the correct host, the specified share does not exist. It’s unclear why this user struggles so much with navigating network shares, but fortunately, there are no negative consequences in this instance.
HackTheBox Reaper Sherlock Answers
What is the IP Address for Forela-Wkstn001?
172.17.79.129
What is the IP Address for Forela-Wkstn002?
172.17.79.136
Which user account’s hash was stolen by attacker?
Arthur Kyle
What is the IP Address of Unknown Device used by the attacker to intercept credentials?
172.17.79.135
What was the fileshare navigated by the victim user account?
\DC01\Trip
What is the source port used to logon to target workstation using the compromised account?
40252
What is the Logon ID for the malicious session?
0x64A799
The detection was based on the mismatch of hostname and the assigned IP Address.What is the workstation name and the source IP Address from which the malicious logon occur?
FORELA-WKSTN002, 172.17.79.135
When did the malicious logon happened. Please make sure the timestamp is in UTC?
2024–07–31 04:55:16
What is the share Name accessed as part of the authentication process by the malicious tool used by the attacker?
\*\IPC
