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

DET0468: Detect DHCP Spoofing Across Linux, Windows, and macOS

DET0468 is a detection strategy for identifying DHCP spoofing associated with ATT&CK technique T1557.003. The business issue is that a malicious DHCP serve...

EnterpriseDET0468Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0468 is a detection strategy for identifying DHCP spoofing associated with ATT&CK technique T1557.003. The business issue is that a malicious DHCP server can redirect victim network traffic and put an adversary in an adversary-in-the-middle position, creating risk to credential exposure and collection of network communications across Linux, Windows, and macOS environments.

Executive priority

Treat this as a network trust and identity-protection control question: can the organization prove that only authorized DHCP services can influence endpoint routing, and can the SOC detect when that trust is abused? This matters for incident decision-making because DHCP spoofing can change traffic paths before users or applications notice, potentially affecting credential safety, monitoring visibility, and operational resilience.

Technical view

ATT&CK provides no official detection text for this detection-strategy object, so validation should be driven by the related technique context: DHCP spoofing used to redirect traffic to adversary-owned systems for credential access and collection. SOC and IR teams should confirm visibility into DHCP offer/acknowledgment behavior, unexpected DHCP servers, endpoint network configuration changes, and signs that routing, DNS, or gateway settings were assigned by an unauthorized source across Linux, Windows, and macOS endpoints where applicable.

Likely telemetry

  • DHCP server logs and lease records from authorized infrastructure
  • Network sensor or packet metadata showing DHCP discovery, offer, request, and acknowledgment activity
  • Endpoint network configuration state, including assigned gateway, DNS server, DHCP server identifier, and lease timing
  • Switch, router, wireless, or access-layer control logs that can show unauthorized DHCP responses if collected
  • Authentication or application logs that may help assess credential exposure over insecure or unencrypted communications after suspected redirection

Detection direction

  • Inventory authorized DHCP servers and alert on DHCP responses from unexpected systems or network segments.
  • Correlate endpoint lease changes with network telemetry to identify sudden gateway, DNS, or DHCP server changes that do not match expected infrastructure.
  • Tune detections for legitimate network changes, lab networks, VPN/client transitions, and planned DHCP maintenance to reduce false positives.
  • Validate coverage separately for Linux, Windows, and macOS because endpoint evidence and collection methods differ even though the related technique applies to all three.
  • Use relationship context to prioritize follow-up for credential-access and collection risk, including possible network sniffing or exposure of communications sent over insecure protocols.

Mitigation priorities

  • Prioritize controls that prevent unauthorized systems from acting as DHCP servers on production networks.
  • Maintain an authoritative inventory of approved DHCP infrastructure and expected network segments.
  • Reduce downstream credential risk by limiting reliance on insecure or unencrypted protocols where redirected traffic could expose credentials or communications.
  • Ensure incident response playbooks include containment steps for suspected rogue DHCP activity, endpoint lease renewal, and validation of gateway/DNS settings.
  • Use compliance and audit evidence to show that DHCP control ownership, logging, and exception handling are defined and periodically validated.
Analyst notes and limits

This take is based on the detection-strategy object DET0468 and its relationship to T1557.003 DHCP Spoofing. The object itself has no official description, detection text, tactics, or platforms, so the practical guidance is derived from the related technique’s supplied description, tactics, and platforms.

Local network architecture, DHCP design, endpoint logging, and access-layer telemetry determine whether this behavior is detectable in practice. No active exploitation, actor attribution, or guaranteed detection coverage is stated by the supplied ATT&CK fields.

Official MITRE ATT&CK definition

Detect DHCP Spoofing Across Linux, Windows, and macOS

No official description is available in the imported ATT&CK source object.

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

Techniques used

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.003 DHCP Spoofing Sub-technique This object detects DHCP Spoofing.
Relationship explorer

All related ATT&CK context

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.0
Created
Modified
Raw hash
1345ef943951f9a2...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 1345ef943951…
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.

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]
    mitre-attack DET0468
    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.