Detecting Linux Anti-Forensics Log Tampering
When forensically examining Linux systems for malicious intrusion, responders often rely on the following three artefacts to determine logins and logouts:
- /var/run/utmp – currently logged in users
- /var/run/wtmp – current, past logins and system reboot
- /var/log/btmp – bad login attempts
Of course, these artefacts are not all you can forensically investigate for malicious access (there are other artefacts you can examine), however, these will be the focus of this anti-forensics blog post.
In this post, I will walk through two methods of removing and tampering with these aretfacts to delete the malicious logins you want to hide. The first method removes the log line completely from the file through overwriting the binary file, the second method focuses on altering the hex of the file but is more obvious to detect. I will then walk through a simple way of detecting both methods based on timestamps that you can check. If timestamps are king – then I’ll be his queen!
Method 1 – Nulling the Entry
This method is almost trivial to perform but leaves at least two methods of detection for a responder. The picture below shows the untampered output of the /var/log/wtmp binary. Please note that I will be using this file for the examples, but this technique can be used across all 3 artefacts.
To kick this off, the attacker should ensure no bash history is being logged. You can do this through running the command below to set the HISTSIZE=0. This will prevent the shell commands from being logged when you’re on the system:
There are attack tools you can use to do this – but why would you load unnecessary attack tools on the system when you can just LoL? Open up the hexeditor on /var/log/wtmp. I am using “hexedit”.
The account I want to remove from the log is “shutdown” (why? because I felt like it and there is no attacker on my sift workstation lol). The starting point to edit is where you note the first “~” in hex. I have highlighted the areas to edit in purple. Edit these so it is all “0” by nulling all the values out.
If you mess this part up you will end up clearing the entire file xD.
The screenshot below shows the output of /var/log/wtmp now. You can see this entry has been removed as it’s been nulled out. The date has also reverted to the default date.
Method 2 – Overwriting the file
If bash_history is turned off this is slightly harder to detect as this technique results in the entire lines being omitted from the log as we are complexly overwriting the /var/log/wtmp file. The detection of this can be done by looking at timestamps though! UwU
We can accomplish this in two steps. The first is to grep out the lines we want to remove into a “clean” file. In the screenshot below, you can see I got rid of the “sansforensics” login.
Then we want to replace the contents of /var/log/wtmp with the cleaned file:
DETECTION METHODOLOGY
This first method of anti-forensics / log evasion is trivial to detect and the detection is pretty high-fidelity. I would look for entries in wtmp, btmp and utmp where:
- Values are zeroes (null) as this is not normal at all
- Detect entries with the datetime stomped to “1970*”
The next step is to review the timestamp of the actual /var/log/wtmp file. This file should always have the timestamp of the LAST entry that exists within the file. Please observe this following example of a non-tampered wtmp file:
And now compare it to the timestamps on the wtmp file. You will see they are always supposed to match:
Therefore, to summarise the key steps in detecting this:
- Bash history (if HISTSIZE isn’t 0)
- Values of zero (null) in wtmp, btmp, utmp
- Entries with a timestamp containing the year 1970 (default time)
- Timestamp mismatch between the last entry and the file timestamp of the file
Happy hunting! X
Comments
Post a Comment