12,424 views

Reading Time: 12 minutes

Case 001 Triage Disk Analysis

Get the materials and follow along!

Have you built your DFIR Fort Kickass, yet? How to build a DFIR Analyst Workstation found here.

Make sure you understand the basic rundown of forensic artifacts.

This post assumes you have a DFIR Analyst Station ready to analyze the Memory Images from The Case of the Stolen Szechuan Sauce.

IT IS RECOMMENDED THAT OTHER ARTIFACTS ARE ANALYZED PRIOR TO DISK ANALYSIS!

Learning Objectives of FLS Timline Creation and Analysis

Understand what an E01 File is and what it provides
Be able to mount an E01 file in SIFT
Understand what a disk file image is
Know what a body file is when discussing timeline creation and analysis
Be familiar with Volatility’s Timeliner plugin
Have basic knowledge of how to use FLS
Be able to describe what the purpose is of creating an FLS timeline

Semi-Required Knowledge

Common Tools

EWF Mount
Autopsy
FLS

Tools Covered Here

ewfmount
mmls
mount
FLS

Music

Notes

FLS Timelines of these lab machines will be far less impressive than real systems with years of data on them
- But hey – it’s the technique, concepts and tools we are learning here
Keep solid notes on your thinking around evidence and data that you find
- This is for teammates to understand your thinking
- Understand your own thinking later… or after sleep.
Notes should be accompanied by screenshots that tell a story
- Examples: Highlights, Boxes, Arrows Text. The reader should quickly understand what they’re looking at
A great note-keeping App that teams can use to coordinate is OneNote.
- Each host gets a tab etc.
A great piece of software to take Screen Shots is Greenshot

E01 What?

Before doing this lab please head over to the section on what an E01 file is and how to mount it.

Timeline Analysis

Timeline analysis is a one of the most important steps in processing a system during a forensics case. It will often tie up all of the loose ends during a case, as well as uncovering new findings and relevant events. The key is to not start with Timeline analysis. An investigator wants to approach timeline analysis with as many indicators known them from processing other artifacts first. Timeline analysis is not simply starting at line 1 and reading down the list. It is taking millions of lines of data, or more, and pouring them into a huge bucket. Sifting the bucket and producing something like a CSV file to go through. The investigator then begins to search through the timeline for known indicators; looking at events before and after indicators that are located; correlating information; and putting all of this information together to prove or disprove theories on how the incident occurred.

Time Zone Check

This is a great time to check the hosts Time Zone setting. In forensics we want to confirm everything with data. The victim company stated they were in Colorado. The incident happened in September. That means the host should have been set to Mountain time, and was 6 hours behind UTC at the time of the incident.

Wait!? Aren’t we supposed to do all forensics in UTC time? Yes. Not all the tools seem to do this correctly though. Let’s shelf this for a moment and check the data from the host.

With the forensic image mounted we need to copy the SYSTEM registry hive over to the Windows Forensics box.

You are allowed to use the GUI sometimes. Really. You are.

The path to Windows Registry hives is: /mnt/windows_mount/Windows/System32/config. A way to stay organized is to make a folder dedicated for Registry Hives and associated artifacts and tools outputs.

Moving Files Between Hosts

Tip: Copying files from your Linux VM to you Windows VM requires passing that file to the host first. In other words something like this:

Copy file from Linux VM (right click and copy)
Paste into the Host (somewhere like a folder on the desktop etc)
Select the newly placed file on the host and select copy
Paste in the Windows VM

A word of caution: if you’re about to move suspected malware between hosts you should zip the files up, password protect it with a simple password like infected before transporting it. This prevents accidental infection of your windows host. It also prevents Windows Defender from reaching in and deleting the malware. The -eswitch tells zip you want to password protect the file. Zip follows the format of: zip destination source.

Example:

zip -e reghives.zip SYSTEM

Acquiring the System Registry Hive

To analyze the SYSTEM registry hive you will want to grab the SYSTEM Hive logs as well. The System Hive is the file named SYSTEM in the /Windows/System32/config/ directory. The hive log files for the System hive will be SYSTEM.LOG1,SYSTEM.LOG2 etc. The log files and the hive itself are needed to get the most accurate picture of the registry hive in question.

From the location where the DC01 Image is mounted on your SIFT box (example: /mnt/windows_mount/Windows/System32/config/) try something like:
zip -e /cases/szechuan/dc01/disk/reghives/dc01-SYSHives.zip SYSTEM*

Registry Analysis of Time Zone Settings for the Victim

Once the SYSTEM hive, and its Log Files, are on your Windows Forensics host, open it with Eric Zimmerman’s Registry Explorer. Remember to stay to organized and place them into a folder that makes sense. Don’t drop them on the desktop like a bad admin. In Registry Explorer select File, select Load Hive and then the SYSTEM hive.

At this point it is going to ask if you want to load LOG files to help catch the uncommitted data.

Say yes and load logs.

Then save the newly rebuilt registry.

Load the rebuilt hive and skip loading the dirty one.

Profit.

