ITSC 306:

Computer
Forensics
Module 3: Live Response
Module Readings

• Incident Response & Computer Forensics: Third

Edition
◦ Chapter 7: Live Data Collection
• Command-line reference A-Z (https://technet.
microsoft.com/en-ca/library/bb490890.aspx)

© 2017, Southern Alberta Institute of Technology 2

Incident Response Defined

Incident Response is a set of procedures for an

investigator to examine a computer security incident.
This process involves figuring out what has happened
and preserving information related to those events.
Because of the fluid nature of computer investigations,
incident response is more of an art than a science.

(Incident Response, n.d.)

© 2017, Southern Alberta Institute of Technology 3

What is Incident Response?

Incident response is a coordinated and structured approach to go

from incident detection to resolution. Incident response may
include activities that:

• Confirm whether or not an incident occurred

• Provide rapid detection and containment
• Prevent a disjointed, noncohesive response
• Determine and promote facts and actual information
• Minimize disruption to business and network operations

(Luttgens, Pepe and Mandia, 2014)

© 2017, Southern Alberta Institute of Technology 4
Exploitation Life Cycle

• Reconnaissance
• Initial Intrusion into the Network
• Establish a Backdoor into the Network
• Obtain User Credentials
• Install Various Utilities
• Privilege Escalation/Lateral Movement/Data Exfiltration
• Maintain Persistence

(Source: Luttgens, Pepe and Mandia, 2014)

© 2017, Southern Alberta Institute of Technology 5

Incident Response

• The potential loss of valuable information if we shut

the system down prior to gathering the volatile
information overrides the concern of altering data on
the system
• Requirement: Document everything you do prior to
pulling the plug
• There are several ways to gather the information:
◦ Open source or commercial tools
◦ Build your own live response toolkit using open source/free
software and scripting the use of the tools

© 2017, Southern Alberta Institute of Technology 6

IR – Forensic Process

Data Collection Data Processing

Minimize
Host-Based Data
• Live Data
• Forensic Duplications

Network-Based Review Review

Information Information Relevant
Data Information

Other Data

© 2017, Southern Alberta Institute of Technology Leads

© 2017, Southern Alberta Institute of Technology 7

Incident Response Process

• Prepare: The incident response process starts with preparation. You don’t want to figure it out
while dealing with an incident which includes creating your Computer Incident Response Team
(CIRT).
• Identify: Is this a real incident?
• Contain: Limit the impact of the incident by controlling the scope and magnitude
• Eradicate: Eliminate or mitigate the threat
• Recover: Return to the pre-incident state
• Lessons Learned: Determine what did and didn’t work during the incident. Keep what did work
and fix what didn’t. This becomes part of the preparation for the next incident.

Lessons
Prepare Identify Contain Eradicate Recover
Learned

© 2017, Southern Alberta Institute of Technology 8

CIRT Team Membership

Includes identification of core incident responders (typically

corporate security) as well as ancillary members from supporting
organizations. Participants may include:
• Network Operations • Business Line Managers
• Desktop/Server Support • Human Resources
• Application Representatives • Public Relations
• Internal and External Legal Counsel • Executive Management
• Compliance Officers • Other SMEs as required
• Privacy • Third Party Specialists

© 2017, Southern Alberta Institute of Technology 9

Initial Incident Response by Investigators

• Understand how cyber attacks occur

Cyber Attack ◦ How Windows and Unix systems are attacked
• Understand how to collect the data/evidence
◦ Live data collection
◦ Forensic duplication
Data Collection ◦ Network surveillance
◦ Interviews
• Understand how to interpret the data/evidence
◦ Host-based evidence
◦ Network-based evidence
Forensic Analysis
◦ Other evidence
© 2017, Southern Alberta Institute of
Technology

© 2017, Southern Alberta Institute of Technology 10

Live Response

• In Computer Forensics, we usually look at files on a

system after we have imaged the device using a write
block device
• There are instances when we have to look at files on a
system before making the image, such as:
◦ During the Incident Response (IR) of a network breach
◦ Triaging a system during a criminal investigation

© 2017, Southern Alberta Institute of Technology 11

When to Perform a Live Response

