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.
Rule type: esql
Rule indices:
Rule Severity: medium
Risk Score: 47
Runs every:
Searches indices from: now-9m
Maximum alerts per execution: 100
References:
- https://attack.mitre.org/techniques/T1498/
- https://www.leviathansecurity.com/blog/tunnelvision
- https://wazuh.com/blog/monitoring-dhcp-starvation-attack-with-suricata-and-wazuh/
Tags:
- Domain: Network
- Use Case: Threat Detection
- Use Case: Network Security Monitoring
- Tactic: Impact
- Data Source: Network Traffic
- Resources: Investigation Guide
Version: 1
Rule authors:
- Elastic
Rule license: Elastic License v2
This rule requires the Elastic network_traffic (Packetbeat) integration capturing DHCP (UDP 67/68) on the broadcast segment where clients acquire leases, either Packetbeat running on the segment or a SPAN/mirror feeding it.
Zeek and flow-only firewall sources are intentionally not supported: this rule requires per-DISCOVER DHCP transaction
fields and client hardware address values (client_mac) to measure high client MAC cardinality in a short time window.
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.
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.
- 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.
- 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.
- 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.
from logs-network_traffic.dhcpv4-*, packetbeat-*
| eval
Esql.message_type = TO_LOWER(COALESCE(network_traffic.dhcpv4.option.message_type, dhcpv4.option.message_type)),
Esql.client_mac = COALESCE(network_traffic.dhcpv4.client_mac, dhcpv4.client_mac),
Esql.observer_hostname = COALESCE(host.name, observer.hostname)
| where Esql.message_type == "discover" and Esql.client_mac is not null and Esql.observer_hostname is not null
| eval Esql.time_window = DATE_TRUNC(1 minute, @timestamp)
| stats
Esql.dhcpv4_discover_count = COUNT(*),
Esql.dhcpv4_client_mac_count_distinct = COUNT_DISTINCT(Esql.client_mac),
Esql.dhcpv4_client_mac_values = MV_SLICE(VALUES(Esql.client_mac), 0, 10)
by Esql.time_window, Esql.observer_hostname
| where Esql.dhcpv4_discover_count >= 75 and Esql.dhcpv4_client_mac_count_distinct >= 50
| keep Esql.observer_hostname, Esql.time_window, Esql.dhcpv4_discover_count, Esql.dhcpv4_client_mac_count_distinct, Esql.dhcpv4_client_mac_values
Framework: MITRE ATT&CK
Tactic:
- Name: Impact
- Id: TA0040
- Reference URL: https://attack.mitre.org/tactics/TA0040/
Technique:
- Name: Network Denial of Service
- Id: T1498
- Reference URL: https://attack.mitre.org/techniques/T1498/
Sub Technique:
- Name: Direct Network Flood
- Id: T1498.001
- Reference URL: https://attack.mitre.org/techniques/T1498/001/