Which SIEM platforms have a T1499.001 detection rule?

df00tech provides T1499.001 (OS Exhaustion Flood) detection queries for 7 SIEM platforms: Microsoft Sentinel / Defender, Splunk, Elastic Security (EQL), IBM QRadar (AQL), Sumo Logic CSE, Google Chronicle / SecOps, CrowdStrike LogScale (CQL).

What data sources are required to detect OS Exhaustion Flood (T1499.001)?

Detecting OS Exhaustion Flood requires the following data sources: Network Traffic: Network Traffic Flow, Network Traffic: Network Traffic Content, Sensor Health: Host Status, CommonSecurityLog from network devices (Firewall, IDS, IPS), Syslog from Linux kernel.

What severity and confidence is the T1499.001 detection?

The T1499.001 detection is rated high severity with medium confidence.

What are common false positives for T1499.001?

Common false positives for T1499.001 include: Legitimate high-traffic web servers receiving organic traffic spikes from CDN edge nodes, load testing campaigns, or major product launches can trigger connection count thresholds in IPS/IDS signatures; Network security scanners and vulnerability assessment tools (Nessus, Qualys, Rapid7, nmap) performing broad TCP port scans may generate SYN flood-like signatures on IPS/IDS devices when run at high rates; Cloud auto-scaling events and health check storms from load balancers (AWS ELB, Azure Application Gateway) can produce connection bursts that resemble early-stage floods from the perspective of perimeter devices.

T1499.001 IBM QRadar · QRadar

Detect OS Exhaustion Flood in IBM QRadar

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/

QRadar Detection Query

IBM QRadar (QRadar)

sql

// OS Exhaustion Flood — SYN/ACK floods, TCP state exhaustion via IBM QRadar AQL
// Branch 1: Syslog kernel flood indicators and conntrack exhaustion
SELECT
  DATEFORMAT(starttime, 'YYYY-MM-dd HH:mm:ss') AS FirstSeen,
  DATEFORMAT(MAX(endtime), 'YYYY-MM-dd HH:mm:ss') AS LastSeen,
  sourceip AS SourceIP,
  destinationip AS TargetIP,
  destinationport AS TargetPort,
  LOGSOURCENAME(logsourceid) AS LogSource,
  CATEGORYNAME(category) AS Category,
  QIDNAME(qid) AS EventName,
  CASE
    WHEN LOWER(UTF8(payload)) MATCHES '.*syn flood.*|.*syn attack.*|.*synflood.*|.*request_sock_tcp.*|.*sending cookies.*' THEN 'SYN Flood'
    WHEN LOWER(UTF8(payload)) MATCHES '.*ack flood.*|.*ack attack.*|.*ackflood.*' THEN 'ACK Flood'
    WHEN LOWER(UTF8(payload)) MATCHES '.*nf_conntrack.*table full.*|.*ip_conntrack.*table full.*|.*connection table full.*' THEN 'ConnTrack Table Full'
    WHEN LOWER(UTF8(payload)) MATCHES '.*half.open.*exceed.*|.*tcp.*exhaust.*' THEN 'TCP State Exhaustion'
    WHEN LOWER(UTF8(payload)) MATCHES '.*tcp.*orphaned.*' THEN 'TCP Orphaned Socket Exhaustion'
    ELSE 'OS Exhaustion Flood'
  END AS AttackType,
  COUNT(*) AS AlertCount
FROM events
WHERE
  starttime > NOW() - 3600000
  AND (
    (
      devicetype IN (SELECT id FROM device_type_definition WHERE name LIKE '%Syslog%')
      AND (
        LOWER(UTF8(payload)) MATCHES '.*possible syn flooding.*'
        OR LOWER(UTF8(payload)) MATCHES '.*tcp: request_sock_tcp.*'
        OR LOWER(UTF8(payload)) MATCHES '.*sending cookies.*'
        OR LOWER(UTF8(payload)) MATCHES '.*nf_conntrack.*table full.*'
        OR LOWER(UTF8(payload)) MATCHES '.*ip_conntrack.*table full.*'
        OR LOWER(UTF8(payload)) MATCHES '.*tcp.*orphaned.*'
        OR LOWER(UTF8(payload)) MATCHES '.*possible syn attack.*'
      )
    )
    OR
    (
      category IN (
        SELECT id FROM categories WHERE name LIKE '%Denial of Service%'
          OR name LIKE '%Flood%'
          OR name LIKE '%SYN%'
      )
      OR QIDNAME(qid) ILIKE '%syn flood%'
      OR QIDNAME(qid) ILIKE '%ack flood%'
      OR QIDNAME(qid) ILIKE '%tcp flood%'
      OR QIDNAME(qid) ILIKE '%tcp exhaustion%'
      OR QIDNAME(qid) ILIKE '%connection table%'
      OR LOWER(UTF8(payload)) MATCHES '.*(syn.flood|ack.flood|tcp.flood|tcp.exhaust|half.open|synflood|dos.*tcp|ddos.*tcp).*'
    )
  )
GROUP BY
  sourceip, destinationip, destinationport, logsourceid, category, qid
HAVING AlertCount >= 3
ORDER BY AlertCount DESC

high severity medium confidence

Detects OS exhaustion flood attacks (SYN floods, ACK floods, TCP conntrack table exhaustion) by querying QRadar events for Linux kernel syslog flood messages and network device DoS/flood category events. Correlates across source IP, target IP, and port with a minimum alert threshold to suppress noise.

Data Sources

Linux syslog (kern facility) via QRadar Syslog DSMCisco ASA DSMPalo Alto Networks DSMJuniper Networks DSMFortinet FortiGate DSMCheck Point FireWall-1 DSMGeneric Firewall / IDS / IPS DSMs

Required Tables

events

False Positives & Tuning

Security scanners and vulnerability assessment tools (Nessus, Qualys) performing TCP port scans against internal assets may generate half-open connection log entries resembling SYN flood indicators
Cloud load balancers performing health checks at high frequency against backend servers can trigger connection table threshold alerts on under-provisioned hosts
Legitimate traffic spikes during marketing events or product launches may cause transient conntrack table exhaustion on VMs with default nf_conntrack limits

Download portable Sigma rule (.yml)

Other platforms for T1499.001

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

Last updated: 2026-04-20 Research depth: deep

References (8)

Response Playbook

1. Examine the full command line and decode any Base64 content...
2. Identify the parent process chain and user context...
3. Check for concurrent network connections from the process...

Investigation Guide

Related techniques: T1027, T1105, T1562.001...
Forensic artifacts: PSReadLine history, Prefetch, ScriptBlock logs...

Atomic Red Team Tests

Test 1: Encoded command execution...
Test 2: Download cradle via Net.WebClient...

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

Detect OS Exhaustion Flood in IBM QRadar

MITRE ATT&CK

QRadar Detection Query

Data Sources

Required Tables

False Positives & Tuning

Other platforms for T1499.001

Testing Methodology

Response Playbook

Investigation Guide

Atomic Red Team Tests

Unlock Pro Content

Related Detections

Parent Technique

Related Sub-techniques

Related Techniques

Same Tactic: Impact

Popular Detections

MITRE ATT&CK

QRadar Detection Query

Data Sources

Required Tables

False Positives & Tuning

Other platforms for T1499.001

Testing Methodology

Unlock Pro Content

Related Detections

Parent Technique

Related Sub-techniques

Related Techniques

Same Tactic: Impact

Popular Detections

Get new detections in your inbox