Shadow or passwd file named on a Linux command line

Siemphony@siemphonymediumT1003.008unverified

Matches the execve leg of AN1234: a process launched with /etc/shadow on its command line, the unshadow utility that joins the two files into a cracking input, or /etc/passwd handed to a binary whose job is to copy, archive, encode or ship a file elsewhere. The match sits on CommandLine rather than on Image because MITRE's `exe` knob names cat, cp and awk while the same read is equally served by less, strings, tar, base64, head or a python one-liner, so keying on the reader would miss most of the ways this actually happens; unshadow is matched on Image as well, since an adversary who copied the pair out first invokes it against the copies and puts neither /etc path in argv. /etc/passwd on its own is deliberately not enough: it is world-readable and named on command lines constantly by ordinary administration, so it is gated on a transfer or archiving binary — that gate is authored here, not taken from MITRE, which names only the `exe` knob. Two limits follow from using execve. A shell builtin read (`while read line < /etc/shadow`) forks no process, and a program that opens the file through a path it builds at runtime never puts it in argv; the analytic's other log source, an auditd file-access watch such as `-w /etc/shadow -p r`, is the complement that catches both. Prerequisite: a stock auditd install ships no execve rule, so without an explicit `-a always,exit -F arch=b64 -S execve` there is no process_creation telemetry on the host at all and this returns zero rows regardless of what ran — zero rows reads as quiet when it means blind. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0446, 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 (ProcessCommandLine contains "/etc/shadow" or FolderPath endswith "/unshadow" or (ProcessCommandLine contains "/etc/passwd" and (FolderPath endswith "/cp" or FolderPath endswith "/tar" or FolderPath endswith "/base64" or FolderPath endswith "/xxd" or FolderPath endswith "/curl" or FolderPath endswith "/scp" or FolderPath endswith "/nc" or FolderPath endswith "/nc.openbsd" or FolderPath endswith "/nc.traditional" or FolderPath endswith "/netcat" or FolderPath endswith "/ncat")))

Splunk · SPL

Run this as a search.

index=* (CommandLine="*/etc/shadow*" OR Image="*/unshadow" OR (CommandLine="*/etc/passwd*" AND (Image="*/cp" OR Image="*/tar" OR Image="*/base64" OR Image="*/xxd" OR Image="*/curl" OR Image="*/scp" OR Image="*/nc" OR Image="*/nc.openbsd" OR Image="*/nc.traditional" OR Image="*/netcat" OR Image="*/ncat")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(process.command_line) LIKE "*/etc/shadow*" OR TO_LOWER(process.executable) LIKE "*/unshadow" OR (TO_LOWER(process.command_line) LIKE "*/etc/passwd*" AND (TO_LOWER(process.executable) LIKE "*/cp" OR TO_LOWER(process.executable) LIKE "*/tar" OR TO_LOWER(process.executable) LIKE "*/base64" OR TO_LOWER(process.executable) LIKE "*/xxd" OR TO_LOWER(process.executable) LIKE "*/curl" OR TO_LOWER(process.executable) LIKE "*/scp" OR TO_LOWER(process.executable) LIKE "*/nc" OR TO_LOWER(process.executable) LIKE "*/nc.openbsd" OR TO_LOWER(process.executable) LIKE "*/nc.traditional" OR TO_LOWER(process.executable) LIKE "*/netcat" OR TO_LOWER(process.executable) LIKE "*/ncat")))

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. -->  <!-- 3 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 linux so this only evaluates relevant events. -->    <field name="CommandLine" type="pcre2">(?i)/etc/shadow</field>    <description>Shadow or passwd file named on a Linux command line (1/3)</description>    <mitre>      <id>T1003.008</id>    </mitre>  </rule>   <rule id="100001" level="7">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)/unshadow$</field>    <description>Shadow or passwd file named on a Linux command line (2/3)</description>    <mitre>      <id>T1003.008</id>    </mitre>  </rule>   <rule id="100002" level="7">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="CommandLine" type="pcre2">(?i)/etc/passwd</field>    <field name="Image" type="pcre2">(?i)(/cp$|/tar$|/base64$|/xxd$|/curl$|/scp$|/nc$|/nc\.openbsd$|/nc\.traditional$|/netcat$|/ncat$)</field>    <description>Shadow or passwd file named on a Linux command line (3/3)</description>    <mitre>      <id>T1003.008</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / linux
Level: medium
Category: credential_dump
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: c6c302c2-3197-4bde-87f3-dfbc8a1748fd

ATT&CKT1003.008

T1003.008/etc/passwd and /etc/shadow

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.

