Inside Out Blog

Which forensic imager is the fastest?

bradley@schatzforensic.com (Bradley Schatz) — Thu, 05 Jul 2018 11:00:58 +0000

We all face the problem of growing amounts of evidence on a regular basis. Improving raw acquisition speed is one way to limit the impact of this, and Evimetry has been consistently delivering the fastest acquisition speeds bar none since we launched two years ago.

Yet we aren’t the only solution claiming to be the “fastest” or have “unparalleled” speeds.

Led by a practitioner and forensic scientist, it is in Evimetry’s DNA to value substantiation. Our results are backed up by scientifically peer-reviewed publications and documented in our blog posts and workshops.

The following graph shows the acquisition rate of a 1TB Samsung 960 Pro NVMe drive. We used Evimetry to undertake linear acquisitions to 4x Samsung 512 GB 860 Pro SSD’s as striped images, using a 6-core Xeon-D CPU. The variable is drive allocation: we started with an empty (TRIM’ed) drive, then filled it with a Windows 10 OS install and a corpus of common corporate documents and video. These figures don’t account for verification time.

We can acquire an empty 1TB NVMe drive in 4 minutes 52s. That’s a rate of 200 GB/m, or 12 TB/h. No other product comes close to these speeds.

In the real world, suspect drives contain data rather than empty runs of 0x00, and Evimetry’s acquisition speeds depend on how much actual data is stored on the suspect drive. For a drive that is 40% utilized it takes us 7m48s (still faster than anyone else’s claim) and at 95% utilized it takes us 12m57s.

In absence of substantiation from other quarters we remain confident that we offer the fastest acquisition solution available today. We encourage you to do your own validation of both our results, and the claims of other tools.

How to analyse AFF4 linux memory images

bradley@schatzforensic.com (Bradley Schatz) — Mon, 11 Jun 2018 21:13:54 +0000

In my last post I described Evimetry's support remote memory acquisition. In this post I'll give a quick walkthough on setting up Volatility for analysis of those images.

I prefer to make a python virtualenv specifically for working with volatility. In this example, I'm using MacOS with brew for my python (the python shipped with MacOS is broken in regard to pip's TLS authentication). Hence the -p argument.

mkdir volmem
cd volmem
virtualenv -p /usr/local/bin/python volmem
source volmem/bin/activate

