Audit daemon stopped
The Linux audit daemon reported that it was terminating or aborting.
What it detects
The Linux audit daemon reported that it was terminating or aborting. This is the audit log's last word about itself: after a DAEMON_END the host records nothing, so an attacker who stops auditd buys silence for everything that follows.
It is worth alerting on precisely because the evidence is self-limiting. The gap in the timeline after this event is not the absence of activity, it is the absence of recording, and an analyst reading the case needs to know which of the two they are looking at. DAEMON_ABORT is the same outcome arrived at by failure rather than by instruction — auditd dying because it could not write, or because its configuration was changed underneath it.
MITRE ATT&CK mapping
False positives and triage
auditd stops for ordinary reasons: a clean shutdown or reboot, a package upgrade of the audit package, or an augenrules --load that restarts the daemon to pick up new rules. Each of those has a signature you can check:
* A shutdown ends the log entirely and the next records are a fresh boot. * An upgrade is bracketed by package-manager activity and a prompt restart. * A rule reload restarts within seconds and the following records keep flowing.
What none of them look like is a stop in the middle of a working day with no restart, no reboot, and no package transaction — and especially one preceded by activity from a session that had no business touching the audit configuration.
DAEMON_ABORT with res=failed also fires on genuine local faults: a full disk on /var/log, or a misconfigured rule file. Those are operational problems rather than attacks, but they leave the host equally unmonitored, so they still deserve a look.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 60%. Source: rules/linux/audit_daemon_stopped.yaml, licensed under the Apache License 2.0.
id: linux.defense_evasion.audit_daemon_stopped
version: 1.0.0
status: stable
severity: high
confidence: 0.6
platforms: [linux]
mitre_techniques: [T1562.012, T1562.001]
description: |
The Linux audit daemon reported that it was terminating or aborting. This is the
audit log's last word about itself: after a DAEMON_END the host records nothing,
so an attacker who stops auditd buys silence for everything that follows.
It is worth alerting on precisely because the evidence is self-limiting. The gap in
the timeline after this event is not the absence of activity, it is the absence of
recording, and an analyst reading the case needs to know which of the two they are
looking at. DAEMON_ABORT is the same outcome arrived at by failure rather than by
instruction — auditd dying because it could not write, or because its
configuration was changed underneath it.
match:
event_action: audit_daemon_stop
false_positive_guidance: |
auditd stops for ordinary reasons: a clean shutdown or reboot, a package upgrade of
the audit package, or an `augenrules --load` that restarts the daemon to pick up
new rules. Each of those has a signature you can check:
* A shutdown ends the log entirely and the next records are a fresh boot.
* An upgrade is bracketed by package-manager activity and a prompt restart.
* A rule reload restarts within seconds and the following records keep flowing.
What none of them look like is a stop in the middle of a working day with no
restart, no reboot, and no package transaction — and especially one preceded by
activity from a session that had no business touching the audit configuration.
DAEMON_ABORT with `res=failed` also fires on genuine local faults: a full disk on
/var/log, or a misconfigured rule file. Those are operational problems rather than
attacks, but they leave the host equally unmonitored, so they still deserve a look.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.