Webcheck.dll

I saw via Twitter today that a new post had gone up on the TrustWave SpiderLabs Anterior blog, regarding some malware that the TW folks (by that, I mean Chris Pogue) had detected during some engagements.

I think it's great when analysts and organizations share this kind of information, so that the rest of us can see what others are seeing.  So, a big thanks goes out to TrustWave, and the next time you see Chris at a conference, be sure to say hi and buy him a beer...or better yet, treat him some bread pudding!


What I'd like to do is take a moment to go through the post and discuss some things that might add something of a different perspective or view to the issue, or perhaps something .

As you can see from the post, Chris uses timeline analysis to locate the malware in question, and he's got some really good information in the post about creating the timeline for analysis (Chris uses the log2timeline tools).  I'm sure that there's quite a bit about the engagement and the analysis that weren't mentioned in the post, as Chris jumps right to the target date within his timeline and locates the malware.

I like the fact that Chris uses multiple analysis techniques to corroborate and check his findings.  For example, in the post, Chris mentions looking at the file's $STANDARD_INFORMATION and $FILE_NAME attributes in the MFT, and confirming that there were no indications of "time stomping" going on.  This is a great example that demonstrates that anti-forensics techniques target the analyst and their training, and that a knowledgeable analyst isn't slowed down by these techniques.  I think that the post also demonstrates how timelines can be used to add context to what you're looking at, as well as increase the level of confidence that the analyst has in that data.

One of the things that kind of struck me as odd in the post is that there's mention of the "regedit/1" entry in the RunMRU key, and then the post jumps right to discussing the InProcServer32 key, based on the timeline.  The RunMRU information (ie, key LastWrite time) is from a user's hive, so another key of interest to check might be the following:

Software\Microsoft\Windows\CurrentVersion\Applets\Regedit

As you'd think, this key contains information about the key that had focus when the user closed RegEdit.  Specifically, the LastKey value (mentioned in MS KB 244004) contains the name of that key.  This value might be used to make a bit of a transition between the RunMRU data and the changes to the InProcServer32 key that's mentioned in the post, and possible provide insight into how the malware was actually deployed on the system. 

As Chris points out in the post, the value type being changed from "REG_SZ" (string value) to "REG_EXPAND_SZ" does allow for the use of unexpanded references to environment variables, such as %SystemRoot%.  One statement that I don't really follow is:

So now the threading for webcheck.dll is no longer pointing to the legitimate file, but to the malware!

The threading model listed doesn't have anything to do with the path...I'm going to have to reach to Chris and find out what he was referring to in that statement.  He follows that up with this statement later in the post:

So not only did the attackers use a legitimate threading, but they made sure to use a shell extension that was trusted by Windows.

Again, I'm not clear on the "threading" part of that statement, but Chris is quite correct about the shell extension issue.  Basically, the Windows shell (Explorer.exe), which is launched when a user logs into the system, will load the approved shell extensions, which includes this particular malware.  Trust seems to be implicit, as there are no checks run when Explorer goes to load a shell extension DLL.  This is a bit different from the shell extension issue I'd mentioned last August, in part because it doesn't use the DLL Search Order issue.  Instead, it simply points Explorer directly to the malware through the use of an explicit path.

All in all, I'm glad to see that Chris and the TrustWave folks sharing this kind of thing with the community.  I do think that there's more that isn't being said, like how the malware actually got on the system (ie, how it was deployed), but hey, we all know that there are some things that can't be said about engagements.  And that's okay.

Links

WFA Translations
Thanks to the great folks at Elsevier and BJ Public, Windows Forensic Analysis 2/e is now available in Korean!  Very cool!  A copy of this goes on my shelf right next to the French translation, as well as the Chinese translation of WFA 1/e.  I have to say, this is very, very cool...to look up at my bookshelf and see that someone thought enough of something I wrote to translate it.  I have no idea what it says, but it's cool, just the same!

