Having seen Eric Zimmerman’s release of Kape (Or Kale as Ovie Carol calls it) I thought it could be insightful to play around with the Triage idea some more.

Basic premise for this post was this:

For an Incident Response type case, how much answers can you get to by just grabbing and analyzing selective data (triage) versus full disk images.

With remote acquisition, acquiring only a few GB’s of data instead of full images can, in some cases, make a difference of a few hours – depending on network speed. The same calculation applies when it comes to processing the data.

To run this exercise, I dusted off the evidence files from the 2018 Vegas Magnet User Summit CTF. I managed to win the live CTF on the day, but didn’t get a full score. Oleg Skulkin and Igor Mikhaylov however did a write-up of the full CTF that we’re going to use.

You can check out their write-ups here:

https://cyberforensicator.com/2018/06/28/magnet-user-summit-ctf-anti-forensics/
https://cyberforensicator.com/2018/07/01/magnet-user-summit-ctf-exfiltration/
https://cyberforensicator.com/2018/06/29/magnet-user-summit-ctf-misc/
https://cyberforensicator.com/2018/07/01/magnet-user-summit-ctf-intrusion/

For this test, I created a quick and dirty condition in EnCase that only targets specific data. Things like Registry files, Event logs, Browser Artifacts, File System Artifacts etc. A good place to start with a Triage list is to have a look at the Sans Windows Forensics “Evidence Of…” poster for areas of interest.

A condition in EnCase is basically a fancy filter, allowing you to filter for files with specific names, paths, sizes etc. Not that it matters, but I named my condition Wildehond, which is the Afrikaans name for Wild Dog or Painted Wolf. Wild dogs are known to devour their prey while it’s still alive, and that’s what we’re trying to do here… (You can Youtube it at your own risk).

Running my Wildehond condition in EnCase on the Max Powers hard drive image, resulted in 2,279 files totaling 2.5GB. The mock image of Max Powers, the victim in the CTF, was originally 50GB. After running the condition I created a Logical Evidence File of the filtered triage files.

So, the question is, can you get a full score for the CTF from processing and analyzing 5% of the data?

Let’s try.

First off, I processed the ‘full’ image in Axiom v2.9:

And selected all available artifacts to be included:

Processing ran for around 45 minutes, with another 15 minutes to build connections. That’s a round 60 minutes.

The processing resulted in about 727,000 artifacts:

Next up, I used the exact same processing settings on the 2.5GB Triage image I created with EnCase and Wildehond.

Processing took 13 minutes, with another minute to complete the connections. A cool 14 minutes in total. This left us with around 290,000 artifacts for analysis:

So yes, as expected, there is a large difference (45 minutes) in processing 2.5GB in stead of 50GB. (This difference will be a lot bigger between a real world 500GB drive and a 2.5GB triage set)

But this doesn’t mean anything if we can get to the answers, so lets go.

After running the processing, I did a side-by-side comparison between the two sets of data, and worked through the CTF questions on each side.

All of the questions were answerable on the full image processed with Axiom 2.9, except for three questions relating to the $MFT, where a tool like Eric Zimmerman’s MFTEcmd would do the trick.

This is how the two images did in providing answers:

So, with the Triage set of 2.5GB, we could answer 23 of the 28 Questions (82%… which is more than what I got for C++ at University).

However, real world incidents can differ quite a bit from question and answer style exercises, especially if you don’t know what exactly you are looking for.

For the 5 questions that could not be answered from the Triage set, below is the reasons why:

Wiped file names:

Strangely enough, the UsnJrnl did not parse in my Triage image.

From the full image:

However, nothing from my Triage system.

I confirmed that the file was present in my image:

So, to troubleshoot, I used Joachim Schicht’s UsnJrnl2Csv to try and parse the UsnJrnl that was in my Triage image.

And… It liked my UsnJrnl exported from the Triage image:

So… for some odd reason Axiom doesn’t recognize the $UsrnJrnl•$J file when contained in my Triage LX01 image. Will do some more trouble-shooting to figure out why this is the case.

Browser to download Dropbox:

From the full image, the answer was quite clear: Maxthon

Yes, my Triage image contains lots of artifacts referencing Maxthon and Dropbox separately, but no immediate obvious link that Maxthon was used to download Dropbox. The main reason for this is that I did not capture Maxthon web histories (i.e. mxundo.dat) in my Triage image.

Email data:

The last two questions where my Triage image came up short related to Email. As no email was targeted with my Triage, this was to be expected.

So, there you have it. In this case, you could do a pretty good job at getting a handle on a your case by only using Triage data.

Will full disk imaging and analysis not provide you with better context? Yes, perhaps… but with the likely trade-offs in Triaging, it’s worth exploring it first.