Cross-source coverage

T1557.003 / ATT&CK

Adversary-in-the-Middle: DHCP Spoofing

2 rules across 2 sources.

From MITRE ATT&CK 19.2

Adversaries may redirect network traffic to adversary-owned systems by spoofing Dynamic Host Configuration Protocol (DHCP) traffic and acting as a malicious DHCP server on the victim network. By achieving the adversary-in-the-middle (AiTM) position, adversaries may collect network communications, including passed credentials, especially those sent over insecure, unencrypted protocols. This may also enable follow-on behaviors such as Network Sniffing or Transmitted Data Manipulation.

DHCP is based on a client-server model and has two functionalities: a protocol for providing network configuration settings from a DHCP server to a client and a mechanism for allocating network addresses to clients. The typical server-client interaction is as follows:

  1. The client broadcasts a DISCOVER message.

  2. The server responds with an OFFER message, which includes an available network address.

  3. The client broadcasts a REQUEST message, which includes the network address offered.

  4. The server acknowledges with an ACK message and the client receives the network configuration parameters.

Adversaries may spoof as a rogue DHCP server on the victim network, from which legitimate hosts may receive malicious network configurations. For example, malware can act as a DHCP server and provide adversary-owned DNS servers to the victimized computers. Through the malicious network configurations, an adversary may achieve the AiTM position, route client traffic through adversary-controlled systems, and collect information from the client network.

DHCPv6 clients can receive network configuration information without being assigned an IP address by sending a INFORMATION-REQUEST (code 11) message to the All_DHCP_Relay_Agents_and_Servers multicast address. Adversaries may use their rogue DHCP server to respond to this request message with malicious network configurations.

Rather than establishing an AiTM position, adversaries may also abuse DHCP spoofing to perform a DHCP exhaustion attack (i.e, Service Exhaustion Flood) by generating many broadcast DISCOVER messages to exhaust a network’s DHCP allocation pool.

Platforms
Linux · Windows · macOS
Telemetry
WinEventLog:SystemNSM:Flowlinux:syslogmacos:unifiedlog

How MITRE says to detect it DET0468

Detect DHCP Spoofing Across Linux, Windows, and macOS

Windows Analytic 1290

Detects rogue DHCP server activity and anomalous DHCP OFFER/ACK messages assigning unexpected DNS or gateway values. Detection correlates DHCP server role changes, DHCP exhaustion warnings, and sudden network configuration changes across endpoints.

  • WinEventLog:System EventCode=1341, 1342, 1020, 1063
  • NSM:Flow DHCP OFFER or ACK with unauthorized DNS/gateway parameters

Linux Analytic 1291

Detects rogue DHCP activity by monitoring syslog for dhclient messages assigning unauthorized DNS/gateway values. Packet capture or IDS can detect multiple competing DHCP OFFERs from non-authorized servers.

  • linux:syslog suspicious DHCP lease assignment with unexpected DNS or gateway
  • NSM:Flow Gratuitous or duplicate DHCP OFFER packets from non-legitimate servers

macOS Analytic 1292

Detects DHCP spoofing by monitoring unified logs for unexpected DHCP ACK/OFFER parameters and correlating with packet captures for multiple DHCP servers. Behavioral emphasis is on inconsistent DNS and gateway assignments that redirect traffic.

  • macos:unifiedlog new DHCP configuration with anomalous DNS or router values
  • NSM:Flow Multiple DHCP OFFER responses for a single DISCOVER

SigmaHQ/sigma

1 rule
Detection Severity Format
Potential Kerberos Coercion by Spoofing SPNs via DNS Manipulation High Sigma

elastic/detection-rules

1 rule
Detection Severity Format
Multiple DHCP Servers Responding to the Same Transaction High Elastic TOML

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.