• This utility works in any version of Windows, starting from Windows XP and up to Windows 8. Both 32-bit and 64-bit systems are supported.
• The following Web browsers are supported: Internet Explorer, Mozilla Firefox, SeaMonkey, and Google Chrome.
• ImageCacheViewer won't work if you configure your Web browser to clear the cache after closing it.
• It's recommended to close all windows of your Web browser before using ImageCacheViewer, to ensure that all cache files are saved to the disk.

Start Using ImageCacheViewer

IE Password Decryptor is the FREE software to quickly and easily recover all the stored passwords from Internet Explorer.
It automatically detects the installed IE version and use appropriate technique to successfully decrypt all the stored passwords.

One of the unique feature of this tool is that it can recover passwords (from IE v7-v9) for popular websites without depending on the history.

It also presents 'IE History Manager' interface which not only displays the contents of IE history in detail but also provides the option to add/remove websites with ease.

This single tool comes with both GUI as well as command-line interface making it useful for pen testers as well as forensic investigators.

It works on both 32-bit & 64-bit platforms starting from Windows XP to Windows 8.

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 context...my 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 ie_stats.pl 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>fscan.pl -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 ie_stats.pl 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 specific...it 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 comprehensive...it 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.

Resources
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)