Thursday, March 28, 2013

There Are Four Lights: Malware Indicators in the Registry

It can be extremely beneficial to understand various artifacts that malware creates on a system, particularly in light of the fact that AV isn't catching everything.  Most AV appears to look for and then scan across executable files...some AV does find indicators based on text-based data, such as JavaScript code, etc.

Not all malware uses the Registry for persistence.  For example, Theola uses a Chrome plugin to perform bank fraud, and W32/Crimea modifies imm32.dll in order to remain persistent (I found this variant in 2010; this is a write-up from another variant from 2007).

Not all malware creates really obvious indicators in the Registry, either.  Corey talked about indicators for a variant of ZeroAccess.  However, I analyzed a system that had been infected with another variant of ZA, one that created the HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{8AD9C840-044E-11D1-B3E9-00805F499D93} key, the effect of which is explained in this GreyHatHacker blog post.  While this isn't a persistence mechanism, it does illustrate an indicator of a malware infection.

"Detecting" Persistence Mechanisms
There was a SANS webcast in January 2012 titled Detecting Persistence Mechanisms, during which a number of persistence mechanisms were mentioned, including several found in the Registry.  However, something that wasn't mentioned was how to actually go about detecting persistence mechanisms being created by malware.  Corey recently published an excellent blog post titled, Tracking Down Persistence Mechanisms, which does a great job of illustrating how easy it is to quickly examine the contents of autostart (or "ASEP") locations, particularly in the Registry.

