Suspicious one-line command executed as a direct child of sshd

Siemphony@siemphonylowT1021.004unverified

Matches the non-interactive half of AN1638: `ssh host 'command'` makes sshd exec the user's shell directly with `-c "command"`, so the whole remote command lands on one audited execve whose ParentImage is sshd — a shape RDP and SMB lateral movement cannot produce. Gating on a shell launcher plus suspicious content, rather than the parent alone, keeps an ordinary interactive login (a bare shell with no arguments) out of scope. The content list is authored from MITRE's SuspiciousProcessList knob ("nc, base64, bash -i") extended with the bash `/dev/tcp/` reverse-shell idiom; the login-to-execution correlation AN1638 also asks for is a cross-event join Sigma cannot express. OpenSSH 9.8 split the post-authentication session out of sshd into a separate sshd-session binary, so on current distributions the shell's parent is sshd-session and a gate on '/sshd' alone would be dead; both names are listed. Coverage limit, stated plainly: an interactive SSH login is not detected. Commands typed at a shell prompt are children of the login shell rather than of sshd, several hops from what this rule inspects, so interactive lateral movement over SSH passes unseen and only the `ssh host 'command'` shape is caught. Prerequisite: auditd does not record execve by default, so an empty result here means the syscall isn't audited rather than the estate being quiet. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0596, 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 (((InitiatingProcessFolderPath endswith "/sshd" or InitiatingProcessFolderPath endswith "/sshd-session") and (FolderPath endswith "/bash" or FolderPath endswith "/sh" or FolderPath endswith "/dash" or FolderPath endswith "/zsh")) and (ProcessCommandLine contains "base64 -d" or ProcessCommandLine contains "base64 --decode" or ProcessCommandLine contains "/dev/tcp/" or ProcessCommandLine contains "nc -e" or ProcessCommandLine contains "ncat -e" or ProcessCommandLine contains "socat exec" or ProcessCommandLine contains "mkfifo" or ProcessCommandLine contains "0>&1"))

Splunk · SPL

Run this as a search.

index=* (((ParentImage="*/sshd" OR ParentImage="*/sshd-session") AND (Image="*/bash" OR Image="*/sh" OR Image="*/dash" OR Image="*/zsh")) AND (CommandLine="*base64 -d*" OR CommandLine="*base64 --decode*" OR CommandLine="*/dev/tcp/*" OR CommandLine="*nc -e*" OR CommandLine="*ncat -e*" OR CommandLine="*socat exec*" OR CommandLine="*mkfifo*" OR CommandLine="*0>&1*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (((TO_LOWER(process.parent.executable) LIKE "*/sshd" OR TO_LOWER(process.parent.executable) LIKE "*/sshd-session") AND (TO_LOWER(process.executable) LIKE "*/bash" OR TO_LOWER(process.executable) LIKE "*/sh" OR TO_LOWER(process.executable) LIKE "*/dash" OR TO_LOWER(process.executable) LIKE "*/zsh")) AND (TO_LOWER(process.command_line) LIKE "*base64 -d*" OR TO_LOWER(process.command_line) LIKE "*base64 --decode*" OR TO_LOWER(process.command_line) LIKE "*/dev/tcp/*" OR TO_LOWER(process.command_line) LIKE "*nc -e*" OR TO_LOWER(process.command_line) LIKE "*ncat -e*" OR TO_LOWER(process.command_line) LIKE "*socat exec*" OR TO_LOWER(process.command_line) LIKE "*mkfifo*" OR TO_LOWER(process.command_line) LIKE "*0>&1*"))

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="ParentImage" type="pcre2">(?i)(/sshd$|/sshd-session$)</field>    <field name="Image" type="pcre2">(?i)(/bash$|/sh$|/dash$|/zsh$)</field>    <field name="CommandLine" type="pcre2">(?i)(base64 -d|base64 --decode|/dev/tcp/|nc -e|ncat -e|socat exec|mkfifo|0&gt;&amp;1)</field>    <description>Suspicious one-line command executed as a direct child of sshd</description>    <mitre>      <id>T1021.004</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / linux
Level: low
Category: lateral_movement_remote_exec
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 719ec44e-743d-45a4-a953-ba7d94d3fd7f

ATT&CKT1021.004

T1021.004SSH

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.

Lessonlateral movement remote exec

lateral movement remote exec

01 · What this rule detects

Code executed on a remote host from another host inside the network — the step where an attacker moves from their initial foothold to a system that matters.

02 · Telemetry you need

Process creation with parent process on the destination host
Logon events with logon type, to distinguish network from interactive
Service creation events on the destination
Named pipe and SMB activity where available

03 · How the logic works

Remote execution shows up on the destination as a process whose parent is a service host, WMI provider, or the service control manager, combined with a network logon shortly before. Match the parent-child relationships that remote execution produces rather than the tool names — the parentage is a property of how Windows executes remote code and is much harder to avoid than a binary name. Correlating with the preceding logon gives you the source host and account, which is what an analyst needs first.

04 · Common false positives

Remote administration and patch management performing exactly this pattern by design
Monitoring agents that execute remote queries
Clustering and failover software coordinating across nodes
Vulnerability scanners with credentialed scanning enabled

05 · Detection maturity

Tier 1 — starting point: Matches known remote execution tool names.
Tier 2 — tuned: Matches the parent-child patterns remote execution produces, excluding management servers by source.
Tier 3 — correlated: Correlates with the preceding network logon and scores on whether that source-account-destination triple is normal.

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

Exclude by source host rather than by tool — your management servers are a short, stable list
Direction matters: workstation to server is routine, server to workstation rarely is
Enrich with whether the source account normally authenticates to that destination
Administrative tooling used from an unusual source is the case worth alerting on

Declared by the author

Ansible's default SSH connection plugin, which wraps every module execution as sh -c 'echo ... ; base64 -d ...' piped through a decode step run directly under sshd. On any host managed by Ansible this is the highest-volume match by a wide margin and fires on ordinary configuration runs, not just when a base64 term is used maliciously.
Backup, log-shipping and media-processing scripts invoked over SSH that create a named pipe with mkfifo to stream data without a temp file. The term is one of the eight triggers and is ordinary shell craft, so any scheduled job of this shape matches every run on a busy ops or build host.
CI and release steps run as ssh host 'command' that move a small artefact, key or config blob inline by piping it through base64 -d on the far side, which matches the same decode term as the Ansible case and recurs at every pipeline execution.
Remote one-off maintenance commands an administrator runs with ssh host 'command' — for example decoding a base64-encoded config blob or piping a downloaded script through the shell — which is the exact shape this rule is built to catch and is separated from an intrusion only by who ran it and why.

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 T1021.004, evaluated against their process_creation events.

Share this rule

/u/siemphony/719ec44e-743d-45a4-a953-ba7d94d3fd7f

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.

Suspicious one-line command executed as a direct child of sshd

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it