---
name: detect-l2-l3-attacks
description: "Detection and response for on-path Layer 2 and Layer 3 attacks on a local network: ARP cache poisoning, LLMNR/NBT-NS poisoning with SMB/LDAP relay (Responder-style), rogue DHCP, and on-LAN DNS forgery (MITRE ATT&CK T1557, T1557.001, T1557.002, T1557.003). Signals come from switch syslog (Cisco Dynamic ARP Inspection and DHCP Snooping), Zeek dns.log and dhcp.log, arpwatch, Sysmon network and NTLM telemetry, and a canary-name tripwire. Gives the wire-level signal, log sources, a hypothesis-driven hunt, and DAI, DHCP-snooping, LLMNR-disable, and signing hardening. Use when investigating duplicate-IP or gateway-MAC flaps, triaging a DAI or DHCP-snooping violation, hunting for Responder or an on-path adversary, chasing unexplained NTLM relay logons, writing ARP/LLMNR/DNS poisoning detections, or hardening a LAN against adversary-in-the-middle."
---

# Layer 2 / Layer 3 On-Path Attacks - Defensive Methodology

> **Tier 2 - methodology skill.** No bespoke UMBRASEC detection rule ships with this skill yet. It gives the defender's method, the log sources and signals, and the hardening, and points to public rule and sensor sources. Promotion to Tier 1 (a sourced, tuned UMBRASEC rule) is tracked in [COVERAGE.md](https://github.com/umbrasec-labs/umbra-blue/blob/main/COVERAGE.md). Do not treat the content below as citing a UMBRASEC rule; there is none for this threat yet.

## TL;DR

Switched Ethernet and the Windows name-resolution stack both trust unauthenticated broadcast and multicast by design, so an attacker on the same broadcast domain can insert themselves on-path four ways: forge ARP replies to claim the gateway's IP (T1557.002), answer LLMNR (`udp/5355`) and NBT-NS (`udp/137`) name lookups that real DNS failed (T1557.001), stand up a rogue DHCP server that hands out itself as gateway and DNS (T1557.003), and then forge DNS answers for the traffic now flowing through them. The goal is usually to capture or relay NTLM authentication. You detect this from three places at once: switch control-plane syslog (Dynamic ARP Inspection and DHCP Snooping), network metadata (Zeek `dns.log` / `dhcp.log`, arpwatch, Wireshark), and the Windows auth trail (Sysmon network connections plus NTLM relay logons). The highest-confidence single detection is a canary-name tripwire: query a hostname that does not exist and nothing should ever resolve, and treat any answer as a live poisoner. Hardening removes the class: DAI plus DHCP snooping on the switch, LLMNR and NBT-NS off on endpoints, and SMB/LDAP signing so a captured hash cannot be relayed. This skill is defensive and ships no spoofing, relay, or interception tooling.

## What it looks like, defender view

A host's ARP table shows the default gateway's IP suddenly bound to a new, unexpected MAC, and often two IPs (gateway and a target) now share one MAC. On the switch, DAI starts dropping ARP that does not match the DHCP-snooping binding table, and the control plane logs the offending port. In name-service telemetry you see a workstation that is not a DNS server answering LLMNR and NBT-NS queries authoritatively, frequently for mistyped or WPAD names, and answering a large share of the queries on its segment. A rogue DHCP shows up as a second server address issuing offers that no one provisioned, often advertising itself as both router and DNS. The payoff appears in the Windows logs as inbound NTLM network logons (relay) arriving shortly after the poisoning begins. Legitimate traffic keeps flowing, which is the point, so nothing breaks loudly.

## Log sources and signals

The signal lives across the switch control plane, passive network metadata, and the endpoint auth trail. Pull all three.