Security Ripcord
After a lengthy absence, Don is finally back blogging again...and he returns with a bang!  Don's latest post, It will never be too expensive, takes a shot at the statement made by security "professionals" and "experts" to their customers for years...that one should employ/deploy enough "security" to make it too expensive for an attacker to get in, and they'll go away.  It's pretty clear from Don's comments and reasoning that this is clearly a statement that has been made over and over for years, without folks really thinking about what's being said, and how the threat itself has evolved.  This statement may have been true in the early days of the Internet, but the Internet and cybercrime have changed and developed...but apparently, the thinking behind the statement hasn't.  Don does a great job of pointing this out, and with all the talk about advanced persistent and subversive multi-vector threats, doesn't it stand to reason that for some folks, for the really dedicated folks, they're just gonna laugh at your expensive security as they blow right on through it?  Much like he did when he was in the Corps, Don takes a shot at this statement and hits it squarely, center of mass.

Sniper Forensics
Speaking of snipers, Part 3 of Chris's Sniper Forensics series has been posted to the SpiderLabs Anterior blog, be sure to check it out.  I think that one of the biggest things that Chris points out in this segment is defining the target...with respect to IR, why are you there?  What are you there to do?  When it comes to digital forensic analysis, the same thing applies; if someone where to ship me a drive (or image), with clearly defined goals of what they were looking for, I might usually estimate an analysis time of 24 hrs or less.  However, if you were to ship me a drive and say, "...find all bad stuff...", I could spend several weeks looking and never find why you define as "bad"...in part, because you never defined it.  I've seen analysts leave site with a drive, having been told to find "bad stuff"; some initial searching found clear indications of the existence and use of "hacker" tools.  However, upon reporting that to the customer, the analyst was told that the former employee's job was to hack stuff, so the existence of hacking tools wasn't "bad".  Hey, who knew.

Defining the goals of an engagement, and the parameters for success, are critical to that engagement.  Having a contract that just says "do analysis" without any defined goals of that analysis leave the analyst or the team with...what?  Once the hours in the contract have been consumed, a report is delivered to the customer who then says, "no, this isn't what we wanted."

This isn't just an important point for consultants, it's equally important (or perhaps even more so) for the customer.  If you're seeking IR or DF services, ensure that you clearly define what you're looking for, and ensure that this is stated clearly in the contract before you sign it.

MFT Slack
Lance posted an Enscript recently that was written to extract the slack space from MFT records.  This isn't something that I've had a need to do before, but it is interesting and worth taking a look at.  I'm not entirely sure what context you can get from items found in MFT slack, as MFT records are 1024 bytes long; however, Lance thought enough of this to write an Enscript for it, so there must be something there!

On that note, I recently updated the online repository for the Windows Registry Forensics tools, to include Jolanta's regslack tool for locating deleted keys and values in hive files.  For usage and examples of how this tool has been used, check out the book.

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."

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, Tools and Stuff

PDF Stream Dumper
From over at RE Corner comes the PDF Stream Dumper tool; actually, this one has been out for some time now.  This tool was written in VB6, and comes with a number of automation scripts.  Swing on by Lenny's blog for some create examples of how to use it, or check out this KernelMode page for some other examples of the dumper being used.

If you're not too put off by CLI tools, you might consider using this in conjunction with Didier's PDF tools.  Didier's stuff is also in use by VirusTotal.  That's not to say that one's better to use than the other...it's good to have both available.

While we're on the subject of document metadata, it's a good idea to mention Kristinn Gudjonsson, creator of log2timeline, also created the read_open_xml.pl Perl script for extracting metadata from MS Word 2007 documents (use and output described at the SANS Forensic Blog).

TechRadar
There's an interesting article up on TechRadar about how to perform a forensic PC investigation, and it references using OSForensics, available from PassMark Software.  I have to say, I'm a bit concerned about articles like this, even when they suggest early in the article that performing the actions described in the article can be "a little morally dubious".

The beta of OSForensics was recently made available for a limited time, for free.  However, that offer was originally made as "LE only", but seems to have changed recently.

OSForensics
It looks like the folks at PassMark Software removed the LE-only restriction for downloading the OSForensics beta, so I downloaded the 32-bit version to my XP system this morning.

After installing OSForensics and looking around (noticed the nice icons and graphics), I created a new case, and then began looking for a way to load a test image into the tool.  I didn't have much luck, so I went immediately to the Help, which is provided online, in HTML format.  I went through the index and found the word "Image", and from there found this:

