Links and Stuff (Registry research)

The subtitle of this blog post is "There are more things in heaven and earth than are dreamt of in your EnScript", to paraphrase Horatio.

Thanks to the SANS ISC blog, I ran across an AV product (free) called Immunet. This seems very interesting as it takes a "cloud" approach to protection...I know that "cloud" is becoming something of a buzzword in the computing industry, but maybe this will bring it home for the older folks; it take a SETI@Home approach to protection. How's that? The concept (not talking about the actual implementation) sounds pretty cool...

I ran across a tool called TrojanHunter recently that looks pretty interesting from a live system response perspective. The main page for TrojanHunter is absolutely correct...there are Trojans and other malware that don't necessarily hide on the system as much as they are DLLs injected into the memory of other processes. Therefore, when you're doing your live response, you're going to see network connections for some processes that may not normally have network connections...because it's the Trojan that's doing it.

Lately, I've been working on some Registry research, and I came across this page at the MS site, which includes the following:

Executable binary code should never be stored in the registry.

Pretty cool, eh? That's why I wrote the findexes.pl plugin for the RegRipper...Don had written on his blog not long ago about malware that wrote executable files into binary Registry values, so there had to be a way to detect this sort of thing.

As part of this Registry research I was doing, I was digging into the Shell\BagMRU data, as I had read this excellent paper on the use of the keys, but noticed that the paper didn't include anything about the binary data itself. I contacted the authors of the paper and Mr. Zhu was kind enough to respond with some information that proved to be very helpful. I took it from there and wrote up a RegRipper plugin to parse the information...several actually, that provide the information in various formats. Right now, however, it's very bare bones and the data needs to be formatted a bit (no, I take that back...a LOT) better.

Also during that research, I found something interesting...actually, a couple of somethings. First, the MUICache key on Vista has moved to the other user hive file, %LocalAppData%\Microsoft\Windows\UsrClass.dat. On a Vista system, I found the key in the UsrClass.dat file, in this path: Local Settings\Software\Microsoft\Windows\Shell\MuiCache.

The other interesting thing I found was that some of the Shell\BagMRU key appeared to be in the normal location in the NTUSER.DAT file, but there was additional information in the UsrClass.dat file, as well, in the path, Local Settings\Software\Microsoft\Windows\Shell\BagMRU. In fact, some of the information in the UsrClass.dat file seemed to be more inclusive...but that's just in my initial testing.

While we're on the topic of the Registry, its completely clear to me that the Windows Registry maintains a great deal of data, and as has been the case with memory analysis, things also seem to change as the versions of Windows change. With Vista and Windows 7, not only has a great deal of the information we would normally expect to look for on an XP system moved, but new data associated with wireless networking (specifically, binary values for wireless profiles named DateCreated and DateLastConnected) and an entirely new format has been added for the dates.

Mark has a blog post about translating the date format here; completely separately, I wrote the below code for my own use (thanks to my friends who helped me with the format):

sub parseDate128 {
my $date = $_[0];
my @months = ("Jan","Feb","Mar","Apr","May","Jun","Jul", "Aug","Sep","Oct","Nov","Dec");
my @days = ("Sun","Mon","Tue","Wed","Thu","Fri","Sat");
my ($yr,$mon,$dow,$dom,$hr,$min,$sec,$ms) = unpack("v*",$date);
$hr = "0".$hr if ($hr < 10);
$min = "0".$min if ($min < 10);
$sec = "0".$sec if ($sec < 10);
my $str = $days[$dow]." ".$months[$mon - 1]." ".$dom." ".$hr.":".$min.":".$sec." ".$yr; return $str;
}

Okay, so not only does this show us that, clearly, things change between versions of Windows in more than just the memory analysis arena. So, not only does the Registry contain some time stamps in 32-bit Unix time format, as well as the more expected 64-bit Windows FileTime format, but now there's this 128-bit whatever format for time stamps!

More to come...