Install all the dependencies with the following (the last two aren't strictly necessary, but prevent a load of complaints from Volatility).

pip install future
pip install rdflib
pip install pyblake2
pip install intervaltree
pip install expiringdict
pip install aff4-snappy
pip install pyyaml
pip install pycrypto
pip install distorm3

Pull in Volatility, the community plugins repository (where the AFF4 plugin resides), and the python AFF4 reader library. We set the python path so that the plugin can find the latter.

git clone https://github.com/volatilityfoundation/volatility
git clone https://github.com/volatilityfoundation/community
git clone https://github.com/aff4/pyaff4
export PYTHONPATH=$(pwd)/pyaff4:%PYTHONPATH%

Download the Linux profile you want to use with the memory image, and place it in Volatility's profile folder.

wget https://github.com/volatilityfoundation/profiles/raw/master/Linux/Ubuntu/x64/Ubuntu16041.zip
mv Ubuntu16041.zip volatility/volatility/plugins/overlays/linux/

cd volatility

Begin analysis. Note the usage of the --plugins line is crucial for picking up the AFF4 read plugin, as is the pythonpath environment variable we set earlier.

(volmem) neon:volatility bradley$ python vol.py --info
Volatility Foundation Volatility Framework 2.6

Profiles
--------
LinuxUbuntu16041x64 - A Profile for Linux Ubuntu16041 x64



(volmem) neon:volatility bradley$ python vol.py --plugins=../community/AFF4 -f ~/Desktop/ImageDest/Ubuntu16041.RAM.aff4 --profile=LinuxUbuntu16041x64 linux_pslist
Volatility Foundation Volatility Framework 2.6
Offset Name Pid PPid Uid Gid DTB Start Time
------------------ -------------------- --------------- --------------- --------------- ------ ------------------ ----------
0xffff88003bd60000 systemd 1 0 0 0 0x000000003b61a000 2018-05-30 05:25:41 UTC+0000
0xffff88003bd60dc0 kthreadd 2 0 0 0 ------------------ 2018-05-30 05:25:41 UTC+0000
0xffff88003bd61b80 ksoftirqd/0 3 2 0 0 ------------------ 2018-05-30 05:25:41 UTC+0000
0xffff88003bd63700 kworker/0:0H 5 2 0 0 ------------------ 2018-05-30 05:25:41 UTC+0000

This works equally well for newer kernels with kernel address space layout randomisation (KASLR). To test this, I created a new volatility profile for kernel 4.10 on Ubuntu 16.04.4 per the instructions at https://github.com/volatilityfoundation/volatility/wiki/Linux . You can see below the output of the linux_bash plugin run against a VM that I first used to generate the profile and then use as the target of acqusition using the Evimetry live agent.

If you can't find a profile, and haven't done it before, I'd encourage you to give it a go. It is extremely easy to create a new one (especially using VMWare, as it breezes through the install of the the target Linux OS). All up it took me about 5 minutes to install Ubuntu 16.04.4 and create a profile for it. Don't forget to go the extra step contributing back to the community with the new profile (as I did here).

neon:volatility bradley$ python vol.py --plugins=../community/AFF4 -f ~/Desktop/ImageDest/Ubuntu16044_PhysicalMemory.aff4 --profile=LinuxUbuntu16044x64 linux_bash
Volatility Foundation Volatility Framework 2.6
Pid Name Command Time Command
-------- -------------------- ------------------------------ -------
841 bash 2018-05-31 16:08:23 UTC+0000 uname -a
841 bash 2018-05-31 16:08:23 UTC+0000 apt-get update
841 bash 2018-05-31 16:08:23 UTC+0000 apt-cache search linux-kernel
841 bash 2018-05-31 16:08:23 UTC+0000 apt-get install openssh-server
841 bash 2018-05-31 16:08:23 UTC+0000 exit
841 bash 2018-05-31 16:08:23 UTC+0000 apt-cache search linux-image
841 bash 2018-05-31 16:08:23 UTC+0000 apt-cache search kernel
841 bash 2018-05-31 16:08:23 UTC+0000 sudo bash
841 bash 2018-05-31 16:08:23 UTC+0000 uname
841 bash 2018-05-31 16:08:23 UTC+0000 cat /proc/version
841 bash 2018-05-31 16:08:23 UTC+0000 ifconfig
841 bash 2018-05-31 16:08:23 UTC+0000 apt-get install linux-image-4.10.0-14-generic
841 bash 2018-05-31 16:08:23 UTC+0000 sudo bash
841 bash 2018-05-31 16:08:23 UTC+0000 exit
841 bash 2018-05-31 16:08:23 UTC+0000 exit
841 bash 2018-05-31 16:08:23 UTC+0000 reboot
841 bash 2018-05-31 16:08:23 UTC+0000 apt-get install openssh-server
7459 bash 2018-05-31 16:21:46 UTC+0000 uname -a
7459 bash 2018-05-31 16:21:46 UTC+0000 apt-get update
7459 bash 2018-05-31 16:21:46 UTC+0000 apt-cache search linux-kernel
7459 bash 2018-05-31 16:21:46 UTC+0000 apt-get install linux-headers-4.10.0-14-generic
7459 bash 2018-05-31 16:21:46 UTC+0000 zip Ubuntu16044.zip module.dwarf /boot/System.map-4.10.0-14-generic
7459 bash 2018-05-31 16:21:46 UTC+0000 apt-get install openssh-server
7459 bash 2018-05-31 16:21:46 UTC+0000 exit
7459 bash 2018-05-31 16:21:46 UTC+0000 apt-cache search linux-image
7459 bash 2018-05-31 16:21:46 UTC+0000 apt-get install dwarfdump
7459 bash 2018-05-31 16:21:46 UTC+0000 apt-cache search kernel
7459 bash 2018-05-31 16:21:46 UTC+0000 sudo bash
7459 bash 2018-05-31 16:21:46 UTC+0000 make -C /lib/modules/4.10.0-14-generic/build CONFIG_DEBUG_INFO=y M=$PWD modules
7459 bash 2018-05-31 16:21:46 UTC+0000 apt-get install build-essential
7459 bash 2018-05-31 16:21:46 UTC+0000 ls
7459 bash 2018-05-31 16:21:46 UTC+0000 uname
7459 bash 2018-05-31 16:21:46 UTC+0000 cat /proc/version
7459 bash 2018-05-31 16:21:46 UTC+0000 ifconfig
7459 bash 2018-05-31 16:21:46 UTC+0000 zip Ubuntu16044.zip module.dwarf /boot/System.map-4.10.0-14-generic
7459 bash 2018-05-31 16:21:46 UTC+0000 exit
7459 bash 2018-05-31 16:21:46 UTC+0000 cat /proc/version
7459 bash 2018-05-31 16:21:46 UTC+0000 ls
7459 bash 2018-05-31 16:21:46 UTC+0000 apt-get install linux-image-4.10.0-14-generic
7459 bash 2018-05-31 16:21:46 UTC+0000 sudo bash
7459 bash 2018-05-31 16:21:46 UTC+0000 exit
7459 bash 2018-05-31 16:21:46 UTC+0000 sudo bash
7459 bash 2018-05-31 16:21:46 UTC+0000 exit
7459 bash 2018-05-31 16:21:46 UTC+0000 exit
7459 bash 2018-05-31 16:21:46 UTC+0000 dwarfdump -di ./module.o > module.dwarf
7459 bash 2018-05-31 16:21:46 UTC+0000 reboot
7459 bash 2018-05-31 16:21:46 UTC+0000 apt-get install zip
7459 bash 2018-05-31 16:21:46 UTC+0000 apt-get install openssh-server
7459 bash 2018-05-31 16:21:49 UTC+0000 sudo bash
7472 bash 2018-05-31 16:21:50 UTC+0000 exit
7472 bash 2018-05-31 16:21:50 UTC+0000 apt-get install openssh-server
7472 bash 2018-05-31 16:21:50 UTC+0000 sudo bash
7472 bash 2018-05-31 16:21:50 UTC+0000 apt-cache search linux-image
7472 bash 2018-05-31 16:21:50 UTC+0000 exit
7472 bash 2018-05-31 16:21:50 UTC+0000 zip Ubuntu16044.zip module.dwarf /boot/System.map-4.10.0-14-generic
7472 bash 2018-05-31 16:21:50 UTC+0000 dwarfdump -di ./module.o > module.dwarf
7472 bash 2018-05-31 16:21:50 UTC+0000 apt-get install zip
7472 bash 2018-05-31 16:21:50 UTC+0000 ifconfig
7472 bash 2018-05-31 16:21:50 UTC+0000 reboot
7472 bash 2018-05-31 16:21:50 UTC+0000 apt-get install linux-headers-4.10.0-14-generic
7472 bash 2018-05-31 16:21:50 UTC+0000 apt-cache search kernel
7472 bash 2018-05-31 16:21:50 UTC+0000 cat /proc/version
7472 bash 2018-05-31 16:21:50 UTC+0000 apt-get install dwarfdump
7472 bash 2018-05-31 16:21:50 UTC+0000 zip Ubuntu16044.zip module.dwarf /boot/System.map-4.10.0-14-generic
7472 bash 2018-05-31 16:21:50 UTC+0000 make -C /lib/modules/4.10.0-14-generic/build CONFIG_DEBUG_INFO=y M=$PWD modules
7472 bash 2018-05-31 16:21:50 UTC+0000 sudo bash
7472 bash 2018-05-31 16:21:50 UTC+0000 apt-get install openssh-server
7472 bash 2018-05-31 16:21:50 UTC+0000 ls
7472 bash 2018-05-31 16:21:50 UTC+0000 exit
7472 bash 2018-05-31 16:21:50 UTC+0000 ls
7472 bash 2018-05-31 16:21:50 UTC+0000 apt-get install linux-image-4.10.0-14-generic
7472 bash 2018-05-31 16:21:50 UTC+0000 uname
7472 bash 2018-05-31 16:21:50 UTC+0000 apt-get update
7472 bash 2018-05-31 16:21:50 UTC+0000 uname -a
7472 bash 2018-05-31 16:21:50 UTC+0000 apt-cache search linux-kernel
7472 bash 2018-05-31 16:21:50 UTC+0000 apt-get install build-essential
7472 bash 2018-05-31 16:21:50 UTC+0000 exit
7472 bash 2018-05-31 16:21:50 UTC+0000 sudo bash
7472 bash 2018-05-31 16:21:50 UTC+0000 exit
7472 bash 2018-05-31 16:21:50 UTC+0000 cat /proc/version
7472 bash 2018-05-31 16:21:51 UTC+0000 ls
7472 bash 2018-05-31 16:22:04 UTC+0000 ./evimetry.agent 192.168.189.1

How to acquire Linux memory images using without a driver

bradley@schatzforensic.com (Bradley Schatz) — Sat, 09 Jun 2018 19:52:38 +0000

For a long time now, operating systems such as Windows and MacOS have prevented user space applications from accessing the raw physical memory of the machine. Physical acquisition and virtualisation approaches aside, this has led the field to require the use of kernel drivers to export physical ram for acquisition. In the linux realm, Joe Sylve's LiME is the go-to for many.

It appears not widely known that on Linux x64, acquisition of physical memory is possible without using a driver such as LiME. The prerequisite here is that /proc/kcore is enabled, which fortunately is widely the case: Ubuntu ships with it enabled by default, as does Redhat. On x64 the full physical address space is mapped into the kernel address space, and /proc/kcore exports this as a part of its virtual ELF file view.

Fun fact: /proc/kcore is big: 128 TB.

bradley@ubuntu:~$ ls -lh /proc/kcore
-r-------- 1 root root 128T Jun 8 18:44 /proc/kcore

You don't want to acquire /proc/kcore - just the relevant part.

Acquisition via this technique is something that Rekall pioneered, as far as I know (please correct me if you know better). Evimetry supports the technique in our live agent for remote acquisition. The following serves as a short howto on acquisition using currently available tools.

How to acquire: Evimetry

Copy the Evimetry linux liveagent (x64) onto the suspect Linux host, along with its security certificates. Run the agent with the IP address of a Controller or a Dead Boot or Cloud agent as the destination:

root@ubuntu:~# ./evimetry.agent 192.168.189.1
Evimetry Lightweight Agent v3.0.8, a lightweight forensic acquisition agent.
Application IP Address: 192.168.189.207
Application IP Address: fe80::20c:29ff:fed7:3540
Application MAC Address: 00:0c:29:d7:35:40
Memory Size: 971.6MiB
Memory Allocation Alignment Size: 4096
Runnable IO threads: 1
Starting device enumeration
Exported devices:
/dev/sda [20.0GiB] : VMware_Virtual_S
/dev/sda1 (ext4) [19.0GiB] /
/dev/sda2 (unknown) [975.0MiB]
/dev/sda5 (swap) [975.0MiB]
/dev/sr0 [1024.0MiB] : VMware_Virtual_SATA_CDRW_Drive
No medium found
/dev/sr1 [1024.0MiB] : VMware_Virtual_SATA_CDRW_Drive
No medium found
/dev/fd0 [4.0KiB] : Unknown Model
No such device or address
Insufficient privileges to access device!
Checking Memory Map setup.
Memory Description: [971.6MiB / 4.0GiB]
Checking Certificate setup.
Secure Communications Enabled
Starting Fabric Manager
Attempting Fabric Connection

Using the attached Evimetry Controler, acquisition is a simple GUI operation.

This works fine for both old pre-KASLR kernels as well as newer KASLR kernels (the above was for a Ubuntu 14.04.4 x64 VM. More information is available from the following walkthrough.

How to acquire: linpmem

Using the most recent released version of linpmem (2.1post4) from the releases page, I was able to acquire an image of a Ubuntu 14.04.1 VM with the following command.

root@ubuntu:~# ./linpmem-2.1.post4 --format map -c snappy -o image.aff4
Setting compression snappy
Imaging memory
Creating output AFF4 ZipFile.
Reading 0x8000 0MiB / 1023MiB 0MiB/s
Reading 0x3940000 57MiB / 1023MiB 227MiB/s
Reading 0x6068000 96MiB / 1023MiB 156MiB/s



Reading 0x351d0000 849MiB / 1023MiB 247MiB/s
Reading 0x393f0000 915MiB / 1023MiB 264MiB/s
Reading 0x3df38000 991MiB / 1023MiB 300MiB/s
Adding /boot/System.map-4.4.0-31-generic as file:///boot/System.map-4.4.0-31-generic
Adding /boot/abi-4.4.0-31-generic as file:///boot/abi-4.4.0-31-generic
Adding /boot/config-4.4.0-31-generic as file:///boot/config-4.4.0-31-generic
Adding /boot/grub/ as file:///boot/grub/
E0608 12:17:35.730147 4117 aff4_directory.cc:105] Unable to find storage for AFF4Directory file:///boot/grub/
E0608 12:17:35.730480 4117 aff4_imager_utils.cc:259] Unable to find file:///boot/grub/
Adding /boot/initrd.img-4.4.0-31-generic as file:///boot/initrd.img-4.4.0-31-generic
Reading 0x8000 0MiB / 30MiB 0MiB/s
Adding /boot/vmlinuz-4.4.0-31-generic as file:///boot/vmlinuz-4.4.0-31-generic

