Shell one-liner delays before piping a download into an interpreter

Siemphony@siemphonylowT1678unverified

Of this technique's three platform analytics, only the Linux leg (AN1049) has a Sigma logsource with a real field vocabulary to write against: its first entry maps to {category: process_creation, product: linux}, the same raw-auditd-compatible shape used elsewhere in this corpus (Image, CommandLine from a single SYSCALL/EXECVE pair). AN1049 asks for sleep, ping or a low-level delay syscall inside a short-lived chain with no user interaction, "frequently seen in malicious cron jobs or payload stagers" — this rule targets that stager phrasing specifically: a shell (sh, bash, dash, ash) execve'd with an inline -c script whose text both delays (sleep or ping) and fetches-then-executes (curl or wget piped into sh/bash), the `sleep N && curl ... | bash` pattern. It deliberately matches the interpreter's own CommandLine rather than joining a parent sleep/ping event to a child curl event, because ParentImage and ParentCommandLine are not populated by a raw auditd SYSCALL record at all — only Auditbeat-style enrichment, sysmon-for-linux or an EDR normalisation layer resolves and joins the parent for you, the same gap recorded against T1204.005 in this corpus. "Short-lived" and "repeated" (MITRE's TimeWindow and TimeBetweenSyscalls knobs) are process-duration and aggregation properties a single process_creation event cannot carry, so they are not attempted. AN1049's second logsource, {product: linux, service: auditd} keyed on a PROCTITLE record, is not used either: no rule in this corpus has yet established a field mapping for raw PROCTITLE, and inventing one here would risk the exact silent-failure trap this pipeline exists to avoid. AN1048 (Windows) is not attempted: its logsources are Sysmon EID 1 and EID 7, and neither records an API call — EID 7 is a DLL module load, not a Sleep or NtDelayExecution invocation, so "kernel32!Sleep, NTDLL APIs" as stated in the analytic has no matching field on either source. AN1050 (macOS) is not attempted: its only logsource is {product: macos, service: unifiedlog}, which has no standardised Sigma field vocabulary in this pipeline, the same ground on which T1037.002, T1059.002 and T1548.004 declined. Prerequisite: auditd ships no execve audit rule by default, so a host without an `-a always,exit -F arch=b64 -S execve` rule (or equivalent process telemetry agent) produces nothing here at all. UNVERIFIED — derived from MITRE ATT&CK DET0372 and never executed against logs.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 "/sh" or FolderPath endswith "/bash" or FolderPath endswith "/dash" or FolderPath endswith "/ash") and (ProcessCommandLine contains "sleep " or ProcessCommandLine contains "ping ")) and (ProcessCommandLine contains "curl" or ProcessCommandLine contains "wget" or ProcessCommandLine contains "|sh" or ProcessCommandLine contains "| sh" or ProcessCommandLine contains "|bash" or ProcessCommandLine contains "| bash"))

Splunk · SPL

Run this as a search.

