Multiple DHCP Servers Responding to the Same Transaction

Identifies two or more distinct DHCP servers sending an OFFER or ACK for the same transaction ID (xid) within a short window, indicating a rogue DHCP server racing the legitimate one to win the client's handshake. This is the rogue-DHCP / adversary-in-the-middle precondition (T1557.003) and is operating-system agnostic, since it keys only on server behavior observed on the wire. Winning the race lets an attacker intercept traffic via a hostile gateway/DNS, bypass a VPN (TunnelVision), or deliver a malformed response that exploits the client's DHCP parser for code execution.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/06/09"
  3integration = ["network_traffic"]
  4maturity = "production"
  5min_stack_comments = "Requires ES|QL JSON_EXTRACT on _source to read DHCPv4 fields across current and legacy schemas."
  6min_stack_version = "9.4.0"
  7updated_date = "2026/11/03"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Identifies two or more distinct DHCP servers sending an OFFER or ACK for the same transaction ID (xid) within a short
 13window, indicating a rogue DHCP server racing the legitimate one to win the client's handshake. This is the rogue-DHCP /
 14adversary-in-the-middle precondition (T1557.003) and is operating-system agnostic, since it keys only on server behavior
 15observed on the wire. Winning the race lets an attacker intercept traffic via a hostile gateway/DNS, bypass a VPN
 16(TunnelVision), or deliver a malformed response that exploits the client's DHCP parser for code execution.
 17"""
 18from = "now-9m"
 19language = "esql"
 20license = "Elastic License v2"
 21name = "Multiple DHCP Servers Responding to the Same Transaction"
 22note = """## Triage and analysis
 23
 24> **Disclaimer**:
 25> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 26
 27### Investigating Multiple DHCP Servers Responding to the Same Transaction
 28
 29DHCP is plaintext UDP and fully visible to any sensor on the broadcast segment. A rogue server (or an injected response
 30on the victim's L2 broadcast domain) that answers a transaction the legitimate server already owns is the defining
 31precondition for DHCP-based adversary-in-the-middle and for malformed-option client exploits. This rule flags exactly
 32that: two or more distinct server source IPs producing an OFFER/ACK for one transaction ID inside the same 30-second
 33window, and is operating-system agnostic, since it keys only on server behavior observed on the wire.
 34
 35### Possible investigation steps
 36
 37- Identify the server source IPs in `Esql.values_server_ips` and `Esql.values_server_identifiers`. Determine which is
 38  the sanctioned DHCP server and which is unexpected.
 39- Locate the rogue server on the segment (switch CAM/ARP tables, port, VLAN). It is on the same broadcast domain as the
 40  victim by definition.
 41- Inspect the rogue OFFER/ACK options for an oversized or malformed payload (the overflow trigger) and for hostile
 42  configuration such as an attacker-controlled default gateway (option 3), DNS server (option 6), WPAD/proxy
 43  auto-config (option 252), or classless static routes (option 121, TunnelVision-style VPN bypass).
 44- Identify the client(s) acquiring leases on the segment (any OS, including Windows, Linux, macOS, iOS, IoT) and review their
 45  endpoint telemetry for DHCP client service crashes, unexpected route/DNS/gateway changes, or follow-on code execution.
 46  Where the target OS and DHCP client are known, check whether they are unpatched for the relevant CVE (e.g.
 47  CVE-2026-44815 on Windows, CVE-2018-5732 on ISC dhclient).
 48
 49### False positive analysis
 50
 51- DHCP failover pairs (Microsoft or ISC) are designed so that, for a given transaction, only one peer answers; two
 52  peers answering the same xid within 30 seconds is not normal failover behavior. If a known active-active or
 53  load-balancing architecture genuinely does this, add its server IPs to an exception.
 54- DHCP relay agents forward responses but the relayed source is the relay, and a single server still owns each
 55  transaction. Anycast/VIP DHCP designs that present multiple real backend IPs on the wire are rare and would be a known
 56  architectural fact, which can be excepted by those IPs.
 57
 58### Response and remediation
 59
 60- Remove the rogue DHCP server from the segment, then patch the affected client DHCP stacks (e.g. June 2026 Patch
 61  Tuesday for CVE-2026-44815 on Windows, or the fixed ISC dhclient for CVE-2018-5732 on Linux/Unix).
 62- Enable DHCP snooping on managed switches and restrict DHCP server responses to authorized server ports/MACs as a
 63  compensating control, which protects clients of every OS and also mitigates TunnelVision-style route injection.
 64"""
 65references = [
 66    "https://nvd.nist.gov/vuln/detail/CVE-2026-44815",
 67    "https://nvd.nist.gov/vuln/detail/CVE-2024-3661",
 68    "https://www.leviathansecurity.com/blog/tunnelvision",
 69    "https://nvd.nist.gov/vuln/detail/CVE-2018-5732",
 70    "https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2026-44815",
 71]
 72risk_score = 73
 73rule_id = "44b8d933-8fed-485d-a0af-bd97d0093439"
 74setup = """## Setup
 75
 76This rule requires the Elastic network_traffic (Packetbeat) integration capturing DHCP (UDP 67/68) on the broadcast
 77segment where clients acquire/renew leases, either Packetbeat running on the segment or a SPAN/mirror feeding it. A
 78sensor not on the same L2 broadcast domain (or not behind the relevant DHCP relay) will not observe competing OFFER/ACK
 79packets.
 80
 81The query supports Network Packet Capture 2.0.0 and later, earlier integration versions, and standalone Packetbeat by
 82reading both the `network_traffic.dhcpv4.*` and legacy `dhcpv4.*` field layouts.
 83
 84Zeek is intentionally not supported: the zeek.dhcp data stream does not expose a transaction ID and aggregates a full
 85DORA exchange into one record, so the per-transaction server-count comparison cannot be expressed on it.
 86"""
 87severity = "high"
 88tags = [
 89    "Domain: Network",
 90    "Domain: Endpoint",
 91    "Use Case: Threat Detection",
 92    "Use Case: Vulnerability",
 93    "Use Case: Network Security Monitoring",
 94    "Tactic: Credential Access",
 95    "Tactic: Execution",
 96    "Data Source: Network Traffic",
 97    "Resources: Investigation Guide",
 98    "Noise: Medium",
 99    "Performance: Fast",
100    "Profile: Recommended",
101    "Threat: Vulnerability Exploit",
102    "Rule Type: ES|QL",
103    "Data Source: Network Packet Capture",
104]
105timestamp_override = "event.ingested"
106type = "esql"
107
108query = '''
109from logs-network_traffic.dhcpv4-*, packetbeat-* metadata _source
110| eval
111    message_type = TO_LOWER(COALESCE(
112        JSON_EXTRACT(_source, "network_traffic.dhcpv4.option.message_type"),
113        JSON_EXTRACT(_source, "dhcpv4.option.message_type")
114    )),
115    Esql.transaction_id = COALESCE(
116        JSON_EXTRACT(_source, "network_traffic.dhcpv4.transaction_id"),
117        JSON_EXTRACT(_source, "dhcpv4.transaction_id")
118    ),
119    server_identifier = COALESCE(
120        JSON_EXTRACT(_source, "network_traffic.dhcpv4.option.server_identifier"),
121        JSON_EXTRACT(_source, "dhcpv4.option.server_identifier")
122    )
123| where message_type in ("offer", "ack") and Esql.transaction_id is not null and source.ip is not null
124| eval Esql.time_window = DATE_TRUNC(30 seconds, @timestamp)
125| stats
126    Esql.count_distinct_servers = COUNT_DISTINCT(source.ip),
127    Esql.values_server_ips = VALUES(source.ip),
128    Esql.values_server_identifiers = VALUES(server_identifier),
129    Esql.count_replies = COUNT(*)
130  by Esql.time_window, Esql.transaction_id
131| where Esql.count_distinct_servers >= 2
132| keep Esql.transaction_id, Esql.time_window, Esql.count_distinct_servers, Esql.values_server_ips, Esql.values_server_identifiers, Esql.count_replies
133'''
134
135
136[[rule.threat]]
137framework = "MITRE ATT&CK"
138[[rule.threat.technique]]
139id = "T1557"
140name = "Adversary-in-the-Middle"
141reference = "https://attack.mitre.org/techniques/T1557/"
142[[rule.threat.technique.subtechnique]]
143id = "T1557.003"
144name = "DHCP Spoofing"
145reference = "https://attack.mitre.org/techniques/T1557/003/"
146
147
148[rule.threat.tactic]
149id = "TA0006"
150name = "Credential Access"
151reference = "https://attack.mitre.org/tactics/TA0006/"
152
153[[rule.threat]]
154framework = "MITRE ATT&CK"
155[[rule.threat.technique]]
156id = "T1203"
157name = "Exploitation for Client Execution"
158reference = "https://attack.mitre.org/techniques/T1203/"
159
160
161[rule.threat.tactic]
162id = "TA0002"
163name = "Execution"
164reference = "https://attack.mitre.org/tactics/TA0002/"

Triage and analysis

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating Multiple DHCP Servers Responding to the Same Transaction

DHCP is plaintext UDP and fully visible to any sensor on the broadcast segment. A rogue server (or an injected response on the victim's L2 broadcast domain) that answers a transaction the legitimate server already owns is the defining precondition for DHCP-based adversary-in-the-middle and for malformed-option client exploits. This rule flags exactly that: two or more distinct server source IPs producing an OFFER/ACK for one transaction ID inside the same 30-second window, and is operating-system agnostic, since it keys only on server behavior observed on the wire.

Possible investigation steps

  • Identify the server source IPs in Esql.values_server_ips and Esql.values_server_identifiers. Determine which is the sanctioned DHCP server and which is unexpected.
  • Locate the rogue server on the segment (switch CAM/ARP tables, port, VLAN). It is on the same broadcast domain as the victim by definition.
  • Inspect the rogue OFFER/ACK options for an oversized or malformed payload (the overflow trigger) and for hostile configuration such as an attacker-controlled default gateway (option 3), DNS server (option 6), WPAD/proxy auto-config (option 252), or classless static routes (option 121, TunnelVision-style VPN bypass).
  • Identify the client(s) acquiring leases on the segment (any OS, including Windows, Linux, macOS, iOS, IoT) and review their endpoint telemetry for DHCP client service crashes, unexpected route/DNS/gateway changes, or follow-on code execution. Where the target OS and DHCP client are known, check whether they are unpatched for the relevant CVE (e.g. CVE-2026-44815 on Windows, CVE-2018-5732 on ISC dhclient).

False positive analysis

  • DHCP failover pairs (Microsoft or ISC) are designed so that, for a given transaction, only one peer answers; two peers answering the same xid within 30 seconds is not normal failover behavior. If a known active-active or load-balancing architecture genuinely does this, add its server IPs to an exception.
  • DHCP relay agents forward responses but the relayed source is the relay, and a single server still owns each transaction. Anycast/VIP DHCP designs that present multiple real backend IPs on the wire are rare and would be a known architectural fact, which can be excepted by those IPs.

Response and remediation

  • Remove the rogue DHCP server from the segment, then patch the affected client DHCP stacks (e.g. June 2026 Patch Tuesday for CVE-2026-44815 on Windows, or the fixed ISC dhclient for CVE-2018-5732 on Linux/Unix).
  • Enable DHCP snooping on managed switches and restrict DHCP server responses to authorized server ports/MACs as a compensating control, which protects clients of every OS and also mitigates TunnelVision-style route injection.

References

Related rules

to-top