Using RegRipper

I have been doing oodles of analysis lately (6+TB since December!) and have been making heavy, heavy use of registry analysis in each case. For this I've been using Regripper so I figured I would dedicate at least one post to it, and how I make use of it. I also happen to be a firm believer that someone can tell a person to use something 1000 times, but until they actually see it in use or can see the utility in using it, they are less likely to follow your recommendation. With that said, here's a few ways I use regripper.


1) Determine group membership.

Like no other tool I've used to date, the samparse module has saved me hours of analysis time in determining who belonged to what group and what privileges they had. Just this morning I saw some mailing list posts about determining why there was no user account listed for a particular account in the SAM on a windows XP box. The answer was rather simple - The account was a domain account.

Here's an abridged example of what I'm talking about:

User Information
------------------------------------------------
Username: Administrator [500]
Username: Guest [501]
Username: SUPPORT_388945a0 [1002]
Username: SUPPORT_3f151ab9 [1003]
Username: HelpAssistant [1004]
Username: ASPNET [1006]

Group membership information
------------------------------------------------
Group Name: Power Users [1]
Users: S-1-5-21-1461745249-492156796-3006755465-1119

Group Name: Administrators [3]
Users: S-1-5-21-296978250-731684933-3931576523-500

To explain, the top portion are the local user accounts. Under the Group membership section we can see the power users group with a SID/RID combination that doesn't fit with the system. How do I know this? This is easily determined by examination of the Administrators group section of the file. The Administrator account is a well known SID of S-1-5-N-500. As such, I now know the system SID and can say that the account in the power users group is NOT a local account. This can and *should* be correlated to the software hive analysis of the profilelist key and its values that details user account and the SID. When looking at the software hive, you can quickly determine the account name from the SID and the domain name in question.

2) Determine services installed.

Regripper has a great module to determine what services were on the system sorted by last write time. Comparing this to an exemplar list of windows services allows you to a) do data reduction and b) determine what services may have been installed or leveraged by an intruder.

3) Windows Firewall configuration.

I once had an incident where an external consultant claimed the firewall was not disabled by them(which is what caused the incident), however the firewall according to regripper was disabled, and other logs confirmed this with all roads pointing to the consultants.

4) Confirmation of devices in use on the system.

There's been a number of times when I could say to a customer that had been infected with removable media malware "You'll want to make sure you clean up these devices" or identify "rogue" devices that had been used on a system.

5) Determine network configuration.

In a world dominated by a lot of DHCP and variety of network usage, determining the last known IP address used by the system is invaluable, especially when you need to plug the IP address in to various network analysis utilities. I use this (and other markers) to make sure I've got the system I'm supposed to have.

6) Determine user activity.

Naturally there's a bunch of good things here to look at and every investigation includes a look here.

In short there's untold ways to use regripper for analysis. These are just a few small examples of how I've made use of the tool. I don't really know how many people are using it, but there sure are a bunch of people who aren't, and that's just a shame. It's a great tool that simplifies the process of registry analysis and simply stated it saves time. As we all know, time is money and saving both is important to everyone involved in investigations. Don't forget, as I showed in the video I posted some time ago, it can be run in concert with F-response to look at an otherwise "locked" registry hive on a remote system, while it's live.

There's much more I could say about using regripper but I imagine there will be plenty included in Windows Forensic Analysis second edition.

Ripping the Registry Live

So I have been quiet lately and there's been quite a bit happening. First off, Harlan Carvey released RegRipper. This tool is impressive and awfully useful, not to mention NEEDED. If you haven't checked it out, do so. Harlan has said this tool is not designed for live response but I've been dying to get it in to a live response methodology. Well with F-Response I can do it now. Here goes ripping the registry live...sorry for my camtasia-fu or lack of.





A few things if you haven't registered with F-response.

The field kit requires that you put the dongle in the target system - This video starts after I've done that.
The connection is not encrypted - yet.

