Windows denial-of-service stress tool launched

Siemphony@siemphonymediumT1498unverified

AN1434's Windows leg is "an executable or script generating large outbound network traffic," which needs a packets-per-second aggregation MITRE's own ThresholdEventVolume and DestinationDiversity knobs name and Sigma cannot compute — no `| count() by`, no timeframe. What a single Sysmon EventID 1 event can carry instead is the launch of a tool whose only purpose is generating that traffic: the Windows GUI flood clients (LOIC, HOIC, XOIC) descended from the Low Orbit Ion Cannon family, and the Python HTTP/slow-read flood scripts (GoldenEye, Slowloris, Hulk) run through python.exe. This is deliberately a different tool set from the published T1498.001 rule, which matches Linux packet-crafting binaries (hping3, nping, t50, mausezahn) and `ping -f`: that rule's tools are raw-socket generators with everyday diagnostic uses on Linux, these are single-purpose attack clients with no Windows administrative role, which is also why this rule can sit at a comparable severity despite matching on presence alone. As with the Linux rule, a match means only that a flood-capable tool was started, never that outbound volume became abnormal, and a compiled dropper or a hand-rolled socket loop that doesn't match one of these names produces no event here at all. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0518, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

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

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where ((FolderPath endswith "\\loic.exe" or FolderPath endswith "\\hoic.exe" or FolderPath endswith "\\hoic2.exe" or FolderPath endswith "\\xoic.exe") or ((FolderPath endswith "\\python.exe" or FolderPath endswith "\\pythonw.exe") and (ProcessCommandLine contains "goldeneye.py" or ProcessCommandLine contains "slowloris.py" or ProcessCommandLine contains "hulk.py")))

Splunk · SPL

Run this as a search.

index=* ((Image="*\\loic.exe" OR Image="*\\hoic.exe" OR Image="*\\hoic2.exe" OR Image="*\\xoic.exe") OR ((Image="*\\python.exe" OR Image="*\\pythonw.exe") AND (CommandLine="*goldeneye.py*" OR CommandLine="*slowloris.py*" OR CommandLine="*hulk.py*")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(process.executable) LIKE "*\\\\loic.exe" OR TO_LOWER(process.executable) LIKE "*\\\\hoic.exe" OR TO_LOWER(process.executable) LIKE "*\\\\hoic2.exe" OR TO_LOWER(process.executable) LIKE "*\\\\xoic.exe") OR ((TO_LOWER(process.executable) LIKE "*\\\\python.exe" OR TO_LOWER(process.executable) LIKE "*\\\\pythonw.exe") AND (TO_LOWER(process.command_line) LIKE "*goldeneye.py*" OR TO_LOWER(process.command_line) LIKE "*slowloris.py*" OR TO_LOWER(process.command_line) LIKE "*hulk.py*")))

Wazuh · XML rule

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

<group name="sigma,windows,process_creation,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 2 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)(\\loic\.exe$|\\hoic\.exe$|\\hoic2\.exe$|\\xoic\.exe$)</field>    <description>Windows denial-of-service stress tool launched (1/2)</description>    <mitre>      <id>T1498</id>    </mitre>  </rule>   <rule id="100001" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)(\\python\.exe$|\\pythonw\.exe$)</field>    <field name="CommandLine" type="pcre2">(?i)(goldeneye\.py|slowloris\.py|hulk\.py)</field>    <description>Windows denial-of-service stress tool launched (2/2)</description>    <mitre>      <id>T1498</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: medium
Category: impact_destruction
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 7b08fdb0-a663-4d22-a67b-a7b378e3e762

ATT&CKT1498

T1498Network Denial of Service

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 destructionAI draft — unreviewed

01 · What this rule detects

MITRE's AN1434 describes the Windows side of Network DoS as "an executable or script generating large outbound network traffic." This rule cannot see traffic volume at all — it watches for the launch of tools whose only purpose is generating a flood: the GUI clients descended from Low Orbit Ion Cannon (LOIC, HOIC, XOIC) and Python HTTP/slow-read flood scripts (GoldenEye, Slowloris, Hulk). A match means one of these specific tools started, nothing more.

