{
	"id": "ea60cc67-c868-41a0-9a6e-338bc1ab7e4d",
	"created_at": "2026-04-06T00:15:57.842685Z",
	"updated_at": "2026-04-10T03:20:39.231649Z",
	"deleted_at": null,
	"sha1_hash": "89e9d00eab9197203235069e1ebebdfdf31348bf",
	"title": "Detecting Linux Anti-Forensics: Timestomping",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1350566,
	"plain_text": "Detecting Linux Anti-Forensics: Timestomping\r\nBy inversecos\r\nPublished: 2022-08-05 · Archived: 2026-04-05 22:43:11 UTC\r\nThreat actors can modify the timestamps on malicious files to evade detection. This technique has been used\r\ntime and time again across various APT and opportunistic threat groups. How do you detect this when auditd, bash\r\nhistory and EDR does not exist? I notice basically all writeups on timestomping detection on Linux focus solely\r\non looking at command-line usage of \"touch\". I'm here to offer you a different method.\r\nI will cover TWO techniques to perform timestomping and offer a different method of detection that doesn’t rely\r\non auditd, command line logging or EDR. Why should you care? Because inexperienced analysts may notice a\r\nspecific malicious file being created outside of an attack window and consider that the compromise timeframe\r\nmay be even earlier than what it is. Further, the analyst may completely disregard a file as an attacker-based tool if\r\nit is completely outside of the timeframe. I’m here to help :) \r\nThis blog is structured in four sections:\r\nTimestomping on Linux (two methods)\r\nDetection using Tracker3\r\nDetection using AuditD \r\nFinal thoughts on detection\r\nTIMESTOMPING ON LINUX\r\nThere are two methods you can approach timestomping on Linux. These are:\r\n1. Using the “touch” command. I don’t recommend this technique for reasons that I’ll cover. \r\n2. Modifying the system date and then creating the attacker file. \r\nJust as a quick refresher, this is how timestamps work in Linux:\r\nhttps://www.inversecos.com/2022/08/detecting-linux-anti-forensics.html\r\nPage 1 of 7\n\n(M) Modify – Updated whenever the file contents are changed.\r\n(A) Access – Updated when the file contents are accessed (usually via script). Accessing a file via GUI does not\r\nalways update the access time. \r\n(C) Change – Metadata change time for the file i.e. file ownership change.\r\n(B) Birth – Date the file was created. This is based on the operating system time and exists on EXT4.\r\nMethod 1. Timestomping using Touch (bad!)\r\nThis is done by running the command “touch -a -m -t \u003ctimestamp\u003e \u003cfilename\u003e”. There are two downsides to\r\nusing this technique. The first being it’s been written about to death and most people have detections for this\r\nmethod. The second downside is that the “change” time cannot be modified using this method.\r\nAs you can see in the screenshot below – the change time is *very* different from the modify and access time.\r\nThis is because the change time will only be modified based on the system date of the operating system. Without\r\nauditd or command line logging, this already looks a bit odd. This is because the change time is changed based on\r\nthe system date of the operating system. \r\nHaving the change date being later than the modify and access date does not mean a file was necessary\r\ntimestomped. However, it does indicate that changes were made to the metadata for the file around the “attack”\r\nperiod (if it fits in the timeline). I cover proper detections for this in the next section. \r\nIf you’re interested in existing write-ups about detection for the touch command – it’s straight forward and\r\ngenerally command-line based. You can read up about these here: \r\nElastic - https://www.elastic.co/guide/en/security/current/timestomping-using-touch-command.html\r\nAbusing Touch - https://www.thegeekstuff.com/2012/11/linux-touch-command/\r\nMethod 2. Timestomping via Modifying the system date\r\nThe issue with the “touch” method is that it doesn’t change the birth or change time as these are based on the\r\noperating system date. As such, a cleaner method to avoid the use of the “touch” command is to modify the\r\nsystem date, drop the files and then revert the system date. Most modern detections for this attack technique only\r\nsolely detect on the use of the “touch” command *wink wink*.\r\nAs you can see in the screenshot below, I’ve updated the system time to the year 2000 and disabled NTP. Post\r\n“compromise” you can enable NTP again. \r\nhttps://www.inversecos.com/2022/08/detecting-linux-anti-forensics.html\r\nPage 2 of 7\n\nDETECTION METHOD 1: Tracker3\r\nTracker3 indexes the filesystem on GNOME and acts like a search engine. It's enabled by default on newer\r\nversions of Ubuntu. It tracks and indexes files and documents in various database files. These are stored in the\r\ndirectory “/home/\u003cuser\u003e/.cache/tracker3/files/”. These files are broken down in the following DB files:\r\nAudio.db – Audio files \r\nDocuments.db – Documents \r\nFileSystem.db – Files (this is the main one we are interested in)\r\nPictures.db – Picture files \r\nSoftware.db – Application related files\r\nVideo.db – Video files\r\nMeta.db – Index of all files in the environment \r\nOn top of all these files, there are also corresponding SHM and WAL logs. These are the shared memory file and\r\nwrite-ahead logs. The updates will first be committed to the WAL and then written to the DB. As such, for an\r\nanalyst, it’s critical that you also consider these WAL logs as a source of interest and investigation. If you have\r\never performed mobile forensic investigations, you will already be aware of the pivotal role of analysing WAL in\r\nmobile investigations ^_^\r\nhttps://www.inversecos.com/2022/08/detecting-linux-anti-forensics.html\r\nPage 3 of 7\n\nThe only thing you need to know is that tracker3 uses SPARQL and it does retain some deleted data. If you are\r\ninterested in the documentation for tracker3 commands you can run, take a look at this\r\nlink: https://gnome.pages.gitlab.gnome.org/tracker/docs/commandline/.\r\nNow, the most important DB file here is the FileSystem.db file. Every time a file is created it will create two\r\nentries in the FileSystem.db table:\r\nNfo:FileDataObject\r\nNie:DataObject\r\nBoth entries will track the creation time of the file as well as the time this entry was inserted into the database.\r\nPlease note that the “insertion” time (idk the way to refer to this lol) occurs shortly after the file is created and is\r\nbased on the system time.  \r\nThe screenshot below shows the original table creation for “FileDataObject”. As you can see it tracks the\r\nfollowing timestamps:\r\nfileCreated (third value)\r\nfileLastAccessed (second variable)\r\nfileLastModified (second last variable)\r\nFor the table “DataObject” you can also see the original table creation below. You can see that it tracks one\r\ninteresting timestamp:\r\nnie:created (second last variable). \r\nThis essentially tracks when a file was created / inserted into this table. This happens almost simultaneously. \r\nNow let’s delve into some examples of using this artefact to perform detection.\r\n1. Detecting touch command timestomping\r\nIn this example I used touch to timestomp a file named “meow.txt”. As you can see the modify and access time\r\nhave been changed to 2000. \r\nhttps://www.inversecos.com/2022/08/detecting-linux-anti-forensics.html\r\nPage 4 of 7\n\nThe dirty and quick way to query the tracker3 db is through using sqlite3. The command I am running is “sqlite3\r\n\u003cfilename\u003e .dump | grep \u003cfilename\u003e”\r\nFrom above you can see that the three timestamps I have highlighted in pink correlate to the:\r\nfileCreated time\r\nfileLastModified time\r\nnie:Created time\r\nWhat’s important to note here is that when a file is created, an entry is immediately created in both the\r\nFileDataObject and DataObject tables. Therefore, the nie:Created time correlates with the actual file creation time.\r\nLet’s convert these times into something more legible:\r\nThis is a great way to detect timestomping forensically on Linux – by noting that the CREATION time is LATER\r\nthan when the file was accessed and modified. This is the key detection here and results in a high-fidelity outcome\r\n:) \r\n2. Detecting timestomping via updating system time\r\nNow let’s use the second timestomping technique of changing the actual system time on the operating system to\r\nperform timestomping on a file named “bad.txt” and see if this can detect it. As you can see below, I changed the\r\nsystem time to the year 2000 and then dropped a bad.txt file and all the timestamps are written to my desired time.\r\nUsing this technique for detecting timestomping by assessing the Filesystem.db does NOT work for this\r\ntechnique. Because the Filesystem.db time is based on the overall operating system date time. As you can see from\r\nthe screenshot below, the timestamp of 946710001 maps to our timestomped time of 2000-01-01.\r\nhttps://www.inversecos.com/2022/08/detecting-linux-anti-forensics.html\r\nPage 5 of 7\n\nDETECTION METHOD 2: AuditD\r\nI’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\r\nhere is, you can set up the following rules to monitor:\r\nUsage of the touch binary\r\nChanges made to a directory (this is honestly hellish because… it raises the bigger question of… what\r\ndirectory are you monitoring? Do you monitor critical ones and risk missing out on some directories?) For\r\nthis exercise I set it to /tmp which is the directory I am messing around with for this exercise’s sake.\r\nThe screenshot below shows the two audit rules I created for this testing:\r\nBelow is a screenshot of me doing a basic timestomp using the “touch” command:\r\nAs you can see this has been caught by the audit rules:\r\nFINAL THOUGHTS\r\nSo, what does this tell us? It tells us three interesting things:\r\nTimestomping by changing system time evades detections that focus on the “touch” command (which is\r\nthe main detection I keep seeing everywhere). \r\nFileSystem.db will catch instances of timestomping where a client does not have command line logging,\r\nEDR or auditd enabled (also is a good method for detection in terms of forensics)\r\nForensic detection using FileSystem.db in tracker3 fails when the system time change method is used for\r\ntimestomping because the DB is updated using system time (this is understandable) \r\nTrue detection of timestomping would need to focus on a combination of 3 aspects: command line logging (to\r\ncatch instances of touch, datetime modification etc), analysis of FileSystem.db and the associated WAL and\r\nhttps://www.inversecos.com/2022/08/detecting-linux-anti-forensics.html\r\nPage 6 of 7\n\nfinally, use of auditd to filter on binaries of interest / directories of interest.\r\nSource: https://www.inversecos.com/2022/08/detecting-linux-anti-forensics.html\r\nhttps://www.inversecos.com/2022/08/detecting-linux-anti-forensics.html\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.inversecos.com/2022/08/detecting-linux-anti-forensics.html"
	],
	"report_names": [
		"detecting-linux-anti-forensics.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434557,
	"ts_updated_at": 1775791239,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/89e9d00eab9197203235069e1ebebdfdf31348bf.pdf",
		"text": "https://archive.orkl.eu/89e9d00eab9197203235069e1ebebdfdf31348bf.txt",
		"img": "https://archive.orkl.eu/89e9d00eab9197203235069e1ebebdfdf31348bf.jpg"
	}
}