Potential DHCP Starvation via High Client MAC Cardinality

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