{
	"id": "56d26990-8de6-4922-920a-389314844bf4",
	"created_at": "2026-04-06T01:32:34.013592Z",
	"updated_at": "2026-04-10T03:20:19.143008Z",
	"deleted_at": null,
	"sha1_hash": "232803241cde1d5c2273364bf5c7414c040c11fb",
	"title": "HowTo: Determine/Detect the use of Anti-Forensics Techniques",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 49739,
	"plain_text": "HowTo: Determine/Detect the use of Anti-Forensics Techniques\r\nArchived: 2026-04-06 00:31:20 UTC\r\nThe use of anti-forensics techniques to hide malicious activity (malware installation, intrusion, data theft, etc.) can\r\nbe something of a concern during an examination; in fact, in some cases, it's simply assumed when particular data\r\nor artifacts can't be found.  It's easy to assume that these techniques were used when we look at a very limited\r\nrange of artifacts; however, as we begin to incorporate additional and more comprehensive data sources into our\r\nanalysis processes, we begin to be able to separate out the anti-forensics signal from the noise.\r\nThe term \"anti-forensics\" can refer to a lot of different things.  When someone asks me about this topic, I\r\ngenerally try to get them to describe to me what they're referring to, and to be more specific.  As with anything\r\nelse, nomenclature can be important, and messages get scrambled when the use of terms becomes too loose.\r\n Rather than address this as broad topic, I thought we'd take a look at some of the common techniques used to hide\r\nevidence on or remove it from a system...\r\nTimeStomp\r\nOne of perhaps the most publicly discussed anti-forensic techniques is referred to as time stomping, in part due the\r\nname of the tool used to demonstrate this capability.  While this initially threw a monkey wrench into our analysis\r\nprocesses, it was quickly realized that the use of this sort of technique (and tool) could be detected.  Then, as\r\nthings tend to go in any eco-system, there was an adaptation to the technique...rather than modifying a 64-bit time\r\nstamp with a 32-bit value, the technique was adapted to copy the file times from kernel32.dll onto the target file,\r\npreserving 64-bit granularity.  Once again, analysis techniques were updated.  For example, in 2009, Lance\r\nMueller talked about detecting the use of time changing utilities in his blog.  There's been discussion regarding\r\ntechniques for changing the $FILE_NAME attribute time stamps, as well as those within the\r\n$STANDARD_INFORMATION attribute, just as there have been techniques for detecting the use of this\r\ntechnique.  Direct and thorough analysis of the MFT (the analysis of which is predicated by having a thorough\r\nunderstanding of the MFT records themselves) can be revealing, whereas techniques such as detecting program\r\nexecution and David Cowen's NTFS TriForce can prove valuable insight, as well.\r\nTools: MFT parser, knowledge of MFT records\r\nChanging the System Time\r\nOkay, let's say that rather than changing the times of specific files, and intruder changes the system time itself.\r\n This would mean that, after that change, the times recorded by the system would be different...so how could we\r\nhttp://windowsir.blogspot.com/2013/07/howto-determinedetect-use-of-anti.html\r\nPage 1 of 3\n\ndetect this?  One way to do this is to list available Event Log records by sequence number and generated time...if\r\nthe system time were rolled back, this activity would become evident as the sequence numbers increased but at\r\none point, the time generated was earlier than the time for the previous record.  Lance Mueller's first forensic\r\npractical exercise provided a great example of how to detect system time changes using this technique.\r\nTools: evtparse.pl ('-s' switch)\r\nZapping Event Records\r\nI've heard analysts state the there were gaps in the available Event Logs, so an intruder must have been able to\r\nremove specific event records from the log.  Again, I've heard this claimed, but I've never seen the data to support\r\nthis sort of thing.  Writing a tool to do this is hazardous to the intruder...it may not work, and may instead crash the\r\nsystem.  Why not just do something much simpler, such as (given the appropriate privileges) clear the Event Log\r\nand disable auditing all together.\r\nI've had to analyze a number of Windows systems where the Event Logs have been cleared, and with Windows XP\r\nand 2003 systems in particular, it's been pretty trivial to recover a good deal of those deleted event records.\r\nChecking the LastWrite time of a Registry key within the Security hive file (see the auditpol.pl RegRipper plugin)\r\nwill help you determine when the audit policy of the system was last modified.\r\nMultiple Techniques\r\nWhat we've discussed thus far was not intended to be a comprehensive listing of all anti-forensics techniques;\r\nrather, I wanted to look at a couple and point out analysis processes that you could employ to detect the use of\r\nsuch techniques.  The thing about using anti-forensics techniques is that less is better; the fewer and more simple\r\nthe techniques used, the harder they are to address.  For example, simply deleting a file...downloader, executable\r\nfile, etc...after us is perhaps the simplest technique to use, as it prevents an analyst from obtaining a copy of the\r\nfile for analysis.  Say a script downloads and executes a file, then deletes it...the analyst may still find artifacts to\r\nindicate that the file was executed (i.e., Prefetch file, AppCompatCache artifacts, etc.) but not be able to determine\r\nexplicitly what the file was designed to do.\r\nHowever, to use multiple techniques requires additional planning and effort.  If this is done automatically, then\r\neither a larger application, or multiple applications will need to be downloaded to the system.  The problem that\r\nthe intruder then runs up against is that the applications have to be tested specifically against the version of\r\nWindows that has been compromised...different versions of Windows may have different functionality behind the\r\nAPI, and the applications may not work correctly, or may even crash the system.  The more \"sophisticated\" the\r\ntechnique used, the more planning and effort is required.  If multiple applications are used, it's more likely that\r\nindications of program execution will be found.  If a more manual approach is used, then the intruder must spend\r\nmore time and engage with the system more, again leaving more tracks and artifacts as they interact with the\r\nenvironment.\r\nSummary\r\nThe key things to remember with respect to determining or detecting the use of anti-forensics techniques are:\r\n1.  If you suspect it, provide it.  Find the evidence.  If you suspect that a particular technique has been used, gather\r\nthe data that supports, or ultimately disproves, your theory.  Don't just wave your hand and suggest that \"anti-http://windowsir.blogspot.com/2013/07/howto-determinedetect-use-of-anti.html\r\nPage 2 of 3\n\nforensics techniques were used.\"  If you suspect that one or more techniques were used, identify them explicitly.\r\n Then, you can pursue demonstrating or disproving your theory.\r\n2.  Remember that you're not only on the same battlefield as the bad guy, but you actually have an advantage.\r\n You're examining an acquired image, which is the \"scene of the crime\", frozen in time and unchanging.  You can\r\ngo back and start your analysis over again, without the fear of loosing any of your previous artifacts.\r\n3.  Document your analysis; if you didn't document it, it didn't happen.  Once you've documented your analysis,\r\nincluding both what worked and what didn't, you can then incorporate your findings into future analysis, as well\r\nas share your finding with other analysts.\r\nSource: http://windowsir.blogspot.com/2013/07/howto-determinedetect-use-of-anti.html\r\nhttp://windowsir.blogspot.com/2013/07/howto-determinedetect-use-of-anti.html\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"http://windowsir.blogspot.com/2013/07/howto-determinedetect-use-of-anti.html"
	],
	"report_names": [
		"howto-determinedetect-use-of-anti.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775439154,
	"ts_updated_at": 1775791219,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/232803241cde1d5c2273364bf5c7414c040c11fb.pdf",
		"text": "https://archive.orkl.eu/232803241cde1d5c2273364bf5c7414c040c11fb.txt",
		"img": "https://archive.orkl.eu/232803241cde1d5c2273364bf5c7414c040c11fb.jpg"
	}
}