Reaper

Scenario

Reaper is a very easy Sherlock which covers NTLM relay attacks , comprised of AD Forensics, MITM Attack detection & network forensics. In this sherlock players will analyze network traffic and window event logs to find evidence of NTLM relay attack which are common in active directory environments.

Executive Summary

A user mistyped a share name, the lookup fell through DNS to LLMNR, and an unknown host on the same segment answered the broadcast with a spoofed reply. The victim’s workstation sent its NTLM authentication to that host, which relayed it to a second workstation and obtained a network logon as the victim. The packet capture shows the poisoning and the NTLMSSP exchange. The Security log on the target shows the relayed logon, whose workstation name belongs to one machine while the source IP belongs to another. That mismatch is the detection.

Artifacts

• Packet capture: ntlmrelay.pcapng → open with tshark (or Wireshark)
• Security event log: Security.evtx → parse with EvtxECmd to CSV, then filter the CSV

Timestamp note: The time question wants YYYY-MM-DD HH:MM:SS in UTC. EvtxECmd already outputs UTC.

Discovery

Start with the name resolution traffic. DHCP requests and NBNS announcements carry the client hostname next to its address, so a short filter over those protocols maps each workstation to an IP without reading the whole capture.

tshark -r ntlmrelay.pcapng -Y "dhcp || nbns" -T fields -e ip.src -e dhcp.option.hostname -e nbns.name

Same output as Q1, second hostname. Keep this mapping handy: the detection in Q8 depends on this name and this address disagreeing with what the event log reports.

tshark -r ntlmrelay.pcapng -q -z conv,ip

Credential Access

Look at LLMNR and NBNS together. A user mistyped a share name (\\D), the DNS lookup failed, and the client broadcast an LLMNR query. A reply came back from an address that is neither workstation from Q1 and Q2. That host is answering names it has no reason to own, which is the poisoning.

tshark -r ntlmrelay.pcapng -Y "llmnr || nbns" -T fields -e frame.time -e ip.src -e ip.dst -e dns.qry.name

After the spoofed reply, the victim opens an SMB session to the poisoner and runs NTLM. The NTLMSSP_AUTH message carries the account name in clear text, so pull the NTLMSSP fields for the exchange with the Q4 host.

tshark -r ntlmrelay.pcapng -Y "ntlmssp.messagetype == 0x00000003" -T fields -e ip.src -e ip.dst -e ntlmssp.auth.domain -e ntlmssp.auth.username

Gotcha: The task’s format hint reads “Full Name”, but the platform wants the account name as it appears in NTLMSSP (first.last), not a display name.

The intended destination is visible in the SMB2 tree connect requests from the victim. The path in smb2.tree shows the server and share the user was really trying to reach before the mistyped name derailed it.

tshark -r ntlmrelay.pcapng -Y "smb2.cmd == 3" -T fields -e ip.src -e ip.dst -e smb2.tree

Lateral Movement

Parse the Security log first. EvtxECmd exited non-zero in this run because of an argument parsing complaint, but it still wrote the CSV, so check the output directory before assuming failure.

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

Then narrow to the relayed logon: a 4624 for the stolen account from the Q4 address.

grep 4624 work/evtx/sec.csv | grep -i "arthur.kyle" | grep "172.17.79.135"

One 4624 on Forela-Wkstn001 matches the stolen account arriving from the Q4 address. Its WorkstationName field names one of the two real workstations, yet the IpAddress is the attacker’s. The name was supplied by the relay tool during authentication, the IP is the real TCP source, and comparing them against the Q1/Q2 mapping exposes the relay.

The TimeCreated of that same 4624 event, in UTC.

The 4624 payload holds the network details of the logon. Extract IpPort from the same event.

grep 4624 work/evtx/sec.csv | grep "arthur.kyle" | grep -o "IpPort[^,;]*"

Same event, TargetLogonId. This is the handle to pivot on for everything the session did afterwards, such as the share access in Q10.

grep 4624 work/evtx/sec.csv | grep "arthur.kyle" | grep -o "TargetLogonId[^,;]*"

Look for share access events (5140, with 5145 as the detailed variant) on the target around the malicious logon. The relay tool touches the standard IPC share to complete authentication, and the event records the share as a wildcard-host path.

grep -E "5140|5145" work/evtx/sec.csv

Gotcha: The pcap’s tree connect path is the share the user wanted (Q5), not the share the relay tool touched. The answer comes from the 5140 event, not from the capture.

Attack Summary

IOCs

MITRE ATT&CK

Defender Takeaways

Disable LLMNR and NBT-NS. The whole chain started because a mistyped name was answered by whoever replied first. Turn both off by GPO and the typo just fails.

Require SMB signing everywhere. A relayed NTLM authentication is only usable if the target accepts unsigned sessions. Signing on workstations and servers makes the relay worthless.

Alert on 4624 events where workstation name and source IP disagree. Compare WorkstationName and IpAddress against asset records. This is the one check that caught the relay here.

Watch for unknown hosts answering LLMNR or NBNS. A reply from an address that is not a known name server or workstation is a strong poisoning signal in network telemetry.

Read the share events, not just the capture. The pcap showed the share the user wanted, but event 5140 showed what the attacker’s tool actually touched. They are different answers.

Conclusion

The attacker never cracked a password: one typo and a spoofed name reply were enough to relay a user’s NTLM authentication into a valid logon on a second workstation. Disabling LLMNR and enforcing SMB signing close the door, and the hostname-versus-IP mismatch in the 4624 is the cheap detection that would have caught it.