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.
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|
|Floppies, backup media, etc.||Years|
|CD-ROMs, printouts, etc.||Tens of years|
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 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.
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:
Format the external hard drive with EXT4 filesystem:
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:
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).
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
- NIST Special Publication 800-86 - Guide to Integrating Forensic Techniques into Incident Response
- RFC 3227 Guidelines for Evidence Collection and Archiving
- ENISA - Electronic evidence - a basic guide for First Responders
Classification of this document
TLP:WHITE information may be distributed without restriction, subject to copyright controls.
- 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)