T1499.001 Google Chronicle · YARA-L

Detect OS Exhaustion Flood in Google Chronicle

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/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral
rule os_exhaustion_flood_t1499_001 {
  meta:
    author = "df00tech"
    description = "Detects OS Exhaustion Flood attacks (T1499.001) — SYN floods, ACK floods, TCP state exhaustion via Linux kernel syslog and network device alerts"
    severity = "HIGH"
    priority = "HIGH"
    reference = "https://attack.mitre.org/techniques/T1499/001/"
    mitre_attack_tactic = "Impact"
    mitre_attack_technique = "T1499.001"
    false_positives = "Load testing, penetration testing, misconfigured conntrack limits on VMs"

  events:
    // Match Linux kernel syslog SYN flood or conntrack exhaustion indicators
    $kernel_event.metadata.event_type = "GENERIC_EVENT"
    $kernel_event.metadata.product_name = "Linux"
    $kernel_event.principal.hostname = $target_host
    (
      re.regex($kernel_event.metadata.description, `(?i)(possible syn flooding|tcp: request_sock_tcp|sending cookies|tcp: drop open request|nf_conntrack.*table full|ip_conntrack.*table full|possible syn attack|tcp.*orphaned)`)
      or re.regex($kernel_event.target.labels["syslog_message"], `(?i)(possible syn flooding|tcp: request_sock_tcp|sending cookies|nf_conntrack.*table full|ip_conntrack.*table full|orphaned sockets)`)
    )

    // Match network device flood alerts (firewall/IDS)
    $nw_event.metadata.event_type = "NETWORK_CONNECTION"
    $nw_event.target.hostname = $target_host
    (
      re.regex($nw_event.metadata.description, `(?i)(syn.flood|ack.flood|tcp.flood|syn.attack|synflood|half.open|tcp.*exhaust|connection.*table.*full|dos.*tcp|ddos.*tcp)`)
      or $nw_event.security_result.category_details = /(?i)(syn.flood|ack.flood|tcp.*flood|tcp.*exhaust)/
      or $nw_event.security_result.threat_name = /(?i)(syn.?flood|ack.?flood|tcp.?exhaust)/
    )

  match:
    $target_host over 1h

  condition:
    // Fire if we see either kernel alert or network device alert (low threshold — these are high-confidence kernel messages)
    $kernel_event or ($nw_event and #nw_event >= 3)
}
high severity medium confidence

YARA-L 2.0 rule detecting OS Exhaustion Flood (T1499.001) by correlating Linux kernel syslog indicators of SYN cookie activation, conntrack table overflow, and orphaned socket exhaustion with network device telemetry from firewalls and IDS/IPS platforms. Matches are grouped by target host over a 1-hour window.

Data Sources

Linux OS syslog (kern facility) via Chronicle ingestionCisco ASA via Chronicle ingestionPalo Alto Networks Cortex Data LakeFortinet FortiGate via ChronicleJuniper SRX via ChronicleGeneric network IDS/IPS UDM events

Required Tables

UDM Events (GENERIC_EVENT)UDM Events (NETWORK_CONNECTION)

False Positives & Tuning

  • Internal stress testing or chaos engineering exercises against production infrastructure may trigger Linux kernel SYN cookie messages without an external attacker
  • Firewalls with aggressive DoS profile thresholds configured below traffic baselines will fire on legitimate bursty traffic from CDN edge nodes or API clients
  • Virtual machines with auto-scaling misconfigurations receiving initial traffic bursts before conntrack limits are adjusted may briefly exhaust the connection tracking table
Download portable Sigma rule (.yml)

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Unlock Pro Content

Get the full detection package for T1499.001 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections