Disable or Modify Tools — Clear Linux or Mac System Logs
Adversaries clear system logs on Linux and macOS to remove evidence of intrusion. Primary targets include /var/log/auth.log or /var/log/secure (authentication), /var/log/syslog or /var/log/messages (general), /var/log/wtmp and /var/log/btmp (login records), and web server logs (/var/log/apache2/, /var/log/nginx/). Common methods include truncating files (echo > /var/log/auth.log), deletion (rm /var/log/*.log), or overwriting with zeros. TeamTNT (crypto-mining), Rocke, Sea Turtle (DNS hijacking), Salt Typhoon (telecom espionage), UPSTYLE (Volt Typhoon PANW exploit), and MacMa (macOS) have all cleared Linux/macOS logs post-compromise.
What is T1685.006 Clear Linux or Mac System Logs?
Clear Linux or Mac System Logs (T1685.006) 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 Clear Linux or Mac System Logs, covering the data sources and telemetry it touches: File: File Deletion, File: File Modification, Microsoft Defender for Endpoint (Linux/macOS). 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.006 Clear Linux or Mac System Logs
- Canonical reference
- https://attack.mitre.org/techniques/T1685/006/
DeviceFileEvents
| where Timestamp > ago(24h)
| where ActionType in ("FileDeleted", "FileModified", "FileTruncated")
| where FolderPath startswith "/var/log/" or FolderPath startswith "/Library/Logs/" or FolderPath startswith "/private/var/log/"
| where FileName endswith ".log" or FileName in~ ("auth.log", "syslog", "messages", "secure", "wtmp", "btmp", "lastlog", "kern.log")
| where not(InitiatingProcessFileName in~ ("logrotate", "newsyslog", "rsyslog", "syslogd"))
| project Timestamp, DeviceName, AccountName=InitiatingProcessAccountName,
ActionType, FileName, FolderPath, InitiatingProcessFileName,
InitiatingProcessCommandLine
| sort by Timestamp desc Detects modification or deletion of Linux/macOS system log files in /var/log/ and macOS Library/Logs. Excludes legitimate log rotation tools (logrotate, newsyslog, rsyslog) to reduce false positives. The ActionType FileTruncated specifically catches the 'echo > /var/log/auth.log' truncation technique. Covers authentication logs, syslog, kernel logs, and login tracking files (wtmp, btmp, lastlog).
Data Sources
Required Tables
False Positives
- Logrotate and newsyslog performing scheduled log rotation — though they archive rather than delete
- System administrators manually clearing logs after legitimate troubleshooting
- Docker container cleanup processes removing application logs
- Some security tools that manage their own log files in /var/log directories
Sigma rule & cross-platform mapping
The detection logic for Clear Linux or Mac System Logs (T1685.006) 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:
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for T1685.006
Testing Methodology
Validate this detection against 3 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 Clear Linux Auth Log via Truncation
Expected signal: auditd: SYSCALL records showing open with O_TRUNC flag on /var/log/auth.log. File modification event captured by endpoint telemetry. rsyslog may log a restart after the file is truncated if it monitors file size.
- Test 2 Delete /var/log Files Using rm
Expected signal: auditd: SYSCALL records for creat/open (file creation) and unlink (file deletion). File creation and deletion events in endpoint telemetry. The file creation followed immediately by deletion pattern is anomalous.
- Test 3 Clear Login History via wtmp Manipulation
Expected signal: auditd: SYSCALL for open with O_TRUNC on /var/log/wtmp. Any process monitoring wtmp (e.g., login daemons) may detect the size change. File modification event in endpoint telemetry for wtmp.
Response Playbook
Triage
- Identify which log files were cleared: check inode modification timestamps (stat /var/log/auth.log) and compare to expected last rotation time
- If wtmp/btmp were zeroed: 'last' and 'lastb' commands will show empty or truncated history — cross-reference with SSH daemon logs forwarded to SIEM
- Check auditd logs for the clearing: ausearch -f /var/log/auth.log or ausearch -i -m PATH -f auth.log to find who accessed the file
- Review previous log rotation archives (/var/log/auth.log.1, auth.log.2.gz) — if these were left intact, the attack may have only cleared the current file
- Check /proc/<pid>/fd entries or /proc/<pid>/maps for any processes that had the log files open at time of deletion (deleted files remain accessible via /proc while open)
- Review SIEM for any events forwarded before the clearing — the gap in the SIEM timeline identifies when the attack occurred
Containment
- If active intrusion is ongoing: isolate the host before taking any other action
- Restart the logging daemon to recreate cleared log files: systemctl restart rsyslog auditd
- Check /etc/cron.d and cron.daily for any added scripts that continue to clear logs on a schedule
- Verify log forwarding agents (rsyslog, filebeat, fluentd) are still running and configured to forward to SIEM
Evidence Collection
- auditd logs: ausearch -i -m PATH -ts today | grep '/var/log' — shows all file operations on logs
- Shell history: /root/.bash_history, /home/<user>/.bash_history — may contain rm/truncate/echo commands if not also cleared
- Syslog: journal logs if using systemd (journalctl -n 1000 --no-pager) — journald stores logs separately from syslog files
- Filesystem metadata: use 'debugfs' or 'ext4magic' on the log filesystem to recover recently-deleted files
- Process accounting: if psacct/acct is enabled, /var/account/pacct records all executed commands
- SIEM: forwarded log entries showing the last few minutes before the gap reveal the attacker's actions
Escalation Criteria
- ! Auth.log cleared immediately after successful sudo commands or SSH key additions — indicates active privilege escalation
- ! wtmp and btmp cleared — the attacker is removing evidence of login sessions
- ! Web server access logs cleared after exploitation (UPSTYLE/Volt Typhoon pattern)
- ! Log clearing followed by /etc/ld.so.preload modification — rootkit deployment in progress
- ! Multiple log types cleared in sequence — comprehensive cleanup indicating sophisticated attacker
Investigation Guide
Forensic Artifacts
- >
File System: Empty or very small log files where substantial content is expected (ls -la /var/log/) - >
File System: Missing log files that should exist (check /etc/rsyslog.conf for expected log paths) - >
File System Metadata: inode change time (ctime) for log files modified very recently without corresponding log rotation - >
Journal: journalctl may contain events even when syslog files are cleared (systemd-journald stores separately) - >
auditd: /var/log/audit/audit.log entries for syscalls on /var/log/* (if auditd was not also cleared) - >
Login Records: /var/run/utmp (current sessions), /var/log/wtmp (historical), /var/log/btmp (failed logins)
Tuning Guidance
Effective detection requires either endpoint telemetry (MDE for Linux) or auditd configured to monitor /var/log/ directory operations. Configure auditd rules: '-w /var/log -p wa -k log_tampering' to capture all write and attribute change operations. The key is excluding logrotate (which runs as root and legitimately rotates logs) while catching manual clearing. Enable centralized logging (rsyslog → SIEM) to create an off-host record that survives on-host clearing. For high-value systems, use append-only filesystem mounts (chattr +a /var/log) to prevent deletion or truncation without root+
Hunting Queries
Hunt for non-logrotate log file deletions across the fleet. Rare but high-signal: log files in /var/log should almost never be directly deleted by processes other than logrotate.
DeviceFileEvents
| where Timestamp > ago(7d)
| where FolderPath startswith "/var/log/"
| where ActionType == "FileDeleted"
| where not(InitiatingProcessFileName in~ ("logrotate", "newsyslog"))
| summarize count(), Devices=dcount(DeviceName), Accounts=make_set(InitiatingProcessAccountName) by FileName, FolderPath, InitiatingProcessFileName
| sort by count_ desc index=linux_auditd sourcetype="linux:audit" type=SYSCALL (syscall=unlink OR syscall=unlinkat)
| rex field=msg_audit "name=\"(?<filepath>[^\"]+)\""
| where match(filepath, "/var/log/")
| where NOT match(exe, "(logrotate|rsyslog)")
| stats count, dc(host) as Devices, values(auid) as UIDs by filepath, exe
| sort - count Hunt for shell commands that redirect to or delete log files in /var/log. The truncation pattern (> /var/log/auth.log) is a strong indicator — it's used by attackers because it removes content while preserving the file inode, making the clearing less obvious than deletion.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("> /var/log", "truncate -s 0", "dd if=/dev/null", "rm /var/log", "rm -rf /var/log", "shred /var/log")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName
| sort by Timestamp desc index=linux_auditd sourcetype="linux:audit" type=EXECVE
| rex field=msg_audit "a0=\"(?<cmd>[^\"]+)\""
| where match(cmd, "(truncate|shred|dd|rm)") OR match(cmd, ">")
| join type=inner max=1 [search index=linux_auditd type=SYSCALL | rex field=msg_audit "exe=\"(?<exe>[^\"]+)\"" | table host, pid, exe]
| where match(_raw, "/var/log")
| table _time, host, cmd, exe, pid
| sort - _time Hunt specifically for modifications to login record files (wtmp, btmp, lastlog) by processes other than authentication daemons. These files should only be written by legitimate login processes — any other modification indicates tampering to remove login evidence.
DeviceFileEvents
| where Timestamp > ago(7d)
| where FileName in~ ("wtmp", "btmp", "lastlog")
| where ActionType in ("FileModified", "FileDeleted", "FileTruncated")
| where not(InitiatingProcessFileName in~ ("login", "sshd", "su", "sudo", "gdm", "systemd"))
| project Timestamp, DeviceName, AccountName=InitiatingProcessAccountName, FileName, FolderPath, ActionType, InitiatingProcessFileName
| sort by Timestamp desc index=linux_auditd sourcetype="linux:audit"
| rex field=msg_audit "name=\"(?<filepath>[^\"]+)\""
| where match(filepath, "(wtmp|btmp|lastlog)")
| where NOT match(exe, "(login|sshd|gdm|lightdm|systemd)")
| table _time, host, auid, exe, filepath, syscall
| sort - _time Atomic Red Team Tests
Truncates /var/log/auth.log using shell redirection — the most common Linux log clearing technique. Unlike rm, truncation preserves the file inode and may not immediately alert file integrity monitors, making it the preferred method for sophisticated attackers.
Command
sudo bash -c 'cp /var/log/auth.log /tmp/auth.log.backup && echo > /var/log/auth.log && echo Auth log truncated - $(wc -c < /var/log/auth.log) bytes remain' Cleanup
sudo cp /tmp/auth.log.backup /var/log/auth.log 2>/dev/null && rm -f /tmp/auth.log.backup Expected Telemetry
auditd: SYSCALL records showing open with O_TRUNC flag on /var/log/auth.log. File modification event captured by endpoint telemetry. rsyslog may log a restart after the file is truncated if it monitors file size.
Expected Detection
Alert fires on /var/log/auth.log truncation. auditd: type=SYSCALL where key=log_tampering. KQL: DeviceFileEvents where FileName == 'auth.log' and ActionType in ('FileModified', 'FileTruncated'). SPL: linux:audit SYSCALL with O_TRUNC on auth.log.
Deletes a test log file from /var/log to simulate the adversary technique of completely removing log files. Uses a test file rather than production logs to avoid system impact.
Command
sudo sh -c 'echo "test log entry $(date)" > /var/log/argus-test.log && rm -v /var/log/argus-test.log' Expected Telemetry
auditd: SYSCALL records for creat/open (file creation) and unlink (file deletion). File creation and deletion events in endpoint telemetry. The file creation followed immediately by deletion pattern is anomalous.
Expected Detection
Alert on log file deletion in /var/log by non-logrotate process. auditd syscall=unlink on /var/log path. KQL: DeviceFileEvents where FolderPath contains '/var/log' and ActionType == 'FileDeleted'.
Demonstrates clearing of login records by truncating the wtmp file — this removes all historical login evidence including session timestamps. Affects the output of 'last' and 'who' commands.
Command
sudo sh -c 'cp /var/log/wtmp /tmp/wtmp.backup && echo Current wtmp size: $(wc -c < /var/log/wtmp) bytes && > /var/log/wtmp && echo After clearing: $(wc -c < /var/log/wtmp) bytes && last | head -5 && echo Login history cleared - last shows empty' Cleanup
sudo cp /tmp/wtmp.backup /var/log/wtmp 2>/dev/null && rm -f /tmp/wtmp.backup Expected Telemetry
auditd: SYSCALL for open with O_TRUNC on /var/log/wtmp. Any process monitoring wtmp (e.g., login daemons) may detect the size change. File modification event in endpoint telemetry for wtmp.
Expected Detection
High-priority alert on wtmp truncation by non-auth daemon. This should almost never be performed outside of specific system administration procedures. KQL: DeviceFileEvents where FileName == 'wtmp' and ActionType in ('FileModified','FileTruncated') and InitiatingProcessFileName not in ('login','sshd').