It is a good habit in forensics to verify what you are being told or are theorizing. In this case we see the host is set to Pacific Time! Although many forensics tools claim to simply convert the event times to UTC this does not always seem to be the case.

Prior Analysis

Conducting disk analysis is far easier when you have pivots from examining other artifacts in the case. This will be far easier with keyword searches. For example, searching for a known name of previously discovered malware is far easier than simply trying to read through thousands of lines of filenames hoping to spot evil.

Overview of Triage Disk Forensics Process

First, FLS is used to extract a quick picture of the history the Operating System via the disk image. The FLS tool is run against each partition of the disk image and the results are placed into body file. That body file is processed by the program mactime and output to a CSV. If we spend 5 additional minutes we greatly enhance the resultant CSV by adding the timeline of data that was resident in memory at the time of capture. Many events relevant to an investigation live in the memory of the victim machine.

Events in memory are timestamped much like they are on disk. Volatility’s timeliner plugin will parse memory images for interesting events with timestamps and place those in a body file as well.

Image files are copies of computer hard drives. Body files are essentially buckets of data that tools can pour their findings into as they process the image file. CSV files are Comma Seperated Value files that are structured to easily be opened and examined in something like Excel.

The diagram below depicts the two paths previously described.

Filename Layer toolS (FLS) Analysis

FLS is Sleuth Kit tool that is a great way to quickly conduct triage analysis on a host disk image. It runs very quickly and is easily searchable for known IOC’s.

MMLS Revisited

Recall this screen shot from mounting the E01. The Boot Partition (2) starts at 2048. The primary Windows OS partition(3) starts at 718848.

FLS to the Body File

Run the FLS tool against each partition. Use the starting sector for each partition found using MMLS. Lastly, append the two files.

Process the Boot partition is:
fls -m -r -o 2048 /mnt/ewf/ewf1 > fls-dc01.body
Process the Windows partition is:
fls -m -r -o 718848 /mnt/ewf/ewf1 >> fls-dc01.body
You should end up with a roughly 8.5K Body File for the Domain Controller.

23573f1258936e3a14062b53d8caa7df was the MD5 Hash the author had for the body file at the time of this post. Keep in mind that changes to FLS etc. in the future could change the data slightly and vastly change the hash.

FLS and Memory Timelines Combined

During forensics investigations the memory of a victim system holds crucial data for an investigator. There are many artifacts that reside in memory for long periods of time before being written to disk. Investigators must strive to have maximum fidelity of the data they are working with. At this point you should have a body file with data carved from both partitions of the disk. The next step is to carve data from the memory image and add this valuable data to that body file before finally processing it into a CSV file.

Creating Memory Timeliner Body File

The command to process the memory and obtain events for our time lines is:
vol.py -f citadeldc01.mem --profile=Win2012R2x64 timeliner --output=body --output-file=/cases/szechuan/dc01/disk/memory-timeliner-dc01.body

Note the lack of ShimCache data extracted. ShimCache data is valuable residue about program execution. Thankfully, Windows has a lot of telemetry beyond ShimCache data that will give clues about what programs were run and at what time.

Appending Body Files

The following demonstrates how to back up the FLS body file before appending the Memory Body file to it. It is always a good idea to back up files before appending them. This allows for quick recovery without needing to re-run the forensic tool.

Carving the Body File

The final step in creating the CSV file for analysis is to run the body file through a tool called mactime. Mactime will sort and clean up your body file and produce a CSV for analysis.

mactime -y -d -z UTC -b fls-dc01.body > dc01-fls.csv

Notice the odd dates here. The only date time stamps that are really reliable here are time stamps associated with files (which there are few of for now). This is not to say all of them are worthless; only that the reliable ones have to do with files. The memory timestamps are reliable but not in the context of when something exactly started or stopped for the first time. Investigators can still look for evidence of malicious processes having been present on a system, and for when a process was “observed” in memory by the system. In the end, this is only a preliminary look that could be useful in triage. The really reliable timeline analysis occurs during super timeline analysis.

Analyzing the CSV

The CSV created through the above process can now be viewed with Eric Zimmerman’s Timeline Explorer, Excel, or Calc. In any case the process is the same. This likely means moving file from your Linux Analysis machine to your Windows Analysis machine. Once the file is opened look for pivot points found elsewhere in the investigation.

What pivot points do you have already? Look at your notes for the names of malicious files and processes.

Simply do a search for those names in the data and see what you find. Literally do a CTRL+F…

Dates and Times are untrustworthy (sort of) with FLS analysis. They will often show the first time, or the last time, something was run. Take a look and see what you can find.

Spoilers ahead.

Keep in mind this is a lot easier if you already have indicators from other parts of the investigation. These are often found in doing something like memory or PCAP analysis. Actual cases work just like this case. Timeline analysis is one of the last things that you do. You want to start timeline analysis with a pivot point, or place, to the enter the timeline. Don’t simply start at line one and begin reading down the line. Examples of good pivot points would be:

Specific time (down to the second)
Interesting filenames
Interesting IP Addresses
Interesting Users