02 · Telemetry you need

logsource: category: process_creation, product: windows — Sysmon Event ID 1. You need Image (the launched binary's path) and CommandLine. No audit policy caveat here beyond having Sysmon deployed with a config that logs process creation; this is not the Security-log 4688 path, so the separate "include command line" policy doesn't apply.

03 · How the logic works

Two selections, OR'd. selection_gui_tool fires on Image|endswith one of \loic.exe, \hoic.exe, \hoic2.exe, \xoic.exe — a bare name match, no command-line check. The second branch requires both selection_python_parent (Image|endswith \python.exe or \pythonw.exe) and selection_python_flood_script (CommandLine|contains goldeneye.py, slowloris.py, or hulk.py) — you need the interpreter and one of the named scripts on the command line before this branch fires. Watch the naming here: selection_python_parent is misleading. Despite the name, it tests Image, not ParentImage — it matches the Python interpreter process itself, not a parent of anything. Review flagged this exact mismatch: the block name implies a parent-child relationship the logic never checks. The logic is still correct (interpreter-plus-script-name is a reasonable pairing), but read selection names for what field they actually test, not what the label suggests — a name that promises lineage and delivers only "this same process" is an easy trap to inherit into your own rules.

04 · Common false positives

None of the four false positives listed are "this technique looks like something else" — they're all "this exact tool, run for a legitimate reason": authorized load/resilience testing or red-team engagements against owned infrastructure; security-awareness labs, CTF hosts, and training VMs where every student machine runs LOIC or HOIC as coursework; breach-and-attack-simulation platforms deliberately executing a real copy of one of these tools to prove the alert fires; and a downloaded flood script run once against localhost for analysis, which the command line can't distinguish from a real target since it carries no destination.

05 · Detection maturity

tier_1: Unverified — the lowest DeBMM tier. This rule was authored from the MITRE brief and has never been run against a real Sysmon feed, so there is no data on match volume, true-positive rate, or how often the named binaries appear renamed or absent in your environment. Treat it as a starting scaffold to validate against your own EDR data, not a tuned detection.

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

MITRE's mutableElements for AN1434 are ThresholdEventVolume (connections per second) and DestinationDiversity (unique destination IPs/ports) — real tuning knobs, but Sigma has no | count() by and no timeframe, so this rule cannot implement either one. That's exactly why it falls back to matching tool identity instead of traffic behavior: it's a proxy for AN1434, not an implementation of it. The literal-name matching this rule does use is the author's own choice, not MITRE's — and it's brittle: renaming the flood binaries, recompiling them, or invoking the Python scripts inline (python -c) or under a different filename evades every selector, a gap the rule's own description concedes. If you deploy this, add a suppression list for known lab/BAS hosts rather than lowering the level — the noisiest sources are intentional, repeatable executions, not ambiguity about intent.

Declared by the author

Authorised load or resilience testing and red-team engagements that use one of these same publicly available tools against a system the organisation owns, which is the only routine legitimate use of any of them.
Security-awareness labs, CTF hosts and training VMs where LOIC or HOIC is installed and run deliberately as coursework, so every student workstation in the class produces matches for the exercise's duration.
Breach-and-attack-simulation or detection-engineering platforms that execute a real, unmodified copy of one of these tools to validate that this exact class of alert fires.
A downloaded copy of a Python flood script kept for reference or static analysis and executed once, harmlessly, against localhost or a lab target rather than a real destination — the command line alone cannot see the target address.

Noise check0 of 30 fired

Fires on none of the 30 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 30 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 T1498, evaluated against their process_creation events.

Share this rule

/u/siemphony/7b08fdb0-a663-4d22-a67b-a7b378e3e762

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.

Windows denial-of-service stress tool launched

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it