Journey Into Incident Response

Mass injection attacks that compromise thousands of websites are now a common occurrence on the Internet. One of the more recent attacks was DarkLeech. Darkleech compromised thousands of servers running Apache which resulted in iframes being injected into the websites to redirect their visitors to malicious sites. Both the Sucuri Blog and Unmask Parasites Blog do an outstanding job talking about the artifacts left on the compromised servers. The one perspective that doesn’t get discussed often is from the visitors’ computers who happen to browse to these compromised websites. This post demonstrates how to perform a root cause analysis on an infected computer to determine if the initial infection vector was the result of an injected iframe.

The Malware Indicator

Every malware incident starts with an indicator. In this instance it was obvious the computer was infected with malware as can be seen in the screenshots below.




A program named “S.M.A.R.T. Repair” started running on the computer spitting up errors about the computer’s hard drive failing. The malware went so far as trying to hide folders and files to make it appear even more authenticate.

The Response

The purpose of this post is not to illustrate my examination process. For that you can refer to my other posts such as Finding Malware Like Iron Man, Malware Root Cause Analysis, or Finding the Initial Infection Vector. Instead my focus is on showing how the artifacts I found on the system lead me to the injected hidden iframe.

Every story has a beginning so I have to at least fill in the blanks about how I found the malware on this box. I initially grabbed the volatile data with modified version of the tr3secure volatile data collection script before taking the box offline. Looking at the running processes I quickly flagged a few suspicious items.


These stood out since they are randomly named programs; a great indicator by the way to identify malware. The process to executable mapping revealed where these files were located.


Armed with the knowledge about two suspicious files (C:\ProgramData\WqPb9DQGxuSfxt.exe and C:\ProgramData\VHuvoNRQPlUqRK.exe) I was able to quickly perform the root cause analysis. This analysis is what lead me to the injected iframe on a cached webpage.

My intention wasn’t even to discuss this examination; I completed it over a year ago. I saw an email come across a listserv about finding computers impacted by an injected iframe. After I read the email exchanges I wondered how many people actually know how to determine if an infected system was the result of an injected iframe or something else. I wanted to shed light on the topic by illustrating how to do it.

               **** Important *****

To protect the identity of all parties I have changed any identifiable information. I altered user names, URLs, domain names, certain values in URLs, dates, search terms, etc... Basically, everything you are reading related to the infection has been altered except for the malicious items. XMEN had nothing to do with the actual infection; I’m just a huge fan of the XMEN. Also, for brevity I’m only showing some of the final timeline I put together about the infection.

               **** Important *****

Following the Cookies Crumbs to an iframe

Searching for the malware I located in the volatile data brought me to the point of interest in my timeline.


The Tracing registry key showed a program named WqPb9DQGxuSfxt executed after the file was created on the system. To find out what happened on the system I had to look at the activity preceding the creation of the WqPb9DQGxuSfxt.exe file. The picture below shows some of that activity.


The jusched.log file revealed that the Java application ran around the time of this infection. Continuing on I found more interesting artifacts.


The Shim cache showed the presence of some other executables that were on the computer around the time of interest. The browser history showed the system accessing the URL hxxp://leynurivid.com. The web browsing activity continued on as shown below.


Remember my disclaimer above? Fake data alert!! The user visited a XMEN WordPress blog and the products page on the blog. Immediately preceding this activity brought me closer to the initial infection vector as shown in the picture below.


The 0.11512169499856473h7i.exe file’s name closely resembles the pattern I’ve seen numerous times for downloaders dropped onto systems after successful exploits. Not only was this the first reference to other file I found in volatile data (C:\ProgramData\VHuvoNRQPlUqRK.exe) but there was another artifact for Java execution. Can you guess what should appear next?


Immediately preceding the downloader and a modification to the Java prefetch file were Java exploits. At the time I parsed these Java index files manually since there were no tools available. However, at the time of writing this post there are now a few tools including: Brian Baskin's Java Cache IDX Parser (I used this parser for this post), Harlan’s idx parser, or Mark Woan’s JavaIDX parser. The 36158da7-67c256c0 file was a Java exploit and its index file (36158da7-67c256c0.idx) contained the following:

