Process invoked with a path inside the local mail spool

Siemphony@siemphonymediumT1566unverifiedPlaybook · Unexpected execution

Takes the Linux leg of AN0189 (DET0070) rather than the Windows or Office-app legs, because those two are already the mechanism of a published sibling: T1566.001 keys on the Outlook secure-temp cache path and T1566.003 keys on a messaging-client Image list, and both are Windows-only artefacts that a Linux host never produces; AN0191's Office-spawns-a-script-host pattern is also out of scope here, since the T1566.001 rule in this corpus already notes that pattern belongs to T1203/T1204. What is left, and what no sibling covers, is a process launched with a path under the local mail spool or a user's Maildir on its command line — evidence that something was run straight out of a delivered message rather than through a mail client's own attachment handler. `/var/spool/mail/` is added here alongside MITRE's `/var/mail` and `~/Maildir` examples because it is the RHEL-family spool location and MITRE names only the Debian-family one; that value is authored, not sourced. Mail delivery agents write to this same path on every message received, which would otherwise dominate the result set, so `filter_mda` excludes procmail, dovecot, sendmail and postfix by Image name — MITRE's `MonitoredMailPaths` knob is populated with the two directories, `AttachmentHashBaseline` has no equivalent Sigma construct and is not attempted. auditd does not record execve out of the box; without an explicit `-a always,exit -F arch=b64 -S execve` rule this rule is blind, not quiet. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0070, 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

1title: Process invoked with a path inside the local mail spool2id: 5dd9f853-d6cd-4b1d-9a4d-fd9503f4331e3status: experimental4description: |5  Takes the Linux leg of AN0189 (DET0070) rather than the Windows or Office-app6  legs, because those two are already the mechanism of a published sibling:7  T1566.001 keys on the Outlook secure-temp cache path and T1566.003 keys on a8  messaging-client Image list, and both are Windows-only artefacts that a Linux9  host never produces; AN0191's Office-spawns-a-script-host pattern is also out10  of scope here, since the T1566.001 rule in this corpus already notes that11  pattern belongs to T1203/T1204. What is left, and what no sibling covers, is12  a process launched with a path under the local mail spool or a user's Maildir13  on its command line — evidence that something was run straight out of a14  delivered message rather than through a mail client's own attachment handler.15  `/var/spool/mail/` is added here alongside MITRE's `/var/mail` and `~/Maildir`16  examples because it is the RHEL-family spool location and MITRE names only the17  Debian-family one; that value is authored, not sourced. Mail delivery agents18  write to this same path on every message received, which would otherwise19  dominate the result set, so `filter_mda` excludes procmail, dovecot, sendmail20  and postfix by Image name — MITRE's `MonitoredMailPaths` knob is populated21  with the two directories, `AttachmentHashBaseline` has no equivalent Sigma22  construct and is not attempted. auditd does not record execve out of the box;23  without an explicit `-a always,exit -F arch=b64 -S execve` rule this rule is24  blind, not quiet.25  UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0070, not hand-written and not tested by its author. Any lab result is on this rule's own page.26references:27  - https://attack.mitre.org/techniques/T156628  - https://attack.mitre.org/detectionstrategies/DET007029author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)30date: 2026-08-1631tags:32  - attack.initial-access33  - attack.t156634logsource:35  category: process_creation36  product: linux37detection:38  selection:39    CommandLine|contains:40      - '/var/mail/'41      - '/var/spool/mail/'42      - '/Maildir/'43  filter_mda:44    Image|endswith:45      - '/procmail'46      - '/dovecot'47      - '/sendmail'48      - '/postfix'49  condition: selection and not filter_mda50falsepositives:51  - "IMAP or POP retrieval tools such as fetchmail or getmail, which run as ordinary processes and reference the local spool or Maildir path on their command line on every scheduled sync, and are not covered by the MDA filter because their binary names differ from it."52  - "Mail scanning and antivirus integrations such as amavisd or ClamAV milters that open and inspect messages in place inside the spool directory as part of normal delivery-time filtering, producing a hit for every message that passes through the host."53  - "Backup, archival and mailbox-migration jobs that tar, rsync or copy a user's Maildir on a schedule, matching the path on every run without anything having been executed from it."54  - "System administration and troubleshooting, where an operator runs ls, find or grep against a spool directory to diagnose a delivery problem and the path lands on the command line without any attachment being run."55level: medium

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where ((ProcessCommandLine contains "/var/mail/" or ProcessCommandLine contains "/var/spool/mail/" or ProcessCommandLine contains "/Maildir/") and not ((FolderPath endswith "/procmail" or FolderPath endswith "/dovecot" or FolderPath endswith "/sendmail" or FolderPath endswith "/postfix")))

Splunk · SPL

Run this as a search.

