UNIT 3

INT 243: INFORMATION SYSTEM

SECURITY
 Topics to be Covered

• Live Data Collection

• Forensic Duplication
Live Data Collection
 Creating A Response Toolkit
• For an initial response, you need to plan your approach to
obtain all the information without affecting any potential
evidence.

• The best way to meet this goal is to prepare a complete

response toolkit. It consist of:

• Gathering the Tools

• Preparing the Toolkit
 Gathering the Tools

• In all incident responses, regardless of the type of

incident, it is critical to use trusted commands.

• For responding to Windows, we maintain a CD or

two floppy disks that contain a minimum of the tools
listed in Table 5-1.
Nbtstat command
 rmtshare
Syntax Display all shares
RMTSHARE \\server
Display details of a specific share
RMTSHARE \\server\sharename
Share a Folder
RMTSHARE \\server\sharename=drive:path [options]
Share a Printer
RMTSHARE \\server\sharename=printername /PRINTER [options]
Edit an existing SHARE
RMTSHARE \\server\sharename [options]
Delete a SHARE
RMTSHARE \\server\sharename /DELETE

Options
/USERS:number
/UNLIMITED
/REMARK:"text"
/GRANT user:perm
/REMOVE user
 pslist
Process Status, list information about processes running in memory.
Syntax

pslist [-?] [-t] [-m] [-x] [\\computer [-u user]

[-p passwd]] [name | pid]

Options:
Computer: The computer on which the process is running.
Default=local system

-p passwd Specify a password for user (optional).

Passed as clear text. If omitted, you will be prompted
to enter a hidden password.

-u user Specify a user name for login to remote computer

(optional).

-t Show statistics for all active threads on the system,

each thread is grouped with its owning process.
 pslist
-m Show memory-oriented information for each process,
rather than the default of CPU-oriented information.

-x Show CPU, memory and thread information for each

process specified.

Name- Scan only those processes that begin with the

name
process. Thus: pslist exp
will display processes that start with exp...
Explorer,
Export etc

-accepteula Suppress the display of the license

dialog.

-? Display options and units of measurement.

 pslist
The default information listed includes the time the process
has executed, the amount of time the process has executed in
kernel and user modes, and the amount of physical memory
that the OS has assigned the process.When running PsList
against a remote system you must have administrative
rights on that system, and the system must be running the
Remote Registry service
When launched for the first time, PsList will create the regkey
HKCU\Software\Sysinternals\PsList\EulaAccepted=0x01
Examples:

List all processes running on \\workstation64:

C:\> SC \\workstation64 start RemoteRegistry
C:\> pslist \\workstation64
 Preparing the Toolkit
• You need to ensure that your toolkit will function exactly as intended
and not alter the target system.
Several steps are taken to prepare toolkits for initial response:
• Label the response toolkit media
• Case number

• Time and date

• Name of the investigator who created the response media

• Name of the investigator using the response media

• Whether or not the response media (usually a floppy disk) contains output files or evidence from the
victim system

• Create a checksum for the response toolkit

• Write-protect any toolkit floppies
 Storing Information Obtained
During Initial Response
• During your initial response, you will gather a lot of
information from the live system.

• We use the term live to refer to a system that is relevant to an

investigation, whether it is the attacking system or the victim,
and is currently powered on.

• Think of it as the crime scene before photos are taken and

bodies are removed. You are operating in an untrusted
environment, where the unexpected should be anticipated.
Four options are used when retrieving information from a live
system:
• Save the data you retrieve on the hard drive of the target
system.
• Record the data you retrieve by hand in a notebook.
• Save the data you retrieve onto the response floppy disk or
other removable media.
• Save the data you retrieve on a remote “forensic system” using
netcat or cryptcat.
Two ways are:
• Transferring Data with netcat
• Encrypting Data with cryptcat
 Transferring Data with netcat
• netcat is a freely available tool that creates a channel of
communication between hosts.
• We use it during initial response to create a reliable, TCP
connection between the target system and the forensic
workstation used for analysis.

This technique of information gathering promotes two sound

practices:
• It lets you get on and off the target system quickly.
• It allows you to perform an offline review of the information
attained.
 netcat (sending from Kali to windows)
• CMD
• Step 1: //listening
• cd netcat
• nc64 –l –p 8888 > s.mp3(receiving file)
• KALI
• Step 2: //sending
• cd downloads
• netcat (listening ip) 8888 < me.mp3(//file to be
send)
 Netcat for text file
• Step 1: create one file in windows netcat folder eg
abc.txt
• Step 2: KALI(listening)
• #cd downloads
• # netcat –l –p 8888 > xyz.txt(receiving file)
• Step 3: CMD(sending)
• > nc64 <ip of kali> 8888 < abc.txt
• Step 4: check xyz.txt in downloads of kali. It will
have the same content of abc.txt
 netcat

• To send message from Kali to Windows and Vice-

