Let's talk Linux log tampering. If these commands show you anything, it's time to take a look: #DFIR
utmpdump /var/run/utmp | grep -E "(^\\[0\\]|^\\[.[0-9]+\\])"
utmpdump /var/log/wtmp | grep -E "(^\\[0\\]|^\\[.[0-9]+\\])"
utmpdump /var/log/btmp | grep -E "(^\\[0\\]|^\\[.[0-9]+\\])"
Thread
utmpdump /var/run/utmp | grep -E "(^\\[0\\]|^\\[.[0-9]+\\])"
utmpdump /var/log/wtmp | grep -E "(^\\[0\\]|^\\[.[0-9]+\\])"
utmpdump /var/log/btmp | grep -E "(^\\[0\\]|^\\[.[0-9]+\\])"
Thread
On Linux the valid types for wtmp|utmp|btmp records (first column) are 1-9. Common detection tools only look for type 0 (null) to find tampering. But, you need to check for all possibilities. Type 16 below is illegal. How did it get there? #DFIR
In this example Sandfly flags a type "16" that was inserted into the log even though the rest of the entry was smashed. This entry will not show in standard Linux detection tools. Likewise, type 0 is the classic attack and again it's a good idea to look for it. #DFIR
It's also not a bad idea to look in /tmp for signs that a log file tamper dropper was left behind. Some of the tools will core dump and leave behind traces or not clean up properly. Finding their traces is as good as finding the tampered audit log. #DFIR
If you want to read more about using Linux utmpdump command to look at audit logs, check out this article:
#DFIR https://www.sandflysecurity.com/blog/using-linux-utmpdump-for-forensics-and-detecting-log-file-tampering/
#DFIR https://www.sandflysecurity.com/blog/using-linux-utmpdump-for-forensics-and-detecting-log-file-tampering/
Advanced log cleaners will splice the logs together instead of overwriting them. They can also be detected, but it takes more work. I'll talk about that in the future. It's very hard to hide as an intruder on Linux.
#DFIR
#DFIR