Detecting Disabled or Modified Linux Audit System (T1685.004)

Disable or Modify Linux Audit System Log (T1685.004) is a sub-technique of Disable or Modify Tools. Adversaries disable or change the Linux Audit system to hide malicious activity. MITRE lists the Defense Impairment tactic and Linux as the platform.

Administrators use the Linux Audit system to track security-relevant events. It runs in the kernel and records process, network, file and login activity according to preconfigured rules. If those rules stop firing, an investigation loses its best source of host evidence.

How attackers use it

MITRE describes the pieces. The daemon that writes events to disk is auditd, governed by parameters in its configuration file. Log generation rules are set with the auditctl command line utility, and by the file /etc/audit/audit.rules, which holds a sequence of auditctl commands loaded at boot.

With root privileges, an adversary may keep activity out of the log in three ways:

• Disabling the Audit service, by killing the processes of the auditd daemon or by stopping the service with systemctl.
• Editing the configuration or rules files, such as /etc/audit/audit.rules, so that malicious activity is ignored.
• Hooking Audit system library functions to turn off logging.

MITRE's documented example is a backdoor that disables OpenSSH, systemd and the audit daemon while the backdoor is active.

An important limit applies. The adversary needs root to use this technique fully. That makes it a late-stage action: by the time it happens, other controls have already failed.

How to detect it

MITRE's detection strategy lists these observable signs:

• Process termination, such as auditd being killed.
• Service management, such as systemctl stop auditd.
• Changes to rule and configuration files, such as /etc/audit/audit.rules and the audit.conf file.
• A sudden absence of audit logs that lines up with a privileged command.

Because the audit system is what would normally record these actions, send events off the host as they are written. Events forwarded before the daemon stops still tell the story. Also watch for a host whose audit stream ends abruptly while the host itself stays up.

How to reduce the risk

MITRE lists two mitigations.

1. User Account Management. The adversary already needs root to use this fully, so limit users and accounts to the least privilege they require.
2. Audit. Routinely check account role permissions so that only expected users and roles can change logging settings.

MITRE adds a specific hardening step. To keep rules from being changed at runtime, add auditctl -e 2 as the last command in the audit rules file. In that mode, any attempt to change the configuration is audited and denied, and the configuration can only be changed by rebooting the machine.

Think about that trade-off before you apply it: a locked configuration also means that legitimate rule updates need a reboot. Plan a change window for it.

Check your own environment

These checks are read-only. Run them with sudo on a Linux host that uses auditd.

systemctl status auditd
sudo auditctl -s
sudo auditctl -l

The first shows whether the service is running. The second shows audit status, including whether logging is enabled and the lock state. The third lists the rules currently loaded. You can also look at the rules file:

sudo cat /etc/audit/audit.rules

Then check:

• Is the rule set the one you expect, and does it match what is in version control?
• Does the status output show the configuration as locked, as in auditctl -e 2 mode?
• Are audit events forwarded to a collector outside the host?
• Do you alert when auditd stops or its rules change?
• Who has root, and who has sudo rights for systemctl and auditctl?

Quick check

Sources

• MITRE ATT&CK, Disable or Modify Linux Audit System Log (T1685.004): https://attack.mitre.org/techniques/T1685/004