CAVEAT: The most recent release of linpmem (linpmem-2.1.post4) failed for the Ubuntu 14.04.4 VM I tested. See github issue.

How to analyse

My next post will describe how to analyse the images created above.

Announcing Evimetry Lab: changing the game for in-lab forensics

bradley@schatzforensic.com (Bradley Schatz) — Mon, 04 Jun 2018 15:01:16 +0000

When it comes to preserving evidence, DF labs generally fall into two camps. Those that acquire in the field, and those that collect evidence in the field, only later doing acquisition in-lab. Over the last two years, Evimetry's product offerings have been primarily aimed at the former. Practitioners have benefited from the fastest in-field acquisitions, while at the same time enabling meaningful analysis work to occur while waiting for acquisition complete.

Evimetry Lab, announced last week at the EnFuse conference, changes the game for the latter group. This groundbreaking approach enables analysis and time-consuming processing tasks (such as indexing) to begin immediately after acquisition begins. The traditional delay between waiting for acquisition to complete prior to beginning processing is removed, leading to processing tasks completing hours earlier, and answers sooner.

How much sooner? The comparison above shows a time-consuming indexing run using NUIX completing hours earlier when using Evimetry Lab as opposed to traditional forensic imaging workflows. There is also some live analysis using EnCase thrown in good measure.

Want more info? Check out the Evimetry Lab in more detail, or send us an email.

Simple Deadboot provisioning and acquisition with Evimetry

bradley@schatzforensic.com (Bradley Schatz) — Wed, 14 Feb 2018 03:03:50 +0000

We have just shipped two releases of Evimetry: v3.0.7 (in our stable stream) & v3.1.5 (in our pre-release stream). Recent releases bring native Deadboot media creation, and introduce an improved Deadboot Imager UI.

Native Deadboot Media Creation.

We can now create Evimetry Deadboot USB's directly from the Controller, and for larger drives, use the additional space for evidence storage. With a single hard drive serving both as an Evimetry Deadboot and Evidence Repository, scarce USB ports are freed up on target devices, workflow is simplified, and the number of devices to manage limited.

Small USB flash drives are setup solely as a Deadboot, just like our former workflow.

Improved Deadboot Imager UI.

For a while now the Deadboot agent has included a simple ASCII console-based Imager application. This is useful for acquiring single computers, when it is either inconvenient or unfeasable to use the Controller and a network.

While we love the retro feel and simplicity of an ASCII/curses interface, the world is no longer friendly to text-mode UI's, with high-DPI monitors and text-mode free UEFI implementations meaning that text-mode no longer works everywhere. A graphical window based UI is now necessary.

In the v3.1.3 pre-release we launched a graphical Imager application, and in today's prerelease (v3.1.5) the layout of the Imager UI has been refined.

Pulling it all together.

The following video demonstrates the workflow of preparing a Deadboot USB and then subsequent acquisition of a 500G NVMe drive in under 6 minutes.

More information.

Full release notes are available via the releases page. The software may be downloaded from the portal.

Native AFF4 read support for X-Ways & Forensic Explorer

bradley@schatzforensic.com (Bradley Schatz) — Sat, 09 Dec 2017 03:15:07 +0000

In the last two weeks, two of our favourite disk forensic tools integrated native read support for the AFF4 forensic format. Forensic Explorer released v4 of their product, with native AFF4 read support, and X-Ways Forensics released v19.5, which has a plugin API supporting our AFF4 read plugin.

This represents a big step forward towards general adoption of the next-generation image format.

Background

Evimetry's filesystem bridge provides a straightforward and efficient way of consuming AFF4 images from any commercial forensic tool, and results in faster analysis & processing than E01's. Despite this, it is convenient to be able to open AFF4 images directly from tools without having this dependency.

For the last year and a half, Evimetry have been investing significant effort in growing the AFF4 ecosystem, by standardising the format, providing open-source implementations, integrations with leading open source forensic software, and working with commercial vendors to integrate read support.

In October we worked closely with X-Ways to define a plug-in API to support new forensic image formats, which X-Ways integrated in the 19.5 beta releases. We followed this up by producing an X-Ways plugin to read AFF4 images via our C++ based Evimetry libAFF4 Reader DLL. Around the same time, we provided the reader DLL's to the folks behind Forensic Explorer (FEX). In no time, the v4 beta builds of FEX supported reading AFF4 images too.

Usage: X-Ways >= 19.5

Download the current Evimetry X-Ways AFF4 reader plugin, and copy the contents into the X-Ways installation folder. Make sure you have the Visual C++ 2015 Runtime installed.

~~CAVEAT: Only x64 is supported for now.~~

UPDATE: We now support x86 (32 bit) as well.

Usage: Forensic Explorer >= 4.0

The current FEX 4.0 build already integrates the Evimetry libAFF4 reader DLLs. This DLL contains a bug that has since been fixed in a later version of the DLL. We anticipate that this will make it into the next release of FEX. In the meantime replace the libaff4 DLL in Forensic Explorer with the one contained in the Evimetry libAFF4 reader DLL package.

Caveat: BETA code quality

Please note that the Evimetry libAFF4 reader DLLs are currently at BETA quality, while we undertake further testing and importantly, tuning. If you strike any issues, please submit a bug report to support@evimetry.com .

Update 18 June 2019