• Is there reason to believe that the volatile data

contains information that is vital to the investigation
that is not available elsewhere?
• Are there a large number of systems to be analyzed,
making forensic duplication impractical?
• Are there legal considerations making a full forensic
duplication unwise?
• Will making forensic duplications take an excessive
amount of time or possibly fail?

(Luttgens, Pepe and Mandia, 2014)

© 2017, Southern Alberta Institute of Technology 12
Possible Issues with a Live Response

• Have you tested the live response tool on a similar

platform?
• Is the system particularly sensitive to performance
issues?
• If the system crashes, what is the impact?
• Have you communicated with all of the stakeholders
and received their approval?
◦ Consider getting it in writing

(Luttgens, Pepe and Mandia, 2014)

© 2017, Southern Alberta Institute of Technology 13
Collection Best Practices

• Document what you • Collect in order of

do and when you volatility
do it
• Treat collected data as
• Get on and off the evidence
system quickly
• Consider any credentials
• Use tools that you use as lost to the
minimize impact on attacker
the target system
• Minimize modifications to
• Fully automate the suspect computer
process

(Luttgens, Pepe and Mandia, 2014)

© 2017, Southern Alberta Institute of Technology 14
Collecting Volatile Data

• RFC 3227 contains the Guidelines for Evidence

Collection and Archiving which is used as the basis of
our Live Response process
• Among the contents of this document is the Order of
Volatility (or OOV) which specifies the order in which it
is suggested you collect data based on the volatility of
the data

© 2017, Southern Alberta Institute of Technology 15

Breaking from Tradition

• There is a common belief that there is not sufficient

forensic information contained within the CPU cache
and register contents to merit the effort required to
acquire the data
• The remaining volatile data is invaluable to an
investigation

© 2017, Southern Alberta Institute of Technology 16

Volatile Information

• Volatile Information Includes:

◦ Memory
◦ Open TCP/IP Ports
◦ Running Processes
◦ Running Services
◦ Open Files
◦ Processes Opening TCP/IP Ports
◦ Network Interface Information
◦ Routing Table

© 2017, Southern Alberta Institute of Technology 17

Building a Live Response Toolkit

• Typically run from a DVD or USB Drive

• Should be scripted and run from a single command
• “Known Good” copies of any commands from the basic
operating system should be copied to the toolkit as
well as a “Known Good” copy of the cmd.exe file.
• Remember to add any required DLLs or other system
files for the commands you will be running.

© 2017, Southern Alberta Institute of Technology 18

CMD.EXE Internal Commands

• Some commands are internal to the cmd.exe command

shell, such as date and time.
• When running the date and time commands during
your live response add the /t switch, which causes the
command not to ask for date or time input.
• This makes the command non-interactive and will not
require any input to move onto the next command in
the LRK script.

© 2017, Southern Alberta Institute of Technology 19

System Date and Time

• Once we have the system’s date and time information,

we need to:
◦ Determine the system’s offset from actual date and time
◦ Show date/time offset when comparing system information
when multiple systems are involved in the investigation
◦ Show in investigative documentation what date/time the live
response started and finished

© 2017, Southern Alberta Institute of Technology 20

Windows Tools To Consider Including
Microsoft Utilities Windows Sysinternals…
• date • psloggedon / logonsessions
• netstat • autoruns
• tlist / tasklist • psloglist
• handles
• nbtstat
• at / schtasks Other Apps
• ipconfig • cports / openports
• arp
Extra Utilities
• regdump • dd
• LogParser • UnxUtils zip
• UserDump • md5sum
• nc (netcat)
Windows Sysinternals
• psservice
• psfile
• psinfo

© 2017, Southern Alberta Institute of Technology 21

Standard Live Response Summary

• Load Live Response Kit (LRK) on victim

◦ May be an external USB hard drive or a DVD
• Open Trusted Command Shell from the LRK
◦ Run as Administrator
• Address external storage path
◦ Do this within the response script
• Run the response script

© 2017, Southern Alberta Institute of Technology 22

Scripting the Live Response

• Automation is necessary
◦ Eliminate errors due to typing
◦ Consistent data from multiple systems
◦ Work smarter, not harder
• Use batch scripting
• Your scripts can be as simple or complex as you have
the time to invest in their creation
• IMPORTANT: Test your scripts before you need them

