DHCP spoofing is an attack in which a threat actor impersonates a legitimate DHCP server and sends clients malicious network configuration. The false server can hand out rogue IP settings, gateway information, or DNS details, allowing traffic redirection, interception, or denial of service on the affected network segment.
Expanded Definition
DHCP spoofing is a local-network impersonation attack against Dynamic Host Configuration Protocol, where the false server competes with the legitimate one and answers client requests first. The abuse is usually limited to the broadcast domain where clients can hear the rogue server, which is why segmentation and port-level trust boundaries matter so much.
It is not the same as IP spoofing or DNS poisoning, although it may be used to support both. The practical boundary is simple: the attacker is not forging a packet header in isolation, but is manipulating the client’s automatic trust in configuration supplied by DHCP. In many environments, this turns a convenience protocol into a control point for routing and name resolution. OWASP Non-Human Identity Top 10 is useful here because the same trust-assumption problem appears whenever infrastructure components accept identity or configuration from sources that are not strongly authenticated.
Guidance versus consensus: the industry agrees on the attack mechanism, but implementations differ on how much trust is placed in access switches, endpoint posture, and DHCP server controls. A common misunderstanding is assuming “automatic address assignment” is inherently safe because it is routine. In practice, the risk comes from trusting whichever responder wins the race, not from DHCP itself.
Examples and Use Cases
DHCP spoofing can appear in several operational settings, especially where endpoint control is uneven or network access is loosely governed:
- A malicious laptop plugged into a guest port advertises itself as the DHCP server and gives clients a gateway that forwards traffic through the attacker.
- A compromised workstation on a flat office VLAN hands out DNS settings that point internal lookups to a rogue resolver for interception or outage.
- A penetration tester demonstrates that unmanaged ports allow rogue configuration to reach new devices during onboarding.
- An attacker uses the rogue server briefly to steer users toward a phishing portal or a credential capture site before moving off-network.
The implementation trade-off is that DHCP is lightweight and fast, but that same simplicity can make unauthenticated configuration delivery easy to abuse. In environments with many transient devices, the problem is often not a single misconfigured server; it is the absence of reliable enforcement at the edge of the broadcast domain.
Security Implications
When DHCP spoofing succeeds, the immediate consequence is control over how affected clients reach the network. That can redirect traffic through an attacker, break name resolution, isolate devices from legitimate services, or quietly degrade connectivity in ways that resemble an ordinary outage.
Because DHCP often supplies gateway and DNS settings together, one rogue response can create multiple failure modes at once. Clients may still appear “online” while actually using attacker-chosen infrastructure. That makes the problem harder to diagnose than a simple denial of service and increases the chance that users and administrators misread symptoms as a transient network fault.
The blast radius depends on how far the rogue server can reach and how many devices accept the malicious lease. A practitioner observation worth stressing is that a single successful rogue response on an open segment can be enough to affect many newly connected endpoints, especially when users bring unmanaged devices onto the same network path.
Domain and Governance Relevance
In core network security, DHCP spoofing is a trust-boundary problem: infrastructure that is supposed to assign configuration becomes a path for unauthorized control. That makes it relevant to network access governance, switch hardening, and monitoring of edge infrastructure rather than only to endpoint hygiene.
For identity and access teams, the NHI angle is indirect but real. DHCP-supplied DNS and gateway settings can alter how machines reach authentication services, update endpoints, and internal APIs, which means rogue network configuration can undermine trust in non-human system communications even when credentials are not stolen directly.
In practice, this term matters when organisations depend on automatic configuration but do not enforce strong port trust, server isolation, or detection of rogue responders. The governance question is not whether DHCP should exist, but whether the network can distinguish an authorised configuration source from a hostile one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1040 — Network Sniffing | Rogue DHCP can route victim traffic through attacker-controlled paths for interception. |
| Recommendation — Map rogue-DHCP activity to T1040 and monitor segments for traffic redirection and capture. | ||
| CIS Controls v8 | 12 — Network Infrastructure Management | DHCP spoofing is prevented and detected through edge-port and infrastructure control. |
| Recommendation — Enforce CIS Control 12 to restrict rogue servers and validate trusted network infrastructure. | ||
| NIST CSF 2.0 | PR.AC-5 — Network Integrity Is Protected | DHCP spoofing directly weakens network integrity and trusted configuration delivery. |
| Recommendation — Apply PR.AC-5 to protect network integrity against unauthorised configuration sources. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Spoofed configuration can disrupt machine communications that depend on trusted network settings. |
| Recommendation — Inventory machine communication dependencies so rogue configuration sources are easier to spot and isolate. | ||
