Links
WRF Book Reviews
Thanks to everyone who's purchased a copy of Windows Registry Forensics, and in particular to those who've taken the opportunity to post their thoughts, or more formally write a review. Paul Sanderson (@sandersonforens on Twitter), from across the pond, posted a review of the book to his blog recently. Paul has the Kindle version of the book, as that's all that's available over there at the moment.
Speaking of the book, it seems to be doing well, if the Amazon ranking is any indicator. There are a couple pretty helpful things to point out about this book that might be helpful in understanding why it might be useful for you.
First, this is the first book of it's kind. Ever.
Seriously...there are no books out there that come at the topic from the perspective of a forensic analyst. There are a number of books that include discussion of some Registry keys that are of use to an analyst, but none that discusses the Registry at the depth and breadth of WRF. My primary motivation for writing the book was to fill that gap, because I really feel that the Registry is a critical and too-often-overlooked source of forensic artifacts on a system.
Second, the book makes use of primarily free and open-source tools. This can be very important to smaller organizations, such as LE, professors and students at local community colleges, and even just to those learning or looking to develop new skills, as it puts the described capability within reach. I know that not everyone can (or wants to) learn Perl, but the tools are there...and to make it even easier, many of the tools I've written have been provided as standalone EXEs (compiled with Perl2Exe).
SPoE
I was bopping around the TwitterVerse recently and ran across a link to Mike Murr's blog, and from there found a two year old post on the Single Piece of Evidence (SPoE) myth. Mike's always been good for some well-thought-out opinions and comments, and this one is no different. What he mentions with regards to anti-forensics techniques is similar to the reactions surrounding the release of XP and then Windows 7..."OMG! What is this going to do to my investigations!" The fact is that, while each brings it's own nuances and inherent anti-forensics, each also brings with it a whole bunch of new artifacts. As Mike points out, when a user interacts with a Windows system, there are a lot of artifacts...and the same is true, albeit to a somewhat lesser degree, for malware, as well.
Hacking
If you've been watching the news lately, you're probably aware that no one seems to be immune to being compromised. Even small boroughs in PA are susceptible. While the linked article doesn't have a great deal of supporting information (no mention of the use of online banking, did the bank see a legit login from a different IP address, what the independent consultant determined, etc.). In the past, a lot of these types of issues have been attributed to the Zeus bot, and in some cases, there haven't been any indications of Zeus on what were thought to be the affected systems.
Mayor Mowen was just being a mayor when he said, "You guard against it by increasing your firewall, which is what we are in the process of doing."
Analysis
F-Secure recently posted this analysis of an MBR infector. The analysis includes a good number of hex views and listings of code in assembly language and lots of detail. It would be a good idea to read through this carefully and take note of what's said. For example, this baddy infects the MBR, and appears to make a copy (like Mebroot, here, and here) of the original MBR, placing it in sector 5.
The analysis includes the following:
Why an MBR File System Infector? Probably because it can bypass Windows File Protection (WFP). As WFP is running in protected mode, any WFP-protected file will be restored immediately if the file is replaced.
I'm not entirely sure that this is a good line of reasoning in and of itself, in part because the bad guys have done a good job at shutting WFP off for a minute, and installing their malware. WFP is not a polling service, so when it wakes back up, it has no way of knowing that a protected file was modified or replaced. However, it appears from the write-up that the malware infects userinit.exe at startup, possibly prior to WFP starting up, which may be the entire reason for infecting the MBR first.
I'm curious as to which version of Windows this malware was executed on, as the version of userinit.exe on my XP system, as well as a Windows XP VM I have, is 26Kb in size, slightly larger than what's shown in the write-up. However, the write-up does provide a couple of good tips that an analyst can use to detect the presence of this malware.
If you're a responder or forensic analyst, and this one is tough for you to read and follow, keep something in mind that Cory posted to Twitter today (17 Feb), which included (in part), "...you shouldn't rely on malware fetishists for incident response advice." Excellent point.
FakeAV
Another interesting analysis popped up...thanks to Ken for posting his analysis of a FakeAV bit of malware. In his write-up, Ken does a pretty thorough job of documenting what he did, how he did it, and what he found. For example, one of the Registry key that were modified is:
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations
According to Ken, the "LowRiskFileTypes" value was added with the data ".exe". This is interesting, but how does it apply to the malware infection. MS KB article 883260 provides some hints to this. This same KB article provides a hint about why the following key might also be updated:
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments
In Ken's write-up, this key had the "SaveZoneInformation" value added, with "1" as the data. Remember how back with Windows XP SP2, files downloaded via Outlook or IE had a "zoneid" Alternate Data Stream (ADS) attached to the file (this is described on pg. 314 of WFA 2/e)? When analyzing a system with ADS on it, it's usually pretty easy to see them at a glance, as some of the commercial forensic analysis applications list them in red. However, this setting appears to tell the system to not create the ADS.
Finally, Ken mentions that there was a change to the following key:
HKCU\Software\Microsoft\Internet Explorer\Download
In this case, the CheckExeSignatures value was changed from 'yes' to 'no'. TechNet has some information about the value (maybe...the path is a little different,using "Main" in the key path, rather than "Download") and what effect it may have on the system. Other malware seems to modify the same set of keys, as seen here, and with this FakeAV write-up from Sophos.
There are a couple of interesting take-aways from this write-up, I think. First of all, it's great that Ken took the time not only to run this analysis, but to share it with others. I think one of the biggest mistakes analysts make when it comes to sharing and collaboration is assuming that everyone else has already seen everything. I tried to shoot this one down at the WACCI conference last year, where I actually met Ken. I don't see many FakeAV issues at all, to be honest.
Another take-away is that publicly available information provided by the vendor is utilized to take some steps towards not only allowing the malware to run, but also towards anti-forensics. Think about it...by telling the system to not create the ADS for downloaded files, that removes one of the indicators that analysts could use to identify the malware's propagation mechanism.
Finally, this clearly demonstrates that there are steps analysts can use to detect malware on a system beyond running an AV scanner. For example, there are number of Registry keys that Ken identified, as well as what's listed in other write-ups, that could be used to detect the potential presence of malware, even if the malware itself is not detected by AV. The rather odd value in the user's Run key is something of a give-away, but RegRipper already has a plugin that dumps the contents of that key. Now we have other keys that can be used with RegRipper or a forensic scanner to comb through the appropriate hives and check for the possible existence of malware.
IR
Last, but certainly not least, Chris posted today regarding IR activities; in particular, using a batch file to dump Registry hives from a live system for analysis. Chris actually posted the batch file he used...take a look. This one shows that Chris's command line kung fu is very good!
Thanks to everyone who's purchased a copy of Windows Registry Forensics, and in particular to those who've taken the opportunity to post their thoughts, or more formally write a review. Paul Sanderson (@sandersonforens on Twitter), from across the pond, posted a review of the book to his blog recently. Paul has the Kindle version of the book, as that's all that's available over there at the moment.
First, this is the first book of it's kind. Ever.
Seriously...there are no books out there that come at the topic from the perspective of a forensic analyst. There are a number of books that include discussion of some Registry keys that are of use to an analyst, but none that discusses the Registry at the depth and breadth of WRF. My primary motivation for writing the book was to fill that gap, because I really feel that the Registry is a critical and too-often-overlooked source of forensic artifacts on a system.
Second, the book makes use of primarily free and open-source tools. This can be very important to smaller organizations, such as LE, professors and students at local community colleges, and even just to those learning or looking to develop new skills, as it puts the described capability within reach. I know that not everyone can (or wants to) learn Perl, but the tools are there...and to make it even easier, many of the tools I've written have been provided as standalone EXEs (compiled with Perl2Exe).
SPoE
I was bopping around the TwitterVerse recently and ran across a link to Mike Murr's blog, and from there found a two year old post on the Single Piece of Evidence (SPoE) myth. Mike's always been good for some well-thought-out opinions and comments, and this one is no different. What he mentions with regards to anti-forensics techniques is similar to the reactions surrounding the release of XP and then Windows 7..."OMG! What is this going to do to my investigations!" The fact is that, while each brings it's own nuances and inherent anti-forensics, each also brings with it a whole bunch of new artifacts. As Mike points out, when a user interacts with a Windows system, there are a lot of artifacts...and the same is true, albeit to a somewhat lesser degree, for malware, as well.
Hacking
If you've been watching the news lately, you're probably aware that no one seems to be immune to being compromised. Even small boroughs in PA are susceptible. While the linked article doesn't have a great deal of supporting information (no mention of the use of online banking, did the bank see a legit login from a different IP address, what the independent consultant determined, etc.). In the past, a lot of these types of issues have been attributed to the Zeus bot, and in some cases, there haven't been any indications of Zeus on what were thought to be the affected systems.
Mayor Mowen was just being a mayor when he said, "You guard against it by increasing your firewall, which is what we are in the process of doing."
I bring this up, because there's traffic on Twitter recently with respect to the RSA conference, and the definition of "cyberwar", or more specifically, just "war". I'd suggest that any action that forces your adversary to turn away for his main objective (attacking, etc.) and focus resource elsewhere, even if this tactic is used purely for an attrition effect, should be considered part of "war", declared or otherwise.
Analysis
F-Secure recently posted this analysis of an MBR infector. The analysis includes a good number of hex views and listings of code in assembly language and lots of detail. It would be a good idea to read through this carefully and take note of what's said. For example, this baddy infects the MBR, and appears to make a copy (like Mebroot, here, and here) of the original MBR, placing it in sector 5.
The analysis includes the following:
Why an MBR File System Infector? Probably because it can bypass Windows File Protection (WFP). As WFP is running in protected mode, any WFP-protected file will be restored immediately if the file is replaced.
I'm not entirely sure that this is a good line of reasoning in and of itself, in part because the bad guys have done a good job at shutting WFP off for a minute, and installing their malware. WFP is not a polling service, so when it wakes back up, it has no way of knowing that a protected file was modified or replaced. However, it appears from the write-up that the malware infects userinit.exe at startup, possibly prior to WFP starting up, which may be the entire reason for infecting the MBR first.
I'm curious as to which version of Windows this malware was executed on, as the version of userinit.exe on my XP system, as well as a Windows XP VM I have, is 26Kb in size, slightly larger than what's shown in the write-up. However, the write-up does provide a couple of good tips that an analyst can use to detect the presence of this malware.
If you're a responder or forensic analyst, and this one is tough for you to read and follow, keep something in mind that Cory posted to Twitter today (17 Feb), which included (in part), "...you shouldn't rely on malware fetishists for incident response advice." Excellent point.
FakeAV
Another interesting analysis popped up...thanks to Ken for posting his analysis of a FakeAV bit of malware. In his write-up, Ken does a pretty thorough job of documenting what he did, how he did it, and what he found. For example, one of the Registry key that were modified is:
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations
According to Ken, the "LowRiskFileTypes" value was added with the data ".exe". This is interesting, but how does it apply to the malware infection. MS KB article 883260 provides some hints to this. This same KB article provides a hint about why the following key might also be updated:
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments
In Ken's write-up, this key had the "SaveZoneInformation" value added, with "1" as the data. Remember how back with Windows XP SP2, files downloaded via Outlook or IE had a "zoneid" Alternate Data Stream (ADS) attached to the file (this is described on pg. 314 of WFA 2/e)? When analyzing a system with ADS on it, it's usually pretty easy to see them at a glance, as some of the commercial forensic analysis applications list them in red. However, this setting appears to tell the system to not create the ADS.
Finally, Ken mentions that there was a change to the following key:
HKCU\Software\Microsoft\Internet Explorer\Download
In this case, the CheckExeSignatures value was changed from 'yes' to 'no'. TechNet has some information about the value (maybe...the path is a little different,using "Main" in the key path, rather than "Download") and what effect it may have on the system. Other malware seems to modify the same set of keys, as seen here, and with this FakeAV write-up from Sophos.
There are a couple of interesting take-aways from this write-up, I think. First of all, it's great that Ken took the time not only to run this analysis, but to share it with others. I think one of the biggest mistakes analysts make when it comes to sharing and collaboration is assuming that everyone else has already seen everything. I tried to shoot this one down at the WACCI conference last year, where I actually met Ken. I don't see many FakeAV issues at all, to be honest.
Another take-away is that publicly available information provided by the vendor is utilized to take some steps towards not only allowing the malware to run, but also towards anti-forensics. Think about it...by telling the system to not create the ADS for downloaded files, that removes one of the indicators that analysts could use to identify the malware's propagation mechanism.
Finally, this clearly demonstrates that there are steps analysts can use to detect malware on a system beyond running an AV scanner. For example, there are number of Registry keys that Ken identified, as well as what's listed in other write-ups, that could be used to detect the potential presence of malware, even if the malware itself is not detected by AV. The rather odd value in the user's Run key is something of a give-away, but RegRipper already has a plugin that dumps the contents of that key. Now we have other keys that can be used with RegRipper or a forensic scanner to comb through the appropriate hives and check for the possible existence of malware.
IR
Last, but certainly not least, Chris posted today regarding IR activities; in particular, using a batch file to dump Registry hives from a live system for analysis. Chris actually posted the batch file he used...take a look. This one shows that Chris's command line kung fu is very good!
Links
Reviewed by 0x000216
on
Thursday, February 17, 2011
Rating: 5
Reviewed by 0x000216
on
Thursday, February 17, 2011
Rating: 5