The process I use to detect the use of Registry persistence mechanisms and other malware artifacts is to start by adding the key LastWrite times from the Registry hives (both NTUSER.DAT and USRCLASS.DAT for users) to my timeline.  This is exactly how I found the ZeroAccess artifact I described earlier in this blog post...the modified key was right there in the timeline.  I even went so far as to examine the hive file extracted from a VSC created just prior to the LastWrite time of the key, and I was able to determine that the LastWrite time was, in fact, when the key was created (i.e., the key didn't exist in the hive file from the VSC).  Timelines are a fantastic way to add context to the data that you're looking at, as well as to increase your relative level of confidence in the validity of that data.  However, timeline analysis is best utilized as part of an overall analysis plan, developing pivot points and items of interest via other data retrieval and analysis mechanisms.

Once I find an interesting Registry artifact in close proximity to other activity on the system that is associated with the malware, I have a number of options available to me.  Many times, I will open the hive in a viewer and take a look at what information is contained in the key itself...examine the subkeys, values and data.  I can correlate this with information gleaned from online searches, and very often, quickly write a new or modify an existing RegRipper plugin.  I then ensure that the Registry artifact is included as part of my shortened view of the overall timeline, along with a clear description of why it's significant, along with supporting documentation and references.  This serves the purpose of not only providing information to my customer, but also documenting the information for my own use.  In most cases, this entire process covers a span of a couple of minutes, maybe up to an hour depending up how much information is out there and available.

When Does It Start, and Why Does It Matter?
Where within the system that malware creates it's persistence mechanism has significant impact on your investigation, in part because investigations no longer center around the question of "was the system infected?" 

Take a look at this ThreatExpert report; the report points to a Registry value within the user hive that the malware adds data to in order to remain persistent, and then states: that %AppData%\skype.dat runs every time Windows starts

IMHO, this can be easily misinterpreted.  If the analyst assumes that "Windows" refers to the system, then the statement is incorrect.  However, if "Windows" refers to the shell, then it is correct...but to a point.  In this case, the malware will start the next time that user logs into the system, and the Windows Explorer shell starts for that user. 

Ok...but so what?  Well, this can be a very important distinction to make.  For example, let's say that someone from the helpdesk logs into an account on a user's workstation in order to assist with or fix something.  They go to a web site to download a patch or update, and while it's installing, they do a bit of surfing...and the system gets infected.  If the malware infects the system within the context of only that user account (i.e., creates a Registry persistence mechanism in the "HKCU" hive), then that malware will not be launched again until that user account is used to log into that system again.  Where this distinction is important is in cases of the "Trojan Defense" (was the system infected, and did the malware execute?), as well as PCI forensic audits, where the PCI Council requires the analyst to identify the "window of compromise" in a dashboard area of the report.  For merchants that know about how many credit card transactions they have in a given time period, that "window of compromise" can have a significant effect on the overall outcome of the report, potential fines levied by the council, etc.  I examined a system once where the malware was identified and deleted by an on-demand AV scan less than 48 hrs after it was created on the system, and the intruder didn't upload a new version of the malware (albeit with the same name) for 6 weeks...which, like I said, had a significant impact on the overall outcome of the investigation.

In another example, I've seen a server systems that were infected with malware when an administrator logged in and performed some series of activities (usually web surfing or checking email...hey, it happens...) that led to the infection, with the persistence mechanism for the malware being in the Administrator user's NTUSER.DAT.  When the server is rebooted, the malware doesn't persist and begin running again until the user logs into that some cases, depending upon the server, that could be for several days or weeks.  Once again, this is a very important distinction to make.

The ThreatExpert report mentioned above is only an isn't the only site where these sorts of messages can be seen.  I've seen reports at the MMPC site that state that malware creates a persistence mechanism in the HKCU\..\Run key so that it "starts whenever the system starts".  The same is true for a number of reports at AV vendor sites.

I discussed Wow6432Node in a previous blog post, and Corey has discussed this as well. And yes, it is very important to point out yet again.  And again.  And again.  Why is that?  Because I honestly believe that most analysts are missing this source of data.

Monday, March 25, 2013


New HEFCBlog book is out!
David Cowen posted that his new book is out!  The book is titled, Computer Forensics InfoSec Pro Guide (Beginner's Guide).  David's also got a new web site to go along with the  There isn't a great deal of information available about this book or its contents yet, but Dave has always been a fount of great things for DFIR, so keep your eyes on the site.  David did state on his blog that he's working on some "links, documents, and forensic images", so look for good things to come.

If you're going to get David's book, I would recommend that you also consider Brett Shaver's book, Putting the Suspect Behind the Keyboard, which provides an investigator's perspective and insight into determining who was sitting at the keyboard.

CyberThreat Detection
Lesley Carhart posted this article over on the Motorola Solutions Community site, mentioning the need for log monitoring, particularly in the face of Mandiant's APT1 report.  A lot of what Lesley says in the post has been mentioned before, but I tend to think that it's important to keep the same message consistent and repeated...just look around and see all of the organizations that get hit and don't have any of what she mentions implemented.

One statement made in the article that caught my attention was:

Attackers frequently spread laterally, system to system, using legitimate accounts and services. Would your organization detect this?

The reason this caught my attention was that as far back as I can remember, even going back to the 2012 DoD CyberCrime Conference, one of the primary complaints about the mention of "lateral movement" is that there is a dearth of information regarding what that looks, how would an organization be able to detect this sort of activity if the folks who know what it looks like aren't sharing the information?  This was the case at DC3 2012...I heard a couple of attendees lamenting the fact that for all of the presentations that included "APT" in the title, none of them actually provided actionable information.  I can only say that I attended three of those presentations, and not one of the authors actually listed what that lateral movement within the infrastructure looks like to an analyst.

Using RegRipper
Ken posted the Work Smarter, Not Harder article to his blog this weekend, which, in part, raises awareness of how to make the most effectively use of RegRipper.  In his post, Ken discusses using some basic functionality of RegRipper...creating custom profiles...and ties that to another recent blog post.  I greatly appreciate the time that Ken took to not only use the tool, but to write about his experience and use of the tool...I think that this really validates how easy-to-use these tools can be, and how effective their use can be in pursuing an examination.  It's one thing for me to write about how to use the tool, it's something else entirely for someone like Ken to share a real-world example of how he used the tool to complete analysis.

One thing that Ken says in the post is:

Running rip.exe -r ntuser.dat -f ntuser-all, for example, will run every ntuser.dat specific plugin against the ntuser.dat file.

A bit of clarification is required here...the command will run every "ntuser.dat-specific plugin listed in the ntuser-all profile against the ntuser.dat file".  My point is that analysts should not assume that every plugin intended to be run against the NTUSER.DAT file is listed in the ntuser-all profile.  This file is a flat text file, with no extension (which simply means that it does not end in ".txt" or ".dat", or...anything) that contains a list of plugins that you'd like to run, in the order that you'd like to run them.  It's always good to check and ensure that the plugins you want to be included in the profile are actually listed.  If not, they're very easy to add, as Ken described in his post.

My own custom RegRipper profile for retrieving program execution artifacts from the NTUSER.DAT hive includes the following plugins:


As many folks are aware, I teach a couple of courses.  During the courses, I invariably meet people who "use" RegRipper on a regular basis...what this most often amounts to is downloading RegRipper v2.5 (if you watched the SANS webcast from January 2013 closely, you could see that Mandiant is still on v2.02...) and simply running the UI version of RegRipper.  But there's so much more available through the tool, as Ken described in his post.

For example, I get asked, " there a list of available plugins?" on a regular basis.  This is why I provided a very simple facility through rip.exe to output a list of plugins (described in this blog post), including an option for CSV output.  An example of a command line that I discuss in the courses, for providing just a list of plugins that retrieve information from the NTUSER.DAT hive is:

C:\tools>rip -l -c | find ",NTUSER,DAT," /i > ntuser.csv

Run this command, and then open the resulting .csv file in Excel for easy review.  An alternative would be to simply drop the "find" portion of the command, open the resulting .csv file in Excel, and then sort of the third column to list the plugins based on the hive file.

You can also take this same approach to create specific profiles for USB device tracking within various hives, as well.

Side Note: One question is regularly ask users of RegRipper is, what would make RegRipper a 'better' tool. More/better documentation?  Some additional functionality?  If there's a specific plugin that you'd like to see created, you can take a look at Adam's 3RPG site (he blogged about creating four RR plugins in 15 min.), or you can contact me and request the plugin - all I'll need is a concise description of what you're looking for, and some sample data.  If you provide this information, I'm able to get plugins turned around rather quickly.  There is a LOT of information out there embedded in Registry hive files, and relying on a small group of people to create the plugins, when we're not seeing this information, amounts to a significant loss for the community.

"Cyber" Insurance
Something I've been watching with a bit of fascination is the spread of "cyber" insurance.  Looking back over the response and analysis engagements that I've performed or been involved with over the years, including PCI forensic audits, this is a very interesting development.  You'd need to review the annual reports from companies such as Mandiant, Trustwave and Verizon to see the effect that compliance regulations have had on organizations getting compromised...based on previous year's reports, one might think that there hasn't been much of an effect.

What's clear is that the issue of organizations getting "hacked" is getting even more attention.

CyberGuardians post
I did not attend the SANS Cyber Thread Intelligence Summit 2013, but I did get to read about it at the CyberGuardians blog.  Having been engaged in DFIR work for some time, I thought that both the presentations and the reviews of them were very insightful, and that the focus of DFIR work was moving in the right direction.  So many times as an emergency responder, I would show up and find that the on-site IR team was completely hamstrung, with no ability to get any sort of meaningful information during an incident.  In many cases, even the most basic information needed to simply assess systems had to be requested from network or systems ops folks...this was true not only at commercial and private sector sites, but also within the federal government.

What I really took away from the post is the realization that a mainstream organization such as SANS is now espousing the need for organizations to not only effectively consume (i.e., make use of) threat intelligence, but to also produce and share threat intelligence, as well. A number of consulting organizations offer this as a service, but some of them focus solely on one are of the IR spectrum (i.e., network sources, and not bringing memory- or host-based artifacts into the equation).  Part of the problem with this is that, while these are excellent services, many of the potential consumers of this intelligence are simply neither prepared nor equipped to make effective use of this information.

A new version of the ImDisk Toolkit is available, which works on Windows up to Win8 (32- and 64-bit).

There are still seats available for the 9-10 April offering of Timeline Analysis at our Reston location, as well as for the Windows Forensic and Registry Analysis course combo to be held at the Santa Cruz PD training facility.  If you're interested in any of these courses, but cannot make it to the Reston location, contact us about sponsoring the training at your location.

Monday, March 18, 2013

There are Four Lights: Program Execution

I'd seen a tweet recently where someone was asking about information regarding the last time a user launched an application on a system. The system had an SSD drive, and as such, application Prefetching was disabled, by default.  Therefore, one of the more well-known artifacts that indicate program execution was not available to the analyst.  The fact is that there are a number of locations available on Windows systems that will maintain indications of program execution.  Although not all of them allow the program execution or application launch to be tied directly to a user, or to be correlated to a specific time, they may be useful, nonetheless.

A valuable aspect of these locations is that they will very often persist beyond the deletion or removal of the application.

This category of artifacts can assist you in implementing an analysis matrix for your examination.

This post will be directed at providing information about artifacts that provide indications of program execution; many of the artifacts listed will not be able to allow the analyst to state explicitly that a user last launched an application at a specific date and time; rather, analysts should be aware of the artifacts, and be able to apply them (and others) as needed.  These artifacts can be used in a number of cases, in order to demonstrate a window of compromise, malware detection (just because you detected malware, does that mean that it actually ran??), etc.

Application Prefetch Files
Application prefetch files are a great source of information about applications run on the system, as well as when they were last run (although they are not specific to a user).  However, Windows server systems do not have application prefetching enabled by default, and application prefetching is disabled by default when Windows sees that it's being run from an SSD drive.

Shortcut/LNK files and Jump Lists
I include shortcut/LNK files and Jump Lists together because Jump Lists are comprised of LNK streams (this goes back to my post on understanding data structures).  And they can both provide indications of program execution (as well as access to remote storage).  In order to determine which application was launched, you may need to do some file extension analysis, or in the case of Jump Lists, start with an AppID lookup.

Browser History
With the exception of what was described in this blog post, the existence of a browser history will demonstrate the browser had been launched, within the context of a specific user.  In most cases, the specific records requested will include time stamps.  Also, don't forget to check things like bookmarks/favorites, etc., which will provide other indications of the use of the browser, even after the browser history has been cleared or trimmed (most browsers have an automatic process for clearing out older history and cache entries, independent of the user specifically performing the action).  Also, for IE, check out the RegRipper plugin.

Hibernation Files
While hibernation files will not explicitly put the suspect at the keyboard, much like crash dump files, they can be used to demonstrate that an application was (or wasn't) running at one time.  If you're going to analyze hibernation files, I strongly recommend that you consider using Volatility, or take the course taught by these folks.

Windows Event Log
I was analyzing a Windows 2008 R2 server not long ago, and found that an intruder had installed and run Havij and some other, similar tools.  Interesting enough, the Application Experience Event Log included entries indicating that the application had been installed on, as well as removed from the system.  Remember, Process Tracking isn't always enabled within audit configuration, but there may be other ways to determine indications of applications or programs being executed via serivces starting (event ID 7035/7036), etc.

The Windows Registry can contain a number of interesting keys and values that can provide indications of applicaitons being launched, or programs being executed.  In many cases, much like the file system, these locations can contain information about program execution long after the deletion/removal of the application or program.

Windows maintains a list of applications that were installed via Microsoft Installer (*.msi) files.  While this does not tie directly the execution of the program, it can indicate that it was installed.

The user's RecentDocs key can provide indications of program execution, even if indirectly.  For example, an .exe file may have been opened, but rather than launched, the user had opened it in a hex editor...which itself is an indication of "program execution" (of the hex editor).  You may have to perform file extension analysis or timeline analysis in order to determine specifically which application was used to open the file.

Also, be sure to check the OpenSaveMRU and OpenSavePidlMRU subkeys beneath the ComDlg32 key.

An old favorite, Corey Harrell has talked about this Registry value on his blog.  Also, if you really want to get  the available information about this value, check out what Mandiant has to say about it.  They discovered and publicized it, and even wrote up an excellent white paper on parsing the value data.  It's important to keep in mind that the last modification time for each application that is retrieved by the various tools is from the file system.

I've found over the years that some applications run within the user context have had entries created as values beneath this Registry key.  Now, the values do not have a time stamp associated with them

MS states that the Routing and Remote Access protocol has some pretty extensive tracing capabilities used for troubleshooting.  During exams, I've seen applications with networking capabilities included in subkeys beneath this key.

*DirectDraw, etc.
There are a number of subkeys beneath the Microsoft key (in the Software and NTUSER.DAT hives) that have names like DirectDraw, Direct3D, etc., and some of these may have a subkey named MostRecentApplication, which provides the name of the last application to make use of the capability.  I have seen this most often used by legitimate applications, such as iexplorer.exe, but it may also lead to malware (see this Sophos ZBot writeup). 

While this key is particular to a specific set of applications, the fact is that in order to run the SysInternals utilities, you need to accept the EULA, which creates a Registry subkey beneath the SysInternals key.  This can be very useful during an exam.

AppCompatFlags (NTUSER.DAT)
This key contains artifacts of applications executed by a user under the Program Compatibility Assistant, even if no compatibility modes are applied.

These artifacts provide indications of applications that the user launched by clicking on them through the shell, either double-clicking an icon on their Desktop or through Windows Explorer, or by selecting the Start button and clicking on the application through the program menu.

This Registry key provides indications of commands that the user has typed in at the Start->Run box.

AutoStart locations - *Run keys, Windows Services, etc.
You would need to correlate these entries to when the system was started, or when the user logged in.  This can be extremely significant.  If something (malware or another application) is set to autostart based on when a user logs in (usually found within the HKCU hive), then the last time that the application executed could be well after the system was started.  This may not be significant to the examination, but it does go to overall clarity and correctness of your findings.

I've seen a couple of instances where a system I was examining had LANDesk installed; part of the functionality of LANDesk includes the application writing Registry keys for each application launched on the system, including values for when the application was first and last launched, the user account used to launch the application the last time it was run, etc.  This proved very useful, particularly when included in a timeline.

Windows Services/AutoStart Locations
Windows Services can provide some excellent information regarding the start of an application; however, do not assume that because a service is listed that it automatically started with the system booted.  This is not always the case.  An analyst needs to check the start type of the service, as well as check the Windows Event Log for events with ID 7035/7036 (indicate a service start).  Another artifact that can be extremely useful when examining services is the Enum\Root\LEGACY_* keys within the System hive; the subkeys beneath these keys for each service are created the first and last time, respectively, that the service was run, and like other artifacts, will persist after the service was either disabled or removed from the system.

The same is true with other autostart locations; you need to be clear on the location and the effect that it has on the application start...even MS has gotten this one wrong.  If the application is listed in a user hive (HKCU), then it will start when the user logs in, NOT when the system starts.

'*' indicates Registry keys that may also have a counterpart found in the Wow6432Node path.

The artifacts described in this blog post are intended to assist analysts in understanding where to look for indications that applications has been run on a system.  In some cases, the artifacts may tie the program execution to a specific user, and other times, to a specific time.  These artifacts are not specific to fact, I tend to attribute other, specific artifacts to the "malware" artifact category.  Other artifacts may be specific to applications...for example, the Terminal Services Client will maintain a list of systems to which a user has connected in both Jump Lists, as well as beneath a Registry key in the NTUSER.DAT hive, indicating that the user launched the application.  IE (versions 5-9) has Registry artifacts, as well.  Applications that include MRU lists will allow the analyst to demonstrate the use of that application, by a user, at a specific time.

Network artifacts found in the Registry

Saturday, March 16, 2013

BinMode: IE Index.dat

I've posted on the need for analysts to understand data structures before, and I recently conducted some analysis that I think illustrates this point extremely well.

The purpose of this blog post is to illustrate how certain artifacts can be used to detect the presence of malware on a system.  While a tool for doing so is described, this is not a blog post about parsing histories for all of the browsers a user may or could have used, in part because the artifacts examined do not pertain to other browsers.

Not long ago, I tweeted that I'd written a plugin for the Forensic Scanner that gets statistics from IE (version 5 - 9) index.dat browser history files for all user profiles on the system.  Almost immediately, someone tweeted asking, "what if the user isn't using IE?"  That's a good question, but it misses the point of the analysis technique and of having the plugin in the first place.

I was analyzing a system recently that had been infected with ZeroAccess (see the Sophos report), and one of the things I was aware of the malware was capable of doing was click-fraud.  In my analysis, I saw that the malware used an autostart persistence mechanism that was outside the scope of the user timeline illustrated the artifacts being created.  Knowing that much of the malware that communicates off-system will use the WinInet API functions to do so, I began looking at the index.dat files for the various user profiles available on the system.  What I found was that the NetworkService account had much more significant "browser history" than the 'normal' user account on the system.

That's exactly right...there's no typo.  The NetworkService account.  How could that be?  That's not something you see very often, is it?  I mean, how does someone sit down at the keyboard and log into the account, and launch IE?  The answer is...they don't.  What happens is that when code using the WinInet API is run at privileges other than those of a user, the artifacts are created in another account profile.  For example, back when Windows XP was more prevalent in my analysis lab, I would see systems on which the Default User profile had a populated index.dat file.  I've seen the same thing with the LocalService account; this may depend upon which process the malware is injected into, and where that process falls in the svchost.exe hierarchy.

So my point is that for malware detection, checking all user accounts for statistics regarding their index.dat files might be a good idea.  Once you understand the data structures in question - that is, the headers of the index.dat file, which, thanks to Joachim Metz, are well documented - this becomes a trivial task.

I started by writing a simple script that would parse the contents of the header of the index.dat file and tell me a little bit about what I could expect to see.  Based on the format specification for the file, I was interested in things like the offset to the HASH table, as well as the directories beneath the "Temporary Internet Files\Content.IE5" folder and the number of cache files in each folder.  This information is stored in the headers of the files, and is very easy to parse out and display.  I got the script working and it proved to be very useful.  However, I know that there's a process to using the script...I have to determine which user profiles are available, determine the version of Windows being examined, and based on those two pieces of information, type in the appropriate path to the index.dat file in question.  By hand.  Seriously?

So, I created a system class plugin for the Forensic Scanner to do all of this for me.  Automatically.  System class plugins are run against the entire system, whereas user class plugins are run against each user profile selected by the analyst.  Based on the specific artifacts that I'm looking for, a system class plugin is exactly what I need.

What follows is an excerpt of the output from the plugin.  First, the Administrator account profile:

g:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\index.dat
File size              : 163840
Hash Table Offset      : 0x5000
Number of blocks       : 1152
Number of alloc. blocks: 1089

Dir: LPVS8JVQ  Files: 90
Dir: IR1PLUTE  Files: 89
Dir: 5K3JMTA3  Files: 88
Dir: O3VB95DY  Files: 89

As you can see, the Administrator account has some browser history associated with it.  The hash table is located at offset 0x5000 within the index.dat file, and there are four subdirectories, each containing a number of cache files.

g:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\index.dat
File size              : 32768
Hash Table Offset      : 0x0
Number of blocks       : 128
Number of alloc. blocks: 32

Dir: O8WMK2SC  Files: 0
Dir: UAAUTN4C  Files: 0
Dir: Q323MBYB  Files: 0
Dir: 4VRPMD81  Files: 0

Okay, so this is what an empty index.dat looks like; the Default User profile has no IE history associated with it...there is no hash table, and the subdirectories don't contain any files.

g:\Documents and Settings\NetworkService\Local Settings\Temporary Internet Files\Content.IE5\index.dat
File size              : 9437184
Hash Table Offset      : 0x5000
Number of blocks       : 73600
Number of alloc. blocks: 58784

Dir: EIQLTWH3  Files: 384
Dir: KFSPU8SK  Files: 384
Dir: ABR75H1M  Files: 384
Dir: 5QI7EWW7  Files: 384
Dir: TTYX5IX2  Files: 384
Dir: 5GDCH3XG  Files: 383
Dir: KZZXKXWH  Files: 383
Dir: LA2SZ5HL  Files: 383
Dir: TLRE11UL  Files: 383
Dir: IYT9OTGD  Files: 383
Dir: 58I9EM25  Files: 383


The NetworkService account was the one that set off alarms!  As you can see, this profile has a significant history!  Parsing the actual index.dat file and displaying the entries in a micro-timeline (just the URL records) illustrated a significant amount of activity in a relatively short amount of time, with more URLs being requested per second than most users are capable of typing in or clicking via the browser.

In this case, I used the command line version of the Forensic Scanner to run a single plugin.  I had mounted the image file via FTK Imager, and it appeared on my system as the G:\ volume.  I then typed the following command:

C:\Perl\scanner> -s g:\windows\system32 -p ie_stats

That's all it took.  Again, this is NOT a comprehensive analysis...this is a quick check to see if I could expect any potential issues.  Another way to run this would be to select the "malware" artifact category...the plugin is included in that category.  Also, the purpose of running this plugin is NOT to find indications of browser activity, for all browsers, and for all users.  Instead, the purpose of this plugin is to check for something very does so automatically, accurately, and very, very quickly.  This entire exercise took only a couple of minutes, most of which was spent mounting the image file...once that was done, the plugin ran very quickly, and provided me with the information I needed.  I don't want to list all of the URL and REDR records from the NetworkService profile index.dat because just from what we see above (not all of the directories are listed) there are around 4000 or so files in the cache subdirectories.

Again, the purpose of this blog post is to illustrate an analysis technique.  In the past, what I've done is to use ProDiscover to populate the "Internet History View" from within the image, and look for indications of service accounts with URL records in their index.dat.  However, the methodology used by ProDiscover is more searches the entire file system, and parses all of the records out of each index.dat file that it finds.  In this case, that's much more than what I'm looking for.

This analysis technique can be combined with other tools into a more comprehensive process, as described in this blog post.  Parsing application prefetch (*.pf) files and finding indications of wininet.dll as one of the loaded modules might be something to correlate with this analysis technique.

Rob Hensing's post on the Default User with an IE browser history
ForensicsWiki page: IE History File Format
Extremely relevant post from Hogfly (2007)

Thursday, March 07, 2013

Wow6432Node: Registry Redirection

What is Registry redirection? 
MS has a nice little explanation of Registry redirection and reflection here. Note that this MS page indicates that Registry reflection was removed as of Windows 7 and Windows 2008 R2.

In short, when a 32-bit application makes a call to write to the Registry on a 64-bit Windows system, by default, it doesn't go where we expect.  A number of years ago, I was performing analysis of a 64-bit Windows 2003 server that we thought had been compromised via SQL injection...only I couldn't find the instance of the MS SQL Server listed in the Software hive.  It turns out that I had to look beneath the Wow6432Node key

This page at MS provides information regarding Registry keys affected by Wow64.

What does it mean to us?
Well, for one...this is huge.  No, I mean, it's HUGE.  H. U. G. E. Why is that? Well, most of the malware I've seen over the years has been compiled for 32-bit platforms.  While I haven't seen many 64-bit XP and 2003 systems (I have seen a few), I have seen a number of 64-bit Windows 7 systems, and all of the Windows 2008 R2 systems I've analyzed have been 64-bit.

So, if you're looking in the usual locations for malware...say, the Software\Microsoft\Windows\CurrentVersion\Run key, in either the HKLM or HKCU hives...then you're only going halfway and potentially missing a great deal of critical data in the Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run key.  And unfortunately, most of us seem to be only going halfway.

This should be nothing new to the DFIR community.  Redirection and virtualization of the Registry were discussed on pp 246 and 247, respectively, in Windows Forensic Analysis 2/e (published in 2009), as well as on pg 132 of WFAT 3/e.  This topic is also discussed in this blog post.

Elizabeth S., from Google, discussed the Run keys extensively in her presentation at the 2012 SANS Forensic Summit.  You'll notice that if you read through the presentation, she culled a lot of data about Registry keys from an AV vendor site.  It appears that most of the testing platforms used by the vendor may be 32-bit, which may be why the Wow6432Node key isn't mentioned.

A good number of the RegRipper plugins that are affected by Registry redirection have been (or are being) updated to support Wow6432Node (where applicable, of course), and Corey Harrell has identified several others that need to be updated, as well.  We're working on getting updated plugins into a new public distribution, so please bear with us.

Note that similar differences apply to the file system, as well, due to redirection.  For example, on 64-bit systems, 32-bit applications can be found in the C:\Program Files (x86) and C:\Windows\SysWOW64 folders.

Resources article
Windows Confidential article