IDX file: 36158da7-67c256c0.idx (IDX File Version 6.03)

[*] Section 2 (Download History) found:
URL: hxxp://marcelleoonard.aa.am/gipoto/yzjnbweofzjngtc9.jar
IP: 173.236.50.237
: HTTP/1.1 200 OK
content-length: 18799
last-modified: Tue, 17 Apr 2012 04:45:22 GMT
content-type: application/x-java-archive
date: Fri, 20 Apr 2012 12:39:55 GMT
server: Apache/2.2.3 (CentOS)
deploy-request-content-type: application/x-java-archive

The 10874ac5-7334b734 file was another Java exploit and its index file (10874ac5-7334b734.idx) contained the following:

IDX file: 10874ac5-7334b734.idx (IDX File Version 6.03)

[*] Section 2 (Download History) found:
URL: hxxp://marcelleoonard.aa.am/gipoto/xuxvgpcwawdrdt.jar
IP: 173.236.50.237
: HTTP/1.1 200 OK
content-length: 9722
last-modified: Tue, 17 Apr 2012 04:45:22 GMT
content-type: application/x-java-archive
date: Fri, 20 Apr 2012 12:39:55 GMT
server: Apache/2.2.3 (CentOS)
deploy-request-content-type: application/x-java-archive

Both Java exploits were served up from the URL hxxp://marcelleoonard.aa.am. Java wasn’t the only application that was targeted.


An Adobe Reader exploit was served up as well but the system didn’t have this vulnerability. Notice the lack of Adobe Reader activity on the system? In the midst of all this activity involving the marcelleoonard.aa.am domain there was a cached webpage (xmen-steel_claws-for-sale[1].htm) from the XMEN website.


The activity before the exploits appearing on the system showed more Java execution artifacts and the XMEN webpage being accessed as shown above. At this point in the analysis I identified the malware and then traced the malware infection back to Java exploits. What was left was to identify what served up the exploits which the preceding activity revealed as shown below.


The activity that occurred before the exploits was web browsing activity involving that hxxp://marcelleoonard.aa.am URL again. One item was the cached webpage dabstepinattack[1].htm. Looking at the webpage code was confirmation about its purpose.


The dabstepinattack[1].htm file served up the Java exploits (xuxvgpcwawdrdt.jar and yzjnbweofzjngtc9.jar) and Adobe Reader exploit (grfoinbnktbq.pdf). The last piece to the puzzle was to figure out what caused the dabstepinattack.php page to appear. The preceding activity answered that question for me as shown below.


All of the activity involving malware, Java exploits, Adobe exploits, and the marcelleoonard.aa.am domain just stopped. There was only web browsing activity of the user searching for wolverine steel claws which lead them to the xmen-steel_claws-for-sale page on the XMEN website. Something on that webpage resulted in the redirect to the exploits so I took a closer look at it. In the cached xmen-steel_claws-for-sale webpage’s code showed there was an injected iframe pointing to the dabstepinattack.php page on marcelleoonard.aa.am domain.

In Closing

Systems will visit the thousands of websites compromised in mass injection attacks. If these systems have client-side vulnerabilities then mostly likely some of them will cross our paths due to them getting infected. To tie the initial infection vector back to a mass injection campaign all you need to do is locate the injected iframe at the top or bottom of the cached webpage.

This year I decided to step out of my comfort zone by presenting at conferences. I’m not a public speaker but I wanted to reach an audience beyond jIIr to provide information that may be helpful to combat malware. Specifically, a triage technique I have been using to find malware extremely fast (in less than 15 minutes). Below are my CFPs and links to the slide decks for the talk I gave at the SANs Digital Forensic and Incident Response Summit and New York State Cyber Security Conference.

Finding Malware Like Iron Man – SANs DFIR Summit Version

Finding Malware Like Iron Man – NYS Cyber Security Conference Version

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.

