Journey Into Incident Response

The most common question someone asks me after they find out the work I do for a living is “what tools do you use”. This occurs regardless if the person only knows about digital forensics from TV shows or if they are a fellow practitioner. At meetings, conferences, or passing conversations the question is always one of the initial things someone asks. The question that has yet to be asked and in my opinion is the most important is “what process do you use”. The process is what determines the steps one takes to achieve an end goal; the tools only help complete those steps. Talking about tools outside the context of a process doesn’t provide an accurate picture. A carpenter can talk about his hammer all day long. It won’t mean much until he explains how he uses the hammer to accomplish something. In this post I’m unleashing auto_rip which is a wrapper script for RegRipper. Not only do I talk about what auto_rip is and how to use it but I also explain the process behind it as well.

System Examination Process

When I started this blog my main focus was to discuss the “process for investigating security incidents”. My first few posts were about the “initial examination steps I put together to investigate systems”. Ever since those early posts I’ve been honing and improving upon my process. I outlined my methodology on the jIIr methodology webpage and below are some of the steps listed for system examinations.

     * Profile the System
          - General Operating System Information
          - User Account Information
          - Software Information
          - Networking Information
          - Storage Locations Information
     * Examine the Programs Ran on the System
     * Examine the Auto-start Locations
     * Examine Host Based Logs for Activity of Interest
     * Examine Web Browsing
     * Examine User Profiles of Interest
          - User Account Configuration Information
          - User Account General Activity
          - User Account Network Activity
          - User Account File/Folder Access Activity
          - User Account Virtualization Access Activity
     * Examine Communications

Examination Steps + Artifacts = Categories

Taking a closer look at the above examination steps it’s easier to see how artifacts can be organized beneath them. Take for example the step “Examine the programs ran on the system”. Beneath this step you can organize different artifacts such as: application compatibility cache, userassist, and muicache. The same concept applies to every step and artifact.

The biggest benefit to approaching examinations in this manner is the increased efficiency and speed. You no longer find yourself jumping around looking at different items on a system. You remain focus on what you need to do and the data you need to examine to accomplish your end goal. When you start looking at all the artifacts within a category you get a more accurate picture and avoid overlooking artifacts when processing a case. The end result is your examinations are more focused, efficient, and timely. This is the concept behind why auto_rip was needed; this is the examination process auto_rip follows.

Unleash the auto_rip

There is one data source that provides a wealth of artifacts throughout the examination process. This data source is the Windows registry and it contains information for every single examination step I listed above. To parse the information from the registry my tool of choice has been RegRipper. However, I found myself doing one of two things. I was either running all the RegRipper plug-ins according to their registry hives then jumping around the reports depending on the step I was doing. The other method was running select plug-ins with rip (RegRipper command-line tool) based on the step I was performing. Both methods worked but they weren’t as fast as I wanted it to be when doing my examination process. Enter auto_rip.

Auto_rip automates the execution of the RegRipper plug-ins according to my examination process. I reviewed every RegRipper plug-in and organized them beneath the categories. I then looked over my extensive reference sheet to see what plug-ins were needed or had to be updated. Lastly, I wrote auto_rip to execute the majority of the plug-ins based on the categories. As it stands right now, auto_rip is a command-line script and its help menu is listed below:

auto_rip v2013.05.16

auto_rip [-s path] [-n path] [-u path] [-c categories]

-h, --help lists all of the available options
-s, --system path to the folder containing the SAM, Security, Software, and System hives
-n, --ntuser path to the folder containing the NTUSER.DAT hive
-u, --usrclass path to the folder containing the UsrClass.dat hive
-c, --cat specifies the plug-in categories to run. Separate multiple categories with a comma

Supported Categories:
     all                  gets information from all categories
     os                  gets General Operating System Information
     users              gets User Account Information
     software         gets Installed Software Information
     network          gets Networking Configuration Information
     storage           gets Storage Information
     execution        gets Program Execution Information
     autoruns          gets Autostart Locations Information
     log                 gets Logging Information
     web                gets Web Browsing Information
     user_config      gets User Account Configuration Information
     user_act          gets User Account General Activity
     user_network    gets User Account Network Activity
     user_file          gets User Account File/Folder Access Activity
     user_virtual      gets User Account Virtualization Access Activity
     comm              gets Communication Software Information

Usage:

Extract all information from the SAM, Security, Software, and System hives.
C:\>auto_rip -s H:\Windows\System32\config -c all

