Linux Audit system disabled, purged or its config files tampered with

Siemphony@siemphonylowT1685.004unverified

AN0171 names three mechanisms — killing the auditd process, stopping it as a service, and editing/deleting its rule and config files — plus the `auditctl` command line the technique's own description calls out as one of "two primary ways to configure the log generation rules". This rule covers all four as single-event auditd EXECVE or PATH records on the same `product: linux, service: auditd` logsource the brief maps every non-syslog log source in AN0171 onto; the correlation AN0171 also asks for — suspicious commands, file writes and a resulting gap in audit logging inside its `TimeWindow` knob — is not expressible in lib/sigma and is not attempted. The first group matches `auditctl -D` (delete all loaded rules) or `auditctl -e 0` (turn auditing off at runtime) — the two invocations that neutralise the running ruleset without touching a file. Both are pinned to the flag appearing first (a1, with `0` at a2 for the second form), which is how these commands are documented and almost always run; a build with another option ahead of `-D` or `-e` — `auditctl -q -D`, say — is missed by this selection. The second and third groups are two fixed-order selections rather than one selection OR-ing the verb and the target across several argument positions: `systemctl stop|disable|mask auditd` (verb at a1, target at a2) and `service auditd stop|disable|mask` (target at a1, verb at a2), which is the documented argument order for each command and covers the ordinary invocation of both. On most current distributions the auditd unit ships `RefuseManualStop=yes`, so a `systemctl stop auditd` from a shell is refused by systemd at the unit level — but the execve of `systemctl stop auditd` still happens and still lands in this selection, which is why the attempt is matched rather than an assumption that it succeeded. Flags ahead of the verb, `systemctl --user stop auditd` for instance, shift the target out of a2 and are missed, the same positional trade-off made for the auditctl group and made everywhere else in this rule: each cross-field OR that the Sigma logic could otherwise use to absorb argument-order variance costs the Wazuh translator a multiplying number of expanded `<rule>` blocks, and this rule is written to stay under that ceiling rather than refuse Wazuh outright, at the cost of the flagged and reordered forms of every command it matches. The fourth group matches `pkill auditd` and `killall auditd`, the two invocations that reference the daemon by name at a1; `pkill -9 auditd`, with the target pushed to a2, is missed for the same reason. A bare `kill -9 <pid>` cannot be matched at all, because the EXECVE record's arguments carry only the numeric pid and nothing ties that number back to auditd without a live process table this rule has no access to — the second log source in the brief ("kill syscalls targeting auditd process") describes exactly this case and is the reason it is listed as a log source MITRE named but this rule cannot cover. The fifth group matches PATH records naming `/etc/audit/audit.rules`, `/etc/audit/audit.conf`, or the `/etc/audit/rules.d/` drop-in directory that `augenrules` compiles into audit.rules on RHEL-family systems; the drop-in directory is an addition beyond the two files MITRE's `FilePathScope` knob names explicitly, added here because it is the only place these rules actually live on any system using augenrules. As with other PATH-based rules in this corpus, auditd records `name=` exactly as handed to the syscall, so an edit made from inside `/etc/audit/` logs a bare filename with the directory only on a CWD record Sigma cannot join, and a relative-path edit from that working directory is missed by this selection. There is a sharper version of the usual blind-prerequisite problem here: this technique's entire premise is removing the very rules that would detect it, so a `-D` that succeeds deletes the exec-watch rule this detection depends on along with everything else — the kernel evaluates rules at syscall entry, so the `auditctl -D` invocation itself should still be logged before its own deletion takes effect, but nothing after it will be, and MITRE's correlation-based observation of "a gap in audit logs following privileged execution" is precisely the signal this rule cannot produce. As with every other auditd-sourced rule in this corpus, none of these watches exist by default; execve is not audited without `-a always,exit -F arch=b64 -S execve -k exec` (plus its b32 twin), and the file group returns nothing until `/etc/audit/audit.rules` and `/etc/audit/audit.conf` are separately watched with `-p wa`. A watch on `/etc/audit/` does not extend to the `/etc/audit/rules.d/` leg above: `auditctl -w` directory watches are documented as non-recursive — they cover only the entries directly inside the watched directory, not files inside a subdirectory of it — so `/etc/audit/rules.d/` needs its own `-w /etc/audit/rules.d/ -p wa` watch or that leg never fires no matter how the parent directory is configured. Zero rows from any group reads as quiet when it means blind, and here specifically it can mean the attack already succeeded. The fourth log source in AN0171 — `linux:syslog::auditd service stopped or disabled` — is a different logsource block (`product: linux, service: syslog`) and is not attempted here; a rule copying that logsource verbatim would need its own selectors in syslog's field vocabulary and is out of scope for this file. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0062, 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="EXECVE" AND a0="*auditctl") AND (a1="-D" OR (a1="-e" AND a2="0"))) OR (type="EXECVE" AND a0="*systemctl" AND (a1="*stop*" OR a1="*disable*" OR a1="*mask*") AND a2="*auditd*")) OR (type="EXECVE" AND a0="*service" AND a1="*auditd*" AND (a2="*stop*" OR a2="*disable*" OR a2="*mask*"))) OR (type="EXECVE" AND (a0="*pkill" OR a0="*killall") AND a1="*auditd*")) OR (type="PATH" AND (name="*/etc/audit/audit.rules*" OR name="*/etc/audit/audit.conf*" OR name="*/etc/audit/rules.d/*")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((((((TO_LOWER(type) == "execve" AND TO_LOWER(a0) LIKE "*auditctl") AND (TO_LOWER(a1) == "-d" OR (TO_LOWER(a1) == "-e" AND TO_LOWER(a2) == "0"))) OR (TO_LOWER(type) == "execve" AND TO_LOWER(a0) LIKE "*systemctl" AND (TO_LOWER(a1) LIKE "*stop*" OR TO_LOWER(a1) LIKE "*disable*" OR TO_LOWER(a1) LIKE "*mask*") AND TO_LOWER(a2) LIKE "*auditd*")) OR (TO_LOWER(type) == "execve" AND TO_LOWER(a0) LIKE "*service" AND TO_LOWER(a1) LIKE "*auditd*" AND (TO_LOWER(a2) LIKE "*stop*" OR TO_LOWER(a2) LIKE "*disable*" OR TO_LOWER(a2) LIKE "*mask*"))) OR (TO_LOWER(type) == "execve" AND (TO_LOWER(a0) LIKE "*pkill" OR TO_LOWER(a0) LIKE "*killall") AND TO_LOWER(a1) LIKE "*auditd*")) OR (TO_LOWER(type) == "path" AND (TO_LOWER(name) LIKE "*/etc/audit/audit.rules*" OR TO_LOWER(name) LIKE "*/etc/audit/audit.conf*" OR TO_LOWER(name) LIKE "*/etc/audit/rules.d/*")))

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. -->  <!-- 6 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)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)auditctl$</field>    <field name="a1" type="pcre2">(?i)^-D$</field>    <description>Linux Audit system disabled, purged or its config files tampered with (1/6)</description>    <mitre>      <id>T1685.004</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)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)auditctl$</field>    <field name="a1" type="pcre2">(?i)^-e$</field>    <field name="a2" type="pcre2">(?i)^0$</field>    <description>Linux Audit system disabled, purged or its config files tampered with (2/6)</description>    <mitre>      <id>T1685.004</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)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)systemctl$</field>    <field name="a1" type="pcre2">(?i)(stop|disable|mask)</field>    <field name="a2" type="pcre2">(?i)auditd</field>    <description>Linux Audit system disabled, purged or its config files tampered with (3/6)</description>    <mitre>      <id>T1685.004</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="type" type="pcre2">(?i)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)service$</field>    <field name="a1" type="pcre2">(?i)auditd</field>    <field name="a2" type="pcre2">(?i)(stop|disable|mask)</field>    <description>Linux Audit system disabled, purged or its config files tampered with (4/6)</description>    <mitre>      <id>T1685.004</id>    </mitre>  </rule>   <rule id="100004" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^EXECVE$</field>    <field name="a0" type="pcre2">(?i)(pkill$|killall$)</field>    <field name="a1" type="pcre2">(?i)auditd</field>    <description>Linux Audit system disabled, purged or its config files tampered with (5/6)</description>    <mitre>      <id>T1685.004</id>    </mitre>  </rule>   <rule id="100005" 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/audit/audit\.rules|/etc/audit/audit\.conf|/etc/audit/rules\.d/)</field>    <description>Linux Audit system disabled, purged or its config files tampered with (6/6)</description>    <mitre>      <id>T1685.004</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: 96f32db9-8406-4a95-be55-a0e14b0b006c