© 2017, Southern Alberta Institute of Technology 23

Scripting Your Toolkit

@echo off
hostname > tmphost
set /p hostvar= < tmphost
del tmphost
t_dumpit /T RAW /Q /N /O Results/%hostvar%.mem
echo ******************************************
echo Windows 7 Live Response
echo ******************************************

echo ******************************************** >> Results/%hostvar

%.txt
date /t >> Results/%hostvar%.txt
time /t >> Results/%hostvar%.txt
© 2017, Southern Alberta Institute of Technology 24
Storing Live Response Output

• Do not write to the victim machine’s hard disks

• Responder’s machine
◦ netcat
◦ cryptcat
• USB device
◦ Exercise caution
◦ Inserting USB device causes registry and other activity on
Windows systems
◦ Might crash the victim machine
 NT 4.0 very unstable in regard to USB devices

© 2017, Southern Alberta Institute of Technology 25

Mandiant’s Redline

The easy way to construct a live response kit

Source: Redline, 2017.

Reproduced and used in accordance with SAIT’s Fair Dealing Policy (Schedule A Copyright and
External Materials Procedure AC.2.12.1); further distribution may infringe copyright.

© 2017, Southern Alberta Institute of Technology 26

Redline

• Automates the
collection of
volatile data
• Collects other
information as
well

Source: Redline, 2017.

Reproduced and used in accordance with SAIT’s Fair Dealing Policy (Schedule A Copyright and
External Materials Procedure AC.2.12.1); further distribution may infringe copyright.

© 2017, Southern Alberta Institute of Technology 27

Create a Comprehensive Collector

• Edit your script

• Browse to where
you are going to
save the file

Note: Can be used

internally but you must
contact Mandiant
before use for third
parties.

Source: Redline, 2017.

Reproduced and used in accordance with SAIT’s Fair Dealing Policy (Schedule A Copyright and
External Materials Procedure AC.2.12.1); further distribution may infringe copyright.

© 2017, Southern Alberta Institute of Technology 28

Pick Your Poison

• This is the menu

that allows you to
create a collector
or analyze a
collection.

Source: Redline, 2017.

Reproduced and used in accordance with SAIT’s Fair Dealing Policy (Schedule A Copyright and
External Materials Procedure AC.2.12.1); further distribution may infringe copyright.

© 2017, Southern Alberta Institute of Technology 29

Indicators of Compromise (IOC)
• Collected from host- and network-based signatures used to
identify malware-related activity
◦ During incident response, malware is detected and then analyzed to
develop signatures (e.g., MD5, path, file name and size, strings)
◦ These signatures are then used to create IOC
◦ Systems suspected of being compromised have the signatures run against
them to determine if the same or similar malware is on the system.
◦ The signatures can be run using a standalone product, such as Mandiant’s
Redline, or an enterprise tool like Mandiant’s MIR.

© 2017, Southern Alberta Institute of Technology 30

 Editing Your Script - Memory

• Allows the user to

choose which parts of
memory to collect
• Items such as strings
will take longer to
collect and greatly
increase the size of the
collection
• Allows user to pick
which hashing algorithm
they want to use.
Source: Redline, 2017.
Reproduced and used in accordance with SAIT’s Fair Dealing Policy (Schedule A
Copyright and External Materials Procedure AC.2.12.1); further distribution may
infringe copyright.
© 2017, Southern Alberta Institute of Technology 31
 Edit Your Script - Disk

• User needs to Consider

the size of the collection
and the time required to
collect it.
• Some options require the
computer to have an
Internet connection.

Source: Redline, 2017.

Reproduced and used in accordance with SAIT’s Fair Dealing Policy (Schedule A
Copyright and External Materials Procedure AC.2.12.1); further distribution may
infringe copyright.

© 2017, Southern Alberta Institute of Technology 32

 Edit Your Script - System

• This section allows for

gathering information about
the computer and its users.
• Also gathers information
from the Registry, Restore
Points and Event Logs
• Analyzes the system’s
Prefetch files

Source: Redline, 2017.

