Crontab file or cron drop-in directory written on Linux

Siemphony@siemphonylowT1053.003unverified

Matches the file-modification leg of AN0805: an auditd PATH record naming one of the stores cron reads its schedule from — the per-user spool under /var/spool/cron/, the system-wide /etc/crontab and /etc/anacrontab, and the drop-in directories /etc/cron.d/ and the hourly, daily, weekly and monthly run-parts folders. The path list is MITRE's `CronFilePath` knob, populated here with the Debian and RHEL layouts; a distribution that keeps its spool elsewhere needs its own entry. ESXi is one of the technique's platforms and its crontab lives at the same /var/spool/cron/crontabs/root path, but ESXi runs no auditd, so this logsource does not reach it and the ESXi arm of the technique is uncovered. Matching is on `contains` and `endswith` rather than an absolute path because `crontab -e` writes a temporary file and renames it into the spool — the rename target is what shows up, not the editor's scratch file. That does not rescue the relative case: auditd records `name=` exactly as it was handed to the syscall, so `cd /etc/cron.d && echo '* * * * * root /tmp/x' > job` logs `name="job"`, with the directory on a separate CWD record that Sigma cannot join, and no path selection here can match it. Such a write is caught only by the fourth selection, which matches the audit `key` the watches below install and which rides on the SYSCALL record whatever form the path took — so it works only if those watches were loaded with that exact `-k cron` key. Two parts of the analytic cannot be expressed here. auditd emits PATH and SYSCALL as separate records for one event, and the writing process's `exe`, `uid` and `auid` live only on the SYSCALL side, so MITRE's `RunUser` knob ("only root may schedule jobs") cannot be applied inside this selection; and the analytic's second half — an uncommon binary later executing on the schedule, with MITRE's `ExecutionFrequency` knob thresholding how often — is a cross-event correlation Sigma has no way to state. The macOS arm AN0806 is not attempted, because its unifiedlog source has no standardised Sigma field names and inventing them would produce a rule that renders everywhere and matches nothing. Prerequisite: no distribution audits these paths by default, so this rule returns zero rows until watches such as `-w /var/spool/cron -p wa -k cron`, `-w /etc/crontab -p wa -k cron` and `-w /etc/cron.d -p wa -k cron` are loaded — and zero rows reads as quiet when it actually means blind. The `wa` permission also decides the noise floor: with it, only writes and attribute changes are recorded, whereas a watch that includes `r` makes every scan by the cron daemon itself match. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0290, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 3 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

Splunk · SPL

Run this as a search.

index=* ((type="PATH" AND name="*/var/spool/cron/*") OR (type="PATH" AND (name="*/etc/cron.d/*" OR name="*/etc/cron.hourly/*" OR name="*/etc/cron.daily/*" OR name="*/etc/cron.weekly/*" OR name="*/etc/cron.monthly/*")) OR (type="PATH" AND (name="*/etc/crontab" OR name="*/etc/anacrontab")) OR key="cron")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(type) == "path" AND TO_LOWER(name) LIKE "*/var/spool/cron/*") OR (TO_LOWER(type) == "path" AND (TO_LOWER(name) LIKE "*/etc/cron.d/*" OR TO_LOWER(name) LIKE "*/etc/cron.hourly/*" OR TO_LOWER(name) LIKE "*/etc/cron.daily/*" OR TO_LOWER(name) LIKE "*/etc/cron.weekly/*" OR TO_LOWER(name) LIKE "*/etc/cron.monthly/*")) OR (TO_LOWER(type) == "path" AND (TO_LOWER(name) LIKE "*/etc/crontab" OR TO_LOWER(name) LIKE "*/etc/anacrontab")) OR TO_LOWER(key) == "cron")

Wazuh · XML rule

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

<group name="sigma,linux,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 4 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="type" type="pcre2">(?i)^PATH$</field>    <field name="name" type="pcre2">(?i)/var/spool/cron/</field>    <description>Crontab file or cron drop-in directory written on Linux (1/4)</description>    <mitre>      <id>T1053.003</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="type" type="pcre2">(?i)^PATH$</field>    <field name="name" type="pcre2">(?i)(/etc/cron\.d/|/etc/cron\.hourly/|/etc/cron\.daily/|/etc/cron\.weekly/|/etc/cron\.monthly/)</field>    <description>Crontab file or cron drop-in directory written on Linux (2/4)</description>    <mitre>      <id>T1053.003</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="type" type="pcre2">(?i)^PATH$</field>    <field name="name" type="pcre2">(?i)(/etc/crontab$|/etc/anacrontab$)</field>    <description>Crontab file or cron drop-in directory written on Linux (3/4)</description>    <mitre>      <id>T1053.003</id>    </mitre>  </rule>   <rule id="100003" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="key" type="pcre2">(?i)^cron$</field>    <description>Crontab file or cron drop-in directory written on Linux (4/4)</description>    <mitre>      <id>T1053.003</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"product":"linux","service":"auditd"}), so there is nothing honest to query. Pick a logsource this translator maps, or write the KQL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: auditd / linux
Level: low
Category: persistence_scheduled_task
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: d1211ae7-280f-4182-9b93-c55ba2d668ba