The plugin has been updated and can now be found at the Evimetry X-Ways Plugin page.

AWS EC2 Cloud Storage Acquisition with Evimetry

bradley@schatzforensic.com (Bradley Schatz) — Sat, 16 Sep 2017 08:14:32 +0000

You have been tasked with forensic acquisition of 6 servers in the AWS cloud, with a total of 2TB of storage. How do you do it?

This post will describe the method I applied in a recent case, where we collect the storage, acquired it into forensic images, and pulled down the images into our custody overnight. While I will be describing how I did it using Evimetry, the method is easily translatable to other tools.

Storage forensics in AWS

Unlike many cloud IAAS platforms, AWS provides us with the ability to take a Snapshot of the storage of a Virtual Computer (an Instance, in EC2 parlance). This gives you a point in time copy of the storage device. This isn’t a forensic image, as there isn’t a hash protecting the copy.

This enables us to quickly Collect a copy of the storage, without affecting the availability of the Target device. To truly collect the copy though, we need to take it under our control. To do this, we rely on the ability of AWS to share Snapshots between accounts.

Once we have access to the Snapshot in our own Security Domain (account), we can then shift to forensic acquisition of the copy. This is best achieved by generating a Volume from the Snapshot, attaching the Volume to a purpose-built acquisition server, and acquiring using regular forensic processes. Once a forensic image is acquired, we then Transfer it out of the cloud to store on a storage device that we Possess.

The following sections step through the process of undertaking the method.

Evidence Isolation & Location

First up, create your own Security Domain for Collecting the Snapshots into, and undertaking acquisition. In AWS, this is easily achieved by maintaining your own account, separate to the TARGET account. The below screenshot displays an account I have established under my own name, logged into the AWS Console.

I recommend running the two separate AWS security domains (the TARGET and EVIDENCE) using two separate web browser windows, one of them using private mode browsing so that you can use the TARGET’s credentials in one, and your security domain’s credentials in another.

Note the Account ID (993480464498) – this will be required to identify this security domain when we come to share a Snapshot from the TARGET to our security domain.

Identification

In the TARGET AWS console, use the left menu, “Instances” to show the instances, and find the instance that you want to collect.

In the screen capture below, one can see the TARGET instance, the instance ID (in this case i-065e4cd1fbf56c92e), the block device volume (vol-08c5f1566ec4ea6c5), and the Availability Zone “ap-southeast-2c”. These identifiers should be documented to establish the provenance of the evidence.

In the left menu, “Elastic Block Store”, select “Snapshots”, and then “Create Snapshot”.

Select the volume of our TARGET server (ol-08c5f1566ec4ea6c5), and describe the evidence.

We now have a snapshot of the block storage of the instance. We record the Snapshot ID (snap-0925cec0faee0659a) to maintain provenance of the evidence.

Now that we have an image (not a forensic image, as we don’t have a hash), we want to Collect it. This means taking possession of it, so that it can’t be modified. To do this, we share the image with the EVIDENCE security domain we created earlier.

Recalling that the Account ID of our acquisition security domain is (993480464498), we privately share the image with that account.

Note that the snapshot isn’t instantaneous and may take some minutes to complete.

Prepare Evidence Storage Server – Server provisioning

While the snapshot is going, switch browser windows (and security domains), and begin setting up your Evidence Server in the same datacentre as the target server. This will be running the Evimetry Cloud Agent, and will be co-located with the TARGET server for efficiency and speed. In the below AWS control panel, we set the location to “Sydney” which matches the TARGET server in this instance.

In the left menu we select “Instances” and then “Launch Instance”

To deploy the Evimetry Cloud Agent, we need an Ubuntu 14.04 instance. Select that.

The speed at which your acquisition will occur will depend on a number of factors, including the virtual disk size, the performance of the virtual storage, and the number of CPU’s you have in the server. In a future blog post, I will go into this in more detail, but for now, select a 4 CPU machine with moderate performance.

Next up, we want to make sure that the evidence storage server is as close as possible to the target. From before, we have identified that that the target is in “ap-southeast-2c”, so we make sure that the subnet matches. We also ensure that we enable the auto assignment of a public IP, so we can connect to the server. This is sufficient to then “Review & Launch”.

Finally, we launch the new Evidence Storage instance.

The final task in bringing up the evidence storage server is to establish a key pair for working with the server. We create a new key pair called “SF-Acquisition” below.

Download the key pair, and save it somewhere safely. Example shell commands follow.

cp ~/Downloads/SF-Acquisition.pem ~/Documents/keys/

chmod og-rwx ~/Documents/keys/SF-Acquisition.pem

After launching, traverse the launch status window to the new instance.

On following the instance link, we see the Instance details. Note the following important details. The public IP is 54.206.15.84, and the Security Group is “launch-wizard-3”.

Prepare Evidence Server – Deploy Evimetry Cloud Agent

We now deploy the Evimetry Cloud Agent on the Evidence Server.

First up, we SSH into the Evidence Server, using the private key from before, and the public IP address of the machine.

> 
> neon:tmp bradley$ ssh -i ~/Documents/keys/SF-Acquisition.pem ubuntu@54.206.15.84
> 
> 

> 
> Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-125-generic x86_64)
> 
> 

> 
>  * Documentation:  https://help.ubuntu.com/
> 
> 

> 
>   System information as of Fri Sep 15 07:01:38 UTC 2017
> 
> 

> 
>   System load:  0.0               Processes:           140
> 
> 

> 
>   Usage of /:   11.8% of 7.74GB   Users logged in:     0
> 
> 

> 
>   Memory usage: 0%                IP address for eth0: 172.31.19.255
> 
> 

> 
>   Swap usage:   0%
> 
> 

> 
>   Graph this data and manage this system at:
> 
> 

> 
>     https://landscape.canonical.com/
> 
> 

> 
>   Get cloud support with Ubuntu Advantage Cloud Guest:
> 
> 

> 
>     http://www.ubuntu.com/business/services/cloud
> 
> 

> 
> 19 packages can be updated.
> 
> 

> 
> 8 updates are security updates.
> 
> 

> 
> New release '16.04.3 LTS' available.
> 
> 

> 
> Run 'do-release-upgrade' to upgrade to it.
> 
> 

> 
> The programs included with the Ubuntu system are free software;
> 
> 

> 
> the exact distribution terms for each program are described in the
> 
> 