In many cases it may be desirable to work with data from a disk image rather than the physical disk itself. Whilst OSForensics does not deal with disk images directly itself Passmark provides a set of free external tools in order to support working with disk images.

So, it appears that OSForensics is not intended for dead-box/post-mortem analysis.  Some of the available tools, such as System Information and Memory Viewer, pertain to the system on which OSForensics is running.  PassMark does offer the OSMount program, which allows you to mount a raw/dd image as a drive letter, and from there you can use OSForensics in the intended fashion.  As such, I'd guess that there'd be no issues using any of the various other mounting techniques and tools, including accessing VSCs.

Of all of the functionality, the one that really jumps out is the hash set comparison tools.  PassMark provides a number of hash sets for known-good OS files at their download site; however, as with any similar functionality based on hash sets, I can easily see how this can become cumbersome very quickly.  You either scan for all of the hashes, or you run into issues with analysts deciding which hash sets to run, and (more importantly) documenting those that they do run.

OSForensics also provides string and file name search functionality, logging of activity, and the ability to install OSForensics to a USB drive.  I'm sure that this tool will be useful to examiners; for my own uses, however, it simply does not provide enough of the core functionality that I tend to use during my examinations. As a test, I mounted a test image as a read-only F:\ drive and opened OSForensics, and I have to say, moving through the interface wasn't the most intuitive, or easy to use.  However, I may be somewhat biased, given my experience and usual work processes.
No Alternative
Eric's got a rather insightful post over at the AFoD blog.  More and more folks are getting into the cell phone and smart phone market, and those little buggers are really very powerful when you take a look at them.  They also tend to contain more and more storage space.  Of course, we need to keep in mind that the tablet market is still there in that space between the smart phone and the laptop, as well.

I can see where Eric's going with the post, but I have to say from the private/corporate perspective, this isn't such a huge issue.  I would expect that if it ever does become and issue, it'll be an emergency (for legal/compliance purposes) and one-off, not something that gets done on a regular basis, with the cost of applications and training being amortized across multiple customers.  However, from a public perspective, I can definitely see how this is going to be more and more of an issue...after all, how "gangsta" can you really be lugging around a Dell Latitude laptop?

Reading/Education
There are some great new resources over at the e-Evidence site, including stuff about MacOSX artifacts, iPhone and smart devices, Windows artifacts, etc.  This site is always a great place to go and find lots of new and interesting stuff.

Network and Wireless
A question popped up on a list this morning regarding wireless assessments and tools.  The original question asked about an alternative to NetStumbler, that supported a specific NIC, and the first response was for ViStumbler.  ViStumbler is open-source and was originally written to be supported by Vista, but apparently runs on Windows 7, as well.

If you're doing any network forensics, you might also consider NetworkMiner as a viable resource, and something to add to your toolkit right alongside Wireshark.

Tool Sites
ForensicCtrl had a listing of free computer forensics tools available.
List of Windows open source tools
Check out the Collaborative RCE Tools library for a wide range of tools.

Carving

I was looking at a Windows 2003 system, and found that I was somewhat short on Event Log entries, with respect to the incident window. As I looked and used my evtrpt.pl Perl script to get statistics on the Sec, Sys, and App Event Logs, I noticed that Sec and Sys Event Logs only contained a few days of event records. The Application Event Logs actually went back a while past the incident window. I looked a bit closer to the output of evtrpt.pl and noticed that the Security Event Log had an event ID 517 record, indicating that the Event Log had been cleared.

So the first thing I did was run TSK blkls against the image to extract the unallocated space from the image file. I then ran MS's strings.exe (with the "-o" and "-n 4" switches), and then had two files to work with...the unallocated space, and a list of strings found in unallocated space, along with the offset of each string. So I then wrote a Perl script that would go through the strings output and find each line the contained "LfLe", the "magic number" for Windows 2000/XP/2003 event records.

With this list, the script would then run through the unallocated space by first going to the offset of the "LfLe" string, and backing up 4 bytes (DWORD). According to the well-documented event record structure, this DWORD should be the size of the record. As values can vary, and there is no one specific value that is correct, the way to check for a valid event record is to advance through unallocated space for the length provided by the DWORD, and the last DWORD in this blob should be the same as the size of the record. For example, if the initial size DWORD is 124 bytes, you should be able to advance through the file 120 bytes, and the next DWORD should also be 124.

