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)
Showing posts with label binmode. Show all posts
Showing posts with label binmode. Show all posts
Saturday, March 16, 2013
Monday, January 28, 2013
Why "BinMode"?
You may be wondering why I've started posting articles to my blog with titles that start with "BinMode" and "There Are Four Lights".
The "BinMode" posts are dedicated to deeply technical posts; the name comes from the fact that sometimes I'll write a Perl script that requires me to open a file using binmode(), so that I can parse the file on a binary level. These are generally posts that go beyond the tools, which tend to provide a layer of abstraction between the data and analyst. I feel that it's important for analysts to understand what data is available to them, so that they can make better decisions as to which tool to use to extract and process that data.
An example of this is the recent work I've done parsing the Java deployment cache index (*.idx) files. Beyond opening these files in a hex editor, one resource that I had access to in order to assist me in parsing the files is this source code page: CacheEntry.java. Another resource that became available later in the process is the format specification that Mark Woan documented. What these resources show is that within the binary data, there is potentially some extremely valuable information. This information might be most useful during a root cause analysis investigation, perhaps to determine the initial infection vector of malware, or how a compromise occurred.
The "Four Lights" articles are partly a nod to the inner geek (and Star Trek fan) in all of us, but they're also to address something that may be lesser known, or perhaps seen as a misconception within the digital forensic analysis community. The title alludes to an episode of ST:TNG, during which his captors attempted to get the greatest starship captain...EVER...to say that there were only three lights, when, in fact, there were four.
If there is a particular topic that you'd like me to expand upon, or if there's something that you'd like to see addressed, feel free to leave a comment here, or to send me an email.
Interested in Windows DF training? Check it out: Timeline Analysis, 4-5 Feb; Windows Forensic Analysis, 11-12 Mar. Be sure to check the WindowsIR Training Page for updates.
The "BinMode" posts are dedicated to deeply technical posts; the name comes from the fact that sometimes I'll write a Perl script that requires me to open a file using binmode(), so that I can parse the file on a binary level. These are generally posts that go beyond the tools, which tend to provide a layer of abstraction between the data and analyst. I feel that it's important for analysts to understand what data is available to them, so that they can make better decisions as to which tool to use to extract and process that data.
An example of this is the recent work I've done parsing the Java deployment cache index (*.idx) files. Beyond opening these files in a hex editor, one resource that I had access to in order to assist me in parsing the files is this source code page: CacheEntry.java. Another resource that became available later in the process is the format specification that Mark Woan documented. What these resources show is that within the binary data, there is potentially some extremely valuable information. This information might be most useful during a root cause analysis investigation, perhaps to determine the initial infection vector of malware, or how a compromise occurred.
The "Four Lights" articles are partly a nod to the inner geek (and Star Trek fan) in all of us, but they're also to address something that may be lesser known, or perhaps seen as a misconception within the digital forensic analysis community. The title alludes to an episode of ST:TNG, during which his captors attempted to get the greatest starship captain...EVER...to say that there were only three lights, when, in fact, there were four.
If there is a particular topic that you'd like me to expand upon, or if there's something that you'd like to see addressed, feel free to leave a comment here, or to send me an email.
Interested in Windows DF training? Check it out: Timeline Analysis, 4-5 Feb; Windows Forensic Analysis, 11-12 Mar. Be sure to check the WindowsIR Training Page for updates.
Monday, January 21, 2013
BinMode: Parsing Java *.idx files, pt. deux
My last post addressed parsing Java *.idx files, and since I released that post, a couple of resources related to the post have been updated. In particular, Joachim Metz has updated the ForensicsWiki page he started to include more information about the format of the *.idx files, with some information specific to what is thought to be the header of the files.
Also, Corey Harrell was kind enough to share the *.idx file from this blog post with me (click here to see the graphic of what the file "looks like" in Corey's post), and I ran it through the parser to see what I could find:
File: d:\test\781da39f-6b6c0267.idx
Times from header:
------------------------------
time_0: Sun Sep 12 15:15:32 2010 UTC
time_2: Sun Sep 12 22:38:40 2010 UTC
URL: http://xhaito.com/work/builds/exp_files/rox.jar
IP: 91.213.217.31
Server Response:
------------------------------
HTTP/1.1 200 OK
content-length: 14226
last-modified: Sun, 12 Sep 2010 15:15:32 GMT
content-type: text/plain
date: Sun, 12 Sep 2010 22:38:35 GMT
server: Apache/2
deploy-request-content-type: application/x-java-archive
Ah, pretty interesting stuff. Again, the "Times from header" section is comprised of, at this moment, data from those offsets within the header that Joachim has identified as possibly being time stamps. In the code, I have it display only those times that are not zero. What we don't have at the moment is information about the structure of the header so that we can identify to what the time stamps refer.
However, this code can be used to parse *.idx files and help determine to what the times refer. For example, in the output above we see that "time_0" is equivalent to the "last modified" field in the server response, and that the "time_2" field is a few seconds after the "date" field in the server response. Perhaps incorporating this information into a timeline might be useful, while research continues in order to identify what the time stamps represent. What is very useful is that the *.idx files are associated with a specific user profile, so for testing purposes, an analyst should be able to incorporate browser history and *.idx info into a timeline, and perhaps be able to "see" what the time stamps may refer to...if the analyst were to control the entire test environment, to include the web server, even more information may be developed.
Speaking of timelines, Sploited commented to my previous post regarding developing timelines analysis pivot points from other resources; in the comment, a script for parsing IE history files (urlcache.pl) was mentioned; I would suggest that incorporating a user's web history, as well as incorporating searches against the Malware Domain List might be extremely helpful in identifying initial infect vectors and entry points.
Interested in Windows DF training? Check it out: Timeline Analysis, 4-5 Feb; Windows Forensic Analysis, 11-12 Mar. Be sure to check the WindowsIR Training Page for updates.
Also, Corey Harrell was kind enough to share the *.idx file from this blog post with me (click here to see the graphic of what the file "looks like" in Corey's post), and I ran it through the parser to see what I could find:
File: d:\test\781da39f-6b6c0267.idx
Times from header:
------------------------------
time_0: Sun Sep 12 15:15:32 2010 UTC
time_2: Sun Sep 12 22:38:40 2010 UTC
URL: http://xhaito.com/work/builds/exp_files/rox.jar
IP: 91.213.217.31
Server Response:
------------------------------
HTTP/1.1 200 OK
content-length: 14226
last-modified: Sun, 12 Sep 2010 15:15:32 GMT
content-type: text/plain
date: Sun, 12 Sep 2010 22:38:35 GMT
server: Apache/2
deploy-request-content-type: application/x-java-archive
Ah, pretty interesting stuff. Again, the "Times from header" section is comprised of, at this moment, data from those offsets within the header that Joachim has identified as possibly being time stamps. In the code, I have it display only those times that are not zero. What we don't have at the moment is information about the structure of the header so that we can identify to what the time stamps refer.
However, this code can be used to parse *.idx files and help determine to what the times refer. For example, in the output above we see that "time_0" is equivalent to the "last modified" field in the server response, and that the "time_2" field is a few seconds after the "date" field in the server response. Perhaps incorporating this information into a timeline might be useful, while research continues in order to identify what the time stamps represent. What is very useful is that the *.idx files are associated with a specific user profile, so for testing purposes, an analyst should be able to incorporate browser history and *.idx info into a timeline, and perhaps be able to "see" what the time stamps may refer to...if the analyst were to control the entire test environment, to include the web server, even more information may be developed.
Speaking of timelines, Sploited commented to my previous post regarding developing timelines analysis pivot points from other resources; in the comment, a script for parsing IE history files (urlcache.pl) was mentioned; I would suggest that incorporating a user's web history, as well as incorporating searches against the Malware Domain List might be extremely helpful in identifying initial infect vectors and entry points.
Interested in Windows DF training? Check it out: Timeline Analysis, 4-5 Feb; Windows Forensic Analysis, 11-12 Mar. Be sure to check the WindowsIR Training Page for updates.
Subscribe to:
Posts (Atom)