{
	"id": "0d57ab1d-8fa1-4919-857f-e79c2ffeb844",
	"created_at": "2026-04-06T02:13:06.314679Z",
	"updated_at": "2026-04-10T03:33:56.26956Z",
	"deleted_at": null,
	"sha1_hash": "b24e6279d5cc1e48ed83c27c3534465ff1d8c3e8",
	"title": "Expose Evidence of Timestomping with the NTFS Timestamp Mismatch Artifact",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 249105,
	"plain_text": "Expose Evidence of Timestomping with the NTFS Timestamp\r\nMismatch Artifact\r\nBy Rick Andrade\r\nPublished: 2020-08-24 · Archived: 2026-04-06 01:55:45 UTC\r\nMalicious activity can devastate the infrastructure it infects, and so it is increasingly important to be able to first\r\nidentify suspicious behavior so that you can begin remediating its affects. Unfortunately, the goal of malware is to\r\nblend in, go unnoticed, and hide from its target so that it can maintain its presence on the target endpoint. One\r\npotential way that some malicious actors try to accomplish this task is to manipulate the timestamps of the\r\nmalicious file(s), a tactic known as timestomping.\r\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nThe goal of timestomping is to edit the timestamps being displayed and reported to the end user and incident\r\nresponders in an attempt to make it seem as though the file doesn’t fall into the timeline of other detected\r\nmalicious activity. When the incident responder starts reviewing alerts, logs, and other artifacts from the infected\r\nmachine, a timestomped file might fall outside of the scope of investigation if the timestamps are maliciously\r\nmanipulated. The result could be an undetected malicious file that can persist on the infected endpoint.\r\nOften, though, this activity can be detected by comparing multiple timestamps associated within the MFT record\r\ncorresponding to the file in question. The NTFS Timestamp Mismatch artifact, gives you a starting point in the\r\nincident response investigations in which you suspect timestomping may have occurred. Here is how it works!\r\nWithin an MFT record of a file stored within a NTFS endpoint, there are multiple sections, or attributes, that\r\ncontain various types of information about a file. For this new artifact, we will be focusing on the\r\n$Standard_Information ($SI) and $File_Name ($FN) attributes. Both sections of the MFT record contain sets of\r\ntimestamps: Created, Accessed, Modified, and MFT Modified.\r\nhttps://www.magnetforensics.com/blog/expose-evidence-of-timestomping-with-the-ntfs-timestamp-mismatch-artifact-in-magnet-axiom-4-4/\r\nPage 1 of 3\n\nThe $SI section of the MFT record is indicated with the value 0x10, as outlined in red below, and the Created\r\ntimestamp is highlighted and decoded as well in green. The $SI timestamps are what Windows would display the\r\nend user as well as what most forensic tools will display as far as dates/times stamps in the File System view.\r\nOutlined below in red, the $FN section is indicated with the value 0x30, and the Created timestamp is highlighted\r\nand decoded again in green as well. The $FN timestamps in the MFT record are only modified by the Windows\r\nkernel and will generally go untouched by antiforensic timestomping tools.\r\nIn the above example screenshots, the MFT record is from a timestamp manipulated file, and you can see that\r\nwhen the timestamps from both the $SI and $FN are decoded, the difference is worth noting.\r\nNow, in the NTFS Timestamp Mismatch artifact, AXIOM will automatically analyze both sets of timestamps for\r\nevidence of timestomping. Each artifact hit will give you both sets of timestamps, as well as a reason for the\r\nhttps://www.magnetforensics.com/blog/expose-evidence-of-timestomping-with-the-ntfs-timestamp-mismatch-artifact-in-magnet-axiom-4-4/\r\nPage 2 of 3\n\nartifact hit.\r\nFirst, this artifact will compare the timestamps within the MFT Records of files in the file system from both the\r\n$SI and the $FN attributes, and will flag a mismatch when the $SI timestamp is earlier than the $FN timestamp.\r\nAdditionally, this artifact will check to see if the millisecond values in the timestamp are exactly zero, which can\r\nalso sometimes be a potential indicator that timestomping activity may have occurred on an infected system. For a\r\npositive hit on this artifact, only one of these criteria needs to be true, and the reason will be listed in the details\r\npanel in AXIOM Examine.\r\nKeep in mind that this artifact is disabled by default in AXIOM Process, so be sure to select it when processing if\r\nyou believe that timestamp manipulation may have occurred on your Windows endpoint.\r\nThis artifact can help provide you with a starting point if you believe timestomping activity occurred on an\r\ninfected system and allow you to properly timeline activity on your infected endpoint alongside IDS alerts,\r\nnetwork logs, and additional artifacts in your case. Note, however, that there could be legitimate reasons from\r\nnormal system behavior that could cause this mismatch, as well as ways that malicious activity can circumvent\r\nthis timestamp difference (for example, as referenced in this MITRE blog).\r\nSource: https://www.magnetforensics.com/blog/expose-evidence-of-timestomping-with-the-ntfs-timestamp-mismatch-artifact-in-magnet-axio\r\nm-4-4/\r\nhttps://www.magnetforensics.com/blog/expose-evidence-of-timestomping-with-the-ntfs-timestamp-mismatch-artifact-in-magnet-axiom-4-4/\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.magnetforensics.com/blog/expose-evidence-of-timestomping-with-the-ntfs-timestamp-mismatch-artifact-in-magnet-axiom-4-4/"
	],
	"report_names": [
		"expose-evidence-of-timestomping-with-the-ntfs-timestamp-mismatch-artifact-in-magnet-axiom-4-4"
	],
	"threat_actors": [
		{
			"id": "cea5ceec-0f14-4e34-bd0e-4074bc1a707d",
			"created_at": "2022-10-25T15:50:23.629983Z",
			"updated_at": "2026-04-10T02:00:05.362084Z",
			"deleted_at": null,
			"main_name": "Axiom",
			"aliases": [
				"Group 72"
			],
			"source_name": "MITRE:Axiom",
			"tools": [
				"ZxShell",
				"gh0st RAT",
				"Zox",
				"PlugX",
				"Hikit",
				"PoisonIvy",
				"Derusbi",
				"Hydraq"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "5c74936a-79d1-41b8-81eb-01d03c90a26b",
			"created_at": "2022-10-25T16:07:23.371052Z",
			"updated_at": "2026-04-10T02:00:04.570621Z",
			"deleted_at": null,
			"main_name": "Axiom",
			"aliases": [
				"G0001",
				"Group 72",
				"Operation SMN"
			],
			"source_name": "ETDA:Axiom",
			"tools": [
				"9002 RAT",
				"Agent.dhwf",
				"AngryRebel",
				"BlackCoffee",
				"BleDoor",
				"Chymine",
				"Darkmoon",
				"DeputyDog",
				"Derusbi",
				"Destroy RAT",
				"DestroyRAT",
				"Farfli",
				"Fexel",
				"Gen:Trojan.Heur.PT",
				"Gh0st RAT",
				"Ghost RAT",
				"Gresim",
				"HOMEUNIX",
				"HiKit",
				"HidraQ",
				"Homux",
				"Hydraq",
				"Kaba",
				"Korplug",
				"McRAT",
				"MdmBot",
				"Moudour",
				"Mydoor",
				"PCRat",
				"PNGRAT",
				"PlugX",
				"Poison Ivy",
				"RbDoor",
				"RedDelta",
				"RibDoor",
				"Roarur",
				"SPIVY",
				"Sensocode",
				"Sogu",
				"TIGERPLUG",
				"TVT",
				"Thoper",
				"Winnti",
				"Xamtrav",
				"ZXShell",
				"Zox",
				"ZoxPNG",
				"ZoxRPC",
				"gresim",
				"pivy",
				"poisonivy"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775441586,
	"ts_updated_at": 1775792036,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b24e6279d5cc1e48ed83c27c3534465ff1d8c3e8.pdf",
		"text": "https://archive.orkl.eu/b24e6279d5cc1e48ed83c27c3534465ff1d8c3e8.txt",
		"img": "https://archive.orkl.eu/b24e6279d5cc1e48ed83c27c3534465ff1d8c3e8.jpg"
	}
}