Detect OS Exhaustion Flood in Elastic Security
Adversaries may launch a denial of service (DoS) attack targeting an endpoint's operating system (OS). OS exhaustion floods do not need to deplete physical hardware resources—they exhaust OS-imposed limits on concurrent connections and state tracking. SYN floods send excessive TCP SYN packets without completing the three-way handshake, filling the OS half-open connection backlog queue and preventing new legitimate TCP connections from being established. ACK floods send packets referencing non-existent connections, forcing the OS to perform a full TCP state table search for each packet, causing CPU and memory exhaustion that degrades or stops service. Both techniques can render any TCP-based service unavailable on the targeted endpoint.
MITRE ATT&CK
- Tactic
- Impact
- Technique
- T1499 Endpoint Denial of Service
- Sub-technique
- T1499.001 OS Exhaustion Flood
- Canonical reference
- https://attack.mitre.org/techniques/T1499/001/
Elastic Detection Query
// OS Exhaustion Flood — SYN/ACK floods, TCP state exhaustion via Elastic EQL
// Branch 1: Linux kernel syslog messages indicating SYN flood or conntrack exhaustion
any where event.dataset == "system.syslog"
and (
message like~ "*possible syn flooding*"
or message like~ "*tcp: request_sock_tcp*"
or message like~ "*sending cookies*"
or message like~ "*tcp: drop open request*"
or message like~ "*nf_conntrack*table full*"
or message like~ "*ip_conntrack*table full*"
or message like~ "*possible syn attack*"
or message like~ "*tcp*orphaned*"
)
// Branch 2: Network device flood alerts via firewall/IDS logs
any where event.category == "network"
and event.dataset in ("cisco_asa.log", "paloalto_panos.firewall", "fortinet.firewall", "juniper.junos", "checkpoint.firewall")
and (
message like~ "*syn flood*"
or message like~ "*ack flood*"
or message like~ "*tcp flood*"
or message like~ "*half-open*exceed*"
or message like~ "*tcp*exhaustion*"
or message like~ "*connection table full*"
or message like~ "*synflood*"
or message like~ "*syn attack*"
or message like~ "*dos tcp*"
or message like~ "*ddos tcp*"
)
// Branch 3: Sequence — rapid repeated inbound TCP connections from many sources to same target (sensor data)
sequence by destination.ip with maxspan=1m
[network where network.transport == "tcp" and network.direction == "inbound"
and not source.ip == destination.ip] with runs=500Detects OS-level exhaustion flood attacks (SYN floods, ACK floods, TCP state exhaustion) by correlating Linux kernel syslog alerts about conntrack table exhaustion and SYN cookie activation with network device telemetry from firewalls and IDS/IPS platforms. Also includes a high-volume inbound TCP sequence rule for packet-level telemetry.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate high-traffic web services experiencing flash crowd events may trigger the high-volume TCP connection sequence rule
- Load testing tools (e.g., hping3, ab, wrk) used by internal performance teams against dev/staging endpoints will match SYN flood kernel messages
- Misconfigured conntrack table sizes on low-memory virtual machines may log 'nf_conntrack: table full' during normal peak traffic without active attack
Other platforms for T1499.001
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1hping3 SYN Flood Against Local Test Port
Expected signal: Linux kernel ring buffer (dmesg): 'TCP: Possible SYN flooding on port 9999. Sending cookies.' if tcp_syncookies=1. Syslog facility=kern messages with same content routed to /var/log/kern.log and forwarded to SIEM. 'ss -tan state syn-recv' shows multiple SYN_RECV entries for the test port. /proc/net/netstat field TcpExtTCPReqQFullDoCookies increments for each SYN cookie issued.
- Test 2Python Scapy SYN Flood Simulation
Expected signal: Linux kernel: 'TCP: Possible SYN flooding on port 80. Sending cookies.' in dmesg and kern.log. /proc/net/netstat TcpExtTCPReqQFullDoCookies increments. If Sysmon for Linux is deployed: network events for the scapy process with multiple outbound connections. Packet capture shows SYN packets with randomized source IPs and no corresponding ACK completions.
- Test 3PowerShell TCP Half-Open Connection Flood (Windows)
Expected signal: Windows System Event Log Event ID 4227 ('TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts') if connection limit is hit. Sysmon Event ID 3 (Network Connection) showing many connections from powershell.exe to 127.0.0.1:445. Windows Performance counter TCPv4\Connection Failures increases. netstat output shows many ESTABLISHED or SYN_SENT connections from powershell.exe.
- Test 4nf_conntrack Table Exhaustion Simulation (Linux)
Expected signal: Linux kernel ring buffer (dmesg): 'nf_conntrack: table full, dropping packet' — the exact message generated during real TCP flood attacks that exhaust the connection tracking table. This message is forwarded to syslog as facility=kern and typically appears in /var/log/kern.log. SIEM receives it via syslog forwarding. /proc/sys/net/netfilter/nf_conntrack_count shows the table is full.
References (8)
- https://attack.mitre.org/techniques/T1499/001/
- https://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/
- https://web.archive.org/web/20220119104451/https://www.corero.com/resource-hub/syn-ack-flood-attack/
- https://pages.arbornetworks.com/rs/082-KNA-087/images/13th_Worldwide_Infrastructure_Security_Report.pdf
- https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html
- https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview
- https://docs.splunk.com/Documentation/SplunkCloud/latest/SearchReference/CommonStatsFunctions
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1499.001/T1499.001.md
Unlock Pro Content
Get the full detection package for T1499.001 including response playbook, investigation guide, and atomic red team tests.