Packet generator invoked with SYN, ACK or flood arguments on Linux

Siemphony@siemphonylowT1499.001unverified

AN1013 defines its log source as the invocation of packet generation tools, naming hping3 and nping, so this rule matches an auditd EXECVE record whose argv[0] resolves to one of those binaries — the hping and hping2 entries are kept because some distributions install the binary under those names rather than as symlinks — and whose arguments carry SYN, ACK or flood evidence: -S/--syn or -A/--ack, the flags that put hping into the state-exhausting handshake mode this technique is filed under, or --flood, which removes the per-packet pacing either mode would otherwise have. Matching argv[0] and the flag together is possible in one selection because a raw auditd stream keeps both on the same EXECVE record — argv[0] is a0 and every subsequent argument is a1..aN on that record, not split across it and the SYSCALL record the way exe and the arguments are. An earlier version of this rule claimed the opposite and matched on exe alone; that was wrong, made the rule a strict subset of the tool list in this corpus's T1498.001 rule with no argument evidence at all, and left a diagnostic `hping3 -c 3` indistinguishable from `hping3 -S --flood`. Argument position is not fixed, so the flag check is repeated across a1 through a4 to catch the flag wherever the user placed it relative to the target and other options; a flag placed at a5 or later is still missed, and `hping3 --flood` alone (no explicit -S/-A) still matches, which keeps this rule's firing set overlapping with T1498.001's rather than disjoint from it — the two rules describe the same tool family from two different feeds (this one raw auditd, that one the normalised process_creation view) and neither fully separates a state-exhaustion flood from a bandwidth flood on argument evidence alone. Still out of reach entirely: MITRE's AmplificationThreshold knob is a volume and lib/sigma has no aggregation, no timeframe and no near, so a match here means a flood-shaped invocation happened, never that the TCP state table came under measurable pressure; the fork-bomb half of AN1013's log source is a shell construct with no distinct binary; and a compiled dropper or a hand-rolled socket loop leaves no matching command at all. Prerequisite: auditd records nothing about execution until an exec rule is loaded, for example `-a always,exit -F arch=b64 -S execve -k exec` plus its b32 twin, and without it this rule returns zero rows, which reads as quiet when it means blind. Field values must also arrive unquoted and hex-decoded from the auditd parser (auparse, a Wazuh decoder, or a Filebeat auditd module) — against unnormalised text, a trailing quote on a0 or a1 defeats every endswith and contains here. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0356, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 3 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Splunk · SPL

Run this as a search.

index=* ((type="EXECVE" AND (a0="*hping" OR a0="*hping2" OR a0="*hping3" OR a0="*nping")) AND ((a1="*-S*" OR a1="*--syn*" OR a1="*-A*" OR a1="*--ack*" OR a1="*--flood*") OR (a2="*-S*" OR a2="*--syn*" OR a2="*-A*" OR a2="*--ack*" OR a2="*--flood*") OR (a3="*-S*" OR a3="*--syn*" OR a3="*-A*" OR a3="*--ack*" OR a3="*--flood*") OR (a4="*-S*" OR a4="*--syn*" OR a4="*-A*" OR a4="*--ack*" OR a4="*--flood*")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(type) == "execve" AND (TO_LOWER(a0) LIKE "*hping" OR TO_LOWER(a0) LIKE "*hping2" OR TO_LOWER(a0) LIKE "*hping3" OR TO_LOWER(a0) LIKE "*nping")) AND ((TO_LOWER(a1) LIKE "*-s*" OR TO_LOWER(a1) LIKE "*--syn*" OR TO_LOWER(a1) LIKE "*-a*" OR TO_LOWER(a1) LIKE "*--ack*" OR TO_LOWER(a1) LIKE "*--flood*") OR (TO_LOWER(a2) LIKE "*-s*" OR TO_LOWER(a2) LIKE "*--syn*" OR TO_LOWER(a2) LIKE "*-a*" OR TO_LOWER(a2) LIKE "*--ack*" OR TO_LOWER(a2) LIKE "*--flood*") OR (TO_LOWER(a3) LIKE "*-s*" OR TO_LOWER(a3) LIKE "*--syn*" OR TO_LOWER(a3) LIKE "*-a*" OR TO_LOWER(a3) LIKE "*--ack*" OR TO_LOWER(a3) LIKE "*--flood*") OR (TO_LOWER(a4) LIKE "*-s*" OR TO_LOWER(a4) LIKE "*--syn*" OR TO_LOWER(a4) LIKE "*-a*" OR TO_LOWER(a4) LIKE "*--ack*" OR TO_LOWER(a4) LIKE "*--flood*")))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,linux,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 4 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)(hping$|hping2$|hping3$|nping$)</field>    <field name="a1" type="pcre2">(?i)(-S|--syn|-A|--ack|--flood)</field>    <description>Packet generator invoked with SYN, ACK or flood arguments on Linux (1/4)</description>    <mitre>      <id>T1499.001</id>    </mitre>  </rule>   <rule id="100001" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)(hping$|hping2$|hping3$|nping$)</field>    <field name="a2" type="pcre2">(?i)(-S|--syn|-A|--ack|--flood)</field>    <description>Packet generator invoked with SYN, ACK or flood arguments on Linux (2/4)</description>    <mitre>      <id>T1499.001</id>    </mitre>  </rule>   <rule id="100002" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)(hping$|hping2$|hping3$|nping$)</field>    <field name="a3" type="pcre2">(?i)(-S|--syn|-A|--ack|--flood)</field>    <description>Packet generator invoked with SYN, ACK or flood arguments on Linux (3/4)</description>    <mitre>      <id>T1499.001</id>    </mitre>  </rule>   <rule id="100003" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)(hping$|hping2$|hping3$|nping$)</field>    <field name="a4" type="pcre2">(?i)(-S|--syn|-A|--ack|--flood)</field>    <description>Packet generator invoked with SYN, ACK or flood arguments on Linux (4/4)</description>    <mitre>      <id>T1499.001</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"product":"linux","service":"auditd"}), so there is nothing honest to query. Pick a logsource this translator maps, or write the KQL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: auditd / linux
Level: low
Category: impact_destruction
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 07c0cdfb-79dd-47c2-a397-24adc2c8ef6f