index=* ((CommandLine="*/var/mail/*" OR CommandLine="*/var/spool/mail/*" OR CommandLine="*/Maildir/*") AND NOT ((Image="*/procmail" OR Image="*/dovecot" OR Image="*/sendmail" OR Image="*/postfix")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(process.command_line) LIKE "*/var/mail/*" OR TO_LOWER(process.command_line) LIKE "*/var/spool/mail/*" OR TO_LOWER(process.command_line) LIKE "*/maildir/*") AND NOT ((TO_LOWER(process.executable) LIKE "*/procmail" OR TO_LOWER(process.executable) LIKE "*/dovecot" OR TO_LOWER(process.executable) LIKE "*/sendmail" OR TO_LOWER(process.executable) LIKE "*/postfix")))

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="7">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="CommandLine" type="pcre2">(?i)(/var/mail/|/var/spool/mail/|/Maildir/)</field>    <field name="Image" negate="yes" type="pcre2">(?i)(/procmail$|/dovecot$|/sendmail$|/postfix$)</field>    <description>Process invoked with a path inside the local mail spool</description>    <mitre>      <id>T1566</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / linux
Level: medium
Category: office_macro_execution
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 5dd9f853-d6cd-4b1d-9a4d-fd9503f4331e

ATT&CKT1566

T1566Phishing

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.

Evidence

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

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.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1566, evaluated against their process_creation events.

Using it

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

Add /exim and /exim4 to filter_mda's Image|endswith list before running this against any Exim-based host. Populate MonitoredMailPaths further if your environment uses non-default spool locations. There is no tuning available for the relative-path evasion — it's a structural blind spot of a CommandLine-string-match approach, not a threshold to adjust.

Declared by the author

IMAP or POP retrieval tools such as fetchmail or getmail, which run as ordinary processes and reference the local spool or Maildir path on their command line on every scheduled sync, and are not covered by the MDA filter because their binary names differ from it.
Mail scanning and antivirus integrations such as amavisd or ClamAV milters that open and inspect messages in place inside the spool directory as part of normal delivery-time filtering, producing a hit for every message that passes through the host.
Backup, archival and mailbox-migration jobs that tar, rsync or copy a user's Maildir on a schedule, matching the path on every run without anything having been executed from it.
System administration and troubleshooting, where an operator runs ls, find or grep against a spool directory to diagnose a delivery problem and the path lands on the command line without any attachment being run.

Lessonoffice macro execution

office macro executionAI draft — unreviewed

01 · What this rule detects

MITRE's DET0070 covers phishing across five platforms via four analytics. This rule takes only the Linux leg, AN0189, and only a slice of it: a process launched with a command line that references a path inside the local mail spool or a user's Maildir. That is a precursor signal — "something ran out of a delivered message" — not the fuller behaviour AN0189 describes, which is correlating mail logs, file writes, and execution into one story. The Sigma here is a single process_creation event with no join across log sources and no time window, so it can only ever flag the execution step in isolation, not the delivery-then-execution chain MITRE's analytic actually asks for.

02 · Telemetry you need

logsource: category=process_creation, product=linux, sourced from auditd SYSCALL execve records, matched on CommandLine, Image. auditd does not capture execve by default — you need an explicit rule such as -a always,exit -F arch=b64 -S execve. Without it this rule sees zero events, and zero here means blind, not clean.

03 · How the logic works

MITRE's MonitoredMailPaths knob names the kind of value to tune — where mail is stored — and supplies /var/mail and ~/Maildir as examples. The rule author added the third path, /var/spool/mail/, because it's the RHEL-family spool location MITRE's Debian-family examples don't cover; that value is the rule author's own addition, not something MITRE supplied. The second knob, AttachmentHashBaseline, has no Sigma equivalent and isn't attempted here — Sigma can't express "diff against a known-good hash set." filter_mda exists because mail delivery agents write into the spool on every message received, which would otherwise dominate every match; it excludes four MDA binaries by name so the rule only fires when something else runs with the path on its command line.

04 · Common false positives

The four disclosed false positives are the real teaching material: fetchmail or getmail doing scheduled IMAP/POP retrieval (not caught by filter_mda because their binary names don't match it), amavisd/ClamAV scanning messages in place, backup or migration jobs tarring/rsyncing a Maildir, and an admin running ls/find/grep against the spool while troubleshooting.
But the reviewer caught a gap the rule doesn't disclose: filter_mda excludes sendmail and postfix but not Exim, which is at least as common a default MTA on modern Debian/Ubuntu. On an Exim host, every delivered message triggers unfiltered MDA noise that none of the four listed false positives accounts for — a filter list that looks complete for one distro family is actually partial. Separately, the rule only matches an absolute path in CommandLine; a payload run from a shell already cd'd into the Maildir (./payload) never puts the spool path on the command line and evades the selector entirely.

05 · Detection maturity

tier_1: Unverified — the lowest DeBMM tier. This Sigma has never been run against a real auditd stream; every false positive, every gap, and the Exim omission above are reasoned from the logic, not observed in data.

Share this rule

/u/siemphony/5dd9f853-d6cd-4b1d-9a4d-fd9503f4331e

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.

Process invoked with a path inside the local mail spool

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it