auditd Tampering

The Linux Audit framework (auditd plus the kernel's audit subsystem) is the primary source of syscall-level, tamper-evident logging on a Linux host — the same subsystem defenders rely on to catch ptrace attaches, unexpected execve calls, and writes to sensitive paths described throughout this catalog. An attacker who has gained enough privilege to matter can turn that same subsystem off, thin it out, or overwhelm it before doing anything else that would otherwise leave a clean audit trail — an "impair defenses" step that precedes, rather than follows, the actual intrusion activity.

How it works

The crudest form disables auditing outright:

auditctl -e 0            # disable the kernel audit system entirely
# or, more surgically:
auditctl -D               # delete all existing audit rules
systemctl stop auditd     # stop the daemon (if init policy allows it)

A quieter variant edits the rule set rather than stopping the daemon, so auditd keeps running (nothing looks obviously wrong in systemctl status) but no longer watches the paths or syscalls that would catch the attacker:

# remove the specific watch that would have caught this attacker's activity
auditctl -W /etc/passwd -p wa -k passwd_changes   # (attacker deletes this rule)
sed -i '/ptrace/d' /etc/audit/rules.d/audit.rules  # and edits the file so
                                                     # it stays gone on restart

A third approach floods the audit log with high-volume noise (rapid, repeated benign-looking events) to bury the handful of records that actually matter, without touching configuration at all — effective against manual review, less so against automated correlation.

Detection & analysis

Static analysis: In a script or binary, the presence of auditctl calls with -e 0, -D, or -W/-a deletions, or direct edits to /etc/audit/audit.rules / /etc/audit/rules.d/*.rules, is itself the indicator — legitimate software essentially never modifies host audit policy.

Dynamic analysis: The audit subsystem's own state changes are, tellingly, usually still logged right up to the moment of tampering: a CONFIG_CHANGE record showing rules deleted or auditing disabled is the direct signal, if it reaches storage before being suppressed. A gap in otherwise continuous audit log timestamps, or a service-manager record of auditd stopping/restarting outside a patch window, is the indirect one.

Detection rule hint: Ship audit logs to a remote, append-only collector in real time so local tampering cannot erase what was already sent off-host — this is the single most effective control against this technique, since everything else is detecting the tampering after the fact rather than preventing its effect. Alert immediately on any auditctl -e 0, auditctl -D, or write to the audit rules directory, and treat a gap in expected periodic audit events (rather than just an explicit disable record) as its own indicator, since a sufficiently privileged attacker may suppress the disable event too.