Extract file and network access information from NTUSER.DAT hive (Windows XP user profile)
C:\>auto_rip -n "H:\Documents and Settings\Corey" -c user_network,user_file

Extract file access information from NTUSER.DAT and UsrClass.dat hive (Windows 7 profile)
C:\>auto_rip -n H:\Users\Corey -u H:\Users\Corey\AppData\Local\Microsoft\Windows -c user_file

The auto_rip archive contains two files: auto_rip.pl and auto_rip.exe. Auto_rip.pl works with rip.pl while auto_rip.exe works with rip.exe. The script has been successfully tested on Windows and Linux. The auto_rip script needs to be placed in the same directory as rip.pl (or rip.exe). The output reports are placed in a sub-directory named auto_rip-reports as shown below.


Side note: sometimes files named with numbers appear inside the RegRipper folder during execution. These files can be ignored and deleted when the script finishes

Different Ways to Use Auto_rip

Automating RegRipper is not a new concept for me. I first discussed it almost two years ago in the post Obtaining Information about the Operating System. Auto_rip is just taking it to the next level and automating extracting information from the registry according to categories. I’ve been using auto_rip for some time now (initially it was a batch script). It has made my examinations faster; allowing me to produce results faster. How auto_rip is used depends on what you are trying to accomplish but here are a few ways I use it.

One of my initial steps in any examination is to profile the system. To determine basic operating system information such as version, timezone, and installation dates, installed software information, local user accounts, networking configuration, and storage locations. It’s fairly easy to extract all this information with the command below.

C:\>auto_rip -s H:\Windows\System32\config -c os,users,software,network,storage

I tend to look what programs executed on the system and what programs are set to launch automatically when confronted with a system infected with malware. Again it’s fairly easy to do with auto_rip even when a user profile is included.

C:\>auto_rip -s H:\Windows\System32\config -n H:\Users\Corey -u H:\Users\Corey\AppData\Local\Microsoft\Windows –c execution,autoruns

Maybe I’m not interested in the programs that executed and only want to extract the Auto-Start Extensibility Points (ASEPs) from the registry hives. It’s breeze with auto_rip.

C:\>auto_rip -s H:\Windows\System32\config -n H:\Users\Corey -u H:\Users\Corey\AppData\Local\Microsoft\Windows –c autoruns

Another item I’m always interested in is what a user account has been doing on a system. What did they access on the network and what files and folders were opened. Extracting this information may be time consuming with other methods but not with auto_rip.

C:\>auto_rip -n H:\Users\Corey -u H:\Users\Corey\AppData\Local\Microsoft\Windows –c user_act,user_network,user_file

To make things even easier and typically what I end up doing. Just run auto_rip with all the categories selected and review the output reports as needed. It only takes about a minute or two to finish.

C:\>auto_rip -s H:\Windows\System32\config -n H:\Users\Corey -u H:\Users\Corey\AppData\Local\Microsoft\Windows

What’s Next

Auto_rip is an evolving tool. It started out as a batch script (that I didn’t release) and was moved over to Perl to it more versatile. Development is ongoing. My future plans are to extend its functionality and provide a GUI version to go along with the command-line version.

auto_rip download location is here

In this edition of Linkz I’m talking about tools I came across in the past week. There are tool updates, new tools, and some tips about existing tools. Without further ado ….

New RegRipper Version

RegRipper has been a frequent topic on my blog lately. The tool rocks and it has saved me so much time over the years. A new version of RegRipper (v2.8) was released as well as a new plug-in archive. Harlan said what the updates were in his post RegRipper Updates. I tested out the new Alert functionality for its malware detection capabilities and wanted to share some results about my tests.

I ran every auto-runs RegRipper plug-in across the registry hives infected with MD5 0db4749ae2ec96c4612183e85b48cbb9. My keyword search for Alert found the following entries pointing to the malware (alert was generated since those registry values were present).

ALERT: winlogon: Wow6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon Shell value not explorer.exe: Explorer.exe, C:\Windows\System32\1055\svchost.exe

ALERT: winlogon: Wow6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon Userinit value has multiple entries: C:\Windows\System32\userinit.exe, C:\Windows\System32\1055\svchost.exe

ALERT: winlogon: Wow6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon System value found: C:\Windows\System32\1055\svchost.exe

I then ran every auto-runs RegRipper plug-in across the registry hives infected with MD5 04b687a43618272aa88b83efc1cce8a7. My keyword search for Alert found the following entries pointing to the malware (alert was generated based on the registry value).

