File encrypted with a symmetric cipher on the command line

Siemphony@siemphonylowT1048.001unverified

A match is the encryption step alone. This rule sees no protocol, no destination and no transferred byte, so a hit is not by itself evidence that anything left the host, and because the same subcommands also decrypt, an inbound file being unpacked matches identically to data being staged for exfiltration. What it does detect is the manual symmetric step AN1390 pairs with an outbound transfer — `openssl enc` or the bare `openssl <cipher>` shorthand, `gpg --symmetric` or `gpg -c`, or an explicit AES, RC4, 3DES or ChaCha20 algorithm name — which is the half of the analytic a single process-creation event can carry; Sigma has no cross-event window, so MITRE's FileTransferIndicator knob has no form in the rule and the transfer leg must be confirmed from network telemetry before a hit means exfiltration rather than local file encryption. The cipher-name selection deliberately carries no process anchor so that a renamed binary or a wrapper script still matches on the algorithm string, at the cost of matching any command line that names a cipher, including TLS and VPN configuration. Written against the `process_creation` category for Linux, whose `CommandLine` field is a normalised join of the auditd SYSCALL and EXECVE records — a raw auditd feed keeps the arguments in a separate EXECVE record and needs that mapping applied before this rule can match at all. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0503, 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 "/openssl" and ProcessCommandLine contains " enc") or ((FolderPath endswith "/gpg" or FolderPath endswith "/gpg1" or FolderPath endswith "/gpg2") and (ProcessCommandLine contains "--symmetric" or ProcessCommandLine contains "--cipher-algo" or ProcessCommandLine contains " -c "))) or (ProcessCommandLine contains "aes-128-cbc" or ProcessCommandLine contains "aes-192-cbc" or ProcessCommandLine contains "aes-256-cbc" or ProcessCommandLine contains "aes-256-ctr" or ProcessCommandLine contains "aes-256-gcm" or ProcessCommandLine contains "-aes128" or ProcessCommandLine contains "-aes192" or ProcessCommandLine contains "-aes256" or ProcessCommandLine contains "chacha20" or ProcessCommandLine contains "-des3" or ProcessCommandLine contains "-rc4" or ProcessCommandLine contains " rc4 "))

Splunk · SPL

Run this as a search.

