Windows LLMNR/NBT‑NS poisonings
Researchers are flagging LLMNR/NBT‑NS poisoning on Windows networks via packet analysis — an old yet effective lateral‑movement vector that keeps showing up in writeups this week. (x.com) (x.com)
Cynet published a hands‑on packet‑level guide titled “LLMNR & NBT‑NS Poisoning and Credential Access,” updated March 5, 2026, and demonstrates using Responder against Wireshark captures. (cynet.com)) Red Citadel posted a 1,395‑word explainer with annotated Wireshark screenshots on March 5, 2026 that walks through exact LLMNR/NBT‑NS query and response frames. (redcitadel.co.uk)) MITRE classifies LLMNR/NBT‑NS poisoning and SMB relay as ATT&CK sub‑technique T1557.001, explicitly linking broadcast name‑resolution spoofing to credential capture and relay. (explore.ontolocy.com)) Packet‑level indicators researchers point to include LLMNR on UDP port 5355 (filterable with udp.port == 5355 in Wireshark) and NetBIOS name service traffic on port 137. (en.wikiversity.org)) Several recent community repos and labs supply PCAPs and step‑by‑step analysis — for example a March 12 GitHub lab showing screenshots of captured LLMNR queries and subsequent NTLM authentication traffic. (github.com)) CTF and HTB writeups continue to use packet captures to reconstruct attacks, repeatedly showing an initial LLMNR/NBT‑NS response followed by NTLMv2 authentication that tools like Responder harvest. (nathan-ellison.com)) Published mitigations echoed across the writeups are concrete: disable LLMNR/NBT‑NS via Group Policy and enable SMB signing; these countermeasures are recommended in vendor blogs and defensive playbooks. (cynet.com)) Analysts note the reason the vector resurfaces in contemporaneous writeups is operational simplicity — an attacker only needs network presence on the victim’s subnet to respond to multicast name queries and capture authentication material. (resecurity.com))
