DHCP Spoofing Explained: Rogue Servers & DHCP Snooping

When a laptop joins a network, it does not know its own address, where the gateway is, or which server resolves names. It shouts a question into the local segment and takes the first credible answer it gets. That exchange is the Dynamic Host Configuration Protocol, DHCP, and it works well precisely because it asks no questions about who is answering.

That trust is the weakness. DHCP has no authentication. Any device on the same segment can hear the request and send a reply. If an attacker's reply arrives first, or looks better, the victim configures itself with settings the attacker chose. From that moment the attacker can be the victim's gateway, the victim's DNS, or both, and most of the traffic flows straight through attacker-controlled infrastructure.

How DHCP hands over the keys

The normal handshake is four messages, often shortened to DORA: Discover, Offer, Request, Acknowledge.

• Discover. The client broadcasts, asking any server on the segment for configuration.
• Offer. One or more servers reply with a proposed address and options.
• Request. The client picks an offer and broadcasts that it wants those settings.
• Acknowledge. The chosen server confirms, and the client applies the configuration.

The options in that offer are the important part. Beyond the IP address itself, a DHCP offer typically sets the default gateway, the DNS servers, and often other parameters. Whoever fills in those fields decides where the client sends traffic bound for the wider internet, and which server translates the domain names the client looks up. Control the gateway and DNS, and you sit in the path.

The rogue DHCP server

A rogue DHCP server is simply an unauthorized machine on the segment answering Discover messages. The attack has two failure modes it exploits.

First is the race. The client takes the first valid offer it receives. An attacker positioned close to the victim, or one that simply responds faster than a busy central server, can win the race and get its offer accepted. Nothing in the protocol penalizes a fast stranger.

Second is starvation. If the attacker cannot reliably win the race, it can remove the competition. By flooding the legitimate server with a storm of requests using fabricated hardware addresses, the attacker exhausts the real server's pool of available addresses. With no addresses left to offer, the real server falls silent, and the rogue server becomes the only one answering. On the ATT&CK matrix this activity sits under Adversary-in-the-Middle: DHCP Spoofing (T1557.003).

There is a subtlety worth understanding about scope. DHCP is a broadcast protocol, so a rogue server usually has to sit on the same broadcast domain, the same VLAN, as its victims to hear their Discover messages. That is why DHCP spoofing so often follows another local attack that gets the attacker onto the right segment in the first place, and why it pairs naturally with VLAN hopping and rogue access points. In larger networks, DHCP requests cross between segments through relay agents that forward them to a central server. Those relays are configured to talk only to known servers, so the practical attack surface for a rogue server is the local segment where clients and attacker share a broadcast domain.

What the attacker gains

Once a victim is using an attacker-controlled gateway or DNS, several follow-on moves open up:

• Traffic interception. As the gateway, the attacker forwards traffic to the real internet after reading or modifying it, a classic man-in-the-middle position.
• DNS manipulation. As the DNS server, the attacker can answer specific lookups with addresses of its own choosing, steering victims to fake login pages or malware.
• Credential capture. Any cleartext protocol crossing the attacker becomes readable, and even encrypted sessions can be attacked with downgrade or interception tooling against users who click through warnings.
• Selective targeting. The rogue server can hand malicious settings only to chosen victims and leave everyone else alone, which keeps the operation quiet.

Adversary-in-the-middle positioning like this is a common early move in intrusions that go on to steal credentials and move laterally. For the actors who lean on it and the campaigns it shows up in, our Threat Groups directory maps who operates this way and how the local foothold feeds a wider compromise.

Why the protocol cannot self-defend

RFC 2131 describes an exchange built for convenience on a trusted local network. There is no field a client can use to verify that an offer came from an authorized server, and clients are expected to accept configuration from whoever answers. An optional authentication extension exists but is almost never deployed, and it does not change the behaviour of ordinary clients. The defense therefore has to come from the network the DHCP traffic crosses, meaning the switches.

This is a recurring theme across Layer 2 protocols. ARP, DHCP, and the switch fabric itself were all designed for a cooperative local network where every device was assumed friendly. Each one trades verification for speed and simplicity, and each one becomes a liability the moment an untrusted device shares the segment. The controls that harden them, such as DHCP snooping and Dynamic ARP Inspection, are effectively a retrofit of the trust the original protocols never carried, enforced by the one component every frame has to pass through.

DHCP snooping and its supporting cast

The standard control is DHCP snooping, a feature of managed switches. The idea is direct. The switch already sees every DHCP message, so it can enforce a simple rule about which ports are allowed to speak as a server.

Concept	What it does	What it stops
Trusted ports	Ports where a legitimate DHCP server or uplink lives	Nothing by itself, these are allowed to send offers
Untrusted ports	All access ports where only clients connect	Server-role messages (Offer, Acknowledge) are dropped here
Binding table	Records the IP-to-MAC-to-port mappings the switch observes	Feeds later checks with a trusted record of who has which address
Rate limiting	Caps DHCP messages per second on a port	DHCP starvation floods from a single port

