Presentation Archive

Below are a series of presentations I've given over the years, though not a fully inclusive list. Many are too sensitive (FOUO/LES/S/TS/SAP/EIEIO) to store, and others have been lost to digital decay. But, the remainder have been recovered and digitally remastered for your enjoyment.

Walking the Green Mile: How to Get Fired After a Security Incident:

Abstract: Security incidents targeting corporations are occurring on a daily basis. While we may hear about the large cases in the news, network and security administrators from smaller organization quake in fear of losing their jobs after a successful attack of their network. Simple bad decisions and stupid mistakes in responding to a data breach or network intrusion are a great way to find yourself new employment. In this talk I'll show you in twelve easy steps how to do so after, or even during, a security incident in your company.
Notable Venues: Derbycon 1.0, Defcon Skytalks, BSides Las Vegas

Walking the Green Mile from Brian Baskin

Below is a video feed of the talk given at the first ever Derbycon. It was an early morning slot, and I was somehow blissfully unaware that I was being recorded, which may be why I feel it was the best recording of the talk.

Intelligence Gathering Over Twitter:

This was a basic-level presentation geared for a law enforcement audience. It taught the basics of how to use Twitter but also delved into specialized tools to collect and analyze large amounts of data, to help infer relationships and associations. This slide deck is slightly redacted, as much of the good stuff was given orally in the presentation.
Notable Venues: DoD Cyber Crime Conference


Information Gathering Over Twitter from Brian Baskin

Malware Analysis: Java Bytecode

Abstract: This was a short talk given to NoVA Hackers soon after working through a Zeus-related incident response. The Javascript used to drop Zeus on the box had a few layers of obfuscation that I had not seen discussed publicly on the Internet. This was was originally given unrecorded and only published a year later.

Java bytecode Malware Analysis from Brian Baskin

P2P Forensics: 

Abstract: Years ago I began working on an in-depth protocol analysis talk about BitTorrent so that traffic could be monitored. This grew into a BitTorrent forensics talk which grew into an overall P2P Forensics talk. At one point, it was a large two-hour presentation that I had to gently trim down to an hour. Given at multiple venues, each was modified to meet that particular audience (administrators, criminal prosecutors, military).
Notable Venues: GFIRST, DoD Cyber Crime Conference, DojoCon, Virginia State Police Cyber Workshop, USAF ISR Information Security Conference, USDoJ CCIPS Briefing, AFOSI Computer Crime Workshop

P2P Forensics from Brian Baskin

The only video recording of the talk, recorded at DojoCon 2010, for a technical audience.

Brian Baskin, @bbaskin P2P Forensics from Adrian Crenshaw on Vimeo.

Casual Cyber Crime:

Abstract: We're living in an age of devices and applications that push the boundaries of dreams, an age of instant gratification, but also the age of Digital Rights Management and Copyright laws. With questionably illegal modifications becoming simple enough for children to use, where does the line get drawn between squeezing more functionality out of your digital devices and software and breaking felony laws? In this talk attendees will explore the justifications and rationales behind the use of questionable hardware and software modifications and understand the mentality behind why their use is rapidly catching on in the general population.
Notable Venues: TechnoForensics

Casual Cyber Crime from Brian Baskin

Ghetto Forensics!

While I have maintained a blog on my personal website (www.thebaskins.com) for many years, the process of creating new posts on it has become cumbersome over time. As I perform more technical posts, they felt out of place on a personal site. After some weeks of contemplation, I've forked my site to place my new technical content on a site for itself, here, at Ghetto Forensics.

Why Ghetto Forensics? Because this is the world in which we operate in. For every security team operating under a virtual unlimited budget, there are a hundred that are cobbling together a team on a shoestring budget using whatever tools they can. This is the world I've become used to in my long career in security, where knowledgeable defenders make do as virtual MacGyvers: facing tough problems with a stick of bubble gum,  a paperclip, and some Python code.

Many don't even realize they're in such a position. They've created an environment where they are continually on the ball and solving problems, until they are invited to a vendor demonstration where a $10,000 tool is being pitched that does exactly what their custom script already performs. Where an encrypted file volume isn't met with price quotes, but ideas such as "What if we just ran `strings` on the entire hard drive and try each as a password?".

Ghetto forensics involves using whatever is at your disposal to get through the day. Ghetto examiners don't have the luxury of spending money to solve a case, or buying new and elaborate tools. Instead, their focus is to survive the day as cheaply and efficiently as possible.

