chapter11.txt

# Chapter 11 - Scaling, scaling, scaling, a tale of DFIR Triage

{width: 30%}
![](Ch11/triangle.png)

C> By [Guus Beckers](http://discordapp.com/users/323054846431199232) | [LinkedIn](https://www.linkedin.com/in/guusbeckers/)

## What is triage?

While full disk analysis certainly has its place, triaging is an essential part of digital forensics. The purpose of triage is twofold, to cut down on the noise generated by the multitude of events on a host and to determine if deep-dive forensics is required. As time and computing power are precious resources, it is best not to waste them. Luckily, there are a couple of concepts and tools that can help an investigator out on any level of the investigation.

## What should be included in a triage?

Before getting nitty gritty with tools let's examine what's useful to include within a triage while dealing with the majority of cases. If specific cases deal with investigating well known artifacts do not hesitate to add them to your list of triage items. It is advisable to collect multiple sources of evidence type to get a through understanding of the case at hand, sometimes evidence will not be available within all data structures due to the specific behavior of the operating system while at other times an adversary might have deleted one of the available sources. Without further ado, let's take a look at the list:

* A series of artifacts that keep track of locations of files on the disk or an file manager and any performed actions (renaming/deleting), this can be a $MFT or a list of locations that has been accessed.
* Artifacts which track the history of included files within a folder.
* Any hibernation or swap files that have been written to disk, these particular artifacts can extend your window into the past by days or even weeks.
* Artifacts that indicate account usage, modification or deletion.
* Artifacts that can clarify which applications have been installed or uninstalled at a particular date.
* Artifacts which can be used to prove application execution in the past.
* Artifacts which can track network or data transfer by a particular process.
* Any available web browser history and a record of auxiliary actions such as initiated downloads.
* Artifacts which track external events such as plugging in USB drives or/and other devices.
* Any available event logs that have been maintained by the operating system or relevant applications.
* Records of admin level activities on a system.

These artifacts can be used for initial analysis while further processing of a case takes place.

## Forensic triage of one or a limited amount of hosts

Historically, to examine a computer, an investigator would manually collect all artifacts and going through them one by one. You would need to know the artifact, go to the folder containing the artifact, export and repeat the process for any relevant artifact. To say this takes a lot of time investment is an understatement. A few years ago, KAPE was introduced to the forensic community. It is a standalone executable that contains a wealth of forensic knowledge on where artifacts live on a computer (knowledge you can extend by collaborating on the public GitHub). KAPE contains a set of definitions called Targets. A Target defines where a artifact lives on a system. Collecting it is as easy as ticking a checkbox. Targets can also contain other Targets. In this manner, KAPE offers various triage Targets, thereby allowing an investigator to perform triage of an entire host just by selecting a single Target. The Target collection can also be automated on endpoints by utilizing its command line counterpart.

The second part of KAPE covers analysis through definitions called Modules. A Module can comb through data collected by a Target and transform it to a file format that’s easy to ingest in other tools. It does this by interacting with third-party tools that are part of a Module. Any executable that uses a command line is a viable option. As an example, KAPE comes with the entire suite of forensic parsers by Eric Zimmerman (for an entire list check [here](https://ericzimmerman.github.io/)), which cover the most popular Windows forensic artifacts.

Of particular note for triage is the [KapeTriage Target](https://github.com/EricZimmerman/KapeFiles/blob/master/Targets/Compound/KapeTriage.tkape). The following description is provided at the time of writing:

```
KapeTriage collections will collect most of the files needed for a DFIR Investigation. This Target pulls evidence from File System files, Registry Hives, Event Logs, Scheduled Tasks, Evidence of Execution, SRUM data, SUM data, Web Browser data (IE/Edge, Chrome, Firefox, etc), LNK Files, Jump Lists, 3rd party remote access software logs, antivirus logs, Windows 10 Timeline database, and $I Recycle Bin data files.
```

The KapeTriage collection can be post-processed using the [!EZParser Module](https://github.com/EricZimmerman/KapeFiles/blob/master/Modules/Compound/!EZParser.mkape). These parsers, also written by Eric Zimmerman, can be used to extract information from the most common artifacts. Data will be made available in CSV format.

These parsers (and other tools) can also be downloaded individually [here](https://ericzimmerman.github.io/#!index.md). Among the tools is Timeline Explorer, which is a utility that can open CSV files and has robust search and sorting options. A description and demonstration of Timeline Explorer is available at [AboutDFIR](https://aboutdfir.com/toolsandartifacts/windows/timeline-explorer/).

KAPE can be used during live investigations but also after a forensic image has been created. A recommended tool to use with KAPE is Arsenal Image Mounter. Among its capabilities is read-only and write-protected image mounting. Just point KAPE at the assigned drive letter and it can perform collection and analysis.

Utilizing KAPE, collection and transformation of artifacts is brought down to a matter of minutes. This allows an investigator to perform triage to determine if a deep-dive is required or perform triage while other forensic evidence is still processing.

Another possibility when dealing with a single host is creating a custom content image using FTK Imager. You will be able to manually select the artifacts you want to collect using a graphical interface. Richard Davis covers this extensively in a video of his 13Cubed digital forensics YouTube series. It can be found [here](https://www.youtube.com/watch?v=43D18t7l7BI).

### macOS and Linux

Similar tools like KAPE also exist for other operating systems. One of the tools that deals exclusively with macOS (and its mobile counterparts iOS and iPadOS) is [mac_apt](https://github.com/ydkhatri/mac_apt). It can extract a wealth of information from a macOS system and can deal with a variety of images and acquired data. mac_apt can be used exclusively on forensic images. Fortunately, there exists a live response counterpart. Named the [Unix Artifact Collector](https://github.com/tclahr/uac) (or UAC for short), it can acquire data from both macOS and a range of Linux distributions. Both tools are open-source and any contribution is welcomed.

## Scaling up to a medium-sized subnet

The aforementioned tools work fantastically on a single host but how can we scale this to a subnet?

The Kansa PowerShell IR Framework was created by Dave Hull to facilitate a growing need in the DFIR community, determining where deep-dive forensics should take place in ever-expanding networks.

To do this, Kansa operates on two assumptions, malware needs to be present on the machine to perform its actions and malicious activity is relatively rare and therefore automatically stands out. To accomplish this Kansa is made up of two distinct components.

The collection component is able to collect a number of lightweight artifacts including autostart locations, services, new admin users etc. The type of artifact is determined by a PowerShell script, each artifact uses its own script. These scripts are tied together with a Kansa master script. The master script is used to set which evidence needs to be collected. The Kansa scripts need to be executed on each server where evidence needs to be collected. To facilitate a secure transfer of credentials, it uses PowerShell remoting for this purpose. Kansa also integrates with third-party executables. Any required executable can automatically be pushed to the various servers.

The second component is analysis with Kansa. These scripts stack the output of each gathered evidence item and counts the presence of each item. In this manner, outliers become more easily visible.

A limitation of Kansa is that it uses persistent PowerShell connections until a script has been completed. For this reason, it is not recommended to use Kansa for more then 100 hosts. A distributed version of Kansa, developed by Jon Ketchum, addresses this limitation. The distributed version lifts many of the limitations of the original version. Persistent connections are no longer required. Larger data sets also require an optimized parsing method. For this reason the distributed version of Kansa uses an ElasticSearch backend. You're encouraged to check out the [original](https://www.youtube.com/watch?v=ZyTbqpc7H-M) talk.

macOS and Linux don't have similar tools but this shouldn't necessarily be be a problem. Both operating systems have a long history of text manipulation tools like awk, grep and uniq. Depending on the retrieved information, a combination of these tools can be used to achieve the same results.

## Scaling up to an entire network

Individual hosts and small networks are discussed, what are the options when you deal with a massive network? A single tool can be used in that instance. Velociraptor is another addition to the open-source DFIR arsenal. Upon its arrival in 2018 it quickly gathered a following and it isn't difficult to see why. Velociraptor is one of the most powerful tools in the DFIR community. For starters, it supports all the major operating systems, Windows, macOS and Linux alike. What makes Velociraptor stand out is its distributed computing model along with a client/server approach.

A Velociraptor instance consists of a server and a number of clients distributed through a (client) network. The agent creates a persistent connection to the server.

Analysts can use Velociraptor to:

* Retrieve any file on a connected endpoint in a forensically sound manner
* Retrieve forensic artifacts from all connected endpoints with the push of a button
* Scan for IOCs utilizing both regex and YARA rules
* Push and utilize third-party command line tools on all hosts running an agent

It is not possible to do Velociraptor justice within a short section of this chapter. Rather then describe it, it is advised to see the tool in action. Eric Capuano recently gave a [rundown](https://www.youtube.com/watch?v=Q1IoGX--814) on Velociraptor using a small network. Furthermore, Michael Cohen also developed his own tutorial series which is currently available free of charge on this [link](https://docs.velociraptor.app/training/).

## Other tools

A number of other triage tools aren’t discussed in depth but are still quite useful while performing triage. They can either be used on a standalone basis or pushed by Velociraptor. Be aware that these tools might set off AV due to their included malware signatures.

* [Autoruns](https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns) or its CLI version Autorunsc, useful for enumerating all ASEP locations on a host
* [DeepBlueCLI](https://github.com/sans-blue-team/DeepBlueCLI), a tool which enables threat hunting using the Windows Event logs
* [Chainsaw](https://github.com/WithSecureLabs/chainsaw), a similar tool which can group significant events
* [Loki](https://github.com/Neo23x0/Loki), an IOC/Yara scanner which can enumerate known malicious files on a host
* [Hayabusa](https://github.com/Yamato-Security/hayabusa), an expansive threat hunting scanner which offers timelining capabilities

## Practicing triage

Triage can be practiced on any number of forensic disk images. The following community images are included as recommendation:

* [DFIR Madness - The case of the stolen Szechuan sauce](https://dfirmadness.com/the-stolen-szechuan-sauce/)
* [Digital Corpora - 2012 National Gallery DC Scenario](https://digitalcorpora.org/corpora/scenarios/national-gallery-dc-2012-attack/)
* [Digital Corpora - 2019 Narcos Scenario](https://digitalcorpora.org/corpora/scenarios/2019-narcos/)
* [Cyberdefenders - Pawned DC](https://cyberdefenders.org/blueteam-ctf-challenges/89)

## Contributions and sources

Forensic triage, perhaps more than any other aspect of forensics relies on input of the entire community. Without the aid of the developers in this section, triage would surely be more difficult.

* Eric Zimmerman for creating the variety of parsers and KAPE.
* Andrew Rathbun for creating a multitude of KAPE Targets.
* Yogesh Khatri for creating the mac_apt acquisition framework.
* Thiago Lahr for his development of the Unix Artifact Collector.
* Dave Hull for creating Kansa and Jon Ketchum for extending the original suite with DistributedKansa.
* Michael Cohen for creating Velociraptor.
* Eric Conrad for his work on DeepBlueCLI.
* Nextron Systems for developing the Loki scanner.
* WithSecure Labs for developing the Chainsaw EVTX scanner.
* Yamato Security for creating the Hayabusa threat hunting scanner.

Also information from the sources below was used in creating this chapter:

* Richard Davis for creating the excellent 13Cubed YouTube series.
* Eric Capuano for demoing the powerful capabilities of Velociraptor.