Java, Timelines, and Training

A lot of interesting things have gone on lately...and I'm sure that there's more to come.  I thought I'd take a moment to raise awareness of some of what happened recently,

Java In The News

Corey posted some links to tools the other day over on the jIIr blog.  In the blog post, he talks about IDX parsers...not long ago, there was a flurry of activity around Java deployment cache index (*.idx) files, and what was contained in them.  

You can find my IDX parsing code here.  I updated it recently to support a variant to version 605 index files that I happened to see (that's one of the things I love about open source....).

Okay, so what's the big deal with this stuff?  Is it just the "flavor-of-the-week" when it comes to DFIR analysis?  I wouldn't think so...in fact, I'd suggest that if you do any sort of work with respect to malware or intrusion/compromise analysis, I would suggest to you that this is a pretty big deal.  In fact, it's likely that anyone doing any sort of DFIR analysis is going to run up against this at some point...you may not recognize it at first, but it's likely to be there.

Remember this graphic from the SANS Forensic blog post from last year?  Right in the middle of the super timeline, there are two *.idx files being created.  This is from last year...during a recent examination, I added the metadata extracted from *.idx files to my own timeline, because the infection routine started with Java being run.  I discuss that a little bit below.

Did anyone see this article recently?  Java exploit?  Yeah, apparently, that's what it was.  I'd bet that the systems that were examined had some pretty interesting *.idx files on them.

I would suspect that as awareness of these artifacts are raised, analysts will begin to recognize that it's now easier to perform a root cause analysis, and to determine the initial infection vector.  IMHO, the primary reason why this isn't done more often is because most assume that it takes too long to do an investigation; however, in not performing these investigations, we're missing out on a great deal of value information and intelligence that we can use to better protect our infrastructures.

Timeline Analysis

As I mentioned above, I used my own *.idx parser to add information from these files to a timeline...and this really helped my analysis.  

First, as I do sometimes, I parsed the data separately and created a mini-timeline from just the data from the *.idx files.  I do this, because in a full timeline, any times that data just gets lost.  Now, I could have done something like created the events file, and then pulled out the information for the *.idx files using the type command, and piping that through find.  Either way works.

Doing this showed me quite a bit about what the user likes to do during the day.  I think what was most revealing about this data was that it made clear how much Java is used on the Internet.  In a way, it was kind of fascinating, but at the same time, this didn't have much of anything to do with analysis goals.  The fact was that while my timeline showed modifications to several cache directories when the system was being infected,  what I did not see was the *.idx files that should have been part of the infection process.

One of the things I teach in my courses is that we need to understand artifacts so that you can not only recognize what's there, but so that you can also see when something that should be there isn't...and I had just such a case recently.  There were a couple of possibilities as to what I was seeing, and one thing I found was that the installed AV had detected the malware; it quarantined the malware (i.e., created a file in the Quarantine directory) but the AV logs also stated quite clearly that (a) it was unable to remove the files from their original location, and (b) the AV software could not alert the user (notifications were disabled).  Unfortunately, the logs did not go back all the way to the date of the infection, so I could not determine if the AV had actually detected the malware when it was installed, or if the detection I was seeing in the logs was a result of a product update that occurred after the infection.  However, I did see that a file with the extension ".idx" had been created in the Quarantine folder, and had since been deleted.  That wasn't definitive, but it was possible that the AV product had found something malicious in at least one *.idx file and had quarantined it.  This would definitely account for the modification that occurred to the cache folder during the infection routine.

So, from the data I was looking at, there were two possibilities...one was that the AV had detected the infection, and while it was able to remove some of the files, it was unable to remove the actual malware itself...and since most AV products do nothing about the malware persistence mechanisms, the malware remained active (as confirmed by other artifacts).

The other possibility was that during the infection process, the malware "cleaned up" behind itself.  After all, right there in the timeline, I could see that during the infection process, the Security Center was disabled, and the malware disabled the mechanism it used to gain access to the system.  This was a multiple-stage infection...it started with Java via IE, downloaded something that ran and created files on the system.  The second stage .exe file was deleted, but there were plenty of artifacts on the system that clearly showed not only that it had run, but also under what user context it had run.  And it was clear that the infection process had also closed off the first stage of the infection.

So, there were some interesting findings in the analysis...all of the above was determined within the first 6 hours of analysis.  As analysts, however, we're finders of fact, facts that we base and the data that I did have available had me leaning more toward the first possibility than the second.  But the fact is that using these techniques, I had enough data to clearly identify not just the facts, but the gaps, as well.

Addendum: After my initial post, I saw this post at the KrebsOnSecurity blog, and this one on disabling Java for the browser on the Sophos site.  Within minutes, I had written a RegRipper plugin to extract the UseJava2IExplorer value.

Resources

One of my own blog posts on the topic

ForensicsWiki Java Page

Mark Woan's format specification document

Training

Interested in Windows DFIR training?  Windows Forensic Analysis, 11-12 Mar; Timeline Analysis, 9-10 Apr. Pricing and Calendar. Send email here to register.  Each course includes access to tools and techniques that you won't find anywhere else, as well as a demonstration of the use of the Forensic Scanner.

On 10-12 June 2013, a Windows Forensic Analysis and Registry Analysis combo course will be hosted at the Santa Cruz PD training facility.

Course descriptions and other info on the courses is available here.  Pricing for the combo course is $749 per seat, and will be listed on the ASI training page shortly.