RE: Simple Windows incident response methodology

• Previous message: Curt Purdy: "RE: [ok] Simple Windows incident response methodology"
• Maybe in reply to: Lachniet, Mark: "Simple Windows incident response methodology"
• Next in thread: Harlan Carvey: "RE: Simple Windows incident response methodology"
• Reply: Harlan Carvey: "RE: Simple Windows incident response methodology"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Wed, 9 Jun 2004 10:25:53 -0400
To: <incidents@securityfocus.com>

From various comments:

1) Typo noted on RFC number

2) YES, this is not an assessment methodology that will be easy to
defend in court. The IR engineer should discuss this ahead of time - if
prosecution (and not *understanding*) is the goal, then stop and call
the cops, it is not your problem. However, some limited investigation
(ie, the earlier steps) isn't too terribly intrusive, and if you keep
detailed notes and have a witness to what you do, you might be able to
defend it in court

3) An incident response CD is just a bootable CD with boot disk images
and all the tools you need. Every one is different - at a minimum,
you'd need a DOS boot disk with CD-ROM drivers that runs F-prot, and use
that as your CD's boot image. Then just make sure all the tools you
need are on there.

Mark Lachniet

> -----Original Message-----
> From: Security Guy [mailto:securityguy@dslextreme.com]
> Sent: Tuesday, June 08, 2004 5:47 PM
> To: Lachniet, Mark; incidents@securityfocus.com
> Subject: RE: Simple Windows incident response methodology
>
> I'm stepping into the middle of this, so I may have missed
> this info earlier in the thread. What is the "forensics cd?"
> Is there an example somewhere that I can use in setting up
> one of my own.
>
> - SG
>
> -----Original Message-----
> From: Lachniet, Mark [mailto:mlachniet@sequoianet.com]
> Sent: Tuesday, June 08, 2004 5:48 AM
> To: incidents@securityfocus.com
> Subject: Simple Windows incident response methodology
>
> Metaphorical discussion aside, maybe it would be more
> productive to start with a basic incident response
> methodology and kick it around a little bit.
> I have one that I have used - it is for Windows only, and its
> pretty basic, but maybe it's a starting point. I'll also say
> that it only lists the basic data collection steps, and
> nothing about how to actually anaylze the data - I assume
> that a trained IR engineer will be doing the work.
>
> At risk of some putz flaming or otherwise criticizing me,
> I'll go ahead and post it. At least if everyone who said
> "help me! help me!" on the list submitted the data collected
> below, it would be easier for people to respond.
>
> Disclaimer: Use at your own risk, no warranty expressed or
> implied, IANAL (I Am Not A Laywer), this is not the best
> methodology in the world, and is only a starting point, etc.
> etc. etc. There are better tools out there, and this doesn't
> really take into account crafty rootkits, but in my
> experience, most so called "hacks" aren't much more than
> pubstros and IRC/FTP servers.
>
> Also, note that this assumes you have already made a bootable
> forensic CD with all the software, as well as "known safe"
> command interpreters, etc.
>
> Mark Lachniet
>
> --------8<-------------
>
> Phase I - Preparation (Update forensics toolkit)
>
> 1) Download updated virus signatures for F-prot at
> http://www.datafellows.com/download-purchase/updates_manual.shtml#dos
>
> 2) Download updated versions of Anti-trojan at
> http://www.anti-trojan.net/en/download.aspx
>
> 3) Burn a CD-R version of the Forensics CD and label it with
> date it was created
>
> 4) Obtain as much information as possible ahead of time from
> the victim
> including:
>
> a. Detailed information about the event (email threads, logs,
> screen captures, etc.) b. Target system information (IP
> Address, operating system, patch level,
> hardware)
> c. Target system utilization (is it a running server? Can it
> be taken down?
> Who uses the system, and how can they be contacted?) d.
> Target network configuration (network maps, IP plans) e.
> Target network logging sources (operating system, routers,
> firewalls, IDS, etc.) f. Detailed contact information (phone
> numbers, cell/pager numbers, email addresses, etc.) g.
> Obtain administrator passwords, others as needed to access
> the target systems h. If possible, perform a vulnerability
> assessment on the host ahead of time i. Do research, as
> needed, to prepare for the analysis j. Obtain at least ten
> (10) blank, formatted, unused floppy disks k. Obtain at least
> one pad of paper, pens, etc.
>
> 5) Read RFC 3277 "Guidelines for Evidence Collection and Archiving"
>
> 6) Discuss the situation and goals of the analysis with the
> target's administrative staff
>
> a. Advise the client that you cannot provide legal advice of
> any kind, and that they may wish to involve their legal
> counsel if they feel it is appropriate b. What is the server used for?
> c. What is the criticality of the data on the server?
> d. What is the criticality of data not on the server, but in
> the environment (other servers with critical data that could
> also be hacked) e. When was the problem discovered? Who
> discovered it?
> f. What has been done since that time?
> g. What type of system backups exist? What program were they
> created with?
> Have they been tested? How far back do the backups go?
> h. What is the ideal outcome of this process? Prosecution?
> Concerns with internal employees? Stopping further attacks?
> i. Discuss issues of data preservation (i.e., there are two
> ways to approach the analysis - with a foot print or without.
> With a foot print has a chance of altering critical
> evidence, but is less expensive and can be used on production
> servers. Without foot print means imaging the disk and
> working with a forensic disk analysis tool which is outside
> of the scope of this
> service) j. If legal recourse is strongly desired, discuss
> with the client the need for an additional set of eyes (and
> intials) during the process. If desired, the client will
> need to sit with the forensic analyst at all times, and "sign
> off" on each task that was performed, as it was performed.
> k. Discuss how the incident will be treated with other
> employees - is the analysis a "secret" or is it openly known?
> l. Record the highlights of all information discussed with
> the customer in steps a-j, and re-state them to the client to
> confirm that you are in agreement
>
> Phase II - Data Collection (Manual Analysis on running server)
>
> 1) Perform an external vulnerability assessment a. Full port
> scan, identify all running services b. Perform google
> searches on the DNS name and IP address c. Also check
> black-list and open proxy lists for IP address
>
> 2) Prepare for analysis of volatile information (Floppy Disk analysis)
>
> a. Insert the CD-ROM in the CD-ROM drive b. Label a floppy
> disk with the customer name, date, computer name, IP address,
> your name, and the title "Disc#1". Repeat this labeling
> format for subsequent discs (#2, #3, etc.) c. Insert the
> floppy disk in the floppy drive (if possible, otherwise run
> these steps to a shared directory on your laptop) d. Using
> paper and pen, start your activity log. Title the first page
> with the same information as the floppy disc (customer name,
> date, computer name, IP address, your name).
> Also create the following
> columns:
>
> Date/Time Description Initials
>
> Use this format to record the work that you perform. If the
> customer has
>
> 3) Perform the analysis of volatile information (Floppy Disk analysis)
>
> a. Run the appropriate command interpreter on the CD-ROM.
> For Windows 2000 and 4.0 servers, this will be in 'X:\cmd2k'
> and on Windows 98 will be 'X:\cmd98\command.com'
>
> b. Capture the date and time of the system i. date /t >
> a:\datetime.txt ii.
> time /t >> a:\datetime.txt
>
> c. Record the date and time of the computer, as well as the
> "real" date and time (a reliable clock, etc) in your written
> notes. Note the time delta between system time and "real"
> time. Also note the time zone where the analysis is taking place.
>
> d. Capture information about running processes using pslist:
> i. d:\pstools\pslist -t > a:\pslistt.txt ii.
> d:\pstools\pslist -x > a:\pslistx.txt
>
> e. Capture information about logged on users using psloggedon:
> i. d:\pstools\psloggedon > a:\psloggedon.txt
>
> f. Capture netstat information using netstatp:
> i. d:\netstatp\release\netstatp -a -n > a:\netstatp.txt
>
> g. Capture listening ports to program mappings with fportng i.
> d:\fportng\fport > a:\fport.txt
>
> h. Capture open file handles, first in brief, then in full
> (compressed) i.
> d:\handle\handle > a:\handle.txt ii. d:\handle\handle -a |
> d:\unix\gzip > a:\handle-all.gz
>
> i. Capture file system MAC times:
> i. Insert a new, blank floppy disk
> ii. d:\perl\perl.exe \sfile\sfile.pl -d c:\ | \unix\gzip > a:\sfile.gz
>
> j. Capture AT (command scheduler) information i. at > a:\at.txt
>
> k. Capture NBTstat information:
> i. nbtstat -c > a:\nbtstat.txt
>
> l. Capture 'net' information:
> i. echo Net Accounts: > a:\net.txt
> ii. net accounts >> a:\net.txt
> iii. echo Net File: >> a:\net.txt
> iv. net file >> a:\net.txt
> v. echo Net Session: >> a:\net.txt
> vi. net session >> a:\net.txt
> vii. echo Net Share: >> a:\net.txt
> viii. net share >> a:\net.txt
> ix. echo Net Start: >> a:\net.txt
> x. net start >> a:\net.txt
> xi. echo Net Use: >> a:\net.txt
> xii. net use >> a:\net.txt
> xiii. echo Net User: >> a:\net.txt
> xiv. net user >> a:\net.txt
> xv. echo Net View: >> a:\net.txt
> xvi. net view >> a:\net.txt
>
> m. Create MD5 hashes of operating system files:
> i. C:
> ii. Cd\
> iii. Echo **** C:\ **** > a:\md5.txt
> iv. D:\ircr\md5sum *.* >> a:\md5.txt
> v. Echo **** C:\WINNT **** >> a:\md5.txt vi. Cd\winnt\ vii.
> D:\ircr\md5sum
> *.* >> a:\md5.txt viii. Echo **** C:\WINNT\SYSTEM **** >>
> a:\md5.txt ix.
> Cd\winnt\system x. D:\ircr\md5sum *.* >> a:\md5.txt xi. Echo ****
> C:\WINNT\SYSTEM32 **** >> a:\md5.txt xii. Cd\winnt\system32 xiii.
> D:\ircr\md5sum *.* >> a:\md5.txt
>
>
> 4) Back up large files (Network)
>
> a. Create a data directory on your hard drive i. mkdir c:\data
>
> b. Map a network drive FROM the laptop TO the target server's C:
> i. net use o: \\<<ipaddress>>\c$ /user:administrator *
>
> c. Copy IIS logs to your laptop:
> i. xcopy o:\winnt\system32\LogFiles\*.* c:\data /s/e/v
>
> d. Copy Windows Event logs to your laptop*:
> i. xcopy o:\winnt\system32\config\*.evt c:\data /s/e/v
>
> e. Copy any suspicious materials to your laptop. Items to
> consider may include the contents of FTP directories, HTML
> files, log files, suspicious application software, etc.
>
> 5) Scan the target for viruses and Trojans (if possible, boot
> to boot CD to do this)
>
> a. Run F-Prot from the CD-ROM drive:
> i. d:\f-prot\f-prot /hard > a:\fprot.txt
>
> b. Install and run Anti-Trojan on the investigator's laptop
> i. Ensure that the "Remove found Trojans" check box is
> UN-checked ii. Run a "filescan" scan of the mapped O: drive
>
> 6) Identify and analyze other sources of information,
> including e-mail, firewalls, routers, switches, etc. to
> locate additional information about the event
>
> 7) Run 'dumpreg' to dump the Windows Registry to disk
> (optional - to find installed software by date of registry entry)
>
> 8) Run 'filemon' to monitor ongoing file accesses (optional -
> if you believe the system is actively being used by hackers,
> or want to track suspicious system activity)
>
> 9) Run 'regmon' to monitor ongoing registry accesses
> (optional - if you believe the system is actively being used
> by hackers, or want to track suspicious system activity)
>
> 10) Run 'tdimon' to monitor ongoing TCP/IP activity (optional
> - if you want to track TCP/IP activity by process)
>
> Phase III - Data Analysis
>
> 1) Analyze collected data (TBD)
> 2) Additional follow-up as needed
>
> Phase IV - Author and Deliver Report
>
> 1) Using provided template, author an incident response report
> 2) Present the report to the client
> 3) Discuss findings, limitations, next steps
>
>
>

• Previous message: Curt Purdy: "RE: [ok] Simple Windows incident response methodology"
• Maybe in reply to: Lachniet, Mark: "Simple Windows incident response methodology"
• Next in thread: Harlan Carvey: "RE: Simple Windows incident response methodology"
• Reply: Harlan Carvey: "RE: Simple Windows incident response methodology"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]