ALERT: cmd_shell: Clients\StartMenuInternet\IExplore.exe\shell\open\command warning: "C:\Users\lab\AppData\Local\yyr.exe"

The last test I’m mentioning was I ran every auto-runs RegRipper plug-in across the registry hives infected with MD5 78c9d2949c81984414e6e1f5974905e1. My keyword search for Alert found numerous entries and two of them were (alert was generated based file path and file extension).

ALERT: user_run: Temp Path found: Software\Microsoft\Windows\CurrentVersion\Run : User Agent -> C:\Users\lab\AppData\Local\Temp\svchost.com

ALERT: user_run: Path ends in .com/.bat: Software\Microsoft\Windows\CurrentVersion\Run : User Agent -> C:\Users\lab\AppData\Local\Temp\svchost.com

RegRipper Auto-runs Plug-ins

Speaking about RegRipper auto-runs plug-ins. Back in March I wrote up the post Tracking Down Persistence Mechanisms outlining the research I did to track down the most common auto-run locations leveraged by malware. I even did a post about the updates made to the RegRipper to account for all the Run keys. Harlan did a post as well but about the Winlogon key. The RegRipper archive has been updated to account for all the commonly used auto-run locations. The ASEPs RegRipper Wiki page outlines all the auto-run plug-ins and the locations they check.

Parsing the $LogFile

I picked up on the next set of links from Joakim Schicht’s post over at a ForensicFocus forum. I should have known about his tools before now; at least now I’m informed and passing along a gem. Joakim’s post was about his new tool LogFileParser which parses the NTFS $LogFile. There are not that many tools available to parse this artifact so seeing one released (along with its source code) is awesome. I can’t do justice explaining the tool’s capabilities so just read the link to the LogFileParser’s Wiki page. It looks like Joakim wasn’t done since he released another tool (UsnJrnl2Csv) to parse the $UsnJrnl artifact. LogFileParser is able to parse the $UsnJrnl file as well but UsnJrnl2Csv is a standalone tool. Checking out his available downloads there are a slew of other tools from parsing the $MFT (mft2csv) to extracting NTFS artifacts from images and VSCs (NTFS_File_Extractor). Definitely take the time to check out Joakim’s site and try out his tools. I know my toolkit is getting updated.

Not sure why I’m excited about tools to parse NTFS artifacts. Check out these links to see why: Re-Introducing $UsnJrnl, Layering Data, and a bunch of posts on David Cowen’s blog.

Strawberry Perl and Log2timeline 0.65

I recently was rebuilding my laptop and I encountered pretty significant issue. On Windows I always used ActiveState Perl since I keep older versions of the program and never had problems installing modules. However, ActiveState made a change involving older versions of their software. You are no longer able to install modules in older ActiveState Perl programs (5.12 and older) without a business license. This means if you want to run 5.12 then you need to pony up some dough to buy the business license. This is where my issue arose. Log2timeline 0.65 does not work with ActiveState Perl 5.14 and 5.16; you need version 5.12. There is no way I’m going without Log2timeline on Windows so I reached out to Twitter for Perl alternatives. A few people pointed me to Strawberry Perl. I looked into it and tried it out. Final verdict is ActiveState Perl will never touch my systems again. If my endorsement isn’t enough check out the quote on the website from Larry Wall.

The next item was to get Log2timeline working on Windows with Strawberry Perl. Matt Presser has a nice tutorial walking you through the process in his post Timeline Analysis. His instructions worked like a charm and now I’m back in business with Log2timeline on my Windows box (RegRipper works fine with Strawberry too).

Thugging with REMnux

Maybe it’s just me but whenever I think about the Thug honeyclient all I can think about is 90s gangster rap. Westsideeee!!!!!! I first became aware about Thug when Kyle Maxwell mentioned it on his blog. Thug is pretty slick since it enumerates vulnerable clientside applications and captures exploits and malware served up in drive-bys. A new version has been released which you can grab from their GitHub site.

REMnux is a distro put together by Lenny Zelster to perform malware analysis. There are not only tools for performing malware analysis but there are also tools to analyze clientside exploits such as PDFs and office documents. Lenny released REMNux 4 which you can grab from here.

