My previous blog post on this topic was an initial look into what happens (i.e., changes, what 'new' data is available, etc.) when you merge Registry transaction logs into a hive. This started out with me just looking at what tools were available for doing so, and then expanded a bit into, "oh, let's see what changes were made in the hive file...".
In this post, I wanted to provide a bit more information and clarification around what I did and what I found, so that others can more clearly see the process, and hopefully, the value of pursuing this sort of testing and research.
Clarification
My initial testing led to some very interesting findings, one of which was stated as the following:
The del.pl plugin produced some interesting results. When I ran it against the original System hive, it pulled out a number of deleted keys and values; however, running it against the 'new' (i.e., merged) hive, I got nothing. Not one deleted key, not one deleted value.
Now, the assumption here might be that there are no deleted keys and values after the transaction logs have been merged into the hive, and that would be incorrect. The reason that the tool displayed no findings on the second run (and thanks to Maxim for providing insight into this...) is that the plugin only checks the beginning of a free cell for indications of a deleted key or value node; it doesn't traverse and check the entire cell. This is why we have tool testing and verification, and what leads to those of us who write and use such tools to update them.
So, for the sake of clarity, merging the transaction logs into a hive file does not remove all unallocated space and deleted cells. That being said, there is significant value in running tools that check for deleted cells across both the original and the merged hives.
Tools
For testing, I opted for using the LoneWolf scenario image, as it is readily available. Any hives and their corresponding transaction logs can be used, but going with a publicly available image allows for clarity and simplicity in discussions. I opened the image in FTK Imager, and extracted System hive from the system32\config folder, along with the System.log1 and System.log2 transaction log files.
As to merging transaction logs into hives, I tweeted a question regarding tools used to merge hives and transaction logs. I got a response from Maxim, stating "yarp + registryFlush.py". Once I got everything set up and running, this process ran as advertised. I passed the necessary arguments to the script, and ended up with four files in the folder:
03/27/2018 05:45 PM 12,845,056 SYSTEM
09/29/2017 04:45 AM 3,163,136 SYSTEM.LOG1
09/29/2017 04:45 AM 3,211,264 SYSTEM.LOG2
04/08/2019 04:04 PM 12,845,056 system_2019-04-08@160420
At this point, I have the 'dirty' hive and transaction logs extracted from the image, as well as the 'merged' hive file. Note that the file system reports the 'dirty' and 'merged' hives as being the same size.
Deleted Keys/Values
I mentioned checking for deleted keys and values at the beginning of this post; Maxim provided this advice regarding the use of the "yarp-print" tool as the more accurate approach to recovering deleted keys and values.
Specifically, if you're using yarp on Windows, start by opening a command prompt, navigating to the folder where the tools are located, and type:
set PYTHONIOENCODING=utf-8
Then, to parse deleted keys/values from the 'dirty' hive, you can use the following command:
yarp-print --deleted --no-recovery SYSTEM
In this case, you would used the --no-recovery switch as the tool will automatically attempt to discover the transaction log files.
In order to parse the deleted keys and values, incorporating the transaction logs into the process, you'd use the following command line, if you extracted the transaction logs into the same folder as the hive file:
yarp-print --deleted SYSTEM
Again, the yarp tools will attempt to discover the transaction logs for you, and incorporate them into the parsing. This also means that you can use the yarp-print tool to extract deleted keys and values from the merged hive, using the following command:
yarp-print --deleted system_2019-04-08@160420
In this case, you don't have to use the --no-recovery switch, as the tool won't find transaction logs associated with the merged hive.
RegRipper
As I mentioned in my previous post, one of the interesting aspects of this testing was the differences in output from various RegRipper plugins when run against the 'dirty' and 'merged' hives.
The output of the mountdev.pl plugin, when run against the 'merged' hive, included an additional DosDevice entry:
\DosDevices\F:
Drive Signature = 76 d4 59 81
The output of the bam.pl plugin, when run against the 'merged' hive, included two additional entries for the user with RID 1001:
Fri Apr 6 12:27:06 2018 - \Device\HarddiskVolume4\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE
Fri Apr 6 12:41:21 2018 - \Device\HarddiskVolume6\Programs\Imager_Lite_3.1.1\FTK Imager.exe
The same output also included an entry for the Local System account that was not in the 'dirty' hive:
S-1-5-18
Fri Apr 6 12:40:38 2018 - \Device\HarddiskVolume4\Windows\System32\csrss.exe
Take-Aways
Just with this initial testing, using just this one hive, we can begin to see the value of making use of the hive transaction logs. The System hive used in this case was not from a high-use system; that is to say that it was from a forensic challenge scenario system, and not a system used in a corporate environment. Regardless, this limited testing did allow us to see that there is considerable value in incorporating the transaction logs in our Registry parsing process.
Other images are available online which may be used to further this testing. For example, the Mystery Hacked System image includes activity within the user profiles, and as such, may prove to be interesting and provide even more support for this process.
Finally, after merging the transaction logs, I ran some basic diff utilities against the 'dirty' and 'merged' hives, and noted that there were a number of entries that appeared in the 'merged' hive that were not visible in the 'dirty' hive. A method for narrowing this down a bit might be to run RegRipper profiles against both, and then run text-based diff utilities against the results of each of the profile runs.
Next Steps
My next steps are to examine additional tools (specifically, Eric Zimmerman's Registry Explorer and RECmd tools) that can be used in this process, and leveraged to take advantage of the additional data within Registry transaction logs.
References
Maxim - Exploring intermediate states of a registry hive
FireEye - Digging up the past
Other Tools
Regipy - alternative tool for merging transaction logs (note: I'm working with the author...)
RegRippy - RegRipper alternative, written in Python3
No comments:
Post a Comment