Clear Linux or Mac System Logs (T1685.006) is a sub-technique of Disable or Modify Tools. Adversaries clear system logs to hide evidence of an intrusion. MITRE lists the Defense Impairment tactic and Linux and macOS as platforms.
Both operating systems record system and user-initiated actions in logs. Most native logging is stored under the /var/log/ directory, and subfolders group logs by function.
How attackers use it
MITRE lists the typical files under /var/log/:
/var/log/messages: general and system-related messages./var/log/secureor/var/log/auth.log: authentication logs./var/log/utmpor/var/log/wtmp: login records./var/log/kern.log: kernel logs./var/log/cron.log: logs from the cron daemon./var/log/maillog: mail server logs./var/log/httpd/: web server access and error logs.
Clearing these removes the story of who logged in, what ran on a schedule and what the web server served. The technique page lists documented uses: removing logs from /var/log and /Library/logs, clearing log files inside the /var/log/ folder, clearing .bash_history, auth.log, lastlog, wtmp and btmp, overwriting Linux system logs, and unsetting the Bash history file so that command history is no longer kept. One malware example can clear logs on every device along its connection path to compromised network infrastructure.
Notice that some of these are not log files in the usual sense. Shell history and login records are as valuable to an investigator, and they are just as easy to remove.
How to detect it
MITRE's detection strategy combines command behavior with file behavior.
- Linux. Commands that target files under
/var/log/, unusual deletions or truncations of system logs, and unexpected child processes such as shell pipelines or redirections. - macOS. Calls to shell utilities such as
echo >,rmandtruncateaimed at files in/var/log/, with unusual context such as non-administrative users or odd process lineage.
Other signals follow from this:
- A log file whose size suddenly drops to zero or whose modification time is newer than its content.
- A gap in the log timeline while the host kept running.
- A login record file such as
wtmpthat is empty or missing. - Shell history that has been unset or does not match what you know happened.
File integrity monitoring on /var/log/ is a good fit here. If you also run auditd, an audit rule on writes and deletions in that directory records who did it.
How to reduce the risk
MITRE lists three mitigations.
- Restrict File and Directory Permissions. Protect locally stored event files with proper permissions and authentication, and limit chances to escalate privileges.
- Remote Data Storage. Forward events automatically to a log server or repository, so the adversary cannot find and manipulate the data on the local system. Keep the reporting delay short.
- Encrypt Sensitive Information. Obfuscate or encrypt event files locally and in transit, to avoid giving feedback to an adversary.
Forwarding is the control that matters most, because root on the host can still delete local files. A copy that left the machine seconds earlier is still there.
Check your own environment
These read-only commands work on Linux. On macOS, ls -l and last work as shown, though file names differ.
ls -l /var/log
sudo ls -l /var/log/auth.log /var/log/wtmp
last -n 10
systemctl is-active rsyslog
The first lists log files with sizes and times. The second looks at authentication and login records (use /var/log/secure on distributions that name it that way). The third shows the last logins. The fourth checks whether rsyslog is running on systems that use it.
Then check:
- Are logs forwarded off every server, and how fast?
- Are any log files empty, or smaller than yesterday, without a rotation to explain it?
- Who can write to
/var/log/, and who has root? - Do you alert if forwarding stops?
- Is shell history kept and sent off the host for privileged accounts?
Quick check
Which files show who logged in?
Login records in /var/log/utmp and /var/log/wtmp, and authentication logs in /var/log/secure or /var/log/auth.log.
Why does root access not defeat remote log storage?
The copy already left the host. Deleting local files does nothing to the central one.
What file integrity signal suggests tampering?
A log file that suddenly shrinks or is truncated, with no log rotation to explain it.
Sources
- MITRE ATT&CK, Clear Linux or Mac System Logs (T1685.006): https://attack.mitre.org/techniques/T1685/006
