Noxious | Hack the box ctf
The IDS device alerted us to a possible rogue device in the internal Active Directory network. The Intrusion Detection System also indicated signs of LLMNR traffic, which is unusual. It is suspected that an LLMNR poisoning attack occurred. The LLMNR traffic was directed towards Forela-WKstn002, which has the IP address 172.17.79.136. A limited packet capture from the surrounding time is provided to you, our Network Forensics expert. Since this occurred in the Active Directory VLAN, it is suggested that we perform network threat hunting with the Active Directory attack vector in mind, specifically focusing on LLMNR poisoning.
Hunting a Rogue Device: Confirming an LLMNR Poisoning Attack in an AD VLAN
Incident context (what made this suspicious)
On June 24, 2024, the IDS raised an alert inside the Active Directory VLAN: unusual LLMNR traffic targeting Forela-WKstn002 (172.17.79.136). That alone is a red flag in most enterprise AD networks — LLMNR is typically unnecessary when DNS is healthy, and attackers love it because it enables name-resolution impersonation.
We were provided a limited PCAP around the alert window. The goal wasn’t just to say “LLMNR exists,” but to prove three things:
LLMNR was used as a fallback because a hostname failed to resolve normally.
A device was poisoning name resolution by replying to queries it should not own.
The poisoning led directly to NTLM authentication leakage, which can escalate into cracking or relay attacks.
Step-by-step analysis in the packet capture (what the PCAP actually shows)
1) The moment the environment “falls back” to LLMNR
In Windows environments, LLMNR is often triggered when a client can’t resolve a hostname through DNS quickly or at all.
In the capture, the workstation Forela-WKstn002 (172.17.79.136) broadcasts LLMNR queries attempting to resolve a host name. This is the key behavioral clue: instead of asking the DNS server, the host asks the local link:
Protocol: LLMNR
Pattern: Query → multicast/broadcast → anyone can answer
That behavior is exactly what an attacker abuses: they sit on the network and answer faster than legitimate infrastructure.
What to look for in Wireshark
Apply a filter like:
llmnr && ip.src == 172.17.79.136
This shows the victim issuing name queries.Then pivot to responses:
llmnr && ip.dst == 172.17.79.136 && llmnr.flags.response == 1
That pivot is where the poisoning becomes obvious.
2) The poisoning fingerprint: “someone replies who shouldn’t”
When we track the LLMNR responses sent back to Forela-WKstn002, one IP stands out:
✅ 172.17.79.135
This host repeatedly answers name-resolution requests that it does not legitimately own. In a clean environment, LLMNR responses for critical hosts (like DCs/fileservers) should be extremely rare — and even when they happen, they should not consistently come from an unknown endpoint.
Why this is malicious behavior
The rogue device is claiming it is the requested host, by replying:
“Yes, that name is me. Connect to my IP.”Windows then tries to authenticate to that “host” over SMB/NTLM, handing the attacker a challenge-response handshake.
So the packet story is:
Victim fails resolution → asks LLMNR → attacker replies “I’m that host” → victim attempts SMB auth → NTLM handshake leaks.
That chain is the core proof.
✅ Malicious responder IP: 172.17.79.135
3) Confirming the rogue host identity (SMB negotiation gives it away)
After LLMNR successfully tricks the victim into connecting, the next traffic often includes SMB negotiation. That SMB handshake can expose metadata that helps fingerprint the host.
When following the TCP/SMB stream (or inspecting SMB negotiation fields), the capture reveals the rogue machine hostname:
✅ Hostname: kali
That’s not definitive proof by itself (anyone can name a host “kali”), but combined with the LLMNR response behavior and NTLM capture sequence, it strongly matches a typical attacker workflow — especially Responder-style poisoning.
4) The victim credential exposure (NTLMSSP authentication sequence)
Once the victim is tricked into connecting, Windows attempts authentication automatically in many scenarios. The PCAP shows NTLMSSP messages as part of the authentication attempt.
In Wireshark, you can focus on this with:
ntlmsspor more specifically:
ntlmssp && ip.addr == 172.17.79.135
Inside those NTLMSSP packets, the username field appears:
✅ Exposed username: john.deacon
This is the “impact moment”: regardless of whether the attacker gets plaintext, the NTLM handshake is enough to attempt:
offline cracking (if it’s NetNTLMv2 style capture), or
NTLM relay attacks (if signing/protections are weak
5) Pinpointing the first confirmed hash capture (timeline anchor)
To define when the compromise began, we use the first observed NTLMSSP authentication event in the capture.
The earliest handshake appears at:
✅ First timestamp: 2024–06–24 11:18:30
That gives the incident a solid start time and lets defenders correlate:
workstation logs,
authentication logs,
EDR detections,
and any lateral movement attempts right after capture.
6) Root cause trigger: the typo that opened the door
This is the part many reports miss: poisoning often succeeds because of simple human error.
The capture indicates the victim attempted to reach a host using:
✅ DCC01 (typo) instead of DC01
This is important because it explains why LLMNR even happened: the victim asked for a host that doesn’t exist in DNS. When DNS fails, Windows falls back to LLMNR/NBT-NS depending on configuration.
So the “entry point” wasn’t a fancy exploit — it was a typo + legacy protocol fallback.
Extracting the NTLM evidence (what fields we pulled and why)
NTLM Server Challenge
In the NTLMSSP exchange, the server (rogue responder) provides a challenge value used in the response calculation:
✅ Server Challenge: 601019d191f054f1
NTProofStr
The capture also contains the NTProofStr, part of NetNTLMv2 response material that is used during verification/cracking attempts:
✅ NTProofStr: c0cc803a6d9fb5a9082253a04dbd4cd4
Together with the rest of the NTLM blob (domain, username, target info, response structure), these are the exact artifacts attackers export into formats crackable by tools like Hashcat.
Demonstrating real-world risk: cracking outcome
To validate the severity, the captured handshake was tested offline.
✅ Recovered password: NotMyPassword0K?
This confirms two things:
the capture was usable (not “noise”),
and the password strength was insufficient against cracking.
Even if cracking hadn’t worked, the captured handshake could still be used in relay scenarios if protections are missing.
The victim’s original intent (what they meant to access)
By tracking the user’s access attempt (and correlating the hostname they typed with the target share pattern), the intended resource was:
✅ Intended file share: \\DC01\DC-Confidential
That detail matters: this wasn’t a random typo to a printer — this was a sensitive share, which amplifies the impact and urgency.
Why this is a textbook Responder-style LLMNR poisoning attack
This PCAP matches the classic pattern:
LLMNR query from victim
fast spoofed LLMNR response from rogue host
SMB connection attempt to rogue IP
NTLMSSP authentication leaks identity + challenge/response
potential cracking / relay pathway opens immediately
Whether the attacker used Responder, Inveigh, or a custom tool, the packet behavior is the same — and the hostname “kali” is a pretty on-the-nose giveaway.
Defensive recommendations (practical, not generic)
Disable the protocols that make this possible
Disable LLMNR via Group Policy
Disable NBT-NS (NetBIOS name service) where feasible
Hardening against relay and credential abuse
Enforce SMB signing (where possible)
Enforce LDAP signing and LDAP channel binding (to reduce relay paths)
Consider disabling NTLM where feasible and moving toward stronger authentication controls
Detection: treat LLMNR responses as suspicious in AD VLANs
Alert on LLMNR responders, especially when:
responses originate from non-managed endpoints
responder IP is not a DNS server
multiple name queries are answered by the same host
Policy: reduce the blast radius of one leaked credential
Stronger password policy + avoid reuse
Privileged accounts should never be used from workstations
Segment sensitive services and apply strict access control