The next two RegRipper plugins I wanted to highlight are: soft_run and user_run. Some may have been familiar with what these plugins did and the registry keys they checked. I’m referencing the past tense since Harlan has been busy working and he updated these plugins in the process. Not only were new run keys added to the plugins but Wow6432Node keys were added as well. The registry run keys are locations on a system which automatically start programs. Run keys are present in the Software registry hives which start programs when the operating system starts. Run keys are also present in the NTUSER.DAT hives and these execute programs when the user logs onto the system. These plugins are demonstrated against registry hives from a system infected with Symantec detection W32.SillyFDC (MD5 78c9d2949c81984414e6e1f5974905e1).

soft_run plugin

The soft_run plugin parses the run keys located in the Software hive. The following are the keys checked:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKLM\Software\ Microsoft\Windows\CurrentVersion\RunServices
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Runonce
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Run

Windows performs Win32 emulation on 64-bit operating systems to make 32-bit applications work. Part of the emulation is registry redirection. 32-bit applications are redirected to HKLM\Software\Wow6432Node when they try to access HKLM\Software. The additional Wow6432Node run keys parsed by the soft_run plugin are:

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce

Running the soft_run plugin against the Software hive from the infected system produced the output below. In the output you will notice an entry for C:\Users\lab\Templates\cache\SFCsrvc.pif listed beneath a Wow6432Node. This malware entry provides us with a few different clues. First the malware obtained administrative privileges since a system-wide modification was made. The second was the malware was 32-bit executed on a 64-bit system.

soft_run v.20130329
(Software) [Autostart] Get autostart key contents from Software hive

Microsoft\Windows\CurrentVersion\Run
LastWrite Time Thu Apr 4 17:36:00 2013 (UTC)
VMware User Process - "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr

Microsoft\Windows\CurrentVersion\Run has no subkeys.

Microsoft\Windows\CurrentVersion\RunOnce
LastWrite Time Thu Apr 4 17:34:33 2013 (UTC)
Microsoft\Windows\CurrentVersion\RunOnce has no values.
Microsoft\Windows\CurrentVersion\RunOnce has no subkeys.

Microsoft\Windows\CurrentVersion\RunServices not found.

Wow6432Node\Microsoft\Windows\CurrentVersion\Run
LastWrite Time Thu Apr 4 18:48:45 2013 (UTC)
HotKey - C:\Users\lab\Templates\cache\SFCsrvc.pif
User Agent - C:\Windows\SysWOW64\fdisk.com

Wow6432Node\Microsoft\Windows\CurrentVersion\Run has no subkeys.

Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce
LastWrite Time Tue Jul 14 04:53:25 2009 (UTC)
Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce has no values.
Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce has no subkeys.

Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Run not found.

Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\RunOnce not found.

user_run plugin

The user_run plugin parses the run keys located in the NTUSER.DAT hive. The following are the keys checked:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Runonce
HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce
Run value listed in HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows

Similar to the soft_run plugin, user_run also takes into account Win32 emulation on 64-bit operating systems. The additional Wow6432Node run keys parsed are:

HKCU\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

Running the user_run plugin against the Software hive from the infected system produced the output below. In the output notice the entries for C:\Users\lab\Templates\cache\SFCsrvc.pif and C:\Users\lab\AppData\Local\Temp\svchost.com. The biggest clue provided by the output is the lab user account should be focused on to determine the initial infecton vector.

user_run v.20130329
(NTUSER.DAT) [Autostart] Get autostart key contents from NTUSER.DAT hive

Software\Microsoft\Windows\CurrentVersion\Run
LastWrite Time Thu Apr 4 18:48:45 2013 (UTC)
HotKey: C:\Users\lab\Templates\cache\SFCsrvc.pif
User Agent: C:\Users\lab\AppData\Local\Temp\svchost.com

Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run not found.

Software\Microsoft\Windows\CurrentVersion\RunOnce
LastWrite Time Thu Apr 4 17:35:09 2013 (UTC)

Software\Microsoft\Windows\CurrentVersion\RunOnce has no values.

Software\Microsoft\Windows\CurrentVersion\RunServices not found.

Software\Microsoft\Windows\CurrentVersion\RunServicesOnce not found.

Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Run not found.

Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\RunOnce not found.

Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Software\Microsoft\Windows NT\CurrentVersion\Windows
LastWrite Time Thu Apr 4 18:48:46 2013 (UTC)
Run value = C:\Users\lab\AppData\Local\Temp\svchost.com
run value = C:\Users\lab\AppData\Local\Temp\svchost.com
load value = C:\Users\lab\AppData\Local\Temp\svchost.com

