Disable or Modify Tools — Disable or Modify Linux Audit System
Adversaries may disable or modify the Linux audit system to hide malicious activity and avoid detection. Linux admins use the Linux Audit system to track security-relevant information on a system. The Linux Audit system operates at the kernel-level and maintains event logs on application and system activity such as process, network, file, and login events based on pre-configured rules. Often referred to as auditd, this is the name of the daemon used to write events to disk and is governed by the parameters set in the audit.conf configuration file. Two primary ways to configure the log generation rules are through the command line auditctl utility and the file /etc/audit/audit.rules. With root privileges, adversaries may disable the Audit system service, edit the configuration/rule files, or hook the Audit system library functions. This technique was used by the Ebury malware and the SkidMap cryptominer variant.
What is T1685.004 Disable or Modify Linux Audit System?
Disable or Modify Linux Audit System (T1685.004) is a sub-technique of Disable or Modify Tools (T1685) in the MITRE ATT&CK framework. It maps to the Defense Impairment tactic — the adversary is trying to break security mechanisms, pipelines, and tooling so defenders can’t see or trust what’s happening.
This page provides production-ready detection logic for Disable or Modify Linux Audit System, covering the data sources and telemetry it touches: Process: Process Creation, Command: Command Execution, File: File Modification, Application Log: Application Log Content. The queries below are rated high severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Defense Impairment
- Technique
- T1685 Disable or Modify Tools
- Sub-technique
- T1685.004 Disable or Modify Linux Audit System Log
- Canonical reference
- https://attack.mitre.org/techniques/T1685/004/
let AuditdTampering = dynamic([
"service auditd stop", "systemctl stop auditd",
"systemctl disable auditd", "service auditd disable",
"killall auditd", "kill -9", "pkill auditd",
"auditctl -e 0", "auditctl -D",
"auditctl -a never", "auditctl -a exclude"
]);
let AuditConfigFiles = dynamic([
"/etc/audit/auditd.conf", "/etc/audit/audit.rules",
"/etc/audit/rules.d/", "/etc/audisp/"
]);
union
(
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has_any (AuditdTampering)
| project TimeGenerated, Computer, HostName, Facility,
SeverityLevel, SyslogMessage,
DetectionType="AuditdServiceTampering"
),
(
DeviceProcessEvents
| where Timestamp > ago(24h)
| where ProcessCommandLine has_any (AuditdTampering)
| project Timestamp, DeviceName, AccountName, FileName,
ProcessCommandLine, InitiatingProcessFileName,
InitiatingProcessCommandLine,
DetectionType="AuditdProcessTampering"
),
(
DeviceFileEvents
| where Timestamp > ago(24h)
| where FolderPath has_any (AuditConfigFiles)
| where ActionType in ("FileModified", "FileDeleted", "FileCreated")
| project Timestamp, DeviceName, AccountName,
FileName, FolderPath, ActionType,
InitiatingProcessFileName, InitiatingProcessCommandLine,
DetectionType="AuditConfigModified"
)
| sort by TimeGenerated descDetects Linux audit system tampering through three vectors: (1) Process commands that stop, disable, or kill the auditd daemon or use auditctl to disable auditing (-e 0) or flush rules (-D); (2) Syslog messages indicating audit service manipulation; (3) File modifications to audit configuration files (/etc/audit/auditd.conf, /etc/audit/audit.rules, /etc/audit/rules.d/). Covers both direct service manipulation and configuration file tampering used by threats like Ebury and SkidMap.
Data Sources
Required Tables
False Positives
- System administrators performing legitimate auditd maintenance — restarting the service after updating audit rules (systemctl restart auditd is expected, but stop/disable is not)
- Configuration management tools (Ansible, Puppet, Chef) that deploy new audit.rules files and restart the service as part of regular security hardening
- OS package updates (apt/yum update audit) that modify auditd configuration files as part of the package upgrade process
- Security teams performing auditctl -l to list rules or auditctl -s to check status (note: these are read-only operations, not -e 0 or -D)
Sigma rule & cross-platform mapping
The detection logic for Disable or Modify Linux Audit System (T1685.004) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: process_creation
product: windowsBrowse the community-maintained Sigma rules for this technique:
Platform-specific guides for T1685.004
References (6)
- https://attack.mitre.org/techniques/T1685/004/
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/chap-system_auditing
- https://izyknows.medium.com/linux-auditd-for-threat-detection-d06c8b941505
- https://www.welivesecurity.com/2014/02/21/an-in-depth-analysis-of-linuxebury/
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1562.012/T1562.012.md
- https://man7.org/linux/man-pages/man8/auditctl.8.html
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1 Stop auditd Service via systemctl
Expected signal: Syslog entry for auditd service stopping. Systemd journal entry for the unit state change. If Sysmon for Linux is installed, a process creation event for systemctl with the 'stop auditd' arguments. The audit.log will show a final DAEMON_END event before stopping.
- Test 2 Disable Audit Subsystem via auditctl
Expected signal: The audit log will show an AUDIT_ENABLED record with enabled=0. A CONFIG_CHANGE event is generated immediately before auditing stops. Syslog may capture the auditctl process execution. After -e 0, NO further audit events will be generated until re-enabled.
- Test 3 Flush All Audit Rules via auditctl
Expected signal: The audit log will show a CONFIG_CHANGE event with op=remove_rule for each deleted rule. A final entry shows 'audit_enabled=1 ... rules=0' confirming all rules were flushed. The auditd service remains running (systemctl status auditd shows active).
- Test 4 Modify audit.rules Configuration File
Expected signal: File modification event for /etc/audit/audit.rules (Sysmon for Linux file create/modify or audit SYSCALL event for open/write on the file). Process creation events for cp, tee, and augenrules. CONFIG_CHANGE audit events when new (empty) rules are loaded.
Response Playbook
Triage
- Identify WHO ran the command — was it root directly, a sudo user, or a service account? Check the uid/auid fields in the audit record or the User field in the process event.
- Determine WHAT was done — is this a service stop (temporary), a service disable (persistent across reboots), a rule flush (auditctl -D removes all rules), or an audit disable (auditctl -e 0 turns off auditing entirely)?
- Check the context — was the audit modification preceded by a login event from an unusual source IP, an SSH session from an unexpected location, or a privilege escalation?
- Verify against change management — is there an approved change ticket for audit rule updates or system maintenance that would explain this action?
- Check if auditd is currently running — run 'systemctl status auditd' and 'auditctl -s' to determine the current audit state. If auditd is stopped and no admin claims responsibility, this is a critical finding.
- Look for what happened AFTER the audit was disabled — any commands or processes that executed between the audit disable and the current time are unmonitored and should be treated as potentially malicious.
Containment
- Immediately re-enable the audit system: 'systemctl start auditd && auditctl -e 1' to restore visibility.
- If audit rules were flushed (-D): reload the rules from the saved configuration: 'augenrules --load' or 'auditctl -R /etc/audit/audit.rules'.
- If the audit configuration files were modified: restore them from backup or configuration management (Ansible/Puppet) and restart auditd.
- If the acting user account appears compromised: lock the account ('passwd -l username'), kill their active sessions ('pkill -u username'), and rotate their SSH keys.
- If the system shows signs of rootkit activity (Ebury, SkidMap): isolate the host from the network and begin forensic imaging — do not trust the running OS.
- Add an immutable audit rule to prevent future tampering: 'auditctl -e 2' makes the audit configuration immutable until reboot (requires reboot to change).
Evidence Collection
- Audit log file: /var/log/audit/audit.log — review the last entries before the tampering to understand what the adversary wanted to hide.
- Auth log: /var/log/auth.log or /var/log/secure — SSH logins and sudo commands around the time of the audit tampering.
- Systemd journal: 'journalctl -u auditd --since "1 hour ago"' — service state change events with timestamps.
- Audit configuration: /etc/audit/auditd.conf and /etc/audit/audit.rules — capture current state and compare against known-good baseline.
- Process listing: capture the full process tree ('ps auxf') at the time of detection to identify any suspicious processes that may be running during the audit gap.
- File system timeline: use 'find / -newer /var/log/audit/audit.log -type f' to identify files created or modified after the last audit entry.
- Network connections: 'ss -tunap' to capture all current network connections and their associated processes.
Escalation Criteria
- ! auditctl -e 0 (audit completely disabled) — this is the most severe action as it blinds the kernel-level audit subsystem entirely.
- ! auditd service killed (kill -9) rather than stopped cleanly — indicates the adversary wanted immediate silence without graceful shutdown.
- ! Audit configuration files deleted or zeroed out — indicates intent to permanently remove audit capability, not just temporarily disable it.
- ! The tampering was preceded by an SSH login from an unusual IP or a privilege escalation exploit — indicates a compromised system with an active adversary.
- ! The tampering occurred on a system running sensitive workloads (database server, web server, CI/CD runner) where audit logs are a primary detection source.
- ! Evidence of LD_PRELOAD or library injection targeting audit libraries (libaudit) — indicates sophisticated Ebury-style audit hooking.
Investigation Guide
Forensic Artifacts
- >
File: /var/log/audit/audit.log — the primary audit log, check for gaps in event sequence numbers (ausearch -m CONFIG_CHANGE). - >
File: /etc/audit/auditd.conf — audit daemon configuration including log_file location, max_log_file_action, and space_left_action. - >
File: /etc/audit/audit.rules — persistent audit rules loaded at boot, check for unauthorized modifications or empty files. - >
File: /etc/audit/rules.d/*.rules — individual rule files that are compiled into audit.rules by augenrules. - >
Systemd: 'systemctl status auditd' — current service state, whether enabled/disabled, and recent log entries. - >
Kernel: 'auditctl -s' — current audit system state including enabled flag (0=disabled, 1=enabled, 2=immutable), failure flag, and PID. - >
LD_PRELOAD: check /etc/ld.so.preload and the LD_PRELOAD environment variable for injected libraries that may hook audit functions. - >
Process: 'ls -la /proc/*/exe 2>/dev/null | grep -i audit' — verify the running auditd binary matches the expected path and hash.
Tuning Guidance
The most important tuning step is to enable auditd immutable mode ('auditctl -e 2') on production systems — this prevents any runtime modification of audit rules until the next reboot, significantly raising the bar for adversaries. For the detection itself, exclude known configuration management processes (Ansible, Puppet, Chef, SaltStack) by their exact binary paths (not just names). Also exclude legitimate auditd maintenance patterns: 'systemctl restart auditd' is expected after rule changes, but 'systemctl stop auditd' without a subsequent start within 5 minutes is suspicious. Create a baseline of which accounts and automation tools normally modify audit configuration and alert on any deviation. For environments with frequent package updates, use a time-based suppression around maintenance windows but always log the events for retroactive hunting.
Hunting Queries
Hunt for auditd service disruption events over a 30-day period to establish baseline frequency and identify anomalies. A sudden spike in auditd stop events across multiple hosts may indicate automated malware (SkidMap, Ebury) propagating through the environment and disabling audit as part of its installation.
Syslog
| where TimeGenerated > ago(30d)
| where SyslogMessage has "auditd" and SyslogMessage has_any ("stop", "disable", "killed", "signal")
| summarize Count=count(), Hosts=make_set(Computer) by bin(TimeGenerated, 1d)
| sort by TimeGenerated ascindex=linux (sourcetype="syslog" OR sourcetype="linux_audit") "auditd" ("stop" OR "disable" OR "killed" OR "signal")
| bucket _time span=1d
| stats count as Count, values(host) as Hosts by _time
| sort _timeHunt for unexpected modifications to audit configuration files (/etc/audit/audit.rules, auditd.conf, rules.d/) by processes other than known configuration management tools. Legitimate changes come from augenrules, package managers, or configuration management — anything else modifying these files warrants investigation.
DeviceFileEvents
| where Timestamp > ago(7d)
| where FolderPath has_any ("/etc/audit/audit.rules", "/etc/audit/auditd.conf", "/etc/audit/rules.d/")
| where ActionType in ("FileModified", "FileDeleted")
| where InitiatingProcessFileName !in~ ("augenrules", "dpkg", "rpm", "yum", "apt", "puppet", "ansible", "chef-client")
| project Timestamp, DeviceName, AccountName, FolderPath, ActionType, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp descindex=linux sourcetype="linux_audit" type=PATH name="/etc/audit/*" (nametype="NORMAL" OR nametype="DELETE")
NOT (exe="/usr/sbin/augenrules" OR exe="/usr/bin/dpkg" OR exe="/usr/bin/rpm" OR exe="*puppet*" OR exe="*ansible*" OR exe="*chef*")
| table _time, host, uid, exe, name, nametype
| sort - _timeHunt for auditctl commands that disable or weaken the audit subsystem: -D (flush all rules), -e 0 (disable auditing), -a never (add never-audit rules), -a exclude (exclude event types). These commands are rarely used in normal operations and always warrant investigation when they appear outside of planned maintenance.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has "auditctl"
| where ProcessCommandLine has_any ("-D", "-e 0", "-a never", "-a exclude", "--reset")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp descindex=linux (sourcetype="linux_audit" OR sourcetype="syslog") "auditctl" ("-D" OR "-e 0" OR "-a never" OR "-a exclude" OR "--reset")
| table _time, host, user, msg
| sort - _timeAtomic Red Team Tests
Uses systemctl to stop the auditd service, immediately halting kernel-level audit logging. This is the most common method used by adversaries after gaining root access to blind security monitoring before conducting further malicious activity. Requires root/sudo privileges.
Command
sudo systemctl stop auditdCleanup
sudo systemctl start auditdExpected Telemetry
Syslog entry for auditd service stopping. Systemd journal entry for the unit state change. If Sysmon for Linux is installed, a process creation event for systemctl with the 'stop auditd' arguments. The audit.log will show a final DAEMON_END event before stopping.
Expected Detection
KQL: Syslog matches on 'systemctl stop auditd'. DeviceProcessEvents matches on ProcessCommandLine 'systemctl stop auditd'. SPL: IsServiceStop=1, SeverityScore=3.
Uses auditctl -e 0 to disable the kernel audit subsystem entirely. Unlike stopping the auditd service (which stops writing to disk but the kernel may still buffer events), -e 0 disables event generation at the kernel level. This is a more thorough audit evasion technique used by sophisticated adversaries.
Command
sudo auditctl -e 0Cleanup
sudo auditctl -e 1Expected Telemetry
The audit log will show an AUDIT_ENABLED record with enabled=0. A CONFIG_CHANGE event is generated immediately before auditing stops. Syslog may capture the auditctl process execution. After -e 0, NO further audit events will be generated until re-enabled.
Expected Detection
KQL: DeviceProcessEvents matches on 'auditctl -e 0'. SPL: IsAuditDisable=1, SeverityScore=3.
Uses auditctl -D to delete all currently loaded audit rules, effectively removing all file watches, system call monitoring, and custom audit rules. The auditd service remains running but is no longer monitoring anything meaningful. This technique preserves the appearance of a running audit service while eliminating its effectiveness.
Command
sudo auditctl -DCleanup
sudo augenrules --loadExpected Telemetry
The audit log will show a CONFIG_CHANGE event with op=remove_rule for each deleted rule. A final entry shows 'audit_enabled=1 ... rules=0' confirming all rules were flushed. The auditd service remains running (systemctl status auditd shows active).
Expected Detection
KQL: DeviceProcessEvents matches on 'auditctl -D'. SPL: IsRuleFlush=1, SeverityScore=2.
Backs up the existing audit rules file and replaces it with an empty configuration, then reloads the rules. This simulates an adversary permanently weakening the audit configuration so that it persists across auditd restarts. The cleanup restores the original rules.
Command
sudo cp /etc/audit/audit.rules /tmp/audit.rules.bak && echo '# emptied by adversary' | sudo tee /etc/audit/audit.rules > /dev/null && sudo augenrules --loadCleanup
sudo cp /tmp/audit.rules.bak /etc/audit/audit.rules && sudo augenrules --load && rm /tmp/audit.rules.bakExpected Telemetry
File modification event for /etc/audit/audit.rules (Sysmon for Linux file create/modify or audit SYSCALL event for open/write on the file). Process creation events for cp, tee, and augenrules. CONFIG_CHANGE audit events when new (empty) rules are loaded.
Expected Detection
KQL: DeviceFileEvents matches on FolderPath containing '/etc/audit/audit.rules' with ActionType=FileModified. SPL: IsConfigTamper=1, SeverityScore=2.