- **Switch control-plane syslog (the primary L2 signal).** With DHCP Snooping and Dynamic ARP Inspection enabled, Cisco IOS/IOS-XE emits from the `SW_DAI` and `DHCP_SNOOPING` facilities: `%SW_DAI-4-INVALID_ARP` and `%SW_DAI-4-DHCP_SNOOPING_DENY` (ARP that fails the binding table, the ARP-poisoning signal), `%SW_DAI-4-PACKET_RATE_EXCEEDED` (ARP flooding), and `%DHCP_SNOOPING-5-DHCP_SNOOPING_UNTRUSTED_PORT` (a DHCP server reply on a port not trusted to send one, the rogue-DHCP signal). Forward these to the SIEM and alert on the offending interface and MAC. Other vendors expose equivalents under IP Source Guard / ARP inspection and DHCP snooping features.
- **Passive network metadata (Zeek).** The Zeek DNS analyzer registers `udp/5355` (LLMNR) and `udp/137` (NBT-NS) alongside `53` and `5353`, so `dns.log` already carries name-service poisoning. Hunt for records where `id.resp_p == 5355 || id.resp_p == 137` with `answers` populated, then rank responders by `id.resp_h`: a normal endpoint answers almost none, a poisoner answers many. `dhcp.log` fields `server_addr` and `msg_types` give the rogue-DHCP view, any `server_addr` outside your provisioned allowlist is suspect. On-LAN DNS forgery shows as duplicate or inconsistent answers for the same query and answers whose source MAC is not your resolver.
- **ARP watchers and capture.** `arpwatch` logs IP/MAC pairing changes to syslog with the strings `changed ethernet address`, `flip flop` (rapid A/B/A oscillation, the classic poisoning tell), and `new station`. In a capture, Wireshark flags `arp.duplicate-address-detected` and `arp.duplicate-address-frame` when one IP answers from two MACs.
- **Windows endpoint auth trail (Sysmon + Security).** Sysmon Event ID 3 (network connection) to `224.0.0.252:5355` or `ff02::1:3` and broadcast `:137` shows who is sending or answering name-service queries. The relay payoff lands as Security Event ID 4624 LogonType 3 with `AuthenticationPackageName: NTLM` from an unexpected source, and, where NTLM auditing is enabled, Microsoft-Windows-NTLM/Operational Event ID 8004 on the domain controller (the NTLM authentication audit, which names the calling server, the user, and the client workstation). What normal looks like: LLMNR/NBT-NS do fire for genuine failed lookups, but a single host should not be the authoritative answerer for its whole subnet, and inbound NTLM network logons should trace to known services, not a peer workstation.

## Detection approach

