Rogue DHCP and ARP Spoofing: How an Attacker Owns Your LAN Before You Log In
A rogue DHCP server and a handful of forged ARP replies can put an attacker in the middle of every machine on a subnet — no malware, no phishing, no login required. Here's how the attack works, what to check on Windows, and how to stop it.
The attack that happens before you even log in
Picture this: an attacker walks into your office, plugs a $35 single-board computer into an empty wall jack in a conference room, and walks out. Nobody logs into anything. Nobody clicks anything. Yet within minutes, every machine on that subnet is routing its traffic through the attacker's box. No malware was installed, no credentials were stolen — yet. The network itself was turned against its users, and it happened before a single person typed a password.
This is the rogue DHCP and ARP spoofing combination, and it remains one of the most underrated attack scenarios on Windows networks. It works because the protocols it abuses — DHCP and ARP — were designed in an era when every device on a LAN was assumed trustworthy. They still carry no authentication by default.
How rogue DHCP works
When a Windows machine boots or joins a network, it broadcasts a DHCPDISCOVER packet asking, in effect, "who gives me an address?" Whichever DHCP server answers first wins. A rogue server on the same broadcast domain simply answers faster than the legitimate one — or floods the legitimate server with requests until it stops answering at all (DHCP starvation), leaving the rogue as the only responder.
The rogue doesn't need to hand out a broken configuration. The clever version hands out a perfectly working one, with one poisoned detail: the default gateway points at the attacker's machine, and the DNS server points at the attacker's resolver. Now every outbound connection from the victim flows through the attacker, who forwards it onward so nothing visibly breaks. The victim browses, works, and authenticates — all through a machine they never knew existed.
How ARP spoofing finishes the job
Even machines that already have a valid lease are vulnerable. ARP, the protocol that maps IP addresses to MAC addresses on a LAN, accepts unsolicited replies. An attacker sends forged ARP replies telling victim machines that the attacker's MAC address is the gateway's IP. The victims update their ARP caches and start sending gateway-bound traffic to the attacker. This is a man-in-the-middle position achieved with a handful of packets, no exploit, no vulnerability — just protocol behavior working exactly as designed.
From this position, the attacker can harvest credentials from unencrypted traffic, serve fake login pages for internal portals, strip TLS where downgrade is possible, and capture NTLM hashes from coerced authentication attempts. The blast radius is every machine on the subnet, not just one careless user.
What to look for on a Windows machine
The signs are there if you know where to check, and they are all cheap to audit:
- The DHCP server address doesn't match your known server. Run
ipconfig /alland compare the DHCP server against your documented infrastructure. A second or unexpected DHCP server address is the single clearest indicator of a rogue server. - The gateway's MAC address changed.
arp -ashows the gateway's MAC. If it doesn't match the MAC of your real router or firewall, something is answering for the gateway — and it isn't your router. - DNS servers you don't recognize. A rogue DHCP lease often pairs a plausible gateway with an attacker-controlled DNS resolver. Unknown DNS servers in
ipconfig /alloutput deserve immediate investigation, not a shrug. - Duplicate IP or gateway announcements. Multiple devices claiming the gateway's address, or gateway MAC addresses that flap between two values, are classic ARP spoofing fingerprints.
- Certificate warnings on internal sites. If users suddenly see TLS warnings for internal portals that used to load cleanly, treat it as a possible interception event until proven otherwise.
How WinSentinel catches it
WinSentinel audits the network configuration surface on each machine — DHCP server identity, DNS resolver settings, gateway and ARP state, and related network posture — as part of its full audit suite on a single machine, with no limits on which modules run. A machine that picked up a rogue lease shows up immediately: the DHCP server isn't the one you documented, the DNS resolvers aren't yours, and the gateway mapping doesn't match your infrastructure. That is a finding with a clear remediation — find the rogue device, remove it, and re-lease — not a vague warning to "review network settings."
The harder problem is scale. A rogue device affects a subnet, and the first machine that reports a rogue DHCP server tells you the subnet is compromised; the tenth machine reporting the same rogue server confirms it and maps the blast radius. That is where fleet-level rollup earns its keep: one central view of which machines across the organization are seeing the same unexpected DHCP server or the same spoofed gateway, so a local incident becomes a fleet-wide verdict in minutes instead of a ticket that sits in a queue while the attacker keeps collecting traffic.
Defending the LAN layer
- Enable DHCP snooping on managed switches. It drops DHCP offer packets from untrusted ports, which kills the rogue server at the switch before any client sees it. This is the single highest-value control here, and it costs nothing beyond switch configuration.
- Enable Dynamic ARP Inspection (DAI) alongside it. DAI validates ARP packets against the DHCP snooping binding table and drops spoofed replies. The two controls are designed to work together; either alone leaves a gap.
- Segment and police physical access. Unused wall jacks in conference rooms and lobbies should be disabled or placed on an isolated VLAN. The cheapest rogue device attack starts with an unattended port.
- Monitor for the indicators, continuously. DHCP server identity and gateway MAC mappings are not set-and-forget values. Audit them on a schedule, and alert when they change — a change is either an approved infrastructure move or an incident, and the difference should be confirmed, not assumed.
- Use 802.1X port-based authentication where you can. It stops an unauthorized device from joining the network at all, which removes the rogue's foothold entirely.
The lesson
Security teams spend enormous effort on endpoint detection and identity, and rightly so — but the LAN layer underneath it all still runs on trust. An attacker who controls DHCP and ARP doesn't need to defeat your EDR or phish your users. They just need to answer first. Audit the answers your machines are accepting, and a $35 box in a conference room stops being an invisible compromise and becomes a finding you close the same day.