In addition, there's a new version of regripper out. This is just one of the many tools that F-response can facilitate the use of. See why it's so cool?

EDIT: I put the video up on youtube..blogger's video was just too small.
EDIT: Harlan corrected this statement for me: "Harlan has said this tool is not designed for live response." This should read "RegRipper is NOT intended to be run on live Registry hive files".
EDIT: I realized an error in the previous video. The new one is correct.

Analyzing an Intrusion Part III - Corporal and anamnestic

It's been a few days but I've had some time to delve in to the image of the compromised honeypot. I've come across a few surprises and struggled with an evaluation of some software, but it's coming along so here we go...



Corporal and Anamnestic evidence related to the incident that was found on the honeypot:

Time Zone Information:
Time is incredibly important so we need to establish if the TZ settings were correct.
The active time zone information was -4 hours from GMT which is correct.
System Log:

Event Type: Error Date: 04/22/2007 Time: 06:10:10 PM Source: Service Control Manager
Event ID: 7034 EventDescription:The DNS Server service terminated unexpectedly. It has done this 1 time.


AHA! so as suspected, this event was captured by the event log. Note how innocuous this message is. It doesn't say "the DNS service was killed". Also note the time the service was killed because this becomes important as we try to understand the script the attacker executed. Pay attention to the timing as you go through the rest of this.


Security Logs:
To cull the security logs, I tried a number of methods. As this is a honeynet, I use it to test new and different methods and software on a regular basis.

Harlan Carvey details a few methods in his new book Windows Forensic Analysis and I decided to give them a whirl. As an aside, I'd like to plug this book. It's a fantastic resource rich with accurate information, and if you do any sort of windows forensics, it's a must have

First off, the Security logs were corrupted, so that added a modicum of difficulty to the process.
Harlan's most wonderful lsevt2 perl script was able to parse file even though it was corrupted. However, even using csv output, I was unable to import it in to a database or excel because some of some apparent font or type issues, or perhaps they are parsing issues but I've yet to determine that.

The second method was to repair the event logs as detailed here. This site also happens to be mentioned in Harlan's book. This worked and I was able to view the logs as normal in the event viewer.

The third method I tried was using Prodiscover IR. I am impressed that they included an event log viewer in the program, however it crashed reliably when processing the security event logs. Maybe it was too large for the program to handle, but it would just exit, with no warning.


