Deletion of a Linux system log file recorded by auditd

Siemphony@siemphonylowT1685.006unverified

AN1438 asks for "anomalous deletions or truncations of system logs" correlated with the command that caused them. That correlation is out of reach — auditd splits one event across a SYSCALL record, carrying the exe, uid and command, and a PATH record, carrying the filename and how it was touched, and lib/sigma has no join across them — so this rule keeps only the file-side half, on the one PATH field that says what actually happened to the name: `nametype`. A value of `DELETE` means the path was unlinked, which is what `rm`, `shred -u` and a rotate-then-remove sequence all produce on the log file itself. It is deliberately not the whole of AN1438: `echo > /var/log/auth.log`, `truncate -s 0` and `cat /dev/null >` all clear a log's contents through `open(O_TRUNC)` without unlinking the path, so `nametype` stays `NORMAL` for every one of them and this selector is blind to the method MITRE's own citation (Linux Logs) implies is the more common one. The path list is the seven files and one directory the technique's own description names verbatim — /var/log/messages, /var/log/secure, /var/log/auth.log, /var/log/utmp, /var/log/wtmp, /var/log/kern.log, /var/log/cron.log, /var/log/maillog and /var/log/httpd/ — not MITRE's LogFilePathPattern knob restated, since the brief gives no regex, only this prose list. A second selector, `key: 'log_tamper'`, is this pipeline's own suggested audit-key convention, offered as a second path to the same event for a deployment whose watch tags truncating syscalls (`truncate`, `ftruncate`, `unlink`, `unlinkat`, `rename`, `renameat`) under that name instead of relying on `nametype` alone; MITRE supplies the knob's intent, the key string is this pipeline's, not MITRE's. UserContext (higher severity for root) cannot be applied inside a PATH selection: uid and auid live only on the SYSCALL record. AN1439, the macOS arm, is not attempted: its one logsource, {product: macos, service: unifiedlog}, has no standardised Sigma field vocabulary anywhere in this corpus, the same ground T1546.004 and T1027.011 already declined their macOS legs on — inventing field names for it would parse in four backends and match nothing. Prerequisite: auditd watches none of these paths by default. Both selectors need an explicit watch loaded first, for example `-w /var/log/auth.log -p wa -k log_tamper` repeated per path above (and per distribution equivalent — RHEL-family hosts use /var/log/secure where Debian-family hosts use /var/log/auth.log), and zero rows without it reads as quiet when it actually means blind. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0520, 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 nametype="DELETE" AND (name="*/var/log/messages*" OR name="*/var/log/secure*" OR name="*/var/log/auth.log*" OR name="*/var/log/utmp*" OR name="*/var/log/wtmp*" OR name="*/var/log/kern.log*" OR name="*/var/log/cron.log*" OR name="*/var/log/maillog*" OR name="*/var/log/httpd/*")) OR key="log_tamper")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(type) == "path" AND TO_LOWER(nametype) == "delete" AND (TO_LOWER(name) LIKE "*/var/log/messages*" OR TO_LOWER(name) LIKE "*/var/log/secure*" OR TO_LOWER(name) LIKE "*/var/log/auth.log*" OR TO_LOWER(name) LIKE "*/var/log/utmp*" OR TO_LOWER(name) LIKE "*/var/log/wtmp*" OR TO_LOWER(name) LIKE "*/var/log/kern.log*" OR TO_LOWER(name) LIKE "*/var/log/cron.log*" OR TO_LOWER(name) LIKE "*/var/log/maillog*" OR TO_LOWER(name) LIKE "*/var/log/httpd/*")) OR TO_LOWER(key) == "log_tamper")

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. -->  <!-- 2 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="nametype" type="pcre2">(?i)^DELETE$</field>    <field name="name" type="pcre2">(?i)(/var/log/messages|/var/log/secure|/var/log/auth\.log|/var/log/utmp|/var/log/wtmp|/var/log/kern\.log|/var/log/cron\.log|/var/log/maillog|/var/log/httpd/)</field>    <description>Deletion of a Linux system log file recorded by auditd (1/2)</description>    <mitre>      <id>T1685.006</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="key" type="pcre2">(?i)^log_tamper$</field>    <description>Deletion of a Linux system log file recorded by auditd (2/2)</description>    <mitre>      <id>T1685.006</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: defense_evasion_clear_logs
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: fba96e68-528a-49df-9b82-c26eb2399858

ATT&CKT1685.006

T1685.006Clear Linux or Mac System Logs

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.

