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


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
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

  1. Make sure you have more free space on the disk or the USB key you run the memory dump from
  2. Download DumpIt
  3. As it is an archive, extract it (right click, extract). Note: it is easier to provide DumpIt.exe directly to the victim.
  4. 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
  5. Double-click on the file.
  6. 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”.
  7. If it is fine, hit ‘y’ and wait (it can take a very long time)
  8. 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

  1. Power off the infected PC

  2. Get an external Harddrive (USB) which is equal or bigger than the harddrive you want to copy

  3. Download and burn Kali Linux

  4. Boot the compromised PC with the Live system. (Ensure the BIOS settings take optical drive as primary boot drive.)

  5. By default the live system start in text mode.

  6. 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

  7. 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)
  8. Connect the external USB drive on the system
  9. The console will report the new device with something like

     [sdb] Assuming drive cache: write through
  10. You can validate this by entering the command:

  11. Format the external hard drive with EXT4 filesystem:

    mkfs.ext4 /dev/sdb1
  12. Mount the external hard drive:

    mkdir /media/usb
    mount -t ext4 /dev/sdb1 /media/usb
  13. Copy the hard drive into a forensic image:

    ddrescue /dev/sda /media/usb/disk_dump.img
  14. Calculate the MD5 and SHA1sum value of the evidence and record it:

    md5sum /media/usb/inc_12032.img
    sha1sum /media/usb/inc_12032.img
  15. 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


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)