After I repaired the security logs, I used logparser(which I'm still getting the hang of) to narrow down what I wanted to look at.

logparser "select * from SecEvent.EVT where eventid in (592;593) and to_string(timegenerated, 'yyyy-MM-dd HH:mm:ss') like '2007-04%'"
-i:EVT -o:csv and heavily edited the output to make it fit here.

The following shows the execution timeline of the attackers script. You can see the definitive path of the script as it executed. First, a quick explanation. Event ID 592, and 593 are created because process tracking audting is enabled. 592 is for process creation, and 593 is when a process exits. In order for the strings column to make sense you need to know that the far right PID is what spawned the process(parent process), and the PID on the left is the PID of the listed process.

So, we can see cmd.exe was spawned by PID 1732, and was assigned a PID of 4028 in the first line. If you go through the list diagonally like you're tying shoes, you'll see the pattern rather quickly. I've color coded the like PIDS to try to help.

TimeGenerated,EventID,EventType,Strings
4/22/2007 18:09:53,592,8,"4028,C:\WINDOWS\system32\cmd.exe,1732,"
4/22/2007 18:09:56,592,8,"2124,C:\WINDOWS\system32\net.exe,4028,"
4/22/2007 18:09:56,592,8,"2728,C:\WINDOWS\system32\net1.exe,2124"
4/22/2007 18:09:56,593,8,"2728,C:\WINDOWS\system32\net1.exe,"
4/22/2007 18:09:56,593,8,"2124,C:\WINDOWS\system32\net.exe,"
4/22/2007 18:10:03,592,8,"3836,C:\WINDOWS\system32\cscript.exe,4028,"
4/22/2007 18:10:09,593,8,"3836,C:\WINDOWS\system32\cscript.exe,"
4/22/2007 18:10:09,592,8,"832,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"832,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"3244,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"3244,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"4036,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"4036,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"2668,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"2668,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"328,C:\WINDOWS\system32\reg.exe,4028"
4/22/2007 18:10:09,593,8,"328,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"1140,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"1140,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"3996,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"3996,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"1012,C:\WINDOWS\system32\pwdump.exe,4028,"
4/22/2007 18:10:09,593,8,"1012,C:\WINDOWS\system32\pwdump.exe,"
4/22/2007 18:10:10,593,8,"1732,C:\WINDOWS\system32\dns.exe,"
4/22/2007 18:10:25,593,8,"4028,C:\WINDOWS\system32\cmd.exe,"

So, just what is happening? We see that PID 1732 started it all. If you jump down to the second to last line, you'll see what PID 1732 was - that's right dns.exe, which is where system level access was granted and the reverse shell was executed from. Every other process listed was called from PID 4028 which is cmd.exe. The reg.exe calls were successful in changing the ErrorReporting values I listed in Part II, so ErrorReporting was effectively disabled.

However, we know that something was missed. Taskkill.exe was listed in the script in many places, and that's what looked like the cause of dns exiting is, however as evidenced by the process tracking log, we can see that taskkill was never called. Is this because it was never called, or did windows miss the boat and not log it? The answer is evident, but I'll make this somewhat interactive. What killed dns.exe? *answer at the end of this entry*

Application Log:
Nothing of value found here.



I also grabbed the IE history using Prodiscover and found the following.
Internet Activity Information file: E:\132.236.62.102-04222007\PhysicalDrive0.eve\C:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\index.dat
File Deleted: No
Browser Type: Internet Explorer
URL: http://www.dit.net/images/pwdump.exe
File Name: pwdump[1].exe
Last Modified: 04/22/2007 14:06:33
Last Accessed: 04/22/2007 18:10:09
Local Directory:
Type: URL
HTTP Header: HTTP/1.1 200 OK
X-Powered-By: ASP.NET
Content-Type: application/octet-stream
ETag: "809a98f5885c71:ade"
Content-Length: 90624
~U:system

As we can see by the bolded text, the user SYSTEM downloaded pwdump, as Harlan pointed out.


MAC times:
File Name,File Type,Cr Date,Acc Date,Mod Date
rasadhlp.dll,Executable File,1/4/2006 16:30,4/22/2007 18:09,3/24/2005 19:12
vgaoem.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
cmd.exe,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/24/2005 18:57
dosapp.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
ega40woa.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
cga80woa.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
cga40woa.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
dbg0.log,Unknown File Type,4/22/2007 18:09,4/22/2007 18:09,4/22/2007 18:09
net1.exe,Executable File,1/4/2006 16:31,4/22/2007 18:09,3/24/2005 19:07
net.exe,Executable File,1/4/2006 16:31,4/22/2007 18:09,3/24/2005 19:07
R00000000000a.clb,Unknown File Type,1/4/2006 15:00,4/22/2007 18:10,1/4/2006 15:00
imm32.dll,Executable File,1/4/2006 16:32,4/22/2007 18:10,3/24/2005 19:05
wshext.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:26
sensapi.dll,Executable File,3/25/2003 8:00,4/22/2007 18:10,3/25/2003 8:00
msisip.dll,Executable File,1/4/2006 16:31,4/22/2007 18:10,3/24/2005 19:07
vbscript.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:26
rtutils.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:13
msdart.dll,Executable File,1/4/2006 16:31,4/22/2007 18:10,3/24/2005 19:07
scrobj.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:13
iphlpapi.dll,Executable File,1/4/2006 16:32,4/22/2007 18:10,3/24/2005 19:05
winmm.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:26
msado15.dll,Executable File,1/4/2006 16:33,4/22/2007 18:10,3/24/2005 19:07
tapi32.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:25
msxml3r.dll,Executable File,1/4/2006 16:31,4/22/2007 18:10,3/24/2005 19:07
mscorie.dll,Executable File,1/2/2006 13:15,4/22/2007 18:10,3/24/2003 22:31
9PMKWROZ,Folder,1/2/2006 13:20,4/22/2007 18:10,4/22/2007 18:10
$I30,Unknown File Type,1/2/2006 13:15,4/22/2007 18:10,1/4/2006 16:41
msvcr71.dll,Executable File,1/2/2006 13:15,4/22/2007 18:10,2/24/2003 16:42
v1.1.4322,Folder,1/2/2006 13:15,4/22/2007 18:10,1/4/2006 16:41
mscoree.dll,Executable File,3/24/2005 21:41,4/22/2007 18:10,3/24/2005 21:41
reg.exe,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:13
cscript.exe,Executable File,1/4/2006 16:32,4/22/2007 18:10,3/24/2005 18:58
msxml3.dll,Executable File,1/4/2006 16:31,4/22/2007 18:10,3/24/2005 19:07
shimeng.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:13
pwdump[1].exe,Executable File,4/22/2007 18:10,4/22/2007 18:10,4/22/2007 18:10
wbemcons.dll,Executable File,1/4/2006 16:33,4/22/2007 18:10,3/24/2005 19:26
default.LOG,Unknown File Type,1/2/2006 8:06,4/22/2007 18:10,4/22/2007 18:10
system.LOG,Unknown File Type,1/2/2006 8:06,4/22/2007 18:10,4/22/2007 18:10
httperr1.log,Unknown File Type,6/28/2006 0:20,4/22/2007 18:10,4/22/2007 18:10

Anything listed here was touched during the attack. You'll see folders, dll's, exe's, fonts and a few odd files. While these files don't tell us who accessed them, it gives us a blueprint for testing. If we created a virtual machine and ran the attackers scripts, most if not all of these should show up as being accessed.

Of some note is this file: R00000000000a.clb It lives in C:\Windows\Registration and it appears to be related to COM+ applications or having debug rights on a system, which isn't typical for most users. If anyone has more information about this, please share it.

Other locations of artifacts:
$LogFile - If one were so inclined you could reconstruct a lot of the event by using this file alone.
File slack and unallocated space
httperr1.log contained related information as the attacker first scanned my honeypot looking for open ports.

Where there were no artifacts:
Prefetch
MRU
MUICache
UserAssist




I hope this series of entries has shown why we need to use multiple sources of evidence to corroborate and build a strong case and how to do it as well. Digital evidence is largely circumstantial, and we can rarely prove "who" did something, but when evidence from multiple sources is collected and compared, we can reconstruct the events that took place.

*memory analysis coming soon - I hope*


*dns.exe answer*

To answer this question we need to look at the binary pwdump.exe. The strings listed previously indicate some of the capabilities of this particular pwdump binary and provides us enough clues so we can create a hypothesis and test it. I hypothesized that the script didn't actually kill dns, and the script doesn't directly patch the dns hole.
To test this I created an exemplar system running Windows Server 2003 SP1 and DNS to test my hypothesis. The test system was created using VMware Server 1.02 build 39867 running on an Ubuntu Server system.

The test:
copy pwdump[1].exe to the test system, and execute it using: pwdump[1].exe %RANDOM%.

Result:
Upon Execution, we can see the following at the command prompt:


The system was then restored to a snapshot and pwdump was run again, this time by Inctrl5.

InCtrl5 excerpt:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters "RpcProtocol"
Old type: REG_DWORD
New type: REG_DWORD
Old data: 01, 00, 00, 00
New data: 04, 00, 00, 00

System Event log:
Event Type: Error Date: 05/04/2007 Time: 12:38:13 PM Source: Service Control Manager
Event ID: 7034 EventDescription:The DNS Server service terminated unexpectedly. It has done this 1 time.

Conclusion:
pwdump kills dns.exe and "patches" the registry by using the Microsoft workaround.
This pwdump binary also unpacks the samdump.dll that is contained within it.
If anyone is interested in this file for review, let me know.

Sector Inspector

While browsing around today I came across a *not so* highly advertised tool from Microsoft. It was a late addition to the Server 2003 resource kit called Sector Inspector. Before today, I had never heard of this tool and I've never seen in mentioned.

What the heck does it do?
Well, Microsoft explains it like this: SecInspect.exe is a command-line diagnostics tool that allows administrators to view the contents of master boot records, boot sectors, and IA64 GUID partition tables. Additional features include creating hex dumps of binary files and backup/restore of sector ranges. YES Linux does and has had this capability for...years.

Sounds kind of cool eh?
Let's see what this thing can do.

c:\Program Files\Windows Resource Kits\Tools>secinspect.exe -n
0001.033

Sector Inspector Copyright Microsoft Corporation 2003
===========================================================================
Target - \\.\PHYSICALDRIVE0
18241 Cylinders
255 Heads
63 Sectors Per Track
512 BytesPerSector
12 MediaType

===========================================================================
Master Boot Record
===========================================================================
| B | FS TYPE | START | END | | |
| F | (hex) | C H S| C H S| RELATIVE | TOTAL |
===========================================================================
| * | 07 | 0 1 1|1023 254 63| 63| 163846872|
| | 00 | 0 0 0| 0 0 0| 0| 0|
| | 00 | 0 0 0| 0 0 0| 0| 0|
| | 00 | 0 0 0| 0 0 0| 0| 0|
===========================================================================
Disk Signature 0xe0efe0ef

Partition #1 NTFS backup boot sector at LBN 163846934.

---------------------------------------------------------------------------
Primary Partition 1
NTFS BIOS Parameter Block Information

BytesPerSector : 512
Sectors Per Cluster : 8
ReservedSectors : 0
Fats : 0
RootEntries : 0
Small Sectors : 0 ( 0 MB )
Media Type : 248 ( 0xf8 )
SectorsPerFat : 0
SectorsPerTrack : 63
Heads : 255
Hidden Sectors : 63
Large Sectors : 0 ( 0 MB )

ClustersPerFRS : 246
Clust/IndxAllocBuf : 1
NumberSectors : 163846871 ( 80003.4 MB )
MftStartLcn : 786432
Mft2StartLcn : 10240429
SerialNumber : 6388384532698611716
Checksum : 0 (0x0)

---------------------------------------------------------------------------


Just that simple command spits out a bunch of useful information about the drives in your system(I am only showing you one of my drives).

The two pieces of text in bold are important for two different sets of people. The first - the disk signature is used to map a Physical drive to a logical drive letter. In the MBR it lives at offset 0x1b8 and is 4 bytes long, and it can also be found in the registry under the MountedDevices key. This is useful information for at least one major reason; Corroboration.

Here's a little scenario:
You seize a system and note that there is only one drive present in the system. You acquire an image of the disk and you note that the disk had two partitions (C: D:) and during analysis you look in HKLM\SYSTEM\MountedDevices. You see a DosDevice labeled \DosDevices\E:(assume that E: is actually on a different physical volume for this) but you know that you didn't find another disk in the system at the time. Looking at the first 4 bytes of the value for \DosDevices\E: you see the Disk Signature that looks like this:
0000 EF E0 EF E0

Now you know you're looking for a drive with a disk signature of EFE0EFE0. When you go back to the scene and search some more you find a disk buried in a drawer. After you image this disk, you run secinpsect -n and find that the disk signature matches the missing Volume and DosDevice Information in the registry. I know there are other tools that do this..but secinspect is free and we all like free.

The second bit of bolded text is useful for people wanting to restore corrupted or missing boot sectors.

Note that the tool also shows you the logical cluster number of where the MFT starts.

One other useful feature of the tool is you can convert 64Bit hex file times to UTC format. Take the Vista Backup Time I talked about previously and used Dcode to convert the timestamp.
That value 704ac9ebcc6dc701, was a 64 bit timestamp. Using secinspect I can convert the time via the commandline:
C:\Program Files\Windows Resource Kits\Tools\secinspect.exe -time 01c76dccebc94a70
0001.033

Sector Inspector Copyright Microsoft Corporation 2003


UTC TIME 03/24/2007 04:28:49.0994

That's pretty sweet.

Vista Complete System Backup

Lately, I've been kicking around a few Vista Enterprise systems for testing and am working analyzing some of the "new features" of Vista. One such "new feature" is the Backup and Restore Center.
Microsoft decided to change the backup program a bit in this latest OS release. They finally moved away from the old interface they stole from Seagate and Veritas.

As you can see below, we now get the flashy GUI that tells us some interesting information. We can see when I made a complete disk image and when I tried out the shadow copy backup.


After making these backups I thought, hey wait..this has got to exist in the Registry. Like everything else in Windows there is indeed a Registry entry for the new Windows backup system.
You can check it out on your own systems here:
HKLM\software\Microsoft\Windows\CurrentVersion\WindowsBackup

Underneath there I found a few subkeys, one of which is SystemImageBackup.
In here I found a series of values which I exported:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsBackup\SystemImageBackup]
"LastBackupResultHr"=dword:00000000
"LastBackupResultHrDetailed"=dword:00000000
"LastBackupTime"=hex(b):704ac9ebcc6dc701
"LastBackupLocation"="\\\\?\\Volume{2f147a6d-d29b-11db-8792-00188b27e7f8}"
"LastBackupDrive"="E:"
"LastSuccessfulBackupTime"=hex(b):704ac9ebcc6dc701
"LastSuccessfulBackupLocation"="\\\\?\\Volume{2f147a6d-d29b-11db-8792-00188b27e7f8}"
"LastSuccessfulBackupDrive"="E:"


