Potential DHCP Starvation via High Client MAC Cardinality

Identifies a burst of DHCP DISCOVER messages with an unusually high number of distinct client hardware addresses observed on the same capture segment within a short window. Attackers flood DISCOVER requests with spoofed or random MAC addresses to exhaust the DHCP lease pool, often as a precursor to deploying a rogue DHCP server.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/06/25"
  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 a burst of DHCP DISCOVER messages with an unusually high number of distinct client hardware addresses
 13observed on the same capture segment within a short window. Attackers flood DISCOVER requests with spoofed or random MAC
 14addresses to exhaust the DHCP lease pool, often as a precursor to deploying a rogue DHCP server.
 15"""
 16from = "now-9m"
 17language = "esql"
 18license = "Elastic License v2"
 19name = "Potential DHCP Starvation via High Client MAC Cardinality"
 20note = """## Triage and analysis
 21
 22> **Disclaimer**:
 23> 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.
 24
 25### Investigating Potential DHCP Starvation via High Client MAC Cardinality
 26
 27DHCP starvation floods a segment with DISCOVER messages that use many distinct client hardware addresses to consume
 28available leases. This rule keys on high DHCP DISCOVER volume paired with high `client_mac` cardinality seen by the
 29same network capture sensor, which is the wire-level starvation pattern and does not depend on host operating system.
 30
 31### Possible investigation steps
 32
 33- Review `Esql.count_distinct_client_macs` and sample values in `Esql.values_client_macs` to confirm the burst is not a
 34  single client retrying with one address.
 35- Identify the L2 segment or VLAN monitored by `Esql.observer` and check DHCP server logs for pool exhaustion, NAK spikes,
 36  or lease-denial events during the same window.
 37- Look for follow-on rogue DHCP OFFER/ACK activity on the segment, including the Multiple DHCP Servers Responding to the
 38  Same Transaction rule.
 39- Locate the transmitting host using switch CAM tables if Ethernet source addresses are available in raw capture exports.
 40
 41### False positive analysis
 42
 43- Large Wi-Fi reconnect or onboarding events can temporarily increase DISCOVER volume. Compare against historical
 44  baselines for the same `Esql.observer` and time of day before treating as malicious.
 45- Virtualization or VDI provisioning bursts may generate many distinct client MAC addresses during imaging. Exclude known
 46  provisioning VLANs or sensors when the workflow is confirmed.
 47
 48### Response and remediation
 49
 50- Enable or verify DHCP snooping and rate limits on the affected access switches.
 51- Block or isolate the source host if link-layer evidence confirms a single transmitter is generating the flood.
 52- Restore DHCP service capacity and monitor for rogue OFFER/ACK responses after the starvation attempt.
 53"""
 54references = [
 55    "https://attack.mitre.org/techniques/T1498/",
 56    "https://www.leviathansecurity.com/blog/tunnelvision",
 57    "https://wazuh.com/blog/monitoring-dhcp-starvation-attack-with-suricata-and-wazuh/",
 58]
 59risk_score = 47
 60rule_id = "b5f94e78-fb4d-4f4b-879e-e51ea667d09c"
 61setup = """## Setup
 62
 63This rule requires the Elastic network_traffic (Packetbeat) integration capturing DHCP (UDP 67/68) on the broadcast
 64segment where clients acquire leases, either Packetbeat running on the segment or a SPAN/mirror feeding it.
 65
 66The query supports Network Packet Capture 2.0.0 and later, earlier integration versions, and standalone Packetbeat by
 67reading both the `network_traffic.dhcpv4.*` and legacy `dhcpv4.*` field layouts.
 68
 69Zeek and flow-only firewall sources are intentionally not supported: this rule requires per-DISCOVER DHCP transaction
 70fields and client hardware address values (`client_mac`) to measure high client MAC cardinality in a short time window.
 71"""
 72severity = "medium"
 73tags = [
 74    "Domain: Network",
 75    "Use Case: Threat Detection",
 76    "Use Case: Network Security Monitoring",
 77    "Tactic: Impact",
 78    "Data Source: Network Traffic",
 79    "Resources: Investigation Guide",
 80    "Noise: Unknown",
 81    "Performance: Fast",
 82    "Rule Type: ES|QL",
 83    "Data Source: Network Packet Capture",
 84]
 85timestamp_override = "event.ingested"
 86type = "esql"
 87
 88query = '''
 89from logs-network_traffic.dhcpv4-*, packetbeat-* metadata _source
 90| eval
 91    Esql.message_type = TO_LOWER(COALESCE(
 92        JSON_EXTRACT(_source, "network_traffic.dhcpv4.option.message_type"),
 93        JSON_EXTRACT(_source, "dhcpv4.option.message_type")
 94    )),
 95    Esql.client_mac = COALESCE(
 96        JSON_EXTRACT(_source, "network_traffic.dhcpv4.client_mac"),
 97        JSON_EXTRACT(_source, "dhcpv4.client_mac")
 98    ),
 99    Esql.observer_hostname = COALESCE(host.name, observer.hostname)
100| where Esql.message_type == "discover" and Esql.client_mac is not null and Esql.observer_hostname is not null
101| eval Esql.time_window = DATE_TRUNC(1 minute, @timestamp)
102| stats
103    Esql.dhcpv4_discover_count = COUNT(*),
104    Esql.dhcpv4_client_mac_count_distinct = COUNT_DISTINCT(Esql.client_mac),
105    Esql.dhcpv4_client_mac_values = MV_SLICE(VALUES(Esql.client_mac), 0, 10)
106  by Esql.time_window, Esql.observer_hostname
107| where Esql.dhcpv4_discover_count >= 75 and Esql.dhcpv4_client_mac_count_distinct >= 50
108| keep Esql.observer_hostname, Esql.time_window, Esql.dhcpv4_discover_count, Esql.dhcpv4_client_mac_count_distinct, Esql.dhcpv4_client_mac_values
109'''
110
111
112[[rule.threat]]
113framework = "MITRE ATT&CK"
114[[rule.threat.technique]]
115id = "T1498"
116name = "Network Denial of Service"
117reference = "https://attack.mitre.org/techniques/T1498/"
118[[rule.threat.technique.subtechnique]]
119id = "T1498.001"
120name = "Direct Network Flood"
121reference = "https://attack.mitre.org/techniques/T1498/001/"
122
123
124
125[rule.threat.tactic]
126id = "TA0040"
127name = "Impact"
128reference = "https://attack.mitre.org/tactics/TA0040/"

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 Potential DHCP Starvation via High Client MAC Cardinality

DHCP starvation floods a segment with DISCOVER messages that use many distinct client hardware addresses to consume available leases. This rule keys on high DHCP DISCOVER volume paired with high client_mac cardinality seen by the same network capture sensor, which is the wire-level starvation pattern and does not depend on host operating system.

Possible investigation steps

  • Review Esql.count_distinct_client_macs and sample values in Esql.values_client_macs to confirm the burst is not a single client retrying with one address.
  • Identify the L2 segment or VLAN monitored by Esql.observer and check DHCP server logs for pool exhaustion, NAK spikes, or lease-denial events during the same window.
  • Look for follow-on rogue DHCP OFFER/ACK activity on the segment, including the Multiple DHCP Servers Responding to the Same Transaction rule.
  • Locate the transmitting host using switch CAM tables if Ethernet source addresses are available in raw capture exports.

False positive analysis

  • Large Wi-Fi reconnect or onboarding events can temporarily increase DISCOVER volume. Compare against historical baselines for the same Esql.observer and time of day before treating as malicious.
  • Virtualization or VDI provisioning bursts may generate many distinct client MAC addresses during imaging. Exclude known provisioning VLANs or sensors when the workflow is confirmed.

Response and remediation

  • Enable or verify DHCP snooping and rate limits on the affected access switches.
  • Block or isolate the source host if link-layer evidence confirms a single transmitter is generating the flood.
  • Restore DHCP service capacity and monitor for rogue OFFER/ACK responses after the starvation attempt.

References

Related rules

to-top