This list is short for triage disk analysis. For a full Super Timeline analysis it will be a bit longer. This CSV file is merely data scraped from the filename structure. Super Timelines will have this data in addition to logs (MANY LOGS) and residue from many other places including the registry. More sources means more fidelity. More fidelity means more data to search through.

Case 001 Applicable Pivots

For this case in particular there are a few items we know to look for:

203.78.103.109
194.61.24.102
coreupdater.exe
PID (Process ID) 3644
Any .zip files since the owner was worried about exfiltration (data being stolen). Attackers LOVE to zip up data before shipping it out of the network.

Let’s go hunting.

The Analysis

Keep in mind, this data is a combination of Filename

CSV’s from forensic tools should be opened in a spreadsheet viewer like Excel or Libre Office Calc. Eric Zimmerman’s Timeline Explorer is also really great for opening CSV’s and is FREE! Though I recommend you throw him a couple bucks if you can. The top row should be frozen in place and data filtering turned on. This is briefly covered in the autoruns analysis. If you have a hard time opening the CSV in Libre Office Calc ensure that you select Unicode (UTF-8).

There are roughly 9,000 lines of data in this CSV alone. Start with a search and highlight approach. Search for an indicator. If it is interesting highlight it. Use CTRL+F and do a “Find All” for terms related to indicators known so far. You will find that the IP Addresses do not yield much in the FLS timeline. They may however be huge wins during super timeline analysis. Unless a filename was created with an IP Address for a name there won’t be anything there.

We know from previous portions of the investigation there is an interesting filename. Coreupdater.exe is the name of the malware found in memory, Autoruns analysis, and in the PCAP. Search for this Indicator. Try searching for core, coreupdate, and coreupdater. This spreads your search out to anything that may have been shortened by the filename system or some other anomaly.

Core yields 166 results and clearly has a ton of false positives due to names of files like appcore appearing in the results.

Keep pressing forward.

coreupdate and coreupdater returns 6 results. This is much more manageable. Note the results locate an entry for coreupdater.ex. This is not a trick from the attacker. Strings being truncated in forensic artifacts happens regularly. This is why it is important to try different takes on indicators. No results would have been returned if an investigator had simply jumped in and only searched for coreupdater.exe. This could result in important evidence potentially being missed.

Let’s review the results.

A few things to notice here:

coreupdater.ex is very likely coreupdater.exe that is just being truncated. It is definitely our bad file when we consider…
The PID is 3644 which was identified as a malicious meterpreter process during memory analysis. It was named coreupdater.exe
The cells listed are all fairly close and land near the end of the 9000 lines of entries, meaning it was fairly recent prior to the disk image capture
The [PROCESS]and [THREAD]tags along with PID/TID data tells us this was part of our memory body file. This is a great way to enrich our data.

Note: This data is a very small slice of what a super timeline contains. Normally you would do this while your super timeline is being processed, or you are really short on time.

We already knew these events occurred. However, many times FLS timeline analysis can shed light on previously unknown events, or begin fleshing out a story we already knew.

Select one of the cells and take a look at events occurring right before and right after those highlighted events (they should be highlighted from the Find All.

There wasn’t anything ground breaking. We already knew these events were likely to be found here. HOWEVER, this technique can pay dividends to an investigator. FLS timelines can be very useful during investigations. Imagine if you have a cluster of 5 machines and know the name of the malicious executable that is being used. You could quickly scope out which machines may have been impacted by the attacker. FLS timelines on machines that have been in service for years can reveal many gems by simply looking at known popular hiding spots like the AppData TMP Directory. In other words one could search for that key word and quickly sift through the timeline looking for previous breach activity.

Note: there are 2 important things about this exercise and the screen shot. The times associated above are not great to determine things like when this system was first breached etc. In other words, the first entry here is not necessarily the first time the system saw that process. However, that process was seen at that time, so we know that it was there and active at that time. Sometimes looking for things 1 minute prior and 1 minute after may reveal something interesting. Often times it will not, but sometimes you can find something huge!

Can you do this same technique on the Workstation image? Can you use this data to confirm the presence of the malware on the workstation?

Conclusion and Recap for Disk Triage

We combined the data from the memory timeliner and the Filename metadata from the disk image into a single CSV. We then loaded that CSV into a spreadsheet application and looked for known indicators. This data can be used to confirm a machines disk or memory had those indicators present. It can also serve as a great pivot point in the timeline where an analyst can find other interesting findings. For example, there are times you may see a zip file appear right after a piece of malware was active. That zip file could be very interesting.

IOC’s to Take Away

No new IOC’s for this round. However, this technique could be used to quickly scope an incident. It is also possible to quickly scan through a timeline for past breaches etc. whenever there is more FLS data. In this case it is mostly memory timeliner data.

Things to Study or Try Next

SUPER TIMELINES!

Choose Your Next Move

Super Timelines!

Don’t forget to leave any thoughts or questions you have on Memory Analysis in the comments.

James

See author's posts

DFIR Madness

Triage Disk Analysis Case 001