Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1557.003: DHCP Spoofing

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:

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.[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.

EnterpriseT1557.003Sub-techniqueObject v1.1 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

DHCP spoofing matters because it can let an attacker on a victim network influence where systems send traffic by acting like a malicious DHCP server. The business risk is not just address assignment disruption; it can create an adversary-in-the-middle position that supports credential access and collection, especially where insecure or unencrypted protocols are still in use.

Executive priority

Prioritize this as a network trust and resilience issue. Leaders should ask whether the organization can prove that only authorized DHCP infrastructure is assigning network configuration, whether DHCP scope exhaustion would affect business operations, and whether SOC/IR teams have evidence to distinguish normal DHCP activity from rogue server behavior across Linux, Windows, and macOS environments.

Technical view

For SOC and IR teams, validate monitoring around DHCP client-server exchanges, unexpected DHCP OFFER/ACK behavior, DHCPv6 INFORMATION-REQUEST responses, abnormal DHCP scope consumption, and changes that route clients toward unexpected DNS or network paths. Because ATT&CK provides no official detection text for this technique, detection engineering should use the DET0468 relationship as a starting point and test coverage against local DHCP, network, and endpoint configuration telemetry.

Likely telemetry

  • DHCP server operational events and lease activity
  • Network traffic showing DHCP DISCOVER, OFFER, REQUEST, and ACK messages
  • DHCPv6 INFORMATION-REQUEST and response traffic
  • DHCP scope utilization or exhaustion indicators
  • Client network configuration evidence, including assigned DNS servers, gateways, and lease parameters

Detection direction

  • Confirm whether DHCP events are collected from authorized DHCP servers and retained for investigation.
  • Look for DHCP offers or acknowledgements from unexpected systems or network segments.
  • Monitor for rapid or abnormal DHCP DISCOVER volume that could indicate pool exhaustion behavior.
  • Compare assigned client configuration against approved DNS and routing expectations.
  • Tune detections to account for legitimate DHCP infrastructure changes, lab networks, imaging workflows, and network migrations to reduce false positives.

Mitigation priorities

  • Use network intrusion prevention where applicable to identify or block suspicious DHCP-related traffic, consistent with M1031.
  • Apply network traffic filtering controls to restrict unauthorized ingress, egress, and lateral traffic paths, consistent with M1037.
  • Define and maintain an inventory of authorized DHCP services and expected network configuration parameters.
  • Review DHCP scope monitoring and operational alerting so exhaustion or unexpected assignment patterns are visible before they affect users.
  • Reduce exposure of sensitive credentials over insecure or unencrypted protocols, since AiTM positioning can enable collection.
Analyst notes and limits

This technique is a sub-technique of Adversary-in-the-Middle and is associated with credential-access and collection. The supplied relationships identify DET0468 as a detection strategy and M1031/M1037 as mitigations. External references include DHCP protocol specifications, DHCP server operational events, and examples of rogue DHCP server malware, but the take does not assume active exploitation in any environment.

ATT&CK does not provide an official detection section for this object. Local validation is required to determine whether DHCP server logs, network traffic, DHCPv6 activity, endpoint configuration state, and scope utilization are actually collected and usable for detection or response.

Official MITRE ATT&CK definition

DHCP Spoofing

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:

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.[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.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1557 Adversary-in-the-Middle This object subtechnique of Adversary-in-the-Middle.
Relationship explorer

All related ATT&CK context

subtechnique of · Technique T1557: Adversary-in-the-Middle Enterprise mitigates · Mitigation M1037: Filter Network Traffic Enterprise mitigates · Mitigation M1031: Network Intrusion Prevention Enterprise detects · Detection Strategy DET0468: Detect DHCP Spoofing Across Linux, Windows, and macOS Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1037: Filter Network Traffic

Employ network appliances and endpoint software to filter ingress, egress, and lateral network traffic. This includes protocol-based filtering, enforcing firewall rules, and blocking or restricting traffic based on predefined conditions to limit adversary movement and data exfiltration. This mitigation can be implemented through the following measures:

Ingress Traffic Filtering:

- Use Case: Configure network firewalls to allow traffic only from authorized IP addresses to public-facing servers. - Implementation: Limit SSH (port 22) and RDP (port 3389) traffic to specific IP ranges.

Egress Traffic Filtering:

- Use Case: Use firewalls or endpoint security software to block unauthorized outbound traffic to prevent data exfiltration and command-and-control (C2) communications. - Implementation: Block outbound traffic to known malicious IPs or regions where communication is unexpected.

Protocol-Based Filtering:

- Use Case: Restrict the use of specific protocols that are commonly abused by adversaries, such as SMB, RPC, or Telnet, based on business needs. - Implementation: Disable SMBv1 on endpoints to prevent exploits like EternalBlue.

Network Segmentation:

- Use Case: Create network segments for critical systems and restrict communication between segments unless explicitly authorized. - Implementation: Implement VLANs to isolate IoT devices or guest networks from core business systems.

Application Layer Filtering:

- Use Case: Use proxy servers or Web Application Firewalls (WAFs) to inspect and block malicious HTTP/S traffic. - Implementation: Configure a WAF to block SQL injection attempts or other web application exploitation techniques.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.1
Created
Modified
Raw hash
d3cd4c8afb37dfab...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle d3cd4c8afb37…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    rfc2131

    Droms, R. (1997, March). Dynamic Host Configuration Protocol. Retrieved March 9, 2022.

    Open source URL
  2. [2]
    new_rogue_DHCP_serv_malware

    Irwin, Ullrich, J. (2009, March 16). new rogue-DHCP server malware. Retrieved January 14, 2022.

    Open source URL
  3. [3]
    w32.tidserv.g

    Symantec. (2009, March 22). W32.Tidserv.G. Retrieved January 14, 2022.

    Open source URL
  4. [4]
    rfc3315

    J. Bound, et al. (2003, July). Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Retrieved June 27, 2022.

    Open source URL
  5. [5]
    dhcp_serv_op_events

    Microsoft. (2006, August 31). DHCP Server Operational Events. Retrieved March 7, 2022.

    Open source URL
  6. [6]
    mitre-attack T1557.003
    Open source URL
  7. [7]
    solution_monitor_dhcp_scopes

    Shoemaker, E. (2015, December 31). Solution: Monitor DHCP Scopes and Detect Man-in-the-Middle Attacks with PRTG and PowerShell. Retrieved September 12, 2024.

    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use