> 
> individual files in /usr/share/doc/*/copyright.
> 
> 

> 
> Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
> 
> 

> 
> applicable law.
> 
> 

> 
> ubuntu@ip-172-31-19-255:~$ 
> 
>

We need to do admin level install operations, so make sure you are in a root shell session by executing “sudo bash”

ubuntu@ip-172-31-19-255:~$ sudo bash

root@ip-172-31-19-255:~#

Next, we install the Evimetry Cloud Agent, using a simple 2-line UNIX command. First log into the Evimetry Portal using your credentials. Then select the “Deploy Cloud Agent” option from the menu.

We deploy the cloud agent using a simple 2 line shell script. Copy and paste it into your SSH session.

In the SSH session, the VM will be patched, and the Evimetry Cloud Agent installed. Answer “Yes” to all by default. It takes around 30 seconds.

 root@ip-172-31-19-255:~# wget -O install_script_ubuntu.sh https://my.evimetry.com/portal/install_script_ubuntu.sh?6a063dfa450349cef1a1dbc0eacd2b75af6e84ce

--2017-09-15 07:04:20--  https://my.evimetry.com/portal/install_script_ubuntu.sh?6a063dfa450349cef1a1dbc0eacd2b75af6e84ce

Resolving my.evimetry.com (my.evimetry.com)... 104.237.142.195

Connecting to my.evimetry.com (my.evimetry.com)|104.237.142.195|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: 9865 (9.6K) [text/plain]

Saving to: ‘install_script_ubuntu.sh’

100%[==================================================================================>] 9,865       --.-K/s   in 0s

2017-09-15 07:04:21 (216 MB/s) - ‘install_script_ubuntu.sh’ saved [9865/9865]

root@ip-172-31-19-255:~# bash install_script_ubuntu.sh

##########################################################################################

Updating APT and Installing dependencies

##########################################################################################

Run sudo apt-get --yes update [Y/n/a]?```


<<<SNIP>>>


```bash##########################################################################################

Configuring agent config for cloud deployment.

##########################################################################################

Artifact:    evimetry.agent

Description: Agent Application for Evimetry Application Suite

Version:     3.0.1

Build:       1117

Build Date:  2017-07-17T08:39:06.891+1000

evimetry.agent start/running, process 4917

############################################################################################

Evimetry installed and started. Point your controller at 172.31.3.157.

Control service by stop/start/restart evimetry.agent

Logs are in /var/log/upstart/evimetry.agent.log

Configuration is in /etc/init/evimetry.agent.conf

############################################################################################

The final thing to setup is a port forward so that we can connect through to the Evidence Server. Unlike some cloud services, EC2 Instances sit on a private IP address, behind a firewall.

In the “Network & Security” section of the console, go to “Security Groups”. Recalling from the Instance that is was started in the Security Group “Launch Wizard 3”, edit the inbound rules of that security group.

Create a rule forwarding the Evimetry Cloud Agent’s port (TCP 9982) to the Evidence Server.

Verify Access to Evimetry Cloud Agent

At this point, the Evimetry cloud agent is ready to be used. Using the public IP of the VM (54.206.15.84), connect in using the Evimetry Controller.

The agent will appear in the controller’s fabric nodes view (note that the IP of the Evidence Server is showing a 172.X.X.X private IP address). Visible underneath it is its storage, and an Evimetry Repository, which is located on its internal storage. We will acquire our images into this Repository.

Acquiring the image

We now go back to the EVIDENCE Security Domain, and access the "Elastic Block Store" | "Snapshots" section. Be sure to filter the view to “Private Snapshot” as it won’t be visible in the default setting.

The snapshot from the SUSPECT security domain will now be visible (check the Snapshot ID matches). We now transform the image into a Volume, which can then be added to a running instance in much the same way we plug removable storage into a computer. First, right click on the Snapshot and select “Create Volume”.

In the volume creation form, where we create the evidence storage instance, we choose the Availability Zone of _“_ap-southeast-2c”. Make sure that you choose this zone as the instance where the Volume is created, and then click on “Create Volume” to create the volume.

Note the volume ID, of the new Volume, which is vol-097e59361bd515f78. Follow the link.

Now we can attach the volume to our Evidence Server. Go to the "Elastic Block Store" | "Volumes" area and, noting the Volume ID, select Attach Volume.

Recalling that the instance ID of our Evidence Server is i-0af9148e32f37b8ac, attach the Volume as a virtual disk.

Refreshing the Cloud Agent instance listed in the Evimetry Controller now shows the disk attached to the agent as /dev/xvdf . Note that the newly attached disk is locked against mounting and writing. Right click on the disk and select Acquire.

The acquisition settings dialog will appear. Select a full linear acquisition of the attached drive, and add the Repository on the Storage Server as the container location. Give the Image a name using your standard image naming scheme, and document the original Volume ID and Instance ID associated with this image. Then click OK.

Acquisition is now underway. The screenshot below shows an acquisition using the “Provisioned IOPS SSD” as Volume storage, which proceeds at around 90MB/s, constrained by the storage of the infrastructure. Our testing shows that using “General Purpose SSD’s” as storage gives a trickling rate of around 10MB/s (that’s 4x slower than USB2!). A future post will focus on scaling this speed.

When the acquisition (including verification) completes, Evimetry will display a completion dialog.

We then transfer the image locally to the lab using Evimetry, by flipping to the “Images” tab of the Controller, and right clicking on the newly created image.

After choosing the destination, the image downloads locally.

Conclusion

This post has described a methodology for acquiring storage in the EC2 cloud. Using EC2 Snapshots in conjunction with Snapshot Sharing enables one to quickly Collect copies of Target storage. Acquisition can then be undertaken in the Cloud, so that the evidence is protected by a hash at the earliest opportunity, while minimising the amount of data that needs to be copied.

In future posts, I will follow up on how virtual disk selection affects the speed of acquisition; how to acquire volatile memory in AWS; and how to undertake analysis in the cloud.

Updated slides: Accelerating your forensic & incident response workflow

bradley@schatzforensic.com (Bradley Schatz) — Thu, 17 Aug 2017 00:48:03 +0000

Late last year I had the pleasure of attending the F3 conference in Gloucestershire, UK. It is quite unlike any other digital forensics conference I have ever been to; a community run, practitioner focused, 2 day conference situated in a stately manor in the English countryside. I can thoroughly recommend it.

I had the opportunity to present an updated version of my presentation: "Accelerating your forensic & incident response workflow: the case for a new standard in forensic imaging". The slide deck is available for download here.

Call for participation - AFF4 Working Group meeting at DFRWS 2017 USA

bradley@schatzforensic.com (Bradley Schatz) — Sat, 22 Jul 2017 11:42:59 +0000

The Advanced Forensic Format 4 Working Group (AFF4 WG) is calling for interested parties to join the second working group meeting, to be co-located at the DFRWS Conference 2017, in Austin, TX.

Originally proposed in 2009 by Michael Cohen, Simson Garfinkel, and Bradley Schatz, the AFF4 forensic container enables new approaches to forensics, unparalleled forensic acquisition speeds and more accurate representation of evidence. The AFF4 WG has recently released v1.0 of the AFF4 Standard, including canonical images, specification, and open source libraries for implementers. Current AFF4 implementations include Rekall, Evimetry, Sleuth Kit, Volatility and GRR.

For more information, please see the working group mailing list, or contact Bradley Schatz or Michael Cohen.

Co-Chair: Dr Bradley L Schatz, Schatz Forensic/Evimetry, [ bradley schatzforensic com ] Co-Chair: Dr Michael Cohen, Google, [ scudette google com ]

AFF4 working group mailing list: https://groups.google.com/forum/#!forum/aff4-wg

Compiling Sleuth Kit with AFF4 support on MacOS

bradley@schatzforensic.com (Bradley Schatz) — Fri, 09 Jun 2017 06:16:06 +0000

We recently contributed patches to the Sleuth Kit to read AFF4 images. While we are waiting for those to be pulled into the main distribution, the following recipe should suffice for compiling a stand alone copy on MacOS.

Dependencies The following dependencies are needed to compile libAFF4 on OSX. I use MacPorts, and the corresponding packages i needed to install are:

ossp-uuid
zlib
snappy
raptor2
google-glog
pcrexx
* tclap (missing *.pc file - place in /opt/local/lib/pkgconfig/)

Clone and compile LibAFF4 (C/C++)

Use the following to clone the current release of libaff4, configure it, and install.

git clone https://github.com/google/aff4.git
cd aff4
git submodule update --init third_party/gtest
cd third_party/gtest
git reset --hard
cd ../..
./autogen.sh
./configure CC=clang CXX=clang++ CXXFLAGS="-std=c++11 -stdlib=libc++ -O2 -g0 -I/opt/local/include" LDFLAGS="-stdlib=libc++ -L/opt/local/lib"
make
sudo make install

Clone and compile the Sleuth Kit

Use the following to compile the sleuthkit with libaff4 support.

git clone https://github.com/blschatz/sleuthkit.git
cd sleuthkit/
git checkout release-4.4
autoreconf --force --install --verbose
./configure
make
sudo make install

Evimetry v3 Released: Remote volatile memory support

bradley@schatzforensic.com (Bradley Schatz) — Fri, 09 Jun 2017 05:19:54 +0000

We recently released Evimetry 3, the newest release of our revolutionary approach to forensic acquisition and analysis.

Whats new?

The big news is that we now support remote volatile memory acquisition. This means that in addition to being able to acquire remote disks, you can now acquire the volatile memory of live Windows, MacOS, and Linux hosts. We primarily support Windows XP and above (x86 and x64) and OSX Mountain Lion and above (x64). The coverage for Linux memory acquisition is limited to 64 bit Intel machines where the kmem driver is enabled.

Get straight to analysis.

In addition to acquiring the physical memory, we also acquire and store the entry points needed to find the kernel page tables and base kernel data structures. The benefit of this is that time-consuming scanning for these entry points (which are fundamental to further analysis) can be bypassed getting you to analysing evidence sooner.

We have developed patches to the leading volatile memory analysis frameworks, Volatility and Rekall, to support reading these images, and the patches for Volatility have been contributed to the main Volatility project on GitHub.

Acquire faster.

We take full advantage of Evimetry's advanced compression to transport memory over the network at maximal rates. The effects of latency, a killer of network performance over long distance links, can be negated by pushing our networked evidence storage agents into the same network as the suspect computer.

Ready for digital evidence at wire speed?

If you would like to try these features, get in touch to organise an evaluation licence.

Sleuth Kit support for the AFF4 Standard v1.0 Released

bradley@schatzforensic.com (Bradley Schatz) — Fri, 07 Apr 2017 12:28:04 +0000

I am pleased to announce the availability of both a set of patches to the Sleuth Kit and an open source C/C++ implementation for reading AFF4 Standard v1.0 disk images. Last week the AFF4 Standard v1.0 was released by Bradley Schatz (Evimetry) and Michael Cohen (Google) .

Originally proposed in 2009 by Michael Cohen, Simson Garfinkel, and Bradley Schatz, the AFF4 forensic container enables new approaches to forensics, unparalleled forensic acquisition speeds and more accurate representation of evidence. These are enabled through next-generation forensic image features such as storage virtualisation, arbitrary metadata, and partial, non-linear and discontiguous images. The standard is the culmination of research spanning 6 years and 4 scientifically peer reviewed papers.

The release of these is a significant step forwards to the wider adoption of the format, enabling a large portion of the open source forensic toolchain to access AFF4 forensic images, and commercial implementers the ability to support reading the format by integration of a single unencumbered library.

The patches to the SleuthKit were contributed by Schatz Forensic (Evimetry), while the C/C++ library was originally developed by Michael Cohen (Google), with AFF4 Standard v1.0 support added by Schatz Forensic.

This release follows the release last week of the AFF4 Standard v.1.0 and a Python reference implementation (reader), and the release of Evimetry Community Edition, a freely licensed subset of the AFF4-based forensic tool.

For more information on the AFF4, attend the webcast “AFF4: The New Standard in Forensic Image Format, and Why You Should Care”, given by Bradley Schatz, in association with SANS, on 17 April 2017.

Implementers and interested parties are invited to join the AFF4 working group at aff4@googlegroups.com .

Introducing Evimetry Community Edition

bradley@schatzforensic.com (Bradley Schatz) — Fri, 07 Apr 2017 12:11:45 +0000

Evimetry Community Edition provides a subset of the Evimetry system for free. The purpose of this is to grow the AFF4 ecosystem, firstly by providing a pain free path for Evimetry licensees to provide AFF4 images to non-licensees. Secondly, we wanted to provide practitioners, researchers and educators a freely available implementation of the AFF4 standard v1.0 which can be used to gain familiarity with the format. Schatz Forensic, the creators of Evimetry, drove the standardisation effort behind the AFF4 Standard v1.0.

With the Community Licenced Evimetry Controller, you can create Linear AFF4 Images on your Windows based analysis system, verify the integrity of AFF4 images, and convert between AFF4, E01/EWF and Raw images. You can also mount AFF4 images as virtual disks and analyse with your preferred forensic tools.

Using the Community Licenced Evimetry Filesystem Bridge, you can access entire repositories of AFF4 images as virtual raw files, enabling straightforward consumption with your existing forensic toolkit.

The release of Evimetry Community Edition coincides with the release by Schatz Forensic of open source implementations of the AFF4 format, patches to the Sleuth Kit supporting AFF4 images, and the release of the AFF4 Standard v1.0.

To gain access to the initial release of Evimetry Community Edition, email us at info@evimetry.com .

AFF4 Standard v1.0 Released

bradley@schatzforensic.com (Bradley Schatz) — Thu, 30 Mar 2017 07:07:10 +0000

Today marks the release of the Advanced Forensic Format 4 (AFF4) Standard v1.0.

Originally proposed in 2009 by Michael Cohen, Simson Garfinkel, and Bradley Schatz, the AFF4 forensic container enables new approaches to forensics, unparalleled forensic acquisition speeds and more accurate representation of evidence. These are enabled through next-generation forensic image features such as storage virtualisation, arbitrary metadata, and partial, non-linear and discontiguous images. The standard is the culmination of research spanning 8 years and 4 scientifically peer reviewed papers.

Bradley Schatz (Evimetry) and Michael Cohen (Google) have collaborated to make freely available: • a set of canonical reference images which serve as ground truth for the format; and • an explanatory specification document describing the format in detail; and • a Python AFF4 reference implementation capable of reading the format.

This release of a standard specification for the file format is a milestone towards the wider adoption of the format, providing implementers an unambiguous and straightforward path to implementation. The release of the AFF4 Standard coincides with the limited release of Evimetry Community Edition, a freely licensed subset of the AFF4 based forensic tool, and in the coming days, a C++ implementation and patches to the Sleuth Kit, and support for Volatility and Rekall.

The standard specification and reference images are available at [1], the python implementation at [2], and aff4.org [3] becoming the central point of publication.

Implementers and interested parties are invited to join the AFF4 Working Group mailing list [4], and/or contact Bradley Schatz or Michael Cohen.

Contact: Bradley Schatz ( bradley@evimetry.com ) Michael Cohen (scudette@google.com )

[1] https://github.com/aff4
[2] https://github.com/google/aff4
[3] http://www.aff4.org/
[4] https://groups.google.com/d/forum/aff4-wg

AFF4: The new standard in forensic imaging and why you should care

bradley@schatzforensic.com (Bradley Schatz) — Fri, 28 Oct 2016 01:16:32 +0000

At this year's Open Source Digital Forensics Conference (OSDFCon 2016) I presented an update on the AFF4 standardisation effort. For the conference we unveiled a significant milestone: support for consuming Evimetry produced AFF4 forensic images with the Sleuth Kit.

While users of Evimetry are able to exploit the benefits afforded by AFF4 seamlessly with their regular forensic tools, we believe that native support for the format across both opensource and commercial tools will accelerate forensic workflow even further.

The screenshot below demonstrates a non-linear partial physical image (containing only the allocated blocks from the target disk) being interpreted by the SleuthKit.

We will be releasing patches for libaff4 (C++) and Sleuth Kit shortly.

My slides for the seminar are below.

Accelerating forensic and incident response workflow: AusCERT 2016 Slides

bradley@schatzforensic.com (Bradley Schatz) — Tue, 31 May 2016 11:21:19 +0000

Existing forensic image formats are a bottleneck in the multi-core era: The slides from my recent presentation on accelerating forensic & incident response workflow at the AusCERT 2016 Conference. This summarises the research behind Evimetry Wirespeed.

Accelerating forensic and incident response workflow: the case for a new standard in forensic imagingxn--AusCERT2016 from Bradley Schatz

CFP: Digital Investigation Special Issue on Volatile Memory Analysis

bradley@schatzforensic.com (Bradley Schatz) — Sun, 22 May 2016 11:57:41 +0000

The Journal of Digital Investigation is currently calling for papers for a Special Issue on Volatile Memory Analysis. The Guest Editors of this issue are Michael Cohen (Google) and Bradley Schatz (Schatz Forensic).

We would welcome any novel research into aspects of Volatile Memory Analysis. Submissions are due 31 August 2016.

Memory analysis is a hot research topic with wide applications on many fronts - from malware detection and analysis, to recovery of encryption keys, to user activity reconstruction. As advanced contemporary malware increasingly reduces its on-disk footprint, and adopts increasingly sophisticated host detection subversion mechanisms, memory analysis is currently mainstreaming as a valuable technique for detection and response.

While memory analysis presents many new opportunities, it also presents new complications and challenges, ranging from reliance on undocumented program internals, to atomicity of acquisition methodologies. As memory analysis becomes the status quo methodology the use of directed anti-forensics is also becoming prevalent.

This special issue of the Journal of Digital Investigation invites original research papers that report on state-of-the-art and recent advancements in this rapidly expanding area of enquiry, with a particular emphasis on novel techniques and practical applications for the forensic and incident response community.

Topics of interest include but are not limited to:
* Malware detection in memory
* Live memory analysis
* Live system introspection
* Memory acquisition
* Memory analysis of large systems
* Userspace and application specific memory analysis
* Cryptographic analysis, key recovery
* Execution history analysis
* Data fusion between memory/disk/network

Deadline for submissions is 31 August 2016.

Live Partial Acquisition with Evimetry Wirespeed and EnCase

bradley@schatzforensic.com (Bradley Schatz) — Thu, 19 May 2016 05:40:04 +0000

The Evimetry Wirespeed system enables remote live analysis using your existing forensic toolkit. In doing so, a partial physical image is created. Analysis activity drives the partial acquisition process, which in-turn results in an increasingly complete physical disk image. Acquisition may be incrementally widened to categories of evidence, such as Windows Registries, Log Files, Office documents, Allocated, and all of disk.

An important aspect in balancing live analysis with bulk acquisition is interactive latency (liveness). Unlike any other forensic system, live analysis activities are prioritised over bulk activities, enabling effective live analysis with minimal perceptual delay.

A video demonstrating liveness in partial live acquisition using Evimetry Wirespeed & EnCase is available on the Evimetry Website. This blog post summarises the salient parts of the video:

@1:08 Partial acquisition of triage artifacts

A partial acquisition of a 240GB SSD1, collecting Page Files, Swap files, Windows Registry Files, Log Files, and Windows Access Traces, is started.

This causes acquisition of volume metadata, followed by filesystem metadata, and then the content data blocks corresponding to these categories. This acquisition completes in 17s and has stored 2.3GiB in the forensic image2.

The active partial image is shared as a virtual disk, and mounted in windows as the F: drive. Windows explorer is then used to browse the F: drive, into the F:\Videos\Videos1\ folder. All access of the blocks of the virtual disk come from the forensic image, as the filesystem metadata has already been acquired.

On traversing to the F:\Videos\Videos1\Videos\ folder, thumbnails are generated by explorer and shown. As the content for these has not yet been acquired, the underlying blocks are loaded from the suspect drive, stored in the partial image, and then passed on to windows via the iSCSI virtual disk emulator. From there windows explorer renders the thumbnails.

@2:37 Third party application access

The file Mario1_500_HQ_512kb.mp4 is accessed, which contains a mario runthrough video from archive.org. This causes the video to be played using VLC.

The purpose of this is to create an interactive acquisition load on the target drive (recalling that the content of this file have not yet been acquired).

@3:03 Virtual disk access using EnCase.

The virtual disk is loaded into EnCase3, which scans the volume metadata, and filesystem metadata (in this case parsing the MFT).

The volume metadata and MFT are loaded from the partial image. Interactive performance of the video is unaffected, with no glitches or pauses.

@4:40 Interactive analysis with EnCase

Within EnCase, the files are filtered down to JPEG files, and the view shifted to Gallery. All of the pictures displayed on the gallery are loaded from the suspect hard drive, and stored in the partial image on their way to EnCase. At this stage only VLC and Encase are competing for access to the target device, and interactive performance of the video is unaffected. There are no glitches or pauses, and load and display of the pictures in EnCase is snappy.

@5:08 Acquisition scope widened to all of Allocated

A successive partial acquisition operation is started, widening scope to all allocated files. This will only read blocks of files on the target device that aren’t already in the image (a significant portion of the video, and the pictures that were viewed in the gallery are already present in the image, in addition to the volume and filesystem metadata, system logs, registries, etc).

@5:48 Gallery browsing under high acquisition load

The gallery is scrubbed to a random point, causing acquisition and display of a number of as yet un-accessed images. While this interactive process is competing with the video and the batch acquisition (and proceeding at 238 MB/s), interactive latency has increased but still acceptable.

@6:00 Single file browsing under high acquisition load

Encase is switched to the Table browser, and random pictures browsed. Interactive latency for single file access is snappy.

@8:08 Video runthrough completes

Acquisition of 61GiB has completed when the video completes playing.

@ finish

At the point where this screencast ends, acquisition of allocated space is still underway. The analyst needn’t wait for its completion, as a partial forensic image may be completed at any time, with the resulting image still accessible using regular forensic tools. With the volume & filesystem metadata, and the file content that has been acquired to that point, forensic tools will still be able to interpret the disk. Blocks that were not acquired simply show up as unknown data.

Conclusion

This blog post summarised the most important parts of the video, the purpose of which was to demonstrate: - The incremental nature of partial acquisition using Evimetry Wirespeed; - The ease of human-in-the-loop live analysis in driving forward partial acquisition; - The performance of the Evimetry Wirespeed system.

[1] around 50% full, content including a Windows OS folder heirarchy (no user profiles), random data, and multiple copies of the GovDocs corpus, and videos downloaded from archive.org.
[2] We note that this dataset actually doesn’t have any page files or swap files in it.
[3] EnCase is a trademark of Guidance Software and has no affiliation with Schatz Forensic.

Introducing Evimetry: digital forensics at wire speed

bradley@schatzforensic.com (Bradley Schatz) — Mon, 11 Apr 2016 12:24:52 +0000

Digital forensics is full of waiting. Waiting for acquisitions to complete. Waiting for images to process. Waiting for flights and waiting in data centres.

We set out to remove this wait.

In November 2014, Schatz Forensic quietly opened a beta program for a new forensic tool aimed at speeding forensic workflow. The innovative system accelerates acquisition and processing of evidence and closes the gap between acquisition and analysis.

A long beta program has allowed us to listen to our testers, and target the pain points in their forensic process. Practitioners love the faster acquisitions and processing, and cutting hours of wait time from cases. Incident responders are excited by travel-free remote live analysis, and rapid partial imaging of high value artefacts.

Today marks the general availability release of Evimetry Wirespeed. If you are ready for a more efficient workflow and less waiting, visit http://evimetry.com or contact us.

Was the firewall blocking traffic? Identifying active firewall rules using registry analysis.

bradley@schatzforensic.com (Bradley Schatz) — Sat, 06 Dec 2014 02:59:13 +0000

I came across this question recently in relation to claims that access to a Windows 8 host via Windows Remote Desktop Protocol was blocked by the firewall configuration. This post describes my research into the registry artefacts related to answering the question, and provides a patch to RegRipper to assist in analysis.

Theory of operation

Windows 8 uses the same firewall configuration entries used by Windows 7. Windows ships with a number of firewall rules enabled, and these may be added to or modified by the user, for example using the windows firewall control panel applet.

Rules are scoped by Profile, which is either Public, Private, or Domain. Note that I am going to refer to these are a “Network Category” herein, for reasons that will become apparent. These Network Categories (profiles) are associated with particular networks: for example, in the window capture below you can see that my home wireless connection is a “Private network”. For a “Private Network”, firewall rules with a value of “Private” will be applied.

The firewall rules are stored in the registry at HKLM\System\CurrentlControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules.

The value of the rule above for “RemoteDesktop-UserMode-In-TCP” is

v2.20|Action=Allow|Active=FALSE|Dir=In|Protocol=6|Profile=Public|LPort=3389|App=%SystemRoot%\system32\svchost.exe|Svc=termservice|Name=@FirewallAPI.dll,-28775|Desc=@FirewallAPI.dll,-28756|EmbedCtxt=@FirewallAPI.dll,-28752|

Comparing this the applet above, we can see that this corresponds to the disabled RemoteDesktop-UserMode-In-TCP rule. Looking for the second TCP related RDP, I found the following rule with the key name “{6AFE835E-629E-48DA-A87E-AB6C367D2BB7}", which corresponds to the similar rule that is enabled for both Private and Domain.

v2.20|Action=Allow|Active=TRUE|Dir=In|Protocol=6|Profile=Domain|Profile=Private|LPort=3389|App=%SystemRoot%\\system32\\svchost.exe|Svc=termservice|Name=@FirewallAPI.dll,-28775|Desc=@FirewallAPI.dll,-28756|EmbedCtxt=@FirewallAPI.dll,-28752|

Observation: Identifying the Category

Existing theory around mapping active networks from the registry is generally accepted: network profiles are stored in HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles. The RegRipper networklist plugin interprets the contents of this registry sub tree.

What my review of the current literature didn’t reveal is how to identify whether a Network Profile is configured as “Private”, “Public”, or “Domain”. Hence, I started looking for automated ways configuring a network in such a manner, from which I hoped to identify the relevant registry keys.

The documentation for the PowerShell “Set-NetConnectionProfile” command lists the following parameters for the “-NetworkCategory” arguments:

Specifies an array of category types of a network. You cannot set the DomainAuthenticated type by using this cmdlet. The server automatically sets the value of DomainAuthenticated when the network is authenticated to a domain controller. The acceptable values for this parameter are:
-- Public
-- Private

I opened up powershell and issued the following command.

PS C:\Users\bradley.SCHATZFORENSIC> Set-NetConnectionProfile -interfacealias "WiFi 3" -NetworkCategory Public

On running this, we see the Network and Sharing Centre applet immediately updated to indicate that the network was now a Public Network.

Examination of the associated profile shows a registry key called Category. Based on the naming of the powershell argument “NetworkCategory”, I hypothesised that the Category key might contain the value of relevance. In this instance it was set to a value of 0.

I opened then issued the following command.

PS C:\Users\bradley.SCHATZFORENSIC> Set-NetConnectionProfile -interfacealias "WiFi 3" –NetworkCategory Private

On running this, I saw the Network and Sharing Centre applet immediately update to indicate that the network was now a Private Network.

Refreshing the registry viewer, the value of the Category key was now 1.

I undertook the above for three iterations and observed the same changes every time. I additionally attempted to undertake a Remote Desktop session while both settings were in place. The outcomes were consistent with the description of the above Firewall Rules. When the network was configured as private, I was unable to establish a connection, and when it was configured as public, I was able to establish a Remote Desktop session.

Hypothesis formulation

At this point my hypothesis was that the value of the Category key corresponded to the Network Category of a network profile. That is:

0 == Public
1 == Private

Of course, this hypothesis could be wrong: what if what I was observing was just one of many configurations occurring as a result of the powershell command?

Accordingly, I undertook an experiment to confirm both these interpretations of the values, and their application of the corresponding firewall rules.

Testing

I manually edited only the Category key of corresponding Network Profile and set it to 0. I restarted the Windows Firewall Service, at which point, I saw the Network and Sharing Centre applet immediately update to indicate that the network was now a Public Network. I attempted to establish a Remote Desktop session, which failed.

I then manually edited the Category key and set it to 1. I restarted the Windows Firewall Service, at which point, I saw the Network and Sharing Centre applet immediately update to indicate that the network was now a Private Network. I attempted to establish a Remote Desktop session, which succeeded.

I undertook the preceding experiment 3 times and received the same result each time.

Automation

I modified the networklist.pl plugin of RegRipper to interpret the Category key per the above theory. A third value of the “Category” key was observed: the value of 2. Based on context in which it came up I have inferred that it refers to a Network Category of Domain. I have not tested this.

Conclusions

I didn’t undertake an exhaustive literature review in regard to the above research, so it may well be that this registry artefact has already been treated elsewhere. Please do let me know if I have missed any prior work that you are aware of.

The updated networklist.pl script is currently in my GitHub branch of RegRipper.

I encourage you to validate this new version of networklist.pl against your own registry and let me know if it is consistent with your running configuration, or not.

UPDATE: Harlan Carvey has merged this patch into the main RegRipper development tree at GitHub.

Inside Out Blog

Which forensic imager is the fastest?

How to analyse AFF4 linux memory images

How to acquire Linux memory images using without a driver

How to acquire: Evimetry

How to acquire: linpmem

How to analyse

Announcing Evimetry Lab: changing the game for in-lab forensics

Simple Deadboot provisioning and acquisition with Evimetry

Native Deadboot Media Creation.

Improved Deadboot Imager UI.

Pulling it all together.

More information.

Native AFF4 read support for X-Ways & Forensic Explorer

Background

Usage: X-Ways >= 19.5

Usage: Forensic Explorer >= 4.0

Caveat: BETA code quality

Update 18 June 2019

AWS EC2 Cloud Storage Acquisition with Evimetry

Storage forensics in AWS

Evidence Isolation & Location

Identification

Prepare Evidence Storage Server – Server provisioning

Prepare Evidence Server – Deploy Evimetry Cloud Agent

Verify Access to Evimetry Cloud Agent

Acquiring the image

Conclusion

Updated slides: Accelerating your forensic & incident response workflow

Call for participation - AFF4 Working Group meeting at DFRWS 2017 USA

Compiling Sleuth Kit with AFF4 support on MacOS

Evimetry v3 Released: Remote volatile memory support

Sleuth Kit support for the AFF4 Standard v1.0 Released

Introducing Evimetry Community Edition

AFF4 Standard v1.0 Released

AFF4: The new standard in forensic imaging and why you should care

Accelerating forensic and incident response workflow: AusCERT 2016 Slides

CFP: Digital Investigation Special Issue on Volatile Memory Analysis

Live Partial Acquisition with Evimetry Wirespeed and EnCase

@1:08 Partial acquisition of triage artifacts

@2:01 Virtual disk sharing

@2:37 Third party application access

@3:03 Virtual disk access using EnCase.

@4:40 Interactive analysis with EnCase

@5:08 Acquisition scope widened to all of Allocated

@5:48 Gallery browsing under high acquisition load

@6:00 Single file browsing under high acquisition load

@8:08 Video runthrough completes

@ finish

Conclusion

Introducing Evimetry: digital forensics at wire speed

Was the firewall blocking traffic? Identifying active firewall rules using registry analysis.

Theory of operation

Observation: Identifying the Category

Hypothesis formulation

Testing

Automation

Conclusions