Reproduced and used in accordance with SAIT’s Fair Dealing Policy (Schedule A
Copyright and External Materials Procedure AC.2.12.1); further distribution may
infringe copyright.

© 2017, Southern Alberta Institute of Technology 33

 Edit Your Script - Network

• Gathers information about

network traffic and internet
history

Source: Redline, 2017.

Reproduced and used in accordance with SAIT’s Fair Dealing Policy (Schedule A
Copyright and External Materials Procedure AC.2.12.1); further distribution may
infringe copyright.
© 2017, Southern Alberta Institute of Technology 34
 Edit Your Script - Other

• This section looks at the

services and tasks running
on the system.
• Also looks for persistence
mechanisms for malware

Source: Redline, 2017.

Reproduced and used in accordance with SAIT’s Fair Dealing Policy (Schedule A
Copyright and External Materials Procedure AC.2.12.1); further distribution may
infringe copyright.
© 2017, Southern Alberta Institute of Technology 35
 Edit Your Script – Advanced Parameters

• Each section allows the user

to configure some advanced
parameters.
• This allows the user to be
more granular in what is
being collected.

Source: Redline, 2017.

Reproduced and used in accordance with SAIT’s Fair Dealing Policy (Schedule A
Copyright and External Materials Procedure AC.2.12.1); further distribution may
infringe copyright.
© 2017, Southern Alberta Institute of Technology 36
 Completed Collection Package

• Closing the dialogue

box takes you back to
the start screen.
• Use a portable hard
drive to store all of your
collections in one place.

Source: Redline, 2017.

Reproduced and used in accordance with SAIT’s Fair Dealing Policy (Schedule
A Copyright and External Materials Procedure AC.2.12.1); further distribution
may infringe copyright.

© 2017, Southern Alberta Institute of Technology 37

Contents of the Folder

• Run the File

“RunRedlineAudit” from
an Administrator
Command Prompt.
• Will work with 32 and 64
bit operating systems

Used with permission from Microsoft.

© 2017, Southern Alberta Institute of Technology 38

Redline Analysis Home Page

Source: Redline, 2017.

Reproduced and used in accordance with SAIT’s Fair Dealing Policy (Schedule A Copyright and
External Materials Procedure AC.2.12.1); further distribution may infringe copyright.

© 2017, Southern Alberta Institute of Technology 39

Redline - Analysis

Source: Redline, 2017. Reproduced and used in accordance with SAIT’s Fair Dealing Policy
(Schedule A Copyright and External Materials Procedure AC.2.12.1); further distribution may
infringe copyright.

© 2017, Southern Alberta Institute of Technology 40

Summary

• A live response is often a critical part of the incident

response process
• Used to gather volatile data which will be lost once the
system is shut down
• Goal is to gather the evidence while creating as few
changes as possible to the system in the process
• Use commercial, open source toolkits or create your
own toolkit
• Script the process to minimize interaction with the
system and ensure consistency of the tools run during
live response
© 2017, Southern Alberta Institute of Technology 41
References

1.FireEye. (2012). IOC Editor (Version 2.2) [Computer

software]. Retrieved from
https://www.fireeye.com/services/freeware/ioc-
editor.html.
2.FireEye Incident Response. (n.d.). Retrieved Sep. 26,
2017 from http://forensicswiki.org/wiki/
Incident_Response
3.IOC Bucket. (2013). Retrieved from
https://www.iocbucket.com/iocs/9cec8b496b4111051b
c71c6d1fe1bf5cbcdc3f27

© 2017, Southern Alberta Institute of Technology 42

References

1.Luttgens, J. T., Pepe, M. and Mandia, K. (2014). Incident

response & computer forensics (3rd ed.). Toronto:
McGraw Hill.

© 2017, Southern Alberta Institute of Technology 43

© 2017, Southern Alberta Institute of Technology. All rights reserved.
This publication and materials herein are protected by applicable intellectual property laws. Unauthorized reproduction and distribution of this publication in whole or
part is prohibited.

For more information, contact:

Director, Centre for Instructional Technology and Development
Southern Alberta Institute of Technology
1301 16 Ave. N.W., Calgary, AB T2M 0L4