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.

Be prepared

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 acquisition

Memory dump on Windows

  1. 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.
  2. 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
  3. Extract Comae-Toolkit onto your well prepared USB stick and connect it to the computer too analyze.

  4. Open a command line prompt with the option ‘Run as administrator’.

  5. Change directory, depending on the systems architecture:
    cd Z:\comae\x86\

  6. Simply run DumpIt and specify the output file name. A time stamp can support the analyst.
    DumpIt.exe /OUTPUT memory_20201215_1138.bin

  7. Read the texts written on the console and confirm to ‘Proceed with the acquisition’.

  8. Depending on the memory size and the USB stick it can take some time.

  9. Compress the memory dump in an encrypted archive. One way is to use 7-ZIP.

  10. We have to exchange the password out of band, over a secure channel.

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:

    dmesg
    
  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

References

Classification of this document

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

Revision

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