CIRCL » TR-22 - Recommendations for Readiness to Handle Computer Security Incidents

Overview

The objective of this document is to provide a set of practical procedures to enhance incident response team and ensure readiness in case of computer and cybersecurity incidents. The document includes the practical aspects on how to perform minimal response actions like gathering evidences from system or network in order to support LIRT (local incident response team) or public/private CERT supporting organizations in incident handling.

This document contains technical details about gathering evidences that might be updated at a regular interval. Check the revision of the document.

Theory

Incident response can be a daunting task. In order to ease the process, it’s important to keep some basic rules in mind while proceeding like:

Documenting everything you do or notice
Keep your original evidences safe and off-line
Keep calm and don’t rush into actions that could lead into the destruction of evidences (e.g. running Antivirus before acquiring evidences)
Keep in mind the order of volatility

Order Of Volatility (OoV)

Preserving evidences is a key element to help understanding a security incident. The accuracy or the details from a security incident can only be ensured from an adequate set of data sources. The preservation of the evidences highly depend of the expected life span of data. In page 28 of Forensic Discovery, Dan Farmer and Wietse Venema proposed the following expected life span for data on computers:

Type of Data	Life Span
Registers, peripheral memory, caches,…	Nanoseconds
Main memory	Ten nanoseconds
Network state	Milliseconds
Running processes	Seconds
Disk	Minutes
Floppies, backup media, etc.	Years
CD-ROMs, printouts, etc.	Tens of years

Gathering evidences

When you have a suspicion of a compromised system, gathering evidences is often one of the first action to perform. Other actions like applying patches, running Antivirus software or any task that might destroy evidence must be avoided at all costs. The acquisition should be performed in the order ensuring the order of volatility starting with volatile memory. We usually recommend to take the memory acquisition just before the disk acquisition. If an important period is between the acquisition, it could become challenging for the analysts to ensure an accurate timeline between the two evidences.

Memory acquisition

Memory dump on Windows

Make sure you have more free space on the disk or the USB key you run the memory dump from
Download DumpIt
As it is an archive, extract it (right click, extract). Note: it is easier to provide DumpIt.exe directly to the victim.
Connect to the computer the harddisk or the USB key with DumpIt on it to the computer you want to do the memory acquisition from
Double-click on the file.
A window will pop-up, read the texts written there, if the “Address space size” is bigger than “Free space size”, you do not have enough space on the device. In that case, moving DumpIt.exe to an USB key or an SD, empty and bigger than “Address space size”.
If it is fine, hit ‘y’ and wait (it can take a very long time)
Compress the memory dump in an encrypted archive. The best way is to use 7-ZIP, as windows 7 does not support encryption.

Disk acquisition

Power off the infected PC
Get an external Harddrive (USB) which is equal or bigger than the harddrive you want to copy
Download and burn Kali Linux
Boot the compromised PC with the Live system. (Ensure the BIOS settings take optical drive as primary boot drive.)
By default the live system start in text mode.
ENSURE IT IS RIGHT In text mode you do not have to login. For the case you have to login later on Username:root Password:toor
At this stage the hard drive is not mounted. You can identify the location of the hard drive with the command dmesg. Identify the hard drive by entering a command like:
```
 dmesg | grep sda
```
In the output you should find something like:
```
 625142448 512-byte logical blocks: (320 GB/298 GiB)
```
Connect the external USB drive on the system
The console will report the new device with something like
```
 [sdb] Assuming drive cache: write through
```
You can validate this by entering the command:
```
dmesg
```
Format the external hard drive with EXT4 filesystem:
```
mkfs.ext4 /dev/sdb1
```

Mount the external hard drive:

mkdir /media/usb
mount -t ext4 /dev/sdb1 /media/usb

Copy the hard drive into a forensic image:

ddrescue /dev/sda /media/usb/disk_dump.img

Calculate the MD5 and SHA1sum value of the evidence and record it:

md5sum /media/usb/inc_12032.img
sha1sum /media/usb/inc_12032.img

Unmount the external hard drive:
```
umount /dev/sdb1
```

Network acquisition

Full packet capture acquisition is to capture all network traffic crossing a specific element in a network infrastructure (e.g. a segment or a suspicious server that could be compromised). In case of an incident, specific indicators might indicate some infected systems within an infrastructure. It’s recommended to start a full packet capture as soon as possible at the places where the infected/compromised systems are located.

Full packet captures shall be performed outside the boundary of the potentially compromised systems (e.g. malware usually detects packet capture running on the infected host).

Using tcpdump

If you are using tcpdump to acquire a full packet capture, we recommend

to disable name resolution (-n)
to ensure that the snap length is matching the maximum size of a packet on the network (-s 0)
to review a sample capture to ensure that egress/ingress packets are captures
to review packet loss during packet capture

References

Classification of this document

TLP:WHITE information may be distributed without restriction, subject to copyright controls.

Revision

Version 1.3 April 20, 2015
Version 1.2 September 19, 2014
Version 1.1 August 14, 2014
Version 1.0 June 6, 2014 Initial version (TLP:WHITE)