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_macsand sample values inEsql.values_client_macsto confirm the burst is not a single client retrying with one address. - Identify the L2 segment or VLAN monitored by
Esql.observerand 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.observerand 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
- Repeated Stalled TLS Handshakes via ALPN acme-tls/1 Extension
- Potential NFS Destructive Operation Burst
- Splunk Enterprise PostgreSQL Backup-to-Restore Potential RCE Sequence
- Successful AMQP Multi-Queue Purge Burst
- Multiple DHCP Servers Responding to the Same Transaction