Have a tough problem? No EnScript available? Then work through five different, free tools, outputting the results from one to another, until you receive data that meets your demands. Stay on top of the tools, constantly reading blog posts and twitter feeds of others, to see what is currently available. Instead of swishing coffee in a mug while waiting for keyword indexing, having the luxury of weeks to perform an examination, you are multitasking and updating your procedures to go directly after the data that's relevant to answering the questions. Fix your environment so that you can foresee and tackle that mountain of looming threats instead of constantly being responsive to incidents months after the fact.

These are many of the ideals I've learned from and taught others. While others adopted the mentality of posting questions to vendors and waiting for a response, we've learned to bypass corporate products and blaze our own trails. When I helped develop a Linux Intrusions class in 2002, the goal was to teach how to investigate a fully-fledged network intrusion on their zero-dollar budgets. We used Sleuthkit, and Autopsy, and OpenOffice. We created custom timelines and used free spreadsheet (Quattro) to perform filtering and color-coding. Students learned how to take large amounts of data and quickly cull it down to notable entries using grep, awk, and sed. And, when they returned to their home offices, they were running in circles around their co-workers who relied upon commercial, GUI applications. Their task became one of not finding which button to click on, but what data do I need and how do I extract it.

Join me as we celebrate Ghetto Forensics, where being a Ghetto Examiner is a measure of your ingenuity and endurance in a world where you can't even expense parking.

Noriben version 1.1 Released

I've made available the latest version of Noriben with some much-needed updates.

The greatest update is a series of added filters that dramatically help to reduce false positive items in the output. This was missing from the first release due to an oversight on my part, and an unknown usability feature in Procmon. I use my own personal Procmon filters for malware analysis, which are not provided for users to download. The mistake was that I was under the assumption that removing this filter file would prevent Procmon from using them and would provide me the output that everyone else would see. That was a wrong assumption; Procmon stores a backup in the registry.

After seeing the output produced when @TekDefense ran Noriben, I quickly realized the sheer amount of items that should not be in the report, and rushed to fix this.

While updating the filters, I applied a few new improvements under the hood in how filters were applied. Primarily, filters now support regular expressions, though I have not implemented any at this point. Additionally, filters can now include environment variables. So, instead of hard-coding "C:\Users\Brian\AppData\...", which would change on every single machine, a filter can read "%UserProfile%\AppData\...". This lends to greater portability of the script, allowing it to use the same filter set on any machine with no changes.

The new version of Noriben, version 1.1, is available on GitHub here.

If you have any errors or unusual items that you want to report, email the PML/CSV/TXT files (ZIP is fine) to brian -=[at]=- thebaskins -=[dot]=- com. Additionally, if you have any notable filter items that you would like to share, I will review them and, if helpful, add to the trunk with credit to you.

Update (30 Apr 13): I made a gross failure in testing the Regular Expression feature in version 1.1. In short, it didn't work. That's been rectified, and it's working perfectly. I also added some rules on how to create new rules, to meet the requirements of the regular expression parser.

Noriben - The Portable Sandbox System

Noriben is a Python-based script that works in conjunction with SysInternals Procmon to automatically collect, analyze, and report on runtime indicators of malware and suspicious system behavior. In a nutshell, it allows you to run your malware, hit a keypress, and get a simple text report of the system's activity after running an attack.

While there are many well developed and fully featured sandboxes, such as Cuckoo, they all have various limitations that impacted the way I do malware analysis. Noriben was written specifically to fill these gaps. Noriben is an ideal solution for many unusual malware instances, such as those that would not run from within a standard sandbox environment. These files perhaps required command line arguments, or had VMware/OS detection that had to be actively debugged, or extremely long sleep cycles.

Bypassing Anti-Sandboxing

One common instance to use Noriben is with malware that is VM and Sandbox aware. Throwing the sample into any existing sandbox will most likely result in a report with no artifacts as the malware didn't run. Some applications look for manual user activity, such as mouse movement and clicking. Other malware may infect the WinHTTP stack and only trigger when a web browser is used. By just launching Noriben in the background, all of the system behavior is logged as the analyst manually controls the system to give the impression of a normal user. Once the file has been detonated, the results can be reviewed as a standard sandbox report.

Command Line-Based Applications

In rarer cases are malware samples that require command line options in order to run. Launching these executables within a sandbox would immediately fail as the malware does not have the arguments to operate. However, an analyst manually controlling the malware while Noriben is running can quickly gather all system artifacts from various command line options.

General Attack Artifacts

Even more interesting, Noriben has been used by pentesters to determine what system artifacts exist when launching an attack against a system or service. By monitoring files created or registry entries modified, a security analyst can determine all artifacts that result from running an attack, a PowerShell command, or a Javascript-based web page.

Perfect for Malware Analysis on the Road

