Malicious Registry Timestamp Manipulation Technique: Detecting Registry Timestomping
Registry artifact timestamps are extremely important to an incident response investigation. Threat actors may hide persistence mechanisms within the registry or modify registry values to disable Antivirus and other security tools. Knowing the time registry values are set/modified is very important to the overall investigation, especially when faced with answering questions pertaining to…
- Why did <security_tool> not detect the threat?
- What files did the threat actors recently view?
- What folders did the threat actors open?
- When was the persistence mechanism installed in the registry?
- And many other questions that are important to an investigation…
The idea of timestomping / time manipulation of a registry key’s ‘Last Write’ is a topic that has not been comprehensively covered in DFIR write-ups with most timestomping write-ups focused on timestomping of files via manipulation of the $STANDARD_INFORMATION time.
There exists a native Windows API “NtSetInformationKey” that allows a malicious threat actor to timestomp the ‘Last Write’ time of a registry key. I came across this when looking through the Undocumented NTInternals website for registry keys. As I looked further into this research, I came across a PoC tool built by Joakim Schicht (https://github.com/jschicht). This tool is called SetRegTime.exe and runs by using this native API “NtSetInformationKey” to change the Last Write Time for keys in the registry. The link to the tool is here.
Perhaps the most interesting component to all of this is the lack of strong detection for this technique (which I cover later in this blog post). The reason being – typically, the logic for detecting timestomping for files relies on a comparison between the $STANDARD_INFORMATION vs $FILENAME time given that $STANDARD_INFORMATION time can be trivially manipulated via Windows APIs. However, there isn’t a “comparison” time for a registry ‘Last Write’ time which makes the detection more difficult. To make it more difficult, the time change is written to the disk immediately via calling “NtFlushKey” which makes the “detection” of this via memory forensics almost impossible unless you have a memory image of the disk the second these APIs were triggered.
This blog post will cover the following topics:
- How to manipulate a registry key timestamp
- Attack demonstration
- Detection mechanisms and further thoughts
How to manipulate a registry key timestamp
By calling a set of native API keys an attacker can modify the Last Write time of a registry key in an extremely trivial manner. The most important API is the “NtSetInformationKey” API which takes in a few parameters – the most important being the KEY_SET_INFORMATION_CLASS parameter which is used to modify the ‘Last Write’ time by passing in “KEY_WRITE_TIME_INFORMATION”.
The breakdown for the API “NtSetInformationKey” can be seen in the screenshot below taken from Undocumented NtInternals website.
- NtCreateKey >> Creates or opens an existing registry key
- NtOpenKey >> Opens an existing registry key
- NtSetInformationKey >> Used to modify the time
- NtEnumerateKey >> Returns information about a registry key
- NtQueryKey >> Returns information from a registry key
- NtFlushKey >> Write the new timestamp immediately to disk
Step 2: Wait a few seconds for changes to take place
- Why event logs detections fail on this technique
- Detecting discrepancies in registry keys
- Why memory forensics may not be feasible in most circumstances
- Why EDR is your best bet for detection (if your EDR tool monitors for this)
- Final considerations