Analysts may be less familiar with time stomping as it applies to Registry keys, also discussed in great detail by Lina in her blog, discussed by Maxim on X, as well as discussed by Shane McCulley and Kimberly Stone in their SANS DFIR Summit 2023 presentation. During their presentation, Kimberly discussed (mentioned several times) using the Registry transaction logs to detect Registry key time stomping by examining intermediate states of a hive file, which Maxim discussed in his blog in November, 2018. In a way, this technique is no different from examining intermediate states of the file system using the USN change journal.
All of these resources together provide a pretty thorough overview of time stomping activity; what it is, how it's achieved, etc. Lina's blog on time stomping files provides several means by which both $STANDARD_INFORMATION and $FILE_NAME attributes within an MFT record can be modified. I saw $STANDARD_INFORMATION attribute time stamps being modified quite often during the time I was engaged in PCI forensic investigations; in most cases, the time stamps were copied from kernel32.dll, so that the file dropped by the threat actor would appear to be part of normal system files.
Also during the presentation, Kimberly specifically discusses the StrozFriedberg open source library, written in Rust, for parsing offline Windows Registry hive files, named "notatin". The library includes Python bindings, and two utilities that ship as Windows binaries. Kimberly proves examples of the utilities' use during the presentation, and it's definitely a library worth looking into if you're engaged in some form of Registry parsing and analysis.
Detecting Time Stomping/Detection Methodologies
During the presentation, Kimberly mentioned several times that determining time stomping of Registry keys should be a more regular part of the analysis process, and to some extent, I agree with her. However, this perhaps requires a level of understanding of the issue, as well as automation that may not necessarily be accessible to all organizations, as they may not be set up in a manner similar to StrozFriedberg. This level of parsing and tagging/decoration of data is not something you see in commercially available forensic suites, and as such, would require a bit of developer "heavy lifting" to get the automation described by Maxim set up and enabled. This is not to say that it cannot be achieved; rather, fully exploiting the Windows Registry is not something we see in regular, normal practice, either via CTFs or via open reporting, and as such, I wouldn't think that this is something we see being part of regular processing anytime in the near future.
Another way to address the analysis issue, particularly (albeit not solely) when it comes to detecting this form of defense evasion, would to be subject the DF analysis culture to a dramatic shift, to where artifact constellations are developed and used as part of analysis on a regular basis, rather than viewing single artifacts in isolation, which appears to be more common place today.
In Lina's blog post, she provides an attack demonstration, the first two steps focusing on the Run key within the Software hive. At approximately 15:37 in the presentation video, Kimberly provides an example of the Run key within the Software hive being "time stomped". Something to consider when investigating incidents where the Run key, in either the Software or NTUSER.DAT hives, may have been time stomped, analysts should keep the Microsoft-Windows-Shell-Core%4Operational.evtx Windows Event Log file in mind; this log provides a record of when values within the Run and RunOnce keys are processed. If you subject this log to frequency of least occurrence analysis, you can determine those values that are "new" and haven't been processed but once, or even a few times, as well as get the first time they were processed. Comparing this to the full breadth of the log itself, you can determine when the value was processed for the first time. Note that this log file can also assist analysts in tracking Raspberry Robin persistence, as well.
In step 3 of the attack demonstration in her blog, Lina moved from the Run key to the Uninstall key, as this key has a number of subkeys. Not long after Lina's blog post was published, I wrote a RegRipper plugin in an attempt to implement the detection methodology, part 2; what I found was that there are a LOT of Registry keys with subkeys that have more recent LastWrite times than the key itself.
Conclusion
During my time in DFIR, I can't say that I've seen time stomping of Registry keys employed as a defense evasion technique, and so far, I haven't seen anything in public, open reporting to suggest that it has been used "in the wild". It's pretty clear from Lina's blog post that it's possible, but when conducting analysis thus far, I haven't seen any issues where the LastWrite time on the Run key, or any other key for that matter, did not align with the other artifacts within the constellation. However, to Kimberly's point, creating the necessary automation to detect the possible use of this technique, applied during the data parsing, normalization, and decoration phase, would mean that the possible used of the technique would be raised to the analyst's awareness (for further investigation) without requiring a manual examination of the data.
EndNote
Another possible means for detecting the use of this technique is to purposely configure your Windows endpoints to support this detection, by enabling the EnablePeriodicBackup value in the Registry.
