18 January 2016

Creating a Malware Sandbox in Seconds with Noriben.

Happy New Years!

As part of the new year, let's make an effort to make your defensive posture better, especially through quicker and more effective malware analysis! A few years ago I created a sample malware analysis sandbox script to use for the analysis and reverse engineering that I performed on a daily basis. Let's show how you can perform analysis of malware within just a few seconds with almost no setup at all.

  1. Introduction
  2. Automating Sandboxing with VMware
  3. How you can help! Even with no technical background!
  4. Download Information

For those who are already familiar with Noriben, feel skip to the second section to see the new content.

Introduction


If you've followed me on Twitter, or kept up with this blog, you would be familiar with Noriben. If not, it's a very simple script. In typical behavior analysis one would run malware within a sandbox to see exactly what files it creates, what processes it runs, and what changes it makes to the system. The most common way that many defense teams use is to upload the file to a central anti-virus testing site like VirtusTotal and to online sandboxes like Malwr and those using Cuckoo.

For teams who are leery of uploading their files to the Internet, which is especially inadvisable for APT-related investigations. As advanced actors monitor online sites to see if their files are uploaded, they can determine if their free reign within the environment comes to an end and an IR response has started.

Running malware locally is most commonly performed through Cuckoo, an awesome and open-source sandbox application designed for malware that produces very comprehensive results. However, there is is arguably considerable effort required to set up Cuckoo correctly, with multiple sites offering walkthroughs for various environments. While relatively easy to install on Linux, installing on Windows or OSX can be frustrating for many. And, in my case, I'm often on the road with a random laptop and need to make a sandbox very quickly.

If you take a malware analysis training course, you've also likely been exposed to the SysInternals Procmon tool to monitor a system's environment. For those with more vintage knowledge, you learned Regmon and Filemon. Others use Regshot, a tool that is inadequate for many malware as it doesn't track finite changes within runtime.

Noriben is a simple wrapper for Procmon to collects hundreds of thousands of events then uses a custom set of whitelisted system events to reduce this down to a few dozen for quick review. For more, take a look at the slide deck I put together for the 2015 Black Hat Arsenal:

14 September 2015

Solving the 2015 FLARE On Challenges

The second annual FLARE On is a reverse engineering challenge put forth by the FireEye Labs Advanced Reverse Engineering (FLARE). While accepted as a very advanced and tactical recruiting method, it resonates with those who love CTF challenges.

In 2014 the inaugural FLARE On presented seven challenges. As a finisher, you can read my write-up here. Each participant has a different take on the challenges. Each person has different methods, skills, and strengths. Mine are forged by years of forensics, log analysis, and working a mission where results are required regardless of ability, training, or excuses. At the end of this post I've linked to other write-ups that I've seen.

Let's begin by setting a level of expectation. You are reading a blog named GhettoForensics. The ultimate goal of Ghetto Forensics is to get by with whatever tools and knowledge you have to complete a mission. You will not find first-rate techniques and solutions here. In fact, when presented with multiple options, I often went out of my way to choose to worst, most cringe-worthy option available. For the lulz, and to show that you don't need advanced reverse engineering training and experience to survive the industry. I hope you enjoy.

For simplicity sake, unless necessary all IDA output will be as decompiled.

Without further ado.
Flare-On!


Challenge #1


Let's roll up our sleeves and ... oh, nevermind, there's the routine.
.


The routine takes a given email address through ReadFile(), XOR's it by 0x7D, and compares it to an embedded value. So, just find that value in the executable with WinHex (one of my favorite tools) and XOR it there to get the answer. WinHex lets you just highlight text and do basic on-the-fly modification (rotate, addition, subtraction, XOR, etc).


bunny_sl0pe@flare-on.com



Filename Etymology: i_am_happy_you_are_to_playing_the_flareon_challenge
Borat-style filename?


16 March 2015

Of Malware and Adware: Why Forbes Did Not Serve Me Malware

The topic of web-based advertising is always a hot topic for discussion, debate, and outright argument. One realizes that the Internet in which we've grown accustomed to is reliant on ads; after all, Google is an advertisement company.

In the recent past we've seen articles on malvertising targeted using Skype and more recently using the New York Times and BBC. Soon after, comparisons were made between these attacks and an incident I noted in January regarding Forbes.com. Those comparisons are ongoing, motivating me to write this post.