index=* (((Image="*/sh" OR Image="*/bash" OR Image="*/dash" OR Image="*/ash") AND (CommandLine="*sleep *" OR CommandLine="*ping *")) AND (CommandLine="*curl*" OR CommandLine="*wget*" OR CommandLine="*|sh*" OR CommandLine="*| sh*" OR CommandLine="*|bash*" OR CommandLine="*| bash*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (((TO_LOWER(process.executable) LIKE "*/sh" OR TO_LOWER(process.executable) LIKE "*/bash" OR TO_LOWER(process.executable) LIKE "*/dash" OR TO_LOWER(process.executable) LIKE "*/ash") AND (TO_LOWER(process.command_line) LIKE "*sleep *" OR TO_LOWER(process.command_line) LIKE "*ping *")) AND (TO_LOWER(process.command_line) LIKE "*curl*" OR TO_LOWER(process.command_line) LIKE "*wget*" OR TO_LOWER(process.command_line) LIKE "*|sh*" OR TO_LOWER(process.command_line) LIKE "*| sh*" OR TO_LOWER(process.command_line) LIKE "*|bash*" OR TO_LOWER(process.command_line) LIKE "*| bash*"))

Wazuh · XML rule

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

<group name="sigma,linux,process_creation,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)(/sh$|/bash$|/dash$|/ash$)</field>    <field name="CommandLine" type="pcre2">(?i)(sleep |ping )</field>    <field name="CommandLine" type="pcre2">(?i)(curl|wget|\|sh|\| sh|\|bash|\| bash)</field>    <description>Shell one-liner delays before piping a download into an interpreter</description>    <mitre>      <id>T1678</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / linux
Level: low
Category: ingress_tool_transfer
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 3 Sept 2026
Rule ID: 15a2c103-c116-4c83-ad58-1e07ad5bac27

ATT&CKT1678

T1678Delay Execution

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.

Lessoningress tool transfer

ingress tool transferAI draft — unreviewed

01 · What this rule detects

Of this technique's three platform analytics, only the Linux leg (AN1049) has a Sigma logsource this pipeline can write real fields against. AN1049 describes sleep, ping or a low-level delay syscall inside a short-lived chain with no user interaction, "frequently seen in malicious cron jobs or payload stagers." This rule targets that stager phrasing specifically: a shell execve'd with an inline -c script whose text both delays and fetches-then-executes — the sleep N && curl ... | bash pattern.

02 · Telemetry you need

process_creation, product linux — the raw-auditd-compatible shape used elsewhere in this corpus, giving Image and CommandLine from a single SYSCALL/EXECVE pair. Auditd ships no execve audit rule by default, so a host without an -a always,exit -F arch=b64 -S execve rule (or an equivalent process telemetry agent) produces nothing here at all — zero rows means no coverage, not a quiet host.

03 · How the logic works

Three ANDed selectors. selection_shell matches Image|endswith on /sh, /bash, /dash or /ash. selection_delay matches CommandLine|contains on sleep or ping . selection_fetch_pipe matches CommandLine|contains against curl, wget, |sh, | sh, |bash or | bash, ORed together. The condition is selection_shell and selection_delay and selection_fetch_pipe, so all three must appear on the same command line. This deliberately matches the interpreter's own CommandLine rather than joining a parent sleep/ping event to a child curl event, because ParentImage/ParentCommandLine aren't populated by a raw auditd SYSCALL record — only Auditbeat-style enrichment, sysmon-for-linux or an EDR normalization layer resolves and joins the parent, the same gap recorded against T1204.005 elsewhere in this corpus. MITRE's TimeWindow and TimeBetweenSyscalls knobs are process-duration and aggregation properties a single process_creation event can't carry, so neither is attempted; the Windows leg (AN1048) and the macOS leg (AN1050) are skipped entirely because their logsources — EID 7 module loads and unified log respectively — have no field that records the actual delay API call.

04 · Common false positives

An adversarial review flagged that selection_fetch_pipe ORs curl/wget together with the pipe markers as interchangeable alternatives rather than requiring both — so a bare curl call with no pipe at all, like sh -c "sleep 5 && curl -sf http://localhost:8080/health", satisfies the condition just as well as a genuine download-and-execute stager. That gap is disclosed in the rule's own first falsepositives entry, but it's larger than the two named scenarios suggest: any CI/CD pipeline, Kubernetes init-container or deployment script that sleeps before a status-check curl call will match, not only curl-pipe-bash installers. The second disclosed source is legitimate: shell bootstrap scripts using the curl-pipe-to-shell install pattern (rustup, nvm, Homebrew-on-Linux) that include an inline sleep for rate-limiting near the pipe.

05 · Detection maturity

tier_1: This rule has never run against a log line and sits at the lowest DeBMM tier by definition. It is a scaffold for a human to test against real auditd execve data, tighten the fetch/pipe logic, and confirm the execve audit rule is actually active before any hit is trusted as signal.

Tuning & false positivesexperimental · 2 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

The title promises a narrower pattern — piping a download into an interpreter — than the boolean logic enforces. Splitting selection_fetch_pipe into two mandatory legs, one requiring curl/wget present and one requiring a pipe-to-shell marker present, ANDed together, would make the condition only fire when both a fetch tool and a pipe into sh/bash appear on the same line, matching what the rule claims to catch and cutting the CI/health-check noise substantially. Until that split lands, expect to allowlist known CI runner and init-container command patterns by path or by the absence of a pipe marker.

Declared by the author

Deployment or CI scripts that inline a short sleep before curling a health-check or artifact URL as a single -c one-liner, e.g. sh -c "sleep 5 && curl -sf http://localhost:8080/health", for retry backoff.
Shell-based software bootstrap scripts — the common curl-pipe-to-shell install pattern used by tools such as rustup, nvm or Homebrew-on-Linux — that include an inline sleep for rate-limiting immediately before or after the pipe.

Noise check0 of 4 fired

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

Share this rule

/u/siemphony/15a2c103-c116-4c83-ad58-1e07ad5bac27

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.

Shell one-liner delays before piping a download into an interpreter

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it