NIST Hacking Case Tutorial: Wrap up an Old-School Badguy by Happy Hour

Link to the case and evidence download

Link to lab setup post

I'm not looking to create a one shop stop for homework answers, I'd rather use these cases to demonstrate a methodology to efficiently analyze a case. Thus we won't be answering all of the questions from the NIST site, we'll be setting objectives that support the case and using only the evidence and tools needed to answer them. Please read the details on the NIST site and download the evidence E01 image files.

Greg Schardt is suspected to be associated with this acquired laptop and to go by the alias "Mr. Evil", known to war-drive T-Mobile and Starbucks WiFi, intercepting network traffic and stealing user information.

Figure 1: The hacking tools in this case are so nostalgic, they are only relevant to a student in a CEH prep course (Burn!)

Our Basic Objectives:

•  Document basic information on system (time zone, hostname, usernames etc)
• Evidence Needed: Reg hives
  
• Tools Needed: Registry Ripper (rip.pl)
•  Find evidence of the real owner of this computer. Is this system tied to Greg Schardt / Is Schardt Mr. Evil?
• Evidence Needed: Mounted image (for keyword search) and Reg hives
• Tools Needed: Registry Ripper (rip.pl), GoG (Good Ole' Grep)
•  Find evidence of any hacking activity, tools and devices and tie them back to a user.
• Evidence Needed: Reg hives, Prefetch, MFT
• Tools Needed: Filesystem Timeline (fls, mft2csv, or log2timeline/plaso), Registry Ripper (rip.pl)

Given these objectives I've selected a handful of tools to process the evidence and answer our questions. No rabbit holes here (hopefully). Based upon this plan the only environment we should need to process the case is our SIFT Workstation VM.

Here's a link to my evidence and timeline spreadsheet I created throughout the below process if you want to follow along. I have the commands run and the output mapped back to the set objectives. I've found Google Docs to be a KEY tool for documenting cases especially if you're collaborating with multiple analysts. By mapping evidence back to objectives and documenting every significant command run, it's very easy to pick and choose the items that tell the story when writing the report.

1. Prework and Evidence Collection

• Mount the image in the SIFT-Workstation (see link for more detail)
• Ewfmount the E01 in SIFT. This will create a raw image of the drive in the mountpoint you select (replace with full path to your image if necessary): ewfmount 4Dell\ Latitude\ CPi.E01 /mnt/ewf/
• Find the correct offset for mounting the NTFS partition. mmls /mnt/ewf/ewf1 - This disk has 512-byte sectors and the NTFS partition begins at sector 63 thus "expr 63 \* 512" = the NTFS partition starts at byte 32256.
• Mount the raw image stored in "ewf1" as a read only, with the ability to read Windows Alternate Data Streams, starting at the offset we determined previously: mount -o ro,loop,show_sys_files,streams_interface=windows,offset=32256 /mnt/ewf/ewf1 /mnt/windows_mount
• Create a case folder: mkdir /cases/nist
• Assuming we mounted the E01 in /mnt/windows_mount/ run the following command to make a new folder and copy the registry hives to it: mkdir /cases/nist/reg && cp /mnt/windows_mount/WINDOWS/system32/config/*  /cases/nist/reg
• find /mnt/windows_mount -iname "ntuser.dat" -exec cp -v --backup=numbered {} /cases/nist_hack/reg/ \;     <-- the "-exec cp -v --backup=numbered {}" portion of this ensures we copy ALL of the ntuser.dat files into our reg folder.
• Assuming we mounted the E01 in /mnt/windows_mount/ run the following command to make a new folder and copy the MFT to it: mkdir /cases/nist/mft && cp /mnt/windows_mount/\$MFT  /cases/nist/mft
• Is there a hiberfil.sys file? If so lets copy it, this is a memory dump from a point in time: mkdir /cases/nist/hiberfil/ && cp /mnt/windows_mount/hiberfil.sys  /cases/nist/hiberfil/

Figure 2: The "mmls" tool from The Sleuth Kit is vital for finding the partition information used to mount a raw image.

2. Process registry hives

• Many analysts (myself included) use more modules than they need in Reg Ripper, or resort to using another "kitchen sink" tool. Get used to running just the modules that you need. You can search the modules you need using: rip.pl -l | grep "keyword"
• In this case we need to use at least: compname (hostname), logonusertimezone (determine the timezone), appcompatcache (shimcache - evidence of execution), prefetch (to determine if prefetching is enabled), network (for system hive - look at adapters), network (for software hive - look at connected networks)
• Run the Reg Ripper commands that you need to run using: rip.pl -r <hive> -p <modulename>
• Output of all the commands I ran in the Google Sheet

Figure 3: I wonder what the timezone for this system... Oh wait, Thanks Harlan Carvey :-)

3. Keyword Searching

• Based upon the registry hive review - it's clear there are quite a few hacking tools that were installed in the vicinity of 8/27/2004 and adequate evidence that they were run. My main goal in keyword searching this image is to tie Greg Schardt to the "Mr. Evil" account.
• The simplest keyword search against this image is just: grep -r -i -a "schardt" /mnt/windows_mount/" (-r recursive, -i case insensitive, -a don't ignore binary files) which will come back with several hits. A tool such as Autopsy (or a commercial forensic suite) can do a better keyword search - but this is free, fast and sufficient in this case.
• Based upon the user's index.dat file there are several indications that Greg Schardt is in fact "Mr. Evil" and he's tied to the "mrevilrulez@yahoo.com" email address and accompanying "mrevil2000" Yahoo ID. Additionally - the "Look@Lan" software was downloaded by "Mr. Evil", and installed with "Greg Schardt" as the registered owner. Either Mr. Evil is Greg Schardt or someone is planting consistent misinformation.

Figure 4: Simple keyword search using Grep finds ties between "Mr. Evil" and "Greg Schardt" in index.dat file.

 

Figure 5: Keyword searching helped discover a configuration file linking "Mr. Evil" and "Greg Schardt".

4. Create and Analyze Basic Filesystem Timeline

• Using legacy Log2timeline (or tool of your choice) to create a filesystem timeline: log2timeline -z US/Central -r -w /cases/nist/timeline.csv /cases/nist/mft/   (Note - we found the timezone for this host during registry analysis)
• Open the CSV in LibreOffice OR simply use the CLI (Grep, Cut, Sort, Awk if you're so inclined, etc) to analyze the data.
• Document the significant events in your timeline, evidence of creation of the significant files, evidence of execution (Prefetch creation and last modification times), evidence of installation (creation of installer files, Prefetch creation for installer), etc.  

5. Process and Analyze Memory Image

• We found a hiberfil.sys file on this computer, which essentially means that hibernate is enabled. Our filesystem timeline showed us that this hiberfil was created on 8/19/2004 @ 6:04PM CST (before the hacking activity appears to have began). This limits the utility but it could still lead to new evidence and insights.
• Use Volatility to convert the hiberfil to a raw memory dump: vol.py imagecopy -f hiberfil.sys -O winxp.img
• Determine the Volatility profile to use with the "imageinfo" command: vol.py -f winxp.img imageinfo
• Use the pslist command to determine what processes were running at the time: vol.py -f winxp.img --profile=WinXPSP2x86 pslist   <-- Interesting entries: mirc.exe (IRC client) and msmsgs.exe (instant messenger)
• String searching is still a very valid method of finding certain types of evidence within a memory dump: strings winxp.img | grep -i "keyword"  additionally you can use the YARA functionality in volatility to search strings and determine which process they originated from with this format: vol.py -f <image> --profile=<profile> yarascan --yara-rules="keyword"
• The most valuable keyword search to run on memory is "://" because this generally catches URL's, UNC paths, all kinds of goodness. 
• In this case this search identifies highly suspect IRC channel access that could indicate child exploitation activity by Mr. Evil. The text from the IRC channels is explicit - I won't post it here, however let it be known I'd stop examining and be on the phone with the local FBI field office if I encountered this @dayjob.
• We can find some additional value by using the iehistory (gives us IE history as of 8/19 - could show something the user deleted), consoles (command line sessions from 8/19), connscan (network connections from 8/19), and mftparser (extract and analyze MFT from 8/19) commands. 

Figure 6: Network connections from the time the system was hibernated could prove useful.

Figure 7: You could use a command like the above to attempt to find passwords in memory (this one targeting the mirc.exe and msmsgs.exe processes). I have a YARA rule on my Github for this purpose

Figure 8: A simple string search can show IRC interactions in this case. This view shows every time "mrevilrulez" posted in IRC and the surrounding context.

Closing Thoughts:
There is even more one could do with this case, but in my opinion there is more than enough evidence in the Google Sheet to pick and choose through to make a very compelling, concise report that fulfills the objectives we set at the beginning of this post. I hope you picked up a few nuggets from this post, please do me a favor and leave any questions or recommendations in the comments.