While Forbes did experience a malvertising event last year, these attacks are nowhere near the same as the event I posted in January. That people claim so shows a general lack of education, even among security practitioners, of malware vs adware vs PUP, and valid threats vs nuisances.

Forbes did not serve "malware" and cannot be compared to these incidents.

To explain this in detail, let's discuss how my event came to be.


11 November 2014

DJ Forensics: Analysis of Sound Mixer Artifacts

In many forensics examinations, including those of civil and criminal nature, there is an art to finding remnants of previously installed applications. Fearing detection, or assuming that an examination is forthcoming, many suspects attempt to remove unauthorized or suspicious applications from a system. Such attempts are usually unsuccessful and result only in additional hours of processing for forensics. But even with a clean uninstall there are traces left within the Windows registry that note such a program was installed.

The most popular of these is the Windows Shim Cache (a/k/a Application Compatibility Database, a/k/a AppCompatCache), a resource that can be used to catalog applications not natively compiled for newer Windows. It's also a resource that works great for finding APT-related malware running on a system, but not so much legitimate applications.

For a few months I've been playing with another repository of applications: the Windows Sound Mixer. Whenever an application requests the use of the Windows audio drivers, Windows will automatically register this application in the registry. This information is stored so that Windows can create per-application sound settings:



This was a resource I dismissed for a year. It existed only in Windows Vista and newer, it didn't catch any of the malware I threw at it, and wasn't relevant to any of the Incident Response work I do**. Its importance came to me when working some cases that came mixed in with many of my intrusion cases where I had to examine the systems owned by various hackers. One in particular involved tracking the use of alternative web browsers and discovering that the Sound Mixer had catalogued the use, and location, of Tor Browser launched from a TrueCrypt volume. Clear as day, the path even noted that it was a TrueCrypt volume based upon the Windows device name:

\Device\TrueCryptVolumeP\Tor\App\Firefox\firefox.exe

I learned that the registry keys were useful for such cases, but there has been no prior public discussion of the forensic use of this data.


22 September 2014

A Walkthrough for FLARE RE Challenges



The FireEye Labs Advanced Reverse Engineering (FLARE) challenge was causing a bit of a buzz when it was announced and launched in early July. It read like a recruitment campaign for a new division within FireEye, but still a fun challenge to partake in. The challenge started ... and I was on-site at a client site for the week and forgot all about it. 

Busy under the pressure of releasing the new Dissecting the Hack book, the challenge went to the back of my mind until the 24th of July. I was facing a pretty hard-hitting bit of writer's block and frustration. I agreed to let myself have a break to do the challenge for one week before getting back to my commitments.

After the challenge finished, and answers and methods started floating around (notably CodeAndSec's), I realized that many of my tactics were completely different from others. I'm sure that's to be expected from this field; many of my methods were from working in an environment without Internet access and without an expert on-call for answers. I'm also fully from a forensics background (hex editors and data structures and file parsers, etc), and work in commercial incident response with RSA, so I'd be sure to tackle problems different from someone who had a pentesting or vuln discovery background.

Although the challenge started in early July, it ran up until 15 September. There was an unspoken moratorium on answers/solutions while the challenge ran, but now that the samples are all freely available from their website, some are coming forth with how they completed them.

This is my story.


Challenge 1


The first challenge started out with downloading an executable from the flare-on.com website. I immediately threw it into IDA and started poking around, only to discover that it was just a dropper for the real challenge :)  I let it do its thing, agreed to a EULA without reading it, and received the first challenge file:

File Name       : Challenge1.exe
File Size       : 120,832 bytes
MD5             : 66692c39aab3f8e7979b43f2a31c104f
SHA1            : 5f7d1552383dc9de18758aa29c6b7e21ca172634
Fuzzy           : 3072:vaL7nzo5UC2ShGACS3XzXl/ZPYHLy7argeZX:uUUC2SHjpurG
Import Hash     : f34d5f2d4577ed6d9ceec516c1f5a744
Compiled Time   : Wed Jul 02 19:01:33 2014 UTC
PE Sections (3) : Name       Size       MD5
                  .text      118,272    e4c64d5b55603ecef3562099317cad76
                  .rsrc      1,536      6adbd3818087d9be58766dccc3f5f2bd
                  .reloc     512        34db3eafce34815286f13c2ea0e2da70
