Journey Into Incident Response

This is a quick post to pass along that I updated my auto_rip script. For those who may not know, auto_rip is a wrapper script for Harlan Carvey's RegRipper program and it executes RegRipper’s plug-ins based on categories and in a specific order. To learn more about my script please see my previous post Unleashing auto_rip. The auto_rip updates are pretty minor. I separated out the changes to a change log instead of documenting changes in the script itself, added a device category (due to a new plug-in), and I added most of the new RegRipper plug-ins Harlan created (as of 7/30/15). The download location can be found on the right of my blog or using this link to its Google drive location.


****** 08/11/2015  Update *******

At this time I removed the compiled executable from auto_rip. The compiled executable is having issues and I'm working to resolve it. However, the perl script is present and works fine. As soon as I'm able to compile the script into an exe then I'll add it back to the auto_rip archive

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

I find myself in more situations where I’m not completely satisfied with my DFIR tools. They either don’t parse certain information or lack capabilities I want. Batch scripting helped in some situations but the scripts are limited in what I can do. For example, it’s difficult (if not impossible) to create a script to extract information from an artifact that’s not supported by existing tools. Learning a programming language has been at the top of my to-do list for some time due to these reasons. I was browsing my local book store when I came across the book Perl Programming for the Absolute Beginner.

Why Perl Programming for the Absolute Beginner

I chose the book after I skimmed through a few other Perl programming books. Perl Programming for the Absolute Beginner is written for an audience without previous programming experience. The book goes into great detail explaining basic programming concepts such as variables, arrays, loops, and subroutines. I took a C++ course in my undergraduate about seven years ago and the only thing I remember is that I took a C++ course. Basically, I have zero programming knowledge including not knowing much about programming concepts. A lot of the books I skimmed, such as Learning Perl, don’t take the time to explain the basic concepts since they expect the reader to be already familiar with them. I wanted a book to explain the basics in addition to the language; Perl Programming for the Absolute Beginner fit the bill.

Numerous books I looked at use exercises at the end of each chapter to reinforce the material covered. The exercises are pretty simple and perform one action such as a math calculation. Perl Programming for the Absolute Beginner takes a different approach in teaching Perl. Instead of individual exercises the book has the reader write computer games which are fully functioning programs. I thought this approach does a better job showing how to use Perl since it covers the planning, organizing, coding, and testing activities involved with script development. Plus the approach was entertaining and it kept my interest. I’d rather write a “Fortune Teller Game” than a script to compute “the circumference of a circle”. ‘nuff said.

What I learned

My review is going to be a little different. I’m neither discussing the book’s contents (if you want to know then read the table of contents) nor how helpful the book could be. Instead I’m talking about what I learned from the book and how it has impacted my DFIR work so far.

Seeing Behind the Curtain

Bear with me for this analogy… When I was younger I used to love watching Kung-fu. At times I watched movies completely in another language without subtitles. I got the gist of what was going on by watching body language, facial expressions, tones of people’s voices, and the bad guys getting stomped. However, when I watched the same movie in English (subtitles or dubbed over) I realized how much I missed about the movie’s plot. Learning Perl is the equivalent of adding subtitles or dubbed English to a Kung-fu movie. Before I understood the gist of what my Perl tools were doing but it’s completely different when you can read and actually understand the code to see how it produces its output. It let me see behind the tool abstraction curtain.

Extending my Capability

I was considering between learning Perl or Python since programs in my toolbox are written in those languages. One of my goals is to learn a language that lets me customize tools to better meet my needs. I picked Perl because two tools I extensively use are written in Perl and plug-in based. Plug-ins allow the tool to be extended fairly easily and I felt knowing how to write them would have a greater impact on my DFIR work. My immediate need was for a Regripper plug-in to parse the UserInfo registry key in an NTUSER.DAT hive (I could have asked others for this but I wanted to learn how to do it). In the past I manually examined the UserInfo key in the NTUSER.DAT hive and if present the hives in system restore points or volume shadow copies. Performing the task was time consuming but I needed to know the information. Perl Programming for the Absolute Beginner taught me enough about Perl to make it pretty easy to write a plug-in once I re-read the creating plug-ins section in Windows Registry Forensics. Taking the time to put the userinfo plug-in together will make things easier and faster for me in the future since I can now extract the information from a system in seconds. Talk about improving efficiency.

Breaking my Handcuffs

I’m still wearing handcuffs since I’m still dependent on existing tools and scripts created by others. However, Perl Programming for the Absolute Beginner opened my eyes to a future where if I encounter an artifact not supported by my tools then I could just write my own. A future where I no longer have to be satisfied and accept tools’ outputs when I want to see data differently. A future where repetitive tasks can be automated enabling me to spend more time on analyzing information. The book opened my eyes to a world where I don’t have to be handcuffed to my DFIR tools and the capabilities they provide. Perl Programming for the Absolute Beginner did not make me into a tool developer but it provided me with a foundation to build upon.

Four Star Review

Not all is rosy with the book though. I normally can overlook typos but I’m not very forgiven when there are typos in the code the reader is suppose to copy. It’s bad enough that beginners are going to mess something up and spend time tracking down their own mistakes. There’s no need to add even more typos resulting in people questioning themselves wondering what else they did wrong. Chapter Four’s Star Wars Quiz declares a variable named $valid but the rest of the program uses the variable $isvalid (on page 129). That small typo makes the game not work until the variable $valid is changed to $isvalid. As a reader I shouldn’t be required to find typos in code in order to make things work. I spend enough time finding my own mistakes as it is.

Overall I give Perl Programming for the Absolute Beginner a four star review (based on Amazon’s rating scheme). I highly recommend the book for anyone looking to learn the Perl programming language in addition to basic programming concepts. The book teaches the basics in an entertaining way enabling anyone to write simple scripts to solve issues. For those with programming backgrounds then I suggest looking elsewhere for a book on Perl since this is too basic. Learning Perl is a decent candidate because the target audience is for people familiar with programming concepts (I moved on to this book after reading Perl Programming for the Absolute Beginner).