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