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:

1. Using the “touch” command. I don’t recommend this technique for reasons that I’ll cover. 
2. 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:

• Nfo:FileDataObject
• Nie:DataObject

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)

For the table “DataObject” you can also see the original table creation below. You can see that it tracks one interesting timestamp:

• nie:created (second last variable). 

This essentially tracks when a file was created / inserted into this table. This happens almost simultaneously. 

Now let’s delve into some examples of using this artefact to perform detection.

1. Detecting touch command timestomping

In this example I used touch to timestomp a file named “meow.txt”. As you can see the modify and access time have been changed to 2000. 

The dirty and quick way to query the tracker3 db is through using sqlite3. The command I am running is “sqlite3 <filename> .dump | grep <filename>”

From above you can see that the three timestamps I have highlighted in pink correlate to the:

• fileCreated time
• fileLastModified time
• nie:Created time

What’s important to note here is that when a file is created, an entry is immediately created in both the FileDataObject and DataObject tables. Therefore, the nie:Created time correlates with the actual file creation time.

Let’s convert these times into something more legible:

This is a great way to detect timestomping forensically on Linux – by noting that the CREATION time is LATER than when the file was accessed and modified. This is the key detection here and results in a high-fidelity outcome :) 

2. Detecting timestomping via updating system time

Now let’s use the second timestomping technique of changing the actual system time on the operating system to perform timestomping on a file named “bad.txt” and see if this can detect it. As you can see below, I changed the system time to the year 2000 and then dropped a bad.txt file and all the timestamps are written to my desired time.

Using this technique for detecting timestomping by assessing the Filesystem.db does NOT work for this technique. Because the Filesystem.db time is based on the overall operating system date time. As you can see from the screenshot below, the timestamp of 946710001 maps to our timestomped time of 2000-01-01.

DETECTION METHOD 2: AuditD

I’m not going to go into too much detail here because this topic has been written about a lot. All that I have to say here is, you can set up the following rules to monitor:

• 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.

The screenshot below shows the two audit rules I created for this testing:

Below is a screenshot of me doing a basic timestomp using the “touch” command:

As you can see this has been caught by the audit rules:

FINAL THOUGHTS

So, what does this tell us? It tells us three interesting things:

• 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) 

True detection of timestomping would need to focus on a combination of 3 aspects: command line logging (to catch instances of touch, datetime modification etc), analysis of FileSystem.db and the associated WAL and finally, use of auditd to filter on binaries of interest / directories of interest.

For Windows, I wrote a similar blog on timestomping detection here: https://www.inversecos.com/2022/04/defence-evasion-technique-timestomping.html

HAPPY HUNTING xx