Registry Analysis, pt II

In my last blog post, I provided a brief description of how I perform "Registry analysis", and I thought it would be a good idea to share the actual mechanics of getting to the point of performing Registry analysis.

First off, let me state clearly that I rarely perform Registry analysis in isolation from other data sources and artifacts on the system.  Most often, I'll incorporate file system metadata, as well as Windows Event Log metadata, into my analysis in order to develop a clearer picture of the activity.  Doing this helps me to 'see' activity that might be associated with a threat actor, and it goes a long way towards removing guesses and speculation from my analysis.

For instance, I'll incorporate Windows Event Log record metadata using the following command:

C:\tools>wevtx.bat d:\case\*.evtx > d:\case\evtx_events.txt

The above command places the record metadata, decorated using intrusion intel from the eventmap.txt file, into an intermediate file, with all of the entries in the 5-field TLN format.  I can then make use of just this file, or I can incorporate it into my overall timeline events file using the 'type' command:

C:\tools>type evtx_events.txt >> events.txt

That being said, there are times when I have been asked to "take a look at the Registry", and during those times, my hope is to have something around which to pivot...a service name, a specific date and time, some particular event, etc. I'll start this process by listing all of the Registry keys in the Software and System hives based on the key LastWrite times, using the following commands:

C:\tools>regtime -m HKLM/Software/ -r d:\case\software > d:\case\reg_events.txt
C:\tools>regtime -m HKLM/System/ -r d:\case\system >> d:\case\reg_events.txt

Note: RegRipper will tell you if the hive you're accessing is 'dirty', and if so, you'll want to strongly consider merging the transaction logs into the hive prior to parsing.  I like to do this as a separate process because I like to have the original hive file available so that I can look for deleted keys and values.

If there's a suspicion or evidence to suggest that a local user account was created, then adding metadata from the SAM hive is pretty simple and straightforward:

C:\rr3>rip -r d:\case\sam -p samparse_tln >> d:\case\reg_events.txt

When I say "evidence to suggest" that the threat actor added a local account to the system, one way to check for that is to hope the right auditing was enabled, and that you'd find the appropriate records in the Security Event Log. Another way to check is to parse the SAM Registry hive:

C:\rr3>rip -r d:\case\sam -p samparse

Then, correlate what you see to the ProfileList key from the Software hive:

C:\rr3>rip -r d:\case\software -p profilelist

Looking at these two data sources allows us to correlate user accounts and RIDs to user profiles on the system.  In many cases, we'll have to consider domain accounts (different SIDs), as well.

I'll also include other specific information from the Registry hives in the timeline:

C:\rr3>rip -r d:\case\system -p shimcache_tln >> d:\case\reg_events.txt
...

I'll also incorporate the AmCache metadata, as well:

C:\rr3>rip -r d:\case\amcache.hve -p amcache_tln >> d:\case\reg_events.txt

For a user, I generally want to create a separate mini-timeline, using similar commands as above:

C:\tools>regtime -m HKCU/ -r d:\case\user\ntuser.dat -u user > d:\case\user\reg_events.txt
C:\tools>regtime -m HKCU/ -r d:\case\user\usrclass.dat -u user >> d:\case\user\reg_events.txt
C:\rr3>rip -r d:\case\user\usrclass.dat -u user -p shellbags_tln >> d:\case\user\reg_events.txt
C:\rr3>rip -r d:\case\user\ntuser.dat -u user -p userassist_tln >> d:\case\user\reg_events.txt
...

Note: If you're generally looking at the same artifacts within a hive (NTUSER.DAT, etc.) over and over, it's a good idea to open Notepad and create a RegRipper profile.  That way, you have a documented, repeatable process, all in a single command line.

Note: If you're looking at multiple systems, it's not only a good idea to differentiate users on the system via the "-u" switch, but also differentiate the system by using the "-s" switch in the RegRipper command lines.  You can get the system name via the compname.pl RegRipper plugin.

Once the events file has been created, I have a source for parsing out specific items, specific time frames, or just the entire timeline, using parse.exe.  I can create the entire timeline, and based on items I find to pivot on, go back to the events file and pull out specific items using combinations of the type and find commands.  The complete timeline is going to contain all sorts of noise, much of it based on legitimate activity, such as operating system and application updates, normal user activity (logins, logoffs, day-to-day operations, etc.), and sometimes it's really helpful to be able to look at just the items of interest, and then view them in correlation with other items of interest.

Note: If you have a standard extraction process, or if you mount images using a means that makes the files accessible, all of this can be automated with something as simple as a batch or shell script.

Once I get to this point, the actual analysis begins...because parsing and display are not "analysis".  Getting one value or the LastWrite time to one key is not "analysis".  For me, analysis is an iterative process, and what I described above is just the first step.  From there, I'll keep a viewer handy (usually MiTeC's WRR) and a browser open, allowing me to dig in deeper and research items of interest.  This way, I can see values for keys for which there are not yet RegRipper plugins, such as when a new malware variant creates keys and values, or when a threat actor creates or modifies keys. When I do find something new like that (because the process facilitates finding something new), that then becomes a RegRipper plugin  (or a modification to an existing plugin), decoration via the eventmap.txt file, etc.  The point is that whatever 'new thing' is developed gets immediately baked back into the overall process.

For example, did a threat actor disable Windows Defender, and if so how? Via a batch file?  No problem, we can use RegRipper to check the Registry keys and values.  Via GPO?  Same thing...use RegRipper.  Via an sc.exe command?  No problem...we can use RegRipper for that, as well.

What about open source intrusion intel, such as this FireEye blog post?  The FireEye blog post is rich with intrusion intel that can be quickly and easily turned into plugins and event decoration, so that whenever those TTPs are visible in the data, the analyst is immediately notified, providing pivot points and making analysis vastly more consistent and efficient.