REMnux provides a wealth of tools to analyze clientside exploits while Thug provides the ability to capture these exploits. Needless to say, I wanted to get Thug up and running inside REMnux since it’s not installed by default. I Goggled around for installing Thug on Ubuntu and found a tutorial on how to do it. My attempts weren’t successful since the installation failed due to a missing dependency. I was stuck until David Kovar gave me the command to use which resolved my dependency issue. If you want to get Thug up and running on REMnux do the following:

First run the command below

apt-get install libboost-dev libboost-python-dev libboost-thread-dev libboost-system-dev python-pip python-dev python-pydot

Run the command a second time to make sure everything installed properly.

Then follow the steps outlined in the article How to install Thug Python client honeypot. I’ve had Thug up and running for about a week now and so far it doesn’t seem like anymore dependencies are missing.

Thank You

Earlier in the year I sent out a tweet that was driven by disappointment. This blog is for personal use so I barely discuss what kind of work I did. I was in a pretty cool job. On the one hand I provided digital forensic support for security incidents, fraud, and investigations. On the other I was doing pen testing against public sector organizations. This was the role that made me want to get into incident response. I knew how to attack systems as well as investigate them. Seemed like a natural starting point for me to start my journey into incident response. My tweet hinted to the fact my role was changing; a change that didn’t align with my career goals in InfoSec.

I received an overwhelming response from the DFIR community. People offering help in any way they could. I also received support from people I know locally. I may not have taken anyone up on their offer for help but I did appreciate it. It meant a lot and made me realize I have a lot more people I can reach out to then I thought.

Thank you. Thank you to everyone who reached out to me and offered me support.

This Is a Personal Blog but ….

jIIr has always been a personal blog and the content revolves around my personal research and interests. However, I am influenced by the work I do for eight hours a day and it gives me ideas to research. A few weeks back I started in my new position. My primary responsibilities are internal incident response and compliance security testing. I can see the research ideas pouring into my mind as I type this sentence. My blog hopper is already full of things I need to write about. You may see the blog a little more focused on items related to incident response (from the internal perspective) with a sprinkle of pen testing.

Disclaimer: anything you see on this blog is personal and has nothing to do with my employer.

Malware Analysis Course

Hopefully you didn’t get your hopes up about the direction the content is going. You might notice I’m not updating the blog as frequent as I used to. I mentioned on Twitter a few times I’m developing a course. I didn’t really publicized what I’m working on and the impact it’s had on my ability to do research and blogging. I’m developing the Malware Analysis course for Champlain College’s Master of Science in Digital Forensic Science program. The course development has been intense and most of my personal time (and days off) has been focused on the course.

I remember taking college courses (both graduate and undergraduate) and afterwards thinking it was a complete waste of time. I even took courses where I felt the content was lacking. I also took trainings where not only did they not cover the theory behind things but there wasn’t a defined process to what they were teaching. I even took trainings where I wanted more but that content was provided in another course at an additional cost. I wanted Champlain College’s Malware Analysis course to be nothing like what I experienced before. Instead I wanted it to resemble the type of course I would love to take. The course is pretty intense but at the end students will have explored a range of topics including: malware fundamentals, malware anti-forensics, how to find malware (both in memory and on disk), and how to reverse malware and exploits.

Next Project on the Horizon

After I finish the course I’m going to focus on a project I put on hold. Last summer I decided I had to write a book. There are some things I want to say and the best format to do so is in a book. I won’t go into the details about the content at this time. However, I did want to provide a few teasers. If you followed my blog for any time then you know I frequently discuss the process I use to perform examinations. In some posts I show the process in action such as the article Finding the Initial Infection Vector. What I haven’t revealed is the detailed checklist I put together that goes along with the process. Just the Windows examination portion is about 60 pages. This checklist is going to be either Appendix A or B in my book.

A cool thing about having a detailed process is it can be automated. I wrote some initial scripts to automate the majority of my process. I may release an earlier version of one script but the detailed checklist will be accompanied with a tool or three to automate the examination process. The book will outline a process to follow and provide tools to make the process as fast as possible. The process is only a small piece of what I got in store. If you enjoy reading jIIr, learning about malware detection, and exploring attacks involving malware then you won’t be disappointed.

Detecting Fraudulent Documents

I updated the material for my technique to detect fraudulent documents by analyzing their metadata. I uploaded my latest slide deck to my jIIr site (PDF download) and new cheat sheets for Microsoft Word and Excel documents. My intention was to put together a white paper on the technique but I didn’t have the time. Now I’m probably just going to do a blog post on the topic (hopefully) as my formal good-bye to the fraud world.