versa
• CMD:
• nc64 –vlp 3333
• (listening)…………..
• KALI:
• nc64 (target ip) 3333
• Write your message here………………..
 dd and dcfldd(defence computer
forensic lab data duplicator)

• 1. dd if=abc.txt of=xyz.txt
• //content of abc will be copied to xyz

• 2. dcfldd if=abc.txt of=xyz.txt hash=md5 sha1

hashlog=hh.log

//single command will duplicate the data and find the

checksum, hash etc
 Encrypting Data with cryptcat

• The drawback of transferring data across a network is that the

data may be visible to network eavesdroppers. Consider
encrypting the traffic using cryptcat.

There are two compelling arguments for encrypting your traffic

when sending files from a target system:

• An attacker’s sniffer cannot compromise the information you

obtain.
• Encrypting the data nearly eliminates the risk of contamination
or injection of data.
 Obtaining Volatile Data
• Now that you have a forensic toolkit and a methodology, you
need to determine exactly which data to collect.
At a minimum, we collect the following volatile data prior to
forensic duplication:
• System date and time
• A list of the users who are currently logged on
• Time/date stamps for the entire file system
• A list of currently running processes
• A list of currently open sockets
• The applications listening on open sockets
• A list of the systems that have current or had recent connections to
the system
 commands
• time /t
• date /t
• doskey /history
• Command to find the Time/date stamps for the
entire file system:
• 1. stat filename
• 2. atime: time of last access (ls -lu)
• 3. mtime: time of last modification (ls -l)
• 4. ctime: time of last status change (ls -lc)
 commands

• How to find what application is listening on a

TCP/IP port in windows using netstat?
• netstat -ab | more
• netstat -aon | more
netstat –rn //The netstat -rn command displays
the system's routing table.
The netstat -a command will display all network
connections
 commands
1. host abc.com //The host command works a lot
like nslookup by looking up the remote system's IP
address, but also provides the system’s mail handler.
• The nslookup also provides information on the system
(in this case, the local system) that is providing DNS
lookup services.
2. $ nslookup abc.com
• Output:

• Server: 127.0.1.1

• Address: 127.0.1.1#53

• Non-authoritative answer:

• Name: abc.com

• Address: 192.74.137.5
For this you need to
• Organizing and Documenting Your Investigation
• Collecting Volatile Data
• Executing a Trusted Cmd.exe
 Organizing and Documenting Your
Investigation
• It’s one thing to have the technical skills required for proper
incident response; it is quite another to implement a complete,
unbiased, professional process.
• You need to have a methodology that is both organized and
documented.

There are two reasons for diligently documenting your actions

when responding at the console of a victim system:
• To gather information that may become evidence against an
individual
• To protect your own organization
 Collecting Volatile Data
• “top-ten” list of the steps to use for data collection:
1. Execute a trusted cmd.exe.
2. Record the system time and date.
3. Determine who is logged in to the system (and remote-access users,
if applicable).
4. Record modification, creation, and access times of all files.
5. Determine open ports.
6. List applications associated with open ports.
7. List all running processes.
8. List current and recent connections.
9. Record the system time and date.
10. Document the commands used during initial response.
• dir /t:a /a /s /o:d c:\ Provides a recursive directory
listing of all the access times on the C: drive

• dir /t:w /a /s /o:d d:\ Provides a recursive directory

listing of all the modification times on the D: drive

• dir /t:c /a /s /o:d e:\ Provides a recursive directory

listing of all the creation times on the E: drive
 Scripting Your Initial Response

• Many of the steps taken during the initial response can be

incorporated into a single batch script.

• We often script our response, and then use netcat to transfer the
results of the script to a forensic workstation. Simply create a
text file and add a .bat extension to it to make it a batch file.
 Performing In-depth Live Response
• Sometimes, your response at the console of a live system needs
to go beyond merely obtaining the volatile information.

• You may need to find evidence and properly remove rogue

programs without disrupting any services provided by the
victim machine.

For this:
• Collecting the Most Volatile Data
• Creating an In-Depth Response Toolkit
• Collecting Live Response Data
 Collecting the Most Volatile Data
• Run the date and time commands to sandwich your response
between starting and ending times. These commands record the
current system time for correlation between system logs and
network-based logging.
• Use PsLoggedOn to see who is currently connected to the
system.
• Use netstat to view current and recent connections on all
listening ports.
• Run PsList to see all the running processes.
• Use Fport to determine which programs have opened specific
ports. If Fport indicates that a rogue process is running, obtain
the rogue process for tool analysis.
• C:\Users\HP>date >date.txt
• C:\Users\HP>time >>date.txt
• C:\Users\HP> date.txt

C:\Users\HP>psloggedOn

• dir /t:a /a /s /o:d c:\ Provides a recursive

directory listing of all the access times on the
C: drive
• dir /t:w /a /s /o:d d:\ Provides a recursive directory
listing of all the modification times on the D: drive

