Two Legitimate DHCP Servers and One Imposter: Reading the Gateway Column
The challenge
Users on the office VLAN started complaining that the intranet looks slightly wrong, and the network team pulled a morning of DHCP and ARP events off the access switch. Counting DHCP servers will not solve this: there are genuinely two on this network, a primary and a failover, and both are supposed to be there. What matters is not how many servers answer but what they hand out. One of the responders is telling clients to route through an address that is not the site router, and because it also answers faster than the real servers, the clients that hear it take its offer and keep it. Work out which default gateway is the imposter and submit its IP.
What you'll learn
- Separate how many servers answer from what those servers hand out
- Use ARP announcements to establish the legitimate gateway
- Read lease time and address range as indicators of a rogue responder
- Explain why DHCP's first-offer-wins design makes this a race
- Connect a rogue gateway to the DNS answers victims subsequently receive
Skills tested
Prerequisites
- What DHCP discover, offer and ack do
- Reading an IP address and a MAC
How it works
The instinct on a rogue-DHCP question is to count servers and flag the extra one. That instinct is wrong often enough to be worth training out, because networks legitimately run more than one DHCP server. Here 192.0.2.10 and 192.0.2.11 are a primary and a failover, and both belong.
The question that separates them is what they hand out. Filter to event:dhcp_offer and read the gateway column: the two real servers agree on 192.0.2.1, and the arp_reply rows show router-core announcing exactly that address. 192.0.2.87 hands out itself.
Two more tells corroborate it without needing any of the above. The rogue leases from 192.0.2.140 upward while the real servers use the .50s, and it sets a 600 second lease against 86400. A short lease is not an accident: it keeps clients renewing against the attacker and lets the rogue re-establish itself quickly.
The dhcp_ack detail says the client took the first offer, which is simply how DHCP works and is the entire attack. Speed decides. That also explains why the victim set is ragged rather than total: 04:d3:b0:96:12:38 heard both offers and ended up on the legitimate server.
The dns_query rows close the loop. Hosts bound to the rogue resolve intranet.northgate.example to 192.0.2.87; a host bound to the real server resolves it to 192.0.2.30. The rogue is answering DNS as well as routing, which is what users were describing when they said the intranet looked wrong.
Common mistakes
- Flagging 192.0.2.11 as the rogue. It is the failover, and the detail field says so. Two servers is the normal state here.
- Answering with the rogue's MAC or a client MAC. The question asks for the gateway IP being handed out.
- Reading server_ip instead of gateway. They happen to be equal for the rogue, which is the tell, but the column that answers the question is gateway.
- Assuming every client was compromised. At least one host heard both offers and bound to the legitimate server.
- Stopping at the DHCP rows. The DNS answers are what confirm the impact.
How to defend against it
A rogue DHCP server needs nothing more than a network port and a laptop, so the control has to be on the switch.
- Turn on DHCP snooping and trust only the uplink ports where the real servers live. Offers from an access port get dropped.
- Add dynamic ARP inspection on top, so the rogue cannot fall back to ARP spoofing once DHCP is locked down.
- Use port security or 802.1X so an unknown device cannot reach the VLAN in the first place.
- Alert on any DHCP offer whose gateway is not the known router address. It is a one-line detection and it would have fired at 09:14.
- Treat an unusually short lease as a signal in monitoring: legitimate servers rarely hand out 600 seconds on an office VLAN.