Lessoncredential dump

credential dumpAI draft — unreviewed

01 · What this rule detects

The rule watches Linux process creation for a command line that names the local credential files. Three shapes count: anything at all with /etc/shadow in argv, an invocation of unshadow, and /etc/passwd handed to a binary whose purpose is to copy, archive, encode or ship a file somewhere else. It catches the execve half of MITRE's AN1234, which describes reading /etc/passwd and /etc/shadow directly, taking backup copies of them, or parsing them through post-exploitation tooling.

02 · Telemetry you need

logsource: category: process_creation, product: linux, taken verbatim from the analytic. In practice that is auditd SYSCALL records for execve, and a stock auditd install ships no such rule. Without an explicit -a always,exit -F arch=b64 -S execve in your audit rules there is no process creation telemetry on the host at all, and this rule returns zero rows no matter what ran. Zero rows read as "quiet" when they actually mean "blind" — confirm the rule is loaded before you trust an empty result. Any endpoint agent that synthesises a process-creation feed works equally well.

03 · How the logic works

selection_shadow is a bare CommandLine|contains: '/etc/shadow'. The match sits on the command line rather than on the executable because MITRE's exe knob names cat, cp and awk, while the same read is served just as well by less, strings, tar, base64, head or a Python one-liner. Keying on the reader would miss most of the ways this actually happens; keying on the path catches all of them. selection_unshadow matches Image|endswith: '/unshadow'. That leg is on the image because an adversary who copied the pair out first runs unshadow against the copies and puts neither /etc path in argv. selection_passwd_moved requires both halves: /etc/passwd on the command line and an Image ending in /cp, /tar, /base64, /xxd, /curl, /scp, one of the netcat variants, or /ncat. /etc/passwd alone is world-readable and named constantly by ordinary administration, so it is gated on exfiltration or archiving intent. That gate is authored here — MITRE names only the exe knob and its PATH knob for target files, not this list. The condition is 1 of selection*. Two blind spots follow from using execve: a shell builtin read such as while read line < /etc/shadow forks no process, and a program that constructs the path at runtime never puts it in argv. The analytic's other log source, an auditd file watch like -w /etc/shadow -p r, is the complement that covers both.

04 · Common false positives

Compliance and hardening scanners are the dominant match: Lynis, oscap remediation, CIS-benchmark shell scripts, AIDE and Tripwire wrappers all grep, awk or checksum /etc/shadow by absolute path on every host on a schedule. Administrators debugging a locked or expired account type the identical command. Account-management runbooks back the files up before bulk changes, and container image builds copy /etc/passwd into the output tree through cp and tar. That predictable, estate-wide top entry is why the rule is medium, not high.

05 · Detection maturity

tier_1: Lowest tier. This rule is machine-derived from ATT&CK v19.2 and has never been executed against a log line. It cannot advance until someone runs it on real auditd data, measures the scanner volume, and confirms the execve rule is even loaded on the estate it is meant to cover.

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

Start with MITRE's user knob — the analytic expects root, so suppress the specific scanner and backup service accounts by name rather than excluding root wholesale. Then use the exe knob to drop your scanner binaries and CI build paths. MITRE's TimeWindow knob is for correlating the read with the execution around it; Sigma models no timeframe, so that has to live in your platform.

Declared by the author

Compliance and hardening scanners that read /etc/shadow by absolute path on every host on a schedule — Lynis, oscap remediation scripts, CIS-benchmark shell scripts and AIDE or Tripwire wrappers all grep, awk or checksum it as a standard check. This is a predictable, recurring, estate-wide match and the highest-volume one this rule has, which is why it is scored medium rather than high.
Administrators troubleshooting a locked, expired or non-hashing account with sudo cat /etc/shadow or grep <user> /etc/shadow, and password-age audits run by hand from a runbook. The command is identical to the one this rule is written for and only the operator account separates them.
Account-management procedures that take a backup before a bulk change, such as cp /etc/passwd /etc/passwd.bak or cp /etc/shadow /root/shadow.$(date +%F) ahead of a mass useradd, a UID renumbering or a directory migration.
Container image builds and chroot or distroless staging that copy /etc/passwd into the output tree so the runtime user resolves, which is routine in CI and matches selection_passwd_moved through /cp and /tar.
Backup jobs invoking tar with an explicit include list that names /etc/passwd and /etc/shadow, producing one match per host per backup window under a service account.

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 T1003.008, evaluated against their process_creation events.

Share this rule

/u/siemphony/c6c302c2-3197-4bde-87f3-dfbc8a1748fd

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.

Shadow or passwd file named on a Linux command line

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it