ATT&CKT1499.001

T1499.001OS Exhaustion Flood

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonimpact destruction

impact destruction

01 · What this rule detects

The work an operator does to make recovery impossible before, or while, destroying data — deleting volume shadow copies, wiping backup catalogs, disabling Windows recovery and boot repair, and deleting or overwriting files recursively. Most of it happens in a short burst immediately before encryption, which is why the precursors are the part worth detecting: by the time file modification volume is the signal, the decision has already been made for you. This overlaps deliberately with log clearing — the same burst usually destroys evidence and recovery together — but keep the two rules apart, because they point at different questions.

02 · Telemetry you need

Process creation with full command lines — Sysmon EventID 1, or Security 4688 with Audit Process Creation and the command-line inclusion policy; without the second policy you see that vssadmin ran and nothing about what it did
The utilities themselves: vssadmin, wmic shadowcopy, wbadmin, bcdedit, cipher, and the PowerShell and WMI equivalents that never touch a command-line binary
Sysmon EventID 23 and 26 (FileDelete and FileDeleteDetected) — not in the default configuration, and the archiving variant needs disk space budgeted for it
Service and provider activity for the Volume Shadow Copy service, and the backup product's own logs, which record deletion the operating system does not
Security 4663 for delete access on protected shares — Audit Object Access plus a SACL, off by default and inert without the SACL

03 · How the logic works

These command lines are short, fixed and close to unique, which makes this one of the few categories where string matching against the command line is the right primary approach rather than a fallback. Structure each as image AND destructive verb: matching vssadmin alone catches every backup product listing shadows, whereas vssadmin with delete does not. Allow for argument reordering, abbreviation and the several spellings of the same operation, and remember that the same effect is reachable through WMI and the COM interfaces without running the utility at all — so a rule set that names only the executables has a hole in it that any competent tooling walks through. The mass-encryption half is a rate problem: file modifications per process per minute, which Sigma cannot express and which belongs in the correlation layer.

04 · Common false positives

Backup software managing its own shadow storage and pruning old copies — Veeam, Acronis, Windows Server Backup and the built-in scheduled tasks
Disk cleanup and storage reclamation removing shadow copies when a volume fills
Imaging, provisioning and task sequences that use bcdedit and reset recovery configuration by design
Non-persistent VDI and lab rebuild workflows that discard machine state on every cycle
Developers and build systems recursively deleting output directories

05 · Detection maturity

Tier 1 — starting point: Matches vssadmin and wbadmin deletion command lines.
Tier 2 — tuned: Covers the WMI and PowerShell routes and boot configuration tampering, with backup hosts and maintenance windows excluded.
Tier 3 — correlated: Correlates recovery destruction with log clearing, service stops and file modification rate from the same host and process tree.

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

This should be a near-silent category. If it is noisy, find out what is deleting recovery points routinely and fix that rather than filtering it
Never exclude by account — the accounts used here are administrative by definition, which is the point
Scope exclusions to the specific backup hosts and their maintenance windows, and revisit them when the backup product changes
Alert on failed attempts as well as successful ones; a denied shadow deletion is the same intent and better news
Escalate hard on the combination — shadow deletion, log clearing and service stops from one host inside a few minutes is a different alert from any of them alone

Declared by the author

Network and platform engineers using hping3 -S or nping --syn to test whether a firewall rule passes a given TCP flag, or hping3 --flood to measure link throughput or NIC behaviour under load. The command is identical to a real launch and only the target, schedule and account separate them, which is why the level is low.
Scanning and assessment hosts where the nmap package is installed: nping ships with nmap, and reachability or packet-crafting steps in a scan workflow that pass --flood or a SYN flag execute it from the same accounts and on the same schedule as the scan itself.
Booked load and resilience testing, and authorised penetration tests with availability in scope, where hping3 -S --flood or hping3 -A --flood is pointed at the organisation's own service from the same host a real attack would use.
Lab, training and CTF images, where these packages are installed deliberately and the SYN/ACK/flood flags are exercised as coursework, so every student host produces matches for the duration of a course.

Noise check0 of 5 fired

Fires on none of the 5 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 5 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1499.001, evaluated against their — events.

Share this rule

/u/siemphony/07c0cdfb-79dd-47c2-a397-24adc2c8ef6f

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Packet generator invoked with SYN, ACK or flood arguments on Linux

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it