With snooping enabled, a rogue server plugged into an ordinary access port can send all the offers it likes, and the switch discards them before they reach any victim. Only the ports you explicitly trust, the ones leading to your real DHCP infrastructure, are allowed to carry server replies.

The binding table snooping builds is valuable beyond DHCP itself. Dynamic ARP Inspection uses it to reject forged ARP messages, and IP Source Guard uses it to drop packets whose source address does not match the lease the switch recorded. One feature, enabled correctly, becomes the foundation for several Layer 2 defenses.

A rogue server, step by step

Tracing the attack as a sequence shows how ordinary each step is, which is part of why the technique stays effective. Assume the attacker already has a foothold on the segment, a laptop plugged into an access port, a compromised endpoint, or a rogue access point bridged onto the VLAN.

The attacker first sets up a DHCP server on their machine and configures its offers deliberately. The address pool can even overlap the real one, but the fields that matter are the gateway and DNS options, which they point at an address they control. They may also lower the offered lease time so victims renew often and reattach to the rogue server quickly.

Then they decide how to win. The simplest approach is the race: answer Discover messages faster than the real server. An attacker sitting close to the victim, or one whose server is idle while the legitimate server is busy, often replies first, and the client takes the first valid offer it hears. When the race is unreliable, the attacker adds starvation, flooding the real server with requests bearing fabricated hardware addresses until its pool is exhausted. With no addresses left to lease, the real server goes silent and the rogue becomes the only voice answering.

Now the victim joins or renews. It broadcasts a Discover, receives the attacker's Offer, requests those settings, and applies them. Its routing table now sends every off-subnet packet to the attacker's address as the default gateway, and its resolver sends every name lookup to the attacker's DNS. Nothing on the victim's screen looks wrong, because the configuration works.

Finally the attacker monetizes the position. As the gateway they forward traffic onward after reading or altering it, holding a full man-in-the-middle vantage. As the DNS server they answer chosen lookups with addresses of their own, steering the victim to fake pages. They can apply this to every victim on the segment or to a chosen few, keeping the operation quiet. Each defense below breaks one of these steps: the foothold, the winning move, the acceptance of the offer, or the interception that follows.

Detection signals

A rogue DHCP server is designed to be invisible to the victim, so detection lives on the network and the switch rather than on the endpoint.

• More than one server answering Discover messages. The clearest signal is a second source of DHCP offers on a segment that should have exactly one authorized server. Active probes that broadcast a Discover and count distinct responders will surface an extra server directly.
• Offers from unexpected addresses or hardware. A DHCP Offer whose source address or MAC does not belong to your known server infrastructure is a rogue by definition. Passive monitoring for server-role messages from unfamiliar sources catches it.
• Clients handed an unexpected gateway or DNS. An endpoint whose default gateway or DNS server suddenly points at an address that is not your infrastructure indicates it took a rogue lease. Fleet configuration checks that compare handed-out gateway and DNS values against the expected set will flag the anomaly.
• DHCP snooping drops and violations. On a switch running snooping, a rising count of dropped server-role messages on untrusted ports means something is trying to answer as a server where it should not. Those drop counters are a direct rogue indicator.
• Pool exhaustion and a flood of requests. A real server running out of addresses, together with a storm of DHCP requests from many fabricated hardware addresses on one port, is the footprint of a starvation attack clearing the way for a rogue.
• Short or unusual lease times. Leases far shorter than your servers issue can indicate a rogue trying to keep victims reattaching to it.

Common misconceptions

"Static IPs on clients make us immune." Statically configured hosts ignore DHCP, and that protects only those hosts. Any device that still uses DHCP remains a target, and a rogue server also affects the broader trust of the segment. Static addressing is a narrow workaround, not a defense for the network.

"The attacker has to beat the real server in a race." Winning the race is one path. Starvation is the other: drain the real server's pool so it cannot answer, and the rogue wins by being the only responder. A defense that assumes the attacker must be faster misses the exhaustion route entirely.

"DHCP spoofing needs an unpatched device or a software flaw." It exploits the protocol's intended behavior, not a bug. DHCP has no authentication by design, so a fully patched client accepts a rogue offer exactly as the specification says it should. The fix is a network control, DHCP snooping, rather than a patch.

"Encryption everywhere makes this harmless." Widespread TLS raises the cost, and interception still yields metadata, enables DNS-based redirection to lookalike sites, and captures any cleartext that remains. Users who click through certificate warnings can still be downgraded or fooled. Controlling the gateway and DNS is a strong position regardless of how much traffic is encrypted.

"This is only an insider problem." An insider is one route. A compromised endpoint, a device on an open port in a lobby or conference room, or a rogue access point bridged onto the VLAN all put an attacker on the segment without any trusted insider. The common requirement is presence on the broadcast domain, however it is obtained.

Where DHCP spoofing sits among Layer 2 attacks

DHCP spoofing is one member of a family of local-network attacks that all exploit the trusting design of Layer 2, and the defenses overlap because they share the same switch-enforced foundation.