• dir /t:c /a /s /o:d e:\ Provides a recursive directory

listing of all the creation times on the E: drive

• C:\Users\HP>netstat -an
PSLoggedOn
fport
Creating an In-Depth Response Toolkit
 NTlast
• NTLast Developed by Foundstone’s J.D. Glaser, this
is an excellent tool that allows you to monitor
successful and failed logons to a system, if the
system’s Logon and Logoff auditing is turned on.
You will want to look for suspicious user accounts
and remote systems accessing the target system.
• ntlast shows successful logons.
• ntlast –f enumerates failed console logons
• ntlast –r lists all successful logons from remote
systems
• ntlast –f –r shows failed remote logons.
 Collecting Live Response Data

• Two key sources of evidence on Windows NT/2000 systems

are the event logs (if auditing is on) and the Registry on the
target system

• Review the event logs.

• Review the Registry.
• Obtain system passwords.
• Dump system RAM.
 Is
Forensic Duplication Necessary?
• After reviewing the system information you retrieved during
the initial response, you need to decide whether to perform a
forensic duplication of the evidence.
• The forensic duplication of the target media provides the mirror
image of the target system.
• This methodology provides due diligence when handling
critical incidents.
• It also provides a means for having working copies of the target
media for analysis without worrying about altering or
destroying potential evidence.
• Generally, if the incident is severe or deleted material may need
to be recovered, a forensic duplication is warranted.

• Law enforcement generally prefers forensic “bit-for-bit, byte-

for-byte” duplicates of target systems

• It is a good idea to have some policy that addresses when full

duplication of a system is required.
FORENSIC DUPLICATION
 Forensic Duplicates As Admissible
Evidence
• What requirements need to be met by a tool before it becomes a
part of your investigative process?

• The tool or process must ultimately provide you with evidence

that may be presented at a trial.

• In regard to forensic duplicates, the best evidence rule comes

into play. This applies to any information on which the facts of
the case or issues are based.
 What is a Forensic Duplicate?
• A forensic duplicate is a file that contains every bit of
information from the source, in a raw bitstream format.

• A 5GB hard drive would result in a 5GB forensic duplicate. No

extra data is stored within the file, except in the case where
errors occurred in a read operation from the original.
 What Is a Qualified Forensic Duplicate?
• A qualified forensic duplicate is a file that contains every bit of
information from the source, but may be stored in an altered
form.

• Two examples of altered forms are in-band hashes and empty

sector compression.
 What Is a Restored Image?

• A restored image is what you get when you restore a forensic

duplicate or a qualified forensic duplicate to another storage
medium.

• The restoration process is more complicated than it sounds.

 What Is a Mirror Image?

• A mirror image is created from hardware that does

a bit-for-bit copy from one hard drive to another.
 FORENSIC DUPLICATION TOOL
REQUIREMENTS
• The tool must have the ability to image every bit of data on the
storage medium.
• The tool must create a forensic duplicate or mirror image of the
original storage medium.
• The tool must handle read errors in a robust and graceful manner. If
a process fails after repeated attempts, the error is noted and the
imaging process continues.
• The tool must not make any changes to the source medium.
• The tool must have the ability to be held up to scientific and peer
review. Results must be repeatable and verifiable by a third party, if
necessary.
 Creating a Forensic Duplicate of A Hard
Drive
• The most common tools used for obtaining a true forensic
duplicate are built to run in a Unix operating environment

• Duplicating with dd and dcfldd

• Duplicating with the Open Data Duplicator (ODD)
 PERFORMING A DUPLICATION WITH
“dd”
• • In certain situations, duplications will be stored in
a series of files that are sized to fit on a particular
media type (such as CDs or DVDs) or file system
type (such as files under 2.1GB).
• • This is that we call a segmented image. The
following is a bash shell script that will create a true
forensic duplicate of a hard drive and store the
image on a local storage hard drive
 BASH SCRIPT

• #!/bin/bash • # Bash script for duplicating hard

drives with dd • # Set source device name here •
source=/dev/hdc • # Set output file name here •
output_name=/mnt/RAID_1/dd_Image • # Set output
file size here • output_size=2048k; • #### • count=1
• while (dd if=$source of=$output_name.$count
bs=$output_size • count=1 skip=$(($count-1))
conv=noerror,notrunc); • do printf "#";
count=$((count+1)); done • #### • echo "Done. Verify
the image with md5sum."
 Creating A Qualified Forensic
Duplicate Of A Hard Drive
• One of the first things that a beginning examiner must learn is
to never boot from the evidence drive.

• Many items on the evidence media can be altered, starting from

the moment the BIOS executes the boot block on the hard
drive.
• Creating a Boot Disk
• Creating a Qualified Forensic Duplicate with SafeBack
• Creating a Qualified Forensic Duplicate with EnCase