Skip to content

Siemphony is in beta and still being built. How a rule earns its badge.

Siemphony’s repertoire

Deletion of a Linux system log file recorded by auditd

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 detection

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

title: Deletion of a Linux system log file recorded by auditdid: fba96e68-528a-49df-9b82-c26eb2399858status: experimentaldescription: |  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.references:  - https://attack.mitre.org/techniques/T1685/006  - https://attack.mitre.org/detectionstrategies/DET0520author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)date: 2026-08-18tags:  - attack.defense-evasion  - attack.t1685.006logsource:  product: linux  service: auditddetection:  selection_log_deleted:    type: 'PATH'    nametype: 'DELETE'    name|contains:      - '/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/'  selection_watch_key:    key: 'log_tamper'  condition: 1 of selection*falsepositives:  - "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."level: low

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.

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Log in to react
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.

Log in to report a verdict.

Log in to join the discussion.

No comments yet. Someone who deploys this will have something to say about it.