Alert on the control-plane violation, not on the existence of the protocol. The high-signal conditions are: (1) any `SW_DAI` invalid-ARP or `DHCP_SNOOPING` untrusted-port event, which DAI and snooping only raise when the binding table is violated; (2) a single non-resolver host answering a disproportionate share of LLMNR/NBT-NS queries on its segment, measured as `answers`-populated `dns.log` records on `5355`/`137` grouped by `id.resp_h`; (3) a DHCP `server_addr` not on your provisioned allowlist; (4) arpwatch `flip flop` or a Wireshark duplicate-address hit on the gateway IP; and (5) inbound LogonType 3 NTLM logons that correlate in time with any of the above. The near-binary detection is a canary-name tripwire: periodically issue a name-resolution request for a random hostname that does not exist in DNS and is used by nothing, then flag any LLMNR/NBT-NS answer, because no honest workload ever answers for a name that does not exist. [Respounder](https://github.com/codeexpress/respounder) is a real public defensive tool that implements exactly this canary probe to detect a Responder-style poisoner on a segment. A tuned UMBRASEC rule is not yet shipped for this threat; for maintained public detections use the switch-vendor DAI / DHCP-snooping guidance, arpwatch, and the Zeek and network-connection rule directories in the [SigmaHQ repository](https://github.com/SigmaHQ/sigma) (for example `rules/network/zeek/` and `rules/windows/network_connection/`).

## Threat hunt

Hypothesis: an adversary on a user subnet is poisoning ARP, LLMNR/NBT-NS, or DHCP to get on-path and capture or relay NTLM.

1. Pull a window of switch syslog and group `SW_DAI` and `DHCP_SNOOPING` events by interface and source MAC. A clean network sits near zero; a poisoned port spikes. Map the MAC to a port and a physical location.
2. In Zeek `dns.log`, filter `id.resp_p == 5355 || id.resp_p == 137` where `answers` is populated and count by `id.resp_h`. Rank descending. The top responder that is not a designated resolver is your candidate poisoner. Note which queried names it answered, WPAD and mistyped internal names are typical bait.
3. In `dhcp.log`, list distinct `server_addr` values and `msg_types` containing OFFER/ACK. Any address outside the provisioned DHCP allowlist is a rogue server, especially one advertising itself as both router and DNS.
4. Correlate the candidate's IP/MAC and timing with Security Event ID 4624 LogonType 3 NTLM logons and Sysmon Event ID 3 to the multicast/broadcast name-service destinations. A poisoner that lines up with inbound NTLM relay logons is an active credential-capture operation, not a nuisance.
5. Confirm on the wire: arpwatch `flip flop` for the gateway IP, or a short capture showing the gateway IP answering from two MACs (`arp.duplicate-address-detected`).

## Hardening

The decisive controls remove the attack class rather than merely watching for it. On the switch, enable **DHCP Snooping** to build a trusted IP/MAC/port binding table (uplinks to real DHCP servers marked trusted, access ports untrusted), then enable **Dynamic ARP Inspection** and **IP Source Guard** so ARP and IP that do not match that table are dropped at the port. For static-IP segments with no DHCP lease to anchor the table, add explicit ARP ACLs. On endpoints, disable the legacy name services the poisoning abuses: set `EnableMulticast = 0` under `HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient` by GPO to turn off LLMNR, set `NetbiosOptions = 2` per interface under `NetBT\Parameters\Interfaces` to disable NBT-NS, and disable the WinHTTP Web Proxy Auto-Discovery (WPAD) path so a poisoner cannot win the proxy lookup. Finally, close the relay target: enforce **SMB signing** and **LDAP signing and channel binding** so a captured NTLM exchange cannot be relayed onward, which makes a successful poison far less useful. Segment aggressively, since every one of these attacks is confined to a single broadcast domain, so smaller VLANs shrink the blast radius. The framework mappings grounded in the UMBRASEC [detection and response guide](https://umbrasec.dev/guide/detection-and-response.html) cover logging and monitoring (ISO 27001:2022 A.8.15, A.8.16; NIST CSF 2.0 DE.CM, DE.AE) and platform hardening (NIST CSF 2.0 PR.PS) rather than DAI, DHCP snooping, or name-service configuration specifically, so no Essential Eight / ISO / NIST control maps cleanly onto the switch and endpoint controls above, and a framework table is deliberately omitted here rather than invented.

## Honest limitations

DAI and IP Source Guard are only as good as the DHCP-snooping binding table they consult, so static-IP ranges need hand-maintained ARP ACLs or they are unprotected, and neither control inspects trusted or uplink ports, where a compromised switch or server can still poison. These controls address IPv4 ARP; IPv6 Neighbor Discovery and Router Advertisement spoofing is a separate problem that needs RA Guard and ND inspection. Disabling LLMNR and NBT-NS does not disable mDNS (`udp/5353`), which stays open and can be abused similarly on some stacks. The Zeek `dns.log` hunt goes blind where clients use encrypted DNS (DoH/DoT), since the query and answer are no longer visible as plaintext name-service records. The canary-name tripwire only sees its own broadcast domain, so it must be run from a probe on each segment to give full coverage. Switch-MAC and ARP source fields are spoofable, so they identify the abused port, not necessarily the human. Baselines are environment-specific, name-service chatter is higher on networks with flaky DNS, so measure your own floor before alerting on volume, and treat the control-plane violation and the canary answer as the near-binary high-confidence signals.

## ATT&CK and D3FEND

- MITRE ATT&CK: [T1557 Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1557/) with [T1557.001 LLMNR/NBT-NS Poisoning and SMB Relay](https://attack.mitre.org/techniques/T1557/001/), [T1557.002 ARP Cache Poisoning](https://attack.mitre.org/techniques/T1557/002/), and [T1557.003 DHCP Spoofing](https://attack.mitre.org/techniques/T1557/003/). On-LAN DNS forgery that follows the poisoning sits under the T1557 parent.
- MITRE D3FEND: [D3-NTA Network Traffic Analysis](https://d3fend.mitre.org/technique/d3f:NetworkTrafficAnalysis/) and [D3-DNSTA DNS Traffic Analysis](https://d3fend.mitre.org/technique/d3f:DNSTrafficAnalysis/) for the detection side; [D3-BDI Broadcast Domain Isolation](https://d3fend.mitre.org/technique/d3f:BroadcastDomainIsolation/) for the segmentation hardening that confines every one of these attacks.
- Public rule and sensor sources: Cisco DAI / DHCP Snooping / IP Source Guard configuration guides; [arpwatch](https://ee.lbl.gov/); [Respounder](https://github.com/codeexpress/respounder) canary detection; [Zeek](https://docs.zeek.org/) `dns.log` and `dhcp.log`; [SigmaHQ repository](https://github.com/SigmaHQ/sigma) `rules/network/zeek/` and `rules/windows/network_connection/`.

**Scope note.** This is a defensive skill. It explains ARP, LLMNR/NBT-NS, DHCP, and on-LAN DNS poisoning only to the depth needed to detect and mitigate them and deliberately provides no spoofing, relay, interception, or Responder-style tooling. UMBRASEC publishes defense, not offense.