ATT&CKT1685.004

T1685.004Disable or Modify Linux Audit System Log

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

AN0171 describes an attacker with root killing auditd, stopping it as a service, or tampering with its rule/config files. This rule covers four of those mechanisms as single-event auditd EXECVE/PATH records: auditctl -D or auditctl -e 0 neutralising the running ruleset without touching a file; systemctl stop|disable|mask auditd and the equivalent service auditd stop|disable|mask; pkill auditd/killall auditd killing the daemon by name; and edits or deletes to /etc/audit/audit.rules, /etc/audit/audit.conf, or the /etc/audit/rules.d/ drop-in directory. A bare kill -9 <pid> is declined outright — the EXECVE record carries only a numeric pid with nothing to tie it to auditd without a live process table this rule cannot access. The brief's fourth log source, auditd stopping as seen through syslog, uses a different logsource block (service: syslog) and is out of scope here.

02 · Telemetry you need

Everything comes from product: linux, service: auditd. None of these watches exist by default. execve isn't audited without -a always,exit -F arch=b64 -S execve -k exec (plus its b32 twin), and the file-tamper leg returns nothing until /etc/audit/audit.rules and /etc/audit/audit.conf are separately watched with -p wa. Critically, auditctl -w watches are non-recursive: a watch on /etc/audit/ does not cover /etc/audit/rules.d/, so that directory needs its own -w /etc/audit/rules.d/ -p wa rule or the drop-in leg — the pipeline's own addition beyond MITRE's two named files, since it's where augenrules compiles rules from on RHEL-family systems — never fires.