Magic           : PE32 executable for MS Windows (GUI) Intel 80386 32-bit Mono/.Net assembly
.NET Version    : 2.0.0.0
SignSrch        : offset   num  description [bits.endian.size]
                  0040df85 2875 libavcodec ff_mjpeg_val_ac_luminance [..162]
                  0040e05d 2876 libavcodec ff_mjpeg_val_ac_chrominance [..162]

Based on this output from the file, I can see first of all that it was built from .NET 2.0 (based on the mscorlib import). That'll be important later to determine what tool to analyze the file in; IDA Pro is not the most conducive tool for .NET applications.

At this point, let's run it and see what happens:



The image shows some happy little trees and a great, big "DECODE" button. Clicking this button changes the image thusly:



Without any clue of what to do with the challenge, or what I'm actually looking for, I open it up for analysis with Red Gate .NET Reflector.

23 April 2014

Moving On to New Career Opportunities

In the next few days I will be moving on from my current work and into a new and exciting opportunity. As I work through this effort, while writing a book and preparing con talks, I started to think of the practical and emotional tasks needed to ensure that my current employer and clients are taken care of while I prepare for the future.

In this effort, I wanted to pass on a few ideas that may help others.

Personal Side


To begin with, let's discuss the personal side to the move. I've been working with the Defense Cyber Crime Center (DC3) for almost 14 years. I've been with them since before they were even named DC3, and were just the Defense Computer Forensics Lab (DCFL) and the Defense Cyber Investigations Training Program (DCITP a.k.a. The 'TIP). Also, since we had "Cyber" in our agency name since the late 90's, I'm fully allowed to use it in regular conversation without drinks.

I've said goodbye to DC3 once before, temporarily, as I moved on from being the Deputy Technical Lead of the Training Academy. I left with the weight of a serious case of burnout and needed a break. Getting into the down and dirty of regular forensic work was the fix.

I joined my good friends Eoghan Casey, Terrance Maguire, and Chris Daywalt in their venture, cmdLabs. We worked out awesome incident response cases together and delved into research projects and code development. At about this time, cmdLabs was acquired by Newberry Group, run by a CEO and VP that I had known for over a decade. Life was good and, after a cool-down period, I went back into DC3 on a separate contract to work on their Intrusions team.

17 February 2014

Malware with No Strings Attached Part 2 - Static Analysis

In the previous post I showed some dynamic analysis procedures for a variant of a trojan known to Symantec as Coreflood. Based on the dynamic analysis, we discovered that the analyzed sample contained very few strings of use. It decrypted an embedded executable, which was injected into memory for execution. It dropped an encrypted file to the hard drive, then downloaded a second-stage executable from the Internet. This downloaded file was then encrypted in what appeared to be a similar routine as the dropped file.

However, in the end, we still had many questions that couldn't be answered:

  • What is the encryption routine used for thr1.chm and mmc109.exe?
  • Why does the malware rename mmc109.exe to mmc61753109.exe?
  • Why does the malware first make a network connection to Adobe.com? What does that POST value mean?
  • Why does the initial loader contain so few strings?
These questions are best answered through static analysis. However, static analysis can be an extremely time-consuming activity. A full "deep dive" static analysis could take days, or even weeks, to fully document all functionality within a malware sample. Instead, this post will go through the process of a targeted static analysis. With the questions laid out here, we'll focus our static analysis solely on answering those questions, which will mean leaving many aspects of the malware undocumented.

Therefore, we need to focus on what questions can be answered within an hour or two of static analysis.

These questions mirror some of those performing Incident Response work. During incident response work a malware analyst works in conjunction with forensics and the responders to help answer the really difficult questions on why certain indicators are seen, what they mean, and what other indicators should be searched for that may have been missed.

This also answers the concerns of inaccurate preconceptions from those outside the field. When I tell a client that a sample has encoded data and will take a bit longer, I immediately get push back on the expectation that a simple routine may add 40+ hours of billable time. Likewise, if I say that a sample has a custom encryption routine, I'd often get pinged every hour on why it's not decoded yet. 

This post will show some of my personal workflow and mentality when trying to analyze malware, while trying to extract indicators to assist in an overall forensics examination or incident response. As I'm new to much in the RE world, having only learned through self-training and on-the-job work, I'd love any feedback for ways in which to speed up or better hone topics that I covered here.