index=* (((Image="*/openssl" AND CommandLine="* enc*") OR ((Image="*/gpg" OR Image="*/gpg1" OR Image="*/gpg2") AND (CommandLine="*--symmetric*" OR CommandLine="*--cipher-algo*" OR CommandLine="* -c *"))) OR (CommandLine="*aes-128-cbc*" OR CommandLine="*aes-192-cbc*" OR CommandLine="*aes-256-cbc*" OR CommandLine="*aes-256-ctr*" OR CommandLine="*aes-256-gcm*" OR CommandLine="*-aes128*" OR CommandLine="*-aes192*" OR CommandLine="*-aes256*" OR CommandLine="*chacha20*" OR CommandLine="*-des3*" OR CommandLine="*-rc4*" OR CommandLine="* rc4 *"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (((TO_LOWER(process.executable) LIKE "*/openssl" AND TO_LOWER(process.command_line) LIKE "* enc*") OR ((TO_LOWER(process.executable) LIKE "*/gpg" OR TO_LOWER(process.executable) LIKE "*/gpg1" OR TO_LOWER(process.executable) LIKE "*/gpg2") AND (TO_LOWER(process.command_line) LIKE "*--symmetric*" OR TO_LOWER(process.command_line) LIKE "*--cipher-algo*" OR TO_LOWER(process.command_line) LIKE "* -c *"))) OR (TO_LOWER(process.command_line) LIKE "*aes-128-cbc*" OR TO_LOWER(process.command_line) LIKE "*aes-192-cbc*" OR TO_LOWER(process.command_line) LIKE "*aes-256-cbc*" OR TO_LOWER(process.command_line) LIKE "*aes-256-ctr*" OR TO_LOWER(process.command_line) LIKE "*aes-256-gcm*" OR TO_LOWER(process.command_line) LIKE "*-aes128*" OR TO_LOWER(process.command_line) LIKE "*-aes192*" OR TO_LOWER(process.command_line) LIKE "*-aes256*" OR TO_LOWER(process.command_line) LIKE "*chacha20*" OR TO_LOWER(process.command_line) LIKE "*-des3*" OR TO_LOWER(process.command_line) LIKE "*-rc4*" OR TO_LOWER(process.command_line) LIKE "* rc4 *"))

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="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)/openssl$</field>    <field name="CommandLine" type="pcre2">(?i) enc</field>    <description>File encrypted with a symmetric cipher on the command line (1/3)</description>    <mitre>      <id>T1048.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="Image" type="pcre2">(?i)(/gpg$|/gpg1$|/gpg2$)</field>    <field name="CommandLine" type="pcre2">(?i)(--symmetric|--cipher-algo| -c )</field>    <description>File encrypted with a symmetric cipher on the command line (2/3)</description>    <mitre>      <id>T1048.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="CommandLine" type="pcre2">(?i)(aes-128-cbc|aes-192-cbc|aes-256-cbc|aes-256-ctr|aes-256-gcm|-aes128|-aes192|-aes256|chacha20|-des3|-rc4| rc4 )</field>    <description>File encrypted with a symmetric cipher on the command line (3/3)</description>    <mitre>      <id>T1048.001</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / linux
Level: low
Category: data_staging_exfil
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 9fe7b63a-a4ac-4299-bcb4-f7a7d40cdff5

ATT&CKT1048.001

T1048.001Exfiltration Over Symmetric Encrypted Non-C2 Protocol

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.

Lessondata staging exfil

data staging exfil

01 · What this rule detects

Collection before departure: files gathered from profiles and shares, compressed — often into a password-protected archive — dropped into a staging directory, and then moved out of the environment. The staging half is the reliably detectable half, and it usually happens close enough to the transfer that catching it still leaves time to act.

02 · Telemetry you need

Process creation with full command lines for archiving utilities — 7z, rar, WinRAR's console build, tar.exe, makecab, and PowerShell Compress-Archive; the switches are the interesting part, so a truncated command line is worthless here
Sysmon EventID 11 (FileCreate) for archive extensions written under Temp, ProgramData, Public and the recycle bin
Sysmon EventID 3 (NetworkConnect) with DestinationIp, DestinationHostname, DestinationPort and Initiated, tied to the uploading process
Proxy, firewall or flow logs with bytes sent per session — these are the only records that carry volume and direction, and neither Sysmon nor the Security log has them
Security 5145 (detailed file share access) and 4663 (object access) for reads across shares — 5145 requires Audit Detailed File Share, 4663 requires Audit Object Access plus a SACL on the data itself, and all of it is off by default
DNS query logs, for the cloud storage and tunnelling destinations the transfer half resolves

03 · How the logic works

Split this into two rules, because it is really two behaviours with different telemetry. The staging rule is a process rule: an archiving utility invoked with a recursion switch, an output path under a staging directory, or a password flag, over a source path that holds user data or share content. Anchor on the switches and the paths rather than the tool name — a renamed rar.exe still needs the same arguments to do the same job — and keep the password flag as its own higher-severity condition, since ordinary backup rarely needs one. The transfer rule is a volume and destination rule, and it does not express well in Sigma: there is no aggregation, so the bytes-sent threshold and the per-destination grouping live in the backend query or the correlation layer. The pairing that makes both worth having is sequence — an archive created, then that same file opened by a process that immediately connects outbound.

04 · Common false positives

Backup and archiving agents doing precisely this by design, including Veeam, Acronis and Windows Server Backup
Sanctioned cloud sync clients — OneDrive, Dropbox, Box — moving large volumes to destinations that are supposed to receive them
Developers and build agents compressing source trees, artefacts and logs, and CI runners uploading them
IT collecting diagnostic bundles and log archives for a vendor support case
E-discovery, DLP and data-classification scanners reading broadly across shares, and migration tooling moving mailboxes or file servers

05 · Detection maturity

Tier 1 — starting point: Matches archiving utility command lines by tool name.
Tier 2 — tuned: Matches recursion and password switches over sensitive source paths, with backup and sync clients excluded by signed path.
Tier 3 — correlated: Correlates archive creation with the subsequent read and outbound transfer of that file, scored on destination novelty and volume.

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

Password-protected archives of user data are the highest-payoff single condition in this category; alert on those before anything else
Scope the staging rule by source path — profile directories and file shares — rather than by the utility, so unfamiliar tools still match
Exclude sanctioned cloud sync by the signed path of the client process, not by destination domain, or you excuse anything that can reach the same domain
Keep staging and transfer as separate alerts so each stays actionable, and correlate them for severity rather than merging them into one rule
Where the archive is written matters more than what wrote it: a user-writable staging directory holding an archive of someone else's data is the shape you are looking for

Declared by the author

Container entrypoints and cloud-init provisioning that unseal a bundled config at start-up with openssl enc -d -aes-256-cbc. On any containerised estate this fires on every container start and every autoscaling event and is the loudest match by a wide margin, which is what the level below reflects.
Backup and database-export scripts that pipe a dump through openssl enc -aes-256-cbc before shipping it off the host, on a schedule and on every server, where only the destination separates the event from staged exfiltration. Pin the allowed script path and account rather than dropping the cipher terms.
Configuration-management and CI pipelines that seal or unseal a secrets file at deploy time with openssl enc or gpg --symmetric, producing a match on every build agent on every deployment.
Users protecting a document with a passphrase before sending it to an external party, which is the intended purpose of gpg --symmetric, and support staff decrypting one that arrived the same way.
Command lines that name a cipher without encrypting a file at all, such as curl, openvpn or stunnel invocations pinning an AES or ChaCha20 suite, and distribution package builds or regression suites that walk every cipher in the list within a single job.

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 T1048.001, evaluated against their process_creation events.

Share this rule

/u/siemphony/9fe7b63a-a4ac-4299-bcb4-f7a7d40cdff5

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.

File encrypted with a symmetric cipher on the command line

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it