03 · How the logic works

The condition is (auditctl_exec and (delete_flag or disable_flag)) or systemctl_stop or service_stop or kill_direct or file_tamper. Each command group pins its verb/target to fixed argument positions (a0, a1, a2) rather than OR-ing across positions, because every cross-field OR multiplies the Wazuh translator's expanded <rule> blocks — this rule stays inside that ceiling at the cost of missing reordered invocations (systemctl --user stop auditd, pkill -9 auditd). systemctl and service get separate selections because the two commands put verb and target in opposite argument order. Note that most current distributions ship RefuseManualStop=yes on the auditd unit, so systemctl stop auditd is often refused at the unit level — but the execve itself still lands in this selection, so the attempt is still matched. There's a sharper version of the usual blind-prerequisite problem here too: a successful auditctl -D deletes the very exec-watch rule this detection depends on, so nothing logged after that point can be trusted to still be covered.

04 · Common false positives

Four false positives, all named in the rule: augenrules --load — which every normal auditd service start or restart runs, and which begins with its own auditctl -D — makes the delete-flag leg the loudest match by a wide margin on any host that boots or reloads normally, which is why level is set to low rather than medium. Configuration-management convergence (Ansible, Puppet, Salt) rewriting rules.d or audit.rules and restarting the service fires both the file-tamper and service-stop legs on every managed host, every run. Package upgrades of audit/audit-libs restart the daemon and can rewrite audit.conf via postinst scripts. An admin running auditctl -e 0 to rule out audit overhead during troubleshooting is indistinguishable from the technique on command evidence alone.

05 · Detection maturity

tier_1: This rule has never been run against a log line and sits at the lowest DeBMM tier by definition — a syntactically valid, four-backend-renderable scaffold, not a validated detection. It stays there until it's been executed against real auditd output and its false-positive claims checked against actual match volume.

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

MITRE's ServiceWhitelist knob is the first lever — populate it with your CM tool's process identity or argv pattern so its convergence runs don't trip selection_systemctl_stop/selection_service_stop. MITRE's FilePathScope knob names only the two config files; this rule extends it to rules.d/ because that's structurally where rules live under augenrules, so tune scope further only if your fleet stores rules elsewhere. MITRE's TimeWindow knob — correlating command, file write, and a subsequent logging gap — isn't expressible in lib/sigma and isn't attempted; a human analyst has to supply that correlation manually until the pipeline can.

Declared by the author

augenrules --load, which every RHEL-family auditd service start or restart runs as its rule-loading step, and which begins by issuing auditctl -D to clear the running ruleset before reapplying the compiled rules.d contents — this makes the auditctl -D leg the loudest match by a wide margin on any host that boots normally or has its rules refreshed, and is why the level here is low rather than medium.
Configuration management convergence (Ansible, Puppet, Chef, Salt) applying an audit policy module, which typically rewrites /etc/audit/rules.d/*.rules or /etc/audit/audit.rules and then restarts or reloads the service to apply it, producing both a file-tamper and a service-stop match on every managed host on every run.
The audit package's own postinst/postrm scripts during an apt or dnf upgrade of the audit or audit-libs package, which stop and restart the auditd service and may rewrite audit.conf to a new packaged default as part of the upgrade.
An administrator temporarily disabling auditing with auditctl -e 0 to rule out audit overhead while diagnosing a performance issue, then re-enabling it — a legitimate, if risky, troubleshooting step that is indistinguishable from the technique on command evidence 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.004, evaluated against their — events.

Share this rule

/u/siemphony/96f32db9-8406-4a95-be55-a0e14b0b006c

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.

Linux Audit system disabled, purged or its config files tampered with

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it