It's commonly a scenario where an analyst may have a proper sandbox environment in a home lab but on the road has only a laptop. In working with various Sales Engineers and Support individuals from security companies, there were many times where they needed an immediate malware answer out of their hotel room. Noriben was designed to be used with little effort, little setup, and little maintenance. Even if you don't have a dedicated malware VM, any Windows VM will do! Even <a snapshot copy of> your corporate environment!

How to Run Noriben

Noriben is simply a Python wrapper to SysInternal's Process Monitor (procmon.exe). Procmon is a system artifact collection tool that stores millions of events into a massive database. However, for many analysts, this turns into information overload. Noriben works as a filtering system to remove all activity that's known to be from legitimate activity. Therefore, whatever is left over is very likely to be related to suspicious activity from malware or an attack.

Simply run Noriben.py and wait for it to start listening to the system. Once prompted, run your malware or perform your attack actions. When the malware or attack has reached a point of activity necessary for analysis, stop Noriben by pressing Ctrl-C. Noriben will then stop the logging, gather all of the data, and process a report for you.

Noriben will actually produce multiple reports: a readable text document, a CSV separated by activity type, and a full timeline CSV.

Noriben in Action

In my last blog post, I showed one of my recent tools for parsing Java IDX files, a forensic byproduct of Java-based malware infections. In that post we talked about the first-stage malware attack which was used solely to drop a file named hehda.exe to the user's Temporary folder. What was that executable and what does it do? Let's turn to Noriben:

Java Malware - Identification and Analysis

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

This folder contains numerous subdirectories, each corresponding to an instance of a downloaded file. By sorting the directory recursively by date and time, one can easily find the relevant files to examine. These files will be found auto-renamed to a random series of hexadecimal values, so don't expect to find "express.jar", or whatever file name the JAR was initially downloaded as.

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.

Malicious PDF Analysis: Reverse code obfuscation

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:

Geolocational Log Analysis: Think Globally, Act Locally

In many network environments the administrators and security engineers have an understanding of the full geographical scope and reach of their network. While some corporations have a global audience and expect traffic from the far reaches of the world, others are more localized and target a specific small region.

A health care provider for Alaska would monitor its network connections to ensure that network connections are limited to its main source of users, i.e. those in Alaska. An insurance company in St. Louis will see mostly traffic from IP addresses in Missouri, but Illinois as well, due to the city  being on the state line.

Occasionally, administrators may notice connections being made from Hawaii, Bermuda, or Italy, signifying users who are on vacation but are still wired in to their work. However, a long-term series of connections from a Eircom subscriber, Ireland’s largest ISP, should spark interest to the network administrator of a Seattle tax firm.

While anonymous web connections from global addresses are common, specific attention should be paid to such addresses being used to access password-protected areas of a corporation. This could include remote file access, VPN and web-based corporate email.

In such cases the logs from these applications, usually supplied in plain text or W3C format, contain details about transactions to include the remote IP address and the account name being authorized. In reviewing logs from various incident responses cmdLabs has found details to show that a short log review made on a daily basis could help smaller corporations determine quickly if a user account was compromised and accessed from a remote location.

For example, the log sample below from a Cisco ASA tracks VPN connections. The user “cmdLabs\bbaskin” was accessed via the IP address of 159.134.100.100 on 2 April, 2011, an IP that was traced back to Ireland. A few hours later the same account was accessed from an IP address in Austria.

Apr  2 21:53:37 192.168.1.1 Apr 02 2011 21: 53:08: %ASA-6-302013: Built outbound TCP connection 7823 for inside:10.10.10.50/389 (10.10.10.50/389) to NP Identity Ifc:192.168.1.1/1047 (192.168.1.1/1047)
Apr  2 21:53:37 192.168.1.1 Apr 02 2011 21: 53:08: %ASA-6-104: AAA user authentication Successful : server =  10.10.10.50 : user = cmdLabs\bbaskin
Apr  2 21:53:37 192.168.1.1 Apr 02 2011 21: 53:08: %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = cmdLabs\bbaskin
Apr  2 21:53:37 192.168.1.1 Apr 02 2011 21: 53:08: %ASA-6-113008: AAA transaction status ACCEPT : user = cmdLabs\bbaskin
Apr  2 21:53:37 192.168.1.1 Apr 02 2011 21: 53:08: %ASA-6-734001: DAP: User cmdLabs\bbaskin, Addr 159.134.100.100, Connection Clientless: The following DAP records were selected for this connection: DfltAccessPolicy

For this small set of data it is trivial to query each IP address to determine its country of origin, netblock owner, and other details that would highlight unauthorized access. The problem arises when you have hundreds of thousands of such transactions in your daily log files.