Interesting eh? We can see a few values that should be easily recognizable and one that at first threw me off a bit. The LastBackupTime and LastSuccessfulBackupTime values are a little large for 32bit hex values aren't they? I had to do a little searching on this one because it's listed as a REG_QWORD rather than REG_DWORD. Well, QWORD is a 64 bit value in little endian. As evidenced by Dcode You can correlate the time stamps between the image above and the decoded hex datetime stamp



Now, if you look back to the first image you'll see that the image was created on my E: drive. Obviously the registry values I'm showing keeps track of the Volume Information GUID as well as the logical drive letter. Now you have a volume GUID to match up when you start looking for missing disks from a system you are investigating.

After looking at this I decided to try to write a perl script using the Parse-Win32Registry module but have had some difficulty getting it to work. I keep getting this error while trying to use dumpreg.bat. If anyone knows of a fix to this or what the cause is, let me know please.

C:\Perl\site\bin>dumpreg.bat -r f:\vistareg\SOFTWARE Microsoft\Windows\CurrentVe
rsion
Invalid key node type at offset 0x38c8
38c8 a8 ff ff ff 6e 6b 20 10 3b 06 6d b8 fc 67 c7 01 ....nk .;.m..g..
38d8 00 00 00 00 20 00 00 00 b5 0c 00 00 00 00 00 00 .... ...........
38e8 b0 47 74 00 ff ff ff ff 00 00 00 00 ff ff ff ff .Gt.............
38f8 c0 ba 00 00 ff ff ff ff 8c 00 a0 00 00 00 00 00 ................
3908 00 00 00 00 00 00 00 00 6d 00 5c 00 07 00 00 00 ........m.\.....
at dumpreg.bat line 41

There are several other subkeys I'm looking at under this Key, including the ones created for automatic backup schedules.