A new RegRipper plugin archive was released during the RegRipper Consolidation. The archive contains some new plug-ins; one of them is the MenuOrder.pl plug-in. Before discussing the plug-in I thought it would be helpful to first explain the importance of the registry key it parses. I was working a malware case when actions were taken in an attempt to remove the malware. Not only was malware deleted from the system but artifacts associated with the malware were deleted as well. Despite these actions taken, there was still evidence present in the MenuOrder registry key. This plug-in’s importance is not limited to malware cases; it’s important for any case where it’s important to know what programs or favorites were deleted from a system.

The MenuOrder registry key contains Start Menu and IE Favorites artifacts. The article Start Menu and IE Favorites Artifacts in the MenuOrder Registry Key explains in-depth how these artifacts get populated in this key. The article states:

“In most versions of Windows, a user can manually organize the order in which applications and application groups are displayed in the Start Menu. A user might, for example, drag a frequently-used application group to the top of the Start Menu and leave the remainder of the items in alphabetical order.”

“Similarly, a user can manually rearrange items in the Favorites menu”

In essence, when a user changes the display for either the Start Menu or IE Favorites these settings are stored in the registry. The information that gets stored includes the directory structure and file names for the program shortcuts in the Start Menu and favorites in IE. This means we are able to see how the Start Menu or IE favorites looked at a certain point in time even if actions were taken to delete the program shortcuts or favorites. The registry keys storing the information are:

- HCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu2\Programs

- HCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Favorites

This by itself makes the MenuOrder key a useful artifact to examine. However, Harlan discovered something even cooler. In his post DOSDate Time Stamps in Shell Items he mentions how the MenuOrder key contains shell items. This means there are timestamps accompanying the file and directory names stored in the registry key. It’s another source to get the creation dates for items.

I ran the plug-in against a Windows XP NTUSER.DAT hive I had laying around and here are a few snippets from its output (command was rip.pl –p menuorder –r ntuser.dat)


menuorder v.20121005

\Start Menu2
LastWrite: Wed Apr 9 13:15:39 2008 Z

\Start Menu2\Programs
LastWrite: Wed Oct 13 14:32:52 2010 Z
Microsoft Office 2003
Set Program Access and Defaults.lnk
Accessories
WinZip
Adobe Reader 9.lnk
Internet Explorer.lnk (@xpsp1res.dll,-11001)
Microsoft Access 2003.lnk
Microsoft Excel 2003.lnk
Microsoft PowerPoint 2003.lnk
Microsoft Word 2003.lnk

\Start Menu2\Programs\Accessories
LastWrite: Wed Jun 9 19:26:37 2010 Z
Accessibility (@shell32.dll,-21760)
Communications (@shell32.dll,-21768)
Entertainment (@shell32.dll,-21772)
System Tools
Address Book.lnk (@shell32.dll,-22017)
Calculator.lnk (@shell32.dll,-22019)
Command Prompt.lnk (@shell32.dll,-22022)
Notepad.lnk (@shell32.dll,-22051)
Paint.lnk (@shell32.dll,-22054)
Program Compatibility Wizard.lnk (@C:\WINDOWS\system32\compatUI.dll,-115)
Remote Desktop Connection.lnk
Synchronize.lnk (@shell32.dll,-22062)
Tour Windows XP.lnk (@C:\WINDOWS\system32\tourstart.exe,-1)
Windows Explorer.lnk (@shell32.dll,-22067)
WordPad.lnk (@shell32.dll,-22069)

.......

\Favorites\Links
LastWrite: Mon Oct 4 18:31:22 2010 Z
Customize Links.url
Free Hotmail.url
Windows.url
Windows Marketplace.url
Windows Media.url

\Favorites\Microsoft Websites
LastWrite: Tue Sep 7 15:34:21 2010 Z
IE Add-on site.url
IE site on Microsoft.com.url
Marketplace.url
Microsoft At Home.url
Microsoft At Work.url
Welcome to IE7.url