Attack	What it forges	Interception result	Primary switch defense
DHCP spoofing	The gateway and DNS a client is handed	Full man-in-the-middle via bad config	DHCP snooping
ARP spoofing	The MAC-to-IP mapping on the segment	Man-in-the-middle between two hosts	Dynamic ARP Inspection
IP source spoofing	The source address of packets	Impersonation, evasion	IP Source Guard
VLAN hopping	Reachability across VLANs	Access to a segment the attacker should not reach	Port and trunk hardening

The three rightmost defenses in that list share one root. DHCP snooping builds a binding table of which address belongs to which port and MAC, and Dynamic ARP Inspection and IP Source Guard both consult that table to verify claims. Enable snooping first, and the other two gain the trusted record they need. This is why one correctly configured feature underpins a whole tier of Layer 2 protection.

How it evolved

DHCP grew out of the earlier BOOTP protocol, both designed for a cooperative local network where every attached device was assumed friendly. RFC 2131 formalized the exchange with convenience as the priority, and authentication was left out because the networks of the day were small and trusted. An optional authentication extension was defined later, and it saw almost no deployment because it required key management the ecosystem never adopted, and it does not change how ordinary clients behave.

As switched networks grew and untrusted devices routinely shared segments, the gap became a liability, and the answer arrived not in the protocol but in the switch. DHCP snooping, and the Dynamic ARP Inspection and IP Source Guard built on its binding table, retrofitted the verification the original design never carried. The pattern repeats across Layer 2: the protocols traded verification for simplicity, and the fabric they cross was taught to enforce the trust after the fact. Understanding that history explains why the defense is a switch feature rather than a client setting.

Frequently asked questions

What is the difference between DHCP spoofing and DHCP starvation? Spoofing is the rogue server handing out attacker-controlled configuration. Starvation is the supporting move that drains the real server's address pool so it cannot answer, which clears the field for the rogue. Starvation is often a setup for spoofing, and rate limiting on untrusted ports addresses the starvation half.

Can DHCP spoofing cross between VLANs or subnets? Generally no. DHCP relies on broadcast, so a rogue server usually has to share the victim's broadcast domain, meaning the same VLAN, to hear Discover messages. Requests that cross segments go through relay agents configured to talk only to known servers, so the practical attack surface is the local segment where attacker and clients share a broadcast domain.

Does DHCP snooping slow the network down? No in practice. Snooping inspects DHCP messages, which are a tiny fraction of traffic, and forwards ordinary data frames untouched. The switch already sees every frame, so classifying ports as trusted or untrusted and dropping server-role messages on untrusted ports adds negligible overhead.

We use static IP addresses. Do we still need snooping? Yes, unless every device is static, which is rare. Any host still using DHCP remains a target, and guest or unmanaged devices almost always use it. Snooping also builds the binding table that Dynamic ARP Inspection and IP Source Guard depend on, so it earns its place even where many hosts are static.

How is DHCP spoofing related to ARP spoofing? Both are Layer 2 man-in-the-middle techniques that forge trust on the local segment, and they are often used together. DHCP spoofing forges the gateway and DNS a client is handed, while ARP spoofing forges the MAC-to-IP mapping between hosts. DHCP snooping defends the first and feeds the binding table that Dynamic ARP Inspection uses to defend the second.

Can a firewall stop DHCP spoofing? A perimeter firewall does not help, because the attack happens entirely within the local broadcast domain and never crosses the firewall. The effective controls live on the switches: DHCP snooping, rate limiting, Dynamic ARP Inspection, IP Source Guard, and 802.1X port authentication to keep unknown devices off the segment in the first place.

How to defend against DHCP spoofing

1. Enable DHCP snooping on every access switch. Define the small set of trusted ports that lead to real servers, and leave everything else untrusted. This is the single most effective control and it directly kills the rogue server.
2. Rate limit DHCP on untrusted ports. Cap the messages per second so a starvation flood trips a limit and, ideally, error-disables the offending port instead of draining the pool.
3. Turn on Dynamic ARP Inspection and IP Source Guard. Once the snooping binding table exists, these features extend protection to ARP spoofing and source-address forgery on the same segment.
4. Segment and control physical access. A rogue server needs a foothold on the segment. Network segmentation and disabling unused switch ports shrink the places an attacker can plug in.
5. Use 802.1X port authentication where you can. Requiring devices to authenticate before the port carries user traffic keeps unknown machines off the segment in the first place.
6. Alert on unexpected DHCP servers. Monitor for offers arriving from addresses that are not your known servers, so a rogue that slips past a misconfigured port still gets noticed quickly.

DHCP spoofing is a local attack with a global payoff, because the settings it forges decide where a victim's traffic goes for the entire session. The protocol will not defend itself, so the switch has to. Enable DHCP snooping, trust only the ports that hold real servers, rate limit the rest, and build the ARP and source-guard checks on top of the binding table. Do that and the rogue server becomes a machine shouting offers that no one is allowed to hear.

Related guides

• ARP Spoofing Explained
• Man-in-the-Middle Attacks Explained
• VLAN Hopping Explained
• Network Security Fundamentals