Detect Clear Linux or Mac System Logs in CrowdStrike LogScale
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.
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/
LogScale Detection Query
#event_simpleName = /^(FileDeleteInfo|PeFileWritten|EngineFileWritten)$/
| TargetFileName = /\/(var\/log|Library\/Logs|private\/var\/log)\//
| TargetFileName = /(\.log$|auth\.log|syslog|messages|secure|wtmp|btmp|lastlog|kern\.log)/
| CommandLine != /logrotate|newsyslog|rsyslog|syslogd|aslmanager/
| FileName != /logrotate|newsyslog|rsyslog|syslogd/
| select([timestamp, ComputerName, UserName, FileName, TargetFileName, CommandLine, #event_simpleName])
| sort(timestamp, order=desc)CrowdStrike LogScale (Humio) query against Falcon endpoint telemetry detecting FileDeleteInfo and file write events (PeFileWritten/EngineFileWritten used for truncation patterns) on Linux and macOS log paths. Filters on target file path regex matching /var/log/, /Library/Logs/, and known log file names, excluding legitimate log rotation executables.
Data Sources
Required Tables
False Positives & Tuning
- CrowdStrike Falcon sensor self-diagnostics or log cleanup within monitored paths that use non-standard process names not captured in the exclusion filter
- Linux package managers (rpm, dpkg) triggering prerm or postrm scripts that remove log files associated with an uninstalled service package
- macOS Time Machine or third-party backup agents that stage log files before archival, temporarily appearing as deletion events
Other platforms 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_ descindex=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 - countHunt 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 descindex=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 - _timeHunt 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 descindex=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 - _timeAtomic 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.backupExpected 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.backupExpected 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').