Detecting Linux Anti-Forensics: Timestomping
Threat actors can modify the timestamps on malicious files to evade detection. This technique has been used time and time again across various APT and opportunistic threat groups. How do you detect this when auditd, bash history and EDR does not exist? I notice basically all writeups on timestomping detection on Linux focus solely on looking at command-line usage of "touch". I'm here to offer you a different method.
I will cover TWO techniques to perform timestomping and offer a different method of detection that doesn’t rely on auditd, command line logging or EDR. Why should you care? Because inexperienced analysts may notice a specific malicious file being created outside of an attack window and consider that the compromise timeframe may be even earlier than what it is. Further, the analyst may completely disregard a file as an attacker-based tool if it is completely outside of the timeframe. I’m here to help :)
This blog is structured in four sections:
- Timestomping on Linux (two methods)
- Detection using Tracker3
- Detection using AuditD
- Final thoughts on detection
TIMESTOMPING ON LINUX
There are two methods you can approach timestomping on Linux. These are:
- Using the “touch” command. I don’t recommend this technique for reasons that I’ll cover.
- Modifying the system date and then creating the attacker file.
Just as a quick refresher, this is how timestamps work in Linux:
(M) Modify – Updated whenever the file contents are changed.
(A) Access – Updated when the file contents are accessed (usually via script). Accessing a file via GUI does not always update the access time.
(C) Change – Metadata change time for the file i.e. file ownership change.
(B) Birth – Date the file was created. This is based on the operating system time and exists on EXT4.
Method 1. Timestomping using Touch (bad!)
This is done by running the command “touch -a -m -t <timestamp> <filename>”. There are two downsides to using this technique. The first being it’s been written about to death and most people have detections for this method. The second downside is that the “change” time cannot be modified using this method.
As you can see in the screenshot below – the change time is *very* different from the modify and access time. This is because the change time will only be modified based on the system date of the operating system. Without auditd or command line logging, this already looks a bit odd. This is because the change time is changed based on the system date of the operating system.
Having the change date being later than the modify and access date does not mean a file was necessary timestomped. However, it does indicate that changes were made to the metadata for the file around the “attack” period (if it fits in the timeline). I cover proper detections for this in the next section.
If you’re interested in existing write-ups about detection for the touch command – it’s straight forward and generally command-line based. You can read up about these here:
Elastic - https://www.elastic.co/guide/en/security/current/timestomping-using-touch-command.html
Abusing Touch - https://www.thegeekstuff.com/2012/11/linux-touch-command/
Method 2. Timestomping via Modifying the system date
The issue with the “touch” method is that it doesn’t change the birth or change time as these are based on the operating system date. As such, a cleaner method to avoid the use of the “touch” command is to modify the system date, drop the files and then revert the system date. Most modern detections for this attack technique only solely detect on the use of the “touch” command *wink wink*.
As you can see in the screenshot below, I’ve updated the system time to the year 2000 and disabled NTP. Post “compromise” you can enable NTP again.
DETECTION METHOD 1: Tracker3
Tracker3 indexes the filesystem on GNOME and acts like a search engine. It's enabled by default on newer versions of Ubuntu. It tracks and indexes files and documents in various database files. These are stored in the directory “/home/<user>/.cache/tracker3/files/”. These files are broken down in the following DB files:
- Audio.db – Audio files
- Documents.db – Documents
- FileSystem.db – Files (this is the main one we are interested in)
- Pictures.db – Picture files
- Software.db – Application related files
- Video.db – Video files
- Meta.db – Index of all files in the environment
On top of all these files, there are also corresponding SHM and WAL logs. These are the shared memory file and write-ahead logs. The updates will first be committed to the WAL and then written to the DB. As such, for an analyst, it’s critical that you also consider these WAL logs as a source of interest and investigation. If you have ever performed mobile forensic investigations, you will already be aware of the pivotal role of analysing WAL in mobile investigations ^_^
The only thing you need to know is that tracker3 uses SPARQL and it does retain some deleted data. If you are interested in the documentation for tracker3 commands you can run, take a look at this link: https://gnome.pages.gitlab.gnome.org/tracker/docs/commandline/.
Now, the most important DB file here is the FileSystem.db file. Every time a file is created it will create two entries in the FileSystem.db table:
Both entries will track the creation time of the file as well as the time this entry was inserted into the database. Please note that the “insertion” time (idk the way to refer to this lol) occurs shortly after the file is created and is based on the system time.
The screenshot below shows the original table creation for “FileDataObject”. As you can see it tracks the following timestamps:
- fileCreated (third value)
- fileLastAccessed (second variable)
- fileLastModified (second last variable)
- nie:created (second last variable).
- fileCreated time
- fileLastModified time
- nie:Created time
- Usage of the touch binary
- Changes made to a directory (this is honestly hellish because… it raises the bigger question of… what directory are you monitoring? Do you monitor critical ones and risk missing out on some directories?) For this exercise I set it to /tmp which is the directory I am messing around with for this exercise’s sake.
- Timestomping by changing system time evades detections that focus on the “touch” command (which is the main detection I keep seeing everywhere).
- FileSystem.db will catch instances of timestomping where a client does not have command line logging, EDR or auditd enabled (also is a good method for detection in terms of forensics)
- Forensic detection using FileSystem.db in tracker3 fails when the system time change method is used for timestomping because the DB is updated using system time (this is understandable)
HAPPY HUNTING xx
Post a Comment