Every device that joins a network asks, in effect, "who am I and where do I send my traffic?" DHCP answers that question. If the wrong machine answers, the client believes it. DHCP Spoofing (T1557.003) is the technique where an adversary stands up a rogue DHCP server to answer first. MITRE files it under the Credential Access and Collection tactics, and it applies to Linux, Windows and macOS clients.
How attackers use it
MITRE describes the normal exchange in four steps: the client broadcasts a DISCOVER, a server replies with an OFFER that includes an address, the client broadcasts a REQUEST for that address, and the server confirms with an ACK carrying the network settings.
The weakness is that clients broadcast, and any host on the segment can reply. A rogue server can hand out adversary-owned DNS servers, for example. That puts the adversary in the middle (adversary-in-the-middle, or AiTM), where they can collect network communications, including credentials sent over insecure, unencrypted protocols. MITRE notes this can lead to Network Sniffing and Transmitted Data Manipulation.
Two variants are called out. DHCPv6 clients can ask for configuration without being given an address, which a rogue server can also answer. And rather than taking over traffic, an adversary can flood the network with DISCOVER messages to exhaust the DHCP pool, which is a service exhaustion flood.
How to detect it
MITRE's detection strategy for this technique centers on three signals:
- Anomalous OFFER and ACK messages that assign unexpected DNS or gateway values.
- Multiple competing OFFERs from servers that are not on your authorized list, which packet capture or an IDS can reveal.
- DHCP server role changes, DHCP exhaustion warnings and sudden network configuration changes across endpoints.
On Linux, MITRE points to syslog messages from the DHCP client that assign unauthorized DNS or gateway values. On macOS, it points to unified logs for unexpected ACK and OFFER parameters. On Windows, it points to DHCP server role changes and exhaustion warnings.
The practical baseline is simple. Write down which servers are allowed to answer DHCP, and what DNS and gateway values they hand out. Anything else is a finding.
How to reduce the risk
MITRE lists two mitigations.
- Filter network traffic. Filter DHCP traffic on ports 67 and 68 to and from unknown or untrusted DHCP servers. Enable port security on layer 2 switches, and enable DHCP snooping, which MITRE says prevents DHCP spoofing and starvation attacks. Track your available IP addresses with a script or tool so pool exhaustion shows up early. MITRE also recommends blocking DHCPv6 traffic where it is not needed.
- Network intrusion prevention. Use intrusion detection and prevention systems that can identify traffic patterns that look like adversary-in-the-middle activity.
Check your own environment
Start with what your clients were actually told. These commands only read state.
# Windows (cmd): shows the DHCP server, DNS servers and gateway the adapter received
ipconfig /all
# macOS (Terminal): shows the raw DHCP packet the interface received
ipconfig getpacket en0
Compare the server identifier, DNS and gateway against your known values. Then walk the switch side of the checklist:
- Is DHCP snooping on, with trusted ports limited to uplinks and legitimate servers?
- Is port security on for access ports?
- Do you alert when the pool is nearly full?
- Is DHCPv6 blocked on segments that do not use it?
Why the first answer wins
A DHCP client takes whichever offer arrives first, which is the reason a rogue server needs no special access, only a position on the same network segment and a quick reply. Two practical consequences follow.
- Controls must be enforced by the network, because the client cannot tell a good offer from a bad one. That is what DHCP snooping does: it lets the switch decide which ports may send server messages.
- Detection should compare what clients received with what you expect. Reviewing the DNS and gateway values that endpoints report is a cheap way to find a rogue server you have never seen.
Quick check
Which switch feature does MITRE name as preventing both DHCP spoofing and starvation attacks?
DHCP snooping on layer 2 switches. It lets you mark which ports may carry server replies, so an OFFER from a rogue host on an access port gets dropped.
Why would a rogue DHCP server hand out its own DNS servers?
DNS controls where names resolve. Controlling the DNS server a client uses lets the adversary steer traffic through systems they run, which is the adversary-in-the-middle position.
