I like good stuff, interesting stuff. I particularly like stuff that gets me to thinking, and gets me to thinking specifically about validating my analysis process.
I ran across SetRegTime today, from Joakim Schicht. Basically, Joakim started from the perspective that, from his view and his reading on the Internet, modification of Registry key LastWrite times to arbitrary values was "not possible". So, he set out to turn this line of thinking around, achieved it, and released a proof-of-concept tool to demonstrate the capability.
In my courses, I have specifically stated that I was not aware of any open, public APIs (such as the GetFileTime()/SetFileTime() functions) that allow for arbitrary modification of Registry key LastWrite times. Now, thanks to Joakim, we all are.
I greatly applaud and appreciate Joakim's efforts in producing and releasing SetRegTime, as it:
1. Identifies the public API and increased the possibility (albeit not the likelihood) of this occurring.
2. Illustrates the need for an overall analysis process.
3. Illustrates the need for a greater understanding of the Registry as an investigative resource.
4. Illustrates more than ever the need for timeline analysis.
So, the big question for most analysts will likely be...okay, so what does this do to my examinations? I'm sure that the thought will be that it throws an additional level of uncertainty into the exams, but I would suggest that if you have an analysis process, then this won't be the case at all. With an analysis process, you will likely find indications of this sort of activity occurring, particularly if you are using timeline analysis.
In addition, when performing malware analysis, you would want to look for the use of the APIs that Joakim mentions (i.e., NtCreateKey, NtOpenKey, NtSetInformationKey, NtFlushKey), as well as the use of the Windows internal names for the Registry. Behavior analysis of the malware will likely illustrate this activity, as well.
So, if you're "poking around" in the Registry and find something interesting, and rely on that one artifact or finding as the foundation for your case, you're likely going to be building a house of cards. However, if you have an overall analysis process that incorporates multiple data sources and multiple artifacts to support your conclusions, then you're likely going to pick up on the use of this sort of software, and be able to address it accordingly.
I agree that a good process and an experienced and knowledgeable examiner can mitigate this issue. Though it is important to note that there are a large number of examiners (and teams) that simply do not have the skills to perform malware analysis to identify causalities like this. They might determine that a strange binary ran at a certain time, but linking that to the changing of a specific Registry last write time could be a big stretch. Kudos to Joakim Schicht and your blog for getting the word out on how this technique works. Understanding that it is possible is the first step towards starting to look for it within your processes.
ReplyDeleteThe recursive option of SetRegTime is not working in Windows 10.
ReplyDeleteAnonymous,
ReplyDeleteThis blog post is 10 yrs old...did you reach to the tool author?