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.
Responding to an ongoing incident is always a stressful situation. Being prepared will help to calm down.
Never write the results of the data collection and investigation onto the drive of the analyzed computer, because this could overwrite essential evidences and artifacts.
Always use an external drive like an USB stick which is equipped with the most important tools and enough free space to collect all the data.
To be prepared is essential for successfull incident response. Our report “Acquisition Support Tools for Local Incident Response Teams (LIRT)” can help with this task.
Memory dump on Windows
- Connect your well prepared USB stick to the computer too analyze.
- There should be enough free space to store the memory dump next to the tools.
- The file system must support files >4GByte today in most cases (exFAT).
- To save time, at least USB 3.0 is recommended.
- If you need to download the memory dump too:
- Download it from your own computer, never from the computer too be investigated.
- Today DumpIt is part of Comae-Toolkit
- Comae-Toolkit is free for personal usage. Registration is required.
- Supported architectures: ARM64, x64 and x86
Extract Comae-Toolkit onto your well prepared USB stick and connect it to the computer too analyze.
Open a command line prompt with the option ‘Run as administrator’.
Change directory, depending on the systems architecture:
Simply run DumpIt and specify the output file name. A time stamp can support the analyst.
DumpIt.exe /OUTPUT memory_20201215_1138.bin
Read the texts written on the console and confirm to ‘Proceed with the acquisition’.
Depending on the memory size and the USB stick it can take some time.
Compress the memory dump in an encrypted archive. One way is to use 7-ZIP.
- We have to exchange the password out of band, over a secure channel.
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.4 December 15, 2020
- 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)