Threat Hunting Exercise: Analyzing NTLM Relay to LDAP/SMB Dataset

This hunt covers T1557.001: Adversary-in-the-Middle - LLMNR/NBT-NS Poisoning and SMB Relay, where an adversary on the local network poisons name-resolution broadcast requests to coerce a victim host into authenticating to an attacker-controlled listener, then relays the captured NTLM authentication to a high-value target (a domain controller's LDAP service) to perform privileged actions as the victim - all without ever cracking a password hash.

Step 1: Hypothesis Formation

Hypothesis: Adversary running Responder (or ntlmrelayx) on the local subnet answers a broad/multicast LLMNR or NBT-NS name-resolution request from a victim host (triggered by, e.g., a mistyped share path), causing the victim to authenticate directly to the attacker's IP over SMB. The attacker relays this NTLM authentication in real time to the domain controller's LDAP service to add a computer account or modify a privileged group membership - a relay-to-LDAP escalation (the "RemotePotato0"/"ntlmrelayx to LDAP" pattern). Indicators:

• Network/DNS logs: LLMNR (UDP/5355) or NBT-NS (UDP/137) broadcast query with no legitimate DNS answer, followed by a unicast response from an unexpected host.
• Sysmon Event 3 on the victim: outbound SMB (445) connection to a peer workstation IP (not a file server) - victims don't normally initiate SMB sessions to other workstations.
• Security 4624 on the relay target (DC): LogonType=3, AuthenticationPackageName=NTLM, workstation name matching the victim, but source IP matching the attacker's host (IP/name mismatch is the tell).
• Security 5136/4662 on the DC: a directory object modification (e.g., ms-DS-MachineAccountQuota-created computer object, or group membership change) attributed to the victim's account, occurring within the same relay session.

Null Hypothesis: Legitimate NetBIOS/LLMNR fallback resolution during normal name-resolution failures with no attacker present (a very common, usually benign broadcast pattern). Invalidate via the presence of an unexpected unicast responder, the victim's subsequent SMB connection to a workstation (not a server) IP, and - most conclusively - the IP/hostname mismatch on the relayed LDAP authentication at the DC.

Rationale: This is a distinct credential-abuse path from the Kerberoasting, DCSync, and Pass-the-Hash hunts already in this series - it requires no prior credential theft at all, just network position, making it one of the most "zero-to-domain-admin" techniques an internal hunt team needs to actively watch for.

Step 2: Data Sources and Scope

• Sources: Network/DNS broadcast capture or switch-mirrored traffic for LLMNR/NBT-NS; Sysmon (3 net connect) on the victim; Security (4624, 4662, 5136) on the domain controller.
• Scope: ~2022-11-14T14:02:00-14:02:45 UTC; Victim: WORKSTATION27.theshire.local (172.18.39.55); Attacker host: WORKSTATION41.theshire.local (172.18.39.88, compromised via a prior foothold); DC: MORDORDC.theshire.local.
• SIEM Queries (Splunk/ELK):
• Broadcast poisoning: sourcetype=network_capture proto=UDP dest_port IN (5355,137) | stats count by src_ip, query (look for one host answering many others' broadcast queries)
• Victim SMB-to-workstation: index=sysmon EventID=3 DestinationPort=445 | where dest_ip is workstation_subnet AND NOT dest_ip in known_file_servers
• Relay mismatch: index=security EventID=4624 AuthenticationPackageName="NTLM" | where WorkstationName!=resolve(IpAddress)

Step 3: Key Findings

Parsed events (8 shown) confirm the full poison-capture-relay chain, ending in an attacker-controlled computer account added to a privileged group via relayed LDAP write access.

Validation:

• Timeline: Typo'd share path → poisoned response → SMB auth attempt → real-time relay to LDAP → computer account creation → privilege grant, all within 5 seconds - demonstrates why this attack is so dangerous: it requires no dwell time or prior access beyond network position.
• False Positives: WORKSTATION27 has no legitimate reason to resolve or connect to WORKSTATION41 as a file server; the WorkstationName/IpAddress mismatch on the 4624 event has no benign explanation (NAT/proxy scenarios would show consistent, known infrastructure IPs, not another workstation's address).
• Correlation: wkline's account is used as the vector but is not itself the target - the actual objective (a persistent privileged computer account) is fully independent of wkline's own privilege level, which is why relay attacks are so effective against "regular" users.

Step 4: Recommendations & Next Steps

• Response: Disable LLMNR and NBT-NS via GPO (Turn off Multicast Name Resolution, and disable NetBIOS over TCP/IP on adapters); enable SMB Signing (mandatory, not just negotiated) to prevent NTLM relay of SMB sessions; delete the rogue ATTACKERPC$ computer account and reverse its group membership; enable LDAP signing/channel binding on all domain controllers (the actual fix for LDAP-relay specifically).
• Detection: Sigma: title: NTLM Relay via LLMNR Poisoning → selection: EventID=4624 AuthenticationPackageName='NTLM' AND WorkstationName resolves to different IP than IpAddress field combined with network-level LLMNR/NBT-NS anomaly detection (one host answering many broadcast queries).
• Pro Tip: Reducing ms-DS-MachineAccountQuota to 0 for standard users closes the specific escalation path used here (computer account creation) even if relay itself can't be fully prevented - a cheap, high-value compensating control.

Hypothesis confirmed - LLMNR poisoning and real-time NTLM relay to LDAP resulting in full domain compromise, requiring zero prior credential access! The WorkstationName/IpAddress mismatch on the DC's 4624 event was the single most conclusive piece of evidence in this entire hunt.