| ID | Name |
|---|---|
| T1557.001 | LLMNR/NBT-NS Poisoning and SMB Relay |
| T1557.002 | ARP Cache Poisoning |
| T1557.003 | DHCP Spoofing |
| T1557.004 | Evil Twin |
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.[1] The typical server-client interaction is as follows:
The client broadcasts a DISCOVER message.
The server responds with an OFFER message, which includes an available network address.
The client broadcasts a REQUEST message, which includes the network address offered.
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.[2][3] 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.[4] 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.
| ID | Mitigation | Description |
|---|---|---|
| M1037 | Filter Network Traffic |
Consider filtering DHCP traffic on ports 67 and 68 to/from unknown or untrusted DHCP servers. Additionally, port security may also be enabled on layer switches. Furthermore, consider enabling DHCP snooping on layer 2 switches as it will prevent DHCP spoofing attacks and starvation attacks. Consider tracking available IP addresses through a script or a tool. Additionally, block DHCPv6 traffic and incoming router advertisements, especially if IPv6 is not commonly used in the network.[5] |
| M1031 | Network Intrusion Prevention |
Network intrusion detection and prevention systems that can identify traffic patterns indicative of AiTM activity can be used to mitigate activity at the network level.[6] |
| ID | Data Source | Data Component | Detects |
|---|---|---|---|
| DS0015 | Application Log | Application Log Content |
Monitor Windows logs (ex: EIDs 1341, 1342, 1020, and 1063) for changes to DHCP settings. These may also highlight DHCP issues such as when IP allocations are low or have run out.[6][7] |
| DS0029 | Network Traffic | Network Traffic Content |
Monitor network traffic for suspicious/malicious behavior involving DHCP, such as changes in DNS and/or gateway parameters. Additionally, monitor network traffic for rogue DHCPv6 activity. |
| Network Traffic Flow |
Monitor network traffic for anomalies associated with known AiTM behavior. Consider monitoring for modifications to system configuration files involved in shaping network traffic flow. |