Using this approach, I was able to extract over 330 deleted event records. I've used similar techniques in the past, to extract 100 bytes on either side of a keyword from the pagefile. This is an excellent way to gather additional information that you wouldn't normally be able to 'see' through most tools, as well as to look for and carve well-defined structures from unstructured data.

Tools and Stuff

RegRipper
Brett Shavers, who maintains the RegRipper site, has compiled an archive of new plugins and posted them for download. Brett's done a fantastic service for the DF community, in not only setting up the site for RegRipper, but maintaining it, and posting this archive of plugins. A huge thanks to Brett...and if you see him at a conference, be sure to buy him a beer!

As a side note, along with the release of Windows Registry Forensics, I had posted the DVD contents here, as well. The archive contains what's on the DVD, so while you can get it, it's really most helpful when used in conjunction with the book.

El Jefe
Over at the HolisticInfoSec blog, Russ shared a little El Jefe love recently. Russ says that El Jefe is a Windows-based process monitoring tool that "intercepts native Windows API process creation calls, allowing you to track, monitor, and correlate process creation events. " Very cool. The tool is in version 1.1 and is available from the good folks at Immunity, and runs on Windows 2000/XP through Windows 7, reportedly in both 32- and 64-bit versions. This looks like a great tool not only for dynamic malware analysis, but perhaps also for incident preparation. I mean, wouldn't you like to know what ran on a system?

Anti-Rootkit
I haven't been doing a lot of live box forensics/IR work, but I ran across the Tuluka kernel inspector recently, and it caught my eye. If you've read my books, you know that I've used GMER in the past. I can't say that I've really had issues with rootkits, and many times I just get to do "dead box" forensics, but this looks like another tool that folks may find useful.

NetworkMiner
Erik sent out an email recently to say that NetworkMiner had gone to version 1.0. Congrats to Erik and all the folks who've worked on or used NetworkMiner! NM is an excellent compliment to other network data analysis tool such as Wireshark. Per Erik, some of the new features include:

Here are some new features in NetworkMiner since the previous version:

* Support for Per-Packet Information header (WTAP_ENCAP_PPI) as used by Kismet and sometimes Wireshark WiFi sniffing.
* Extraction of Facebook as well as Twitter messages into the message tab. Added support to extract emails sent with Microsoft Hotmail (I.e. Windows Live) into Messages tab.
* Extraction of twitter passwords from when settings are changed. Facebook user account names are also extracted (but not Facebook passwords).
* Extraction of gmailchat parameter from cookies in order to identify users through their Google account logins.
* Protocol parser for Syslog. Syslog messages are displayed on the Parameter tab.

Pretty cool stuff! Check it out, and be sure to check out the NM Wiki if you have any questions! Along with tools like Wireshark and NetWitness Investigator, NetworkMiner can be extremely useful for IR from a network perspective.

EvtxParser
Andreas has released v1.0.7 of his EvtxParser, a Perl-based approach for parsing Vista and Windows 7 Windows Event Log/EVTX files.

Highlighter
Mandiant has released a new version of Highlighter. Not much else to say, really...if you use this tool, take a look at the updates. I know several folks who find Highlighter to be very useful.

PointSec
More of a process than a tool, the folks over at Digital Forensic Solutions have posted to their blog about how to go about examining PointSec-encrypted drives. I can't say that I've had issues with encrypted drives...I've either had the admin boot the system and we'd image it live, or I acquired images of the drives with the customer knowing full well that the images would be encrypted (imaging job, no analysis). However, DFS's post provides some great information.

Java
Also not a tool, but really kind of cool...Corey's written up a nice post about some analysis he did that involved looking into the Java cache folder. Corey walks through identification of the issue, going so far as to demonstrate decompiling a Java .jar file. What I really like about Corey's posts is how complete they are, without giving away any case specific information. This isn't something that you see very often in the IR/DF community...but Corey clearly demonstrates how easy it is to do this and provide a valuable teaching moment. Great job, Corey...thanks!