Lessondefense evasion clear logs

defense evasion clear logsAI draft — unreviewed

01 · What this rule detects

Deletion (unlink) of one of eight canonical Linux system log paths, seen through auditd PATH records with nametype: DELETE — or, on a properly scoped watch, any file event tagged with the audit key log_tamper. AN1438 asks for anomalous deletion or truncation of system logs correlated with the process that caused it; this rule keeps only the file-side half of that.

02 · Telemetry you need

linux/auditd, with explicit watches loaded — none of the eight paths is watched by default. Each needs something like -w /var/log/auth.log -p wa -k log_tamper (repeated per path, and per distro: RHEL-family hosts use /var/log/secure where Debian-family hosts use /var/log/auth.log). Zero rows without these watches means blind, not quiet.

03 · How the logic works

Two selectors, ORed as 1 of selection*. selection_log_deleted requires type: PATH, nametype: DELETE, and a name containing one of the eight paths the technique's own prose names verbatim — not MITRE's LogFilePathPattern knob restated, since the brief supplies no regex, only this list. selection_watch_key matches on key: log_tamper, this pipeline's own suggested audit-key convention, offered as an alternate path to the same event class for a deployment whose watch tags truncating syscalls (truncate, ftruncate, unlink, rename) under that name. Both selectors are deliberately blind to O_TRUNC-based clearing — echo > /var/log/auth.log, truncate -s 0, cat /dev/null > — because nametype stays NORMAL for all three, even though MITRE's own citation implies truncation is the more common method in practice. UserContext (elevated severity for root) cannot be applied either: uid/auid live on the separate SYSCALL record, and auditd's PATH/SYSCALL split has no join construct in lib/sigma.

04 · Common false positives

The reviewer flagged that selection_watch_key carries no type constraint of its own — the selector's precision is entirely a function of how the watch was loaded. -p wa keeps it to writes and attribute changes; a deployment that reuses the key on a broader -p rwxa watch will fire this defense-evasion rule on ordinary reads.
The bigger source is logrotate. Its stock nightly rotation of every path in this list — auth.log/secure, messages, maillog, cron.log — is, by the rule's own false-positive list, "the loudest source here by a wide margin": the rename-and-recreate sequence is exactly the unlink the nametype: DELETE selector is built to catch, and it runs on essentially every mainstream distro's default config, typically via a cron or systemd-timer job between roughly 00:00 and 06:30. Also expected: Apache's own rotatelogs/cronolog cycling of /var/log/httpd/; a syslog package's install, removal or reinstall maintainer scripts touching these same default paths; and an administrator's own incident remediation — manually clearing a runaway auth.log — which is indistinguishable from the technique by this rule alone.

05 · Detection maturity

tier_1: . UNVERIFIED — derived from DET0520 and never executed against a log line. level: low matches a false-positive list whose top entry is near-constant nightly noise; treat any match as a candidate to triage against the logrotate schedule, not a confirmed tampering signal, until this rule has been run against real auditd output.

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 the logrotate window first; it is predictable and by far the dominant source, so a cron-window suppression removes most of the noise without touching the path list. Confirm any deployed watch is loaded at -p wa, not a broader permission set, so the key-based selector keeps the scope its own description assumes. Correlate matches against package-manager activity to drop syslog reinstall noise. A second rule (or a future SYSCALL-side correlation) would be needed to catch O_TRUNC clearing, since this rule cannot see that method at all.

Declared by the author

logrotate's default nightly rotation of every path in this list — auth.log/secure, messages, maillog and cron.log all get renamed and recreated on essentially every mainstream distribution's stock logrotate.d config, which is exactly the unlink-and-recreate sequence the nametype=DELETE selector is built to catch, and is the loudest source here by a wide margin.
Apache's own log rotation for /var/log/httpd/ — a piped rotatelogs or cronolog target recreates the access and error log on its own internal schedule independent of logrotate, on any moderately busy web server.
Package installation, removal or reinstallation of a syslog implementation such as rsyslog or sysklogd, whose postinst and prerm maintainer scripts create or truncate these exact default log files as part of setup and teardown.
An administrator's own disk-space remediation during an incident — manually clearing a runaway auth.log or maillog with a redirect or truncate — which is the same operator-driven event the key-based selector is meant to catch and is indistinguishable from the technique by this rule alone.

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 T1685.006, evaluated against their — events.

Share this rule

/u/siemphony/fba96e68-528a-49df-9b82-c26eb2399858

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.

Deletion of a Linux system log file recorded by auditd

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it