ATT&CKT1053.003

T1053.003Cron

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.

Lessonpersistence scheduled task

persistence scheduled taskAI draft — unreviewed

01 · What this rule detects

The file-modification leg of AN0805: something writes to one of the stores cron reads its schedule from. The rule does not look at the job that later runs — it looks at the table being written. That covers the per-user spool under /var/spool/cron/, the system tables /etc/crontab and /etc/anacrontab, and the drop-in directories /etc/cron.d/ plus the hourly, daily, weekly and monthly run-parts folders. ESXi is one of the technique's platforms and uses the same /var/spool/cron/crontabs/root path, but it runs no auditd, so that arm is uncovered. The macOS arm, AN0806, is not attempted: its unifiedlog source has no standardised Sigma field names.

02 · Telemetry you need

product: linux, service: auditd, copied verbatim from AN0805 — and this is the prerequisite that decides whether the rule works at all. No distribution audits these paths by default. Until watches such as -w /var/spool/cron -p wa -k cron, -w /etc/crontab -p wa -k cron and -w /etc/cron.d -p wa -k cron are loaded, the rule returns zero rows, and zero rows reads as "quiet" when it means "blind". The wa permission set also sets the noise floor: writes and attribute changes only. Add r and every scan the cron daemon itself performs starts matching.

03 · How the logic works

Four selections, joined by 1 of selection*. Three match auditd PATH records by path — selection_spool on contains: '/var/spool/cron/', selection_dropin_dirs on the five drop-in directories, selection_system_tables on endswith for the two system tables. Substring matching rather than absolute paths is deliberate, because crontab -e writes a scratch file and renames it into the spool; the rename target is what appears. That does not rescue the relative case, and this is the rule's sharpest edge. auditd records name= exactly as it was handed to the syscall, so cd /etc/cron.d && echo '...' > job logs name="job" with the directory on a separate CWD record Sigma cannot join. No path selection can reach it. The fourth selection exists for precisely that: selection_watch_key matches key: 'cron' on the SYSCALL record, which carries the watch key whatever shape the path took — so it works only if the watches above were loaded with that exact -k cron key. The path list is MITRE's CronFilePath knob, populated here with the Debian and RHEL layouts; a distribution with its spool elsewhere needs its own entry. Two of MITRE's other knobs cannot be expressed. RunUser ("only root may schedule jobs") lives on the SYSCALL record alongside exe, uid and auid, not on the PATH record the path selections match. ExecutionFrequency thresholds how often the scheduled binary later runs — a cross-event correlation Sigma has no way to state.

04 · Common false positives

Very. Package management dominates: logrotate, man-db, sysstat, certbot and unattended-upgrades all ship schedules into /etc/cron.d or /etc/cron.daily, so every apt or dnf transaction writes several matching PATH records. Then configuration management — Ansible, Puppet, Chef and Salt rewrite the spool on every convergence run, changed or not — then agent installers and provisioning bursts. And crontab -e is separated from the technique only by who ran it. Hence low.

05 · Detection maturity

tier_1: , and it stays there until it has been run against real data. It is derived from a MITRE scaffold with no query logic and has never seen a log line; the relative-path gap above was found by reading, not by testing, and there may be more.
tier_2: load the watches, run read-only for a fortnight, rank hits by writing `exe`, and turn the top of that list into the suppression.
tier_3: ** alert on the correlation AN0805 actually describes — a table written, then an uncommon binary executing on that schedule.

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

Exclude by writing process, not by path — but that needs the SYSCALL record, so do it downstream where PATH and SYSCALL can be joined on the event id. Suppress dpkg, rpm, apt, and the config-management agents by exe, then apply MITRE's RunUser knob against auid to separate a real human from automation. Add distribution-specific spool paths to CronFilePath. Keep -p wa.

Declared by the author

Package installation, upgrade and removal. Distribution packages routinely ship their own schedule into /etc/cron.d or /etc/cron.daily — logrotate, mlocate/plocate, man-db, sysstat, certbot and unattended-upgrades among them — so every apt or dnf transaction on every host writes several matching PATH records. On a patched estate this is the highest-volume match by a wide margin and is why this rule is low rather than medium.
Configuration management convergence. The Ansible cron module, Puppet cron resources, Chef and Salt all rewrite /var/spool/cron/crontabs/<user> or drop a fragment into /etc/cron.d on every run, which on a half-hourly schedule means a match per managed host per run whether or not the content changed.
Agent and appliance installers. Backup, monitoring, vulnerability-scanning and antivirus packages install their own cron entry at setup and rewrite it at each version upgrade, under root, from a legitimate package manager.
A user or administrator running crontab -e to add, edit or remove a normal job, or reinstalling a saved table with crontab mytab. This is the everyday supported way to schedule work and is separated from the technique only by who did it and what the entry runs.
Host provisioning: cloud-init runcmd blocks, container image builds and golden-image bake scripts writing crontabs while the machine is being created, which produces a burst of matches on every new host.

Noise check0 of 5 fired

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

Share this rule

/u/siemphony/d1211ae7-280f-4182-9b93-c55ba2d668ba

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.

Crontab file or cron drop-in directory written on Linux

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it