1 / 44

Fundamental Computer Investigation for Windows

Fundamental Computer Investigation for Windows. Barbara Chung, CISSP, CISM Chief Security Advisor, US Ed Microsoft Corporation bchung@microsoft.com. Agenda. Prepare Assess Acquire Analyze Report. Computer Investigation Model. Assess: Initial Decision Making.

marlis
Download Presentation

Fundamental Computer Investigation for Windows

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Fundamental Computer Investigation for Windows Barbara Chung, CISSP, CISM Chief Security Advisor, US Ed Microsoft Corporation bchung@microsoft.com

  2. Agenda • Prepare • Assess • Acquire • Analyze • Report

  3. Computer Investigation Model

  4. Assess: Initial Decision Making • Preventing further damage should be the first concern • Investigation is secondary unless there are national security issues • You may be required to report to authorities: consult with your legal team

  5. AssessEstablish ScopeIdentify Required Resources

  6. Assess • Notify decision makers: • if no written response policies and procedures exist, you should obtain written authorization to conduct the investigation • Document all actions that you take • Priorities*: • Prevent further harm • Restore services (if necessary) • Investigate incident * Absent national security or life safety issues

  7. Assess Review policies and laws that might pertain: • Do you have legal authority? • Internal privacy policies for employees, contractors, others? • Consult with legal regarding: • Possible compromise of personal data • State/federal privacy laws • Criminal/civil liability for improper interception of electronic communications • Viewing sensitive or privileged info

  8. Assess • Customer privacy and confidentiality issues: • All data should be transferred securely, stored locally, not easily accessible. • Maintain data and documentation per local policy or as advised by legal counsel/law enforcement. • Maintain digital copies of evidence, printouts of evidence, and the chain of custody for all evidence, in case of legal action in secure storage.

  9. Assess Identify Investigation Team Members • Ideally the team is established before they are needed. • Assign one technical lead; clarify responsibilities • A small team minimizes risk to confidential data and information leaks • Engage a trusted external investigationteam if you do not have the internalexpertise • Ensure that each team member has thenecessary clearance and authorization

  10. Assess Prioritize your actions and justify resources • Describe the situation, its potential severity, potentially affected parties, and (if available) the suspected party or parties. • Identify the impact and sensitivity of the investigation on your organization. • Analyze the business impact of the incident throughout the investigation. • Analyze affected intangible resources

  11. Assess

  12. Assess Document the scope • Affected networks • The number affected computers and types • Detailed network topology • External storage and remote computers • Capture network traffic if live analysisis required • Be aware of internal policy around the use of network capture tools, be sure you have clearance/authorization. • Examine the state of software applications and OS on machines that may be affected: application logs, system logs, Sysinternalspstools. • Examine affected file and application servers: Sysinternalstools as pstools, psfile, shareenum, internal Windows security logs. • Ensure that volatile realtime data is securely stored.

  13. Assess Best practices • Build a timeline and map everything to it. • Identify and interview anyone who might be involved, such as sysadmins and users • Document interview outcomes • Retrieve info (logs) from internal and externalfacing network devices that might be in theattack path • Identify public IP address and domain ownership (Windows SysinternalsWhois, or the American Registry for Internet Numbers

  14. Assess Prepare for Evidence Acquisition • Detailed document containing: • Initial estimate of impact • Network topology identifying affected systems • Summaries of interviews • Outcomes of legal and third party interactions • Reports and logs generated during assessment phase • A proposed course of action

  15. Acquire the Data

  16. Assess Prepare for Evidence Acquisition • Detailed document containing: • Initial estimate of impact • Network topology identifying affected systems • Summaries of interviews • Outcomes of legal and third party interactions • Reports and logs generated during assessment phase • A proposed course of action

  17. Acquire the Data Build the Toolkit • Core tools and personnel should be identified before they are needed • Make adjustments as needed for the current situation • Tools (such as WOLF where MS PSS is involved) • Personnel

  18. Build the Toolkit • Laptop • H/W and tools used only for the investigation • Storage device is forensically sterile • Different OS and patches • Application media • Backup devices • Blank Media • Basic Networking Equipment • Cables

  19. Build the Toolkit • Proving accuracy of data acquisition tools is generally easier if you use well-known computer forensics software. • The tools must not modify the access time of files.

  20. Build the Toolkit List each OS you will support and ensure you have the necessary tools: • Include a tool to collect and analyze metadata. • Include a tool for creating bit-to-bit and logical copies. • Include tools to collect and examine volatile data, such as the system state • Microsoft Sysinternals • ListDLLs, LogonSessions, PendMoves, Autoruns, ProcessExplorer • Other Windows Tools • Systeminfo, Ipconfig, Netstat, Arp • Dedicated forensics software, for example: • Encase (Guidance Software) • The Forensic Toolkit (FTK) (AccessData) • ProDiscover (Technology Pathways) • Tools should be archived and preserved to allow for future verification of data

  21. Build the Toolkit • Generate checksums and digital signatures on files and other data: the File Checksum Integrity Validator (FCIV) tool. • This tool is available through Microsoft Knowledge Base article 841290, Availability and description of the File Checksum Integrity Verifier utility.

  22. Build the Toolkit: Worksheets and Samples • Link to the Fundamental Computer Investigation Guide for Windows on the Microsoft Download Center • Chain of Custody Log • Impact Analysis Worksheet • Sample Internal Investigation Report • Appendix C. Sample Worksheets in Forensic Examination of Digital Evidence: A Guide for Law Enforcement by the National Institute of Justice, an agency of the U.S. Department of Justice: • Computer Evidence • Hard Drive Evidence • Removable Media

  23. Build the Toolkit: Preparing Personnel • At least part of the team should have some formal investigation training • List of nonprofit agencies, organizations, Federal law enforcement agencies, and academic institutions that provide computer forensic training, see "Appendix G. Training Resources List" in Forensic Examination of Digital Evidence: A Guide for Law Enforcement by the National Institute of Justice, an agency of the U.S. Department of Justice.

  24. Collect the Data • If a machine is infected with a rootkit, it will probably return lots of false information; you must check for this first • Sysinternals’ RootkitRevealer, but there is no single tool or methodology that will answer the question for you. See: • Mark Russinovich’sTechEdvid Advanced Malware Cleaning (chapter on rootkits)

  25. Collect the Data • Collecting data locally offers greater control over computers and data • Remote collection is sometimes necessary

  26. Collect the Data: Process • Create accurate documentation that will allow the data to be identified and authenticated later • Who performed the action and why they did it. What were they attempting to accomplish? • How they performed the action, including the tools they used and the procedures they followed. • When they performed the action (date and time) and the results.

  27. Collect the Data: Process 2. Determine which methods to use • Online only when necessary, since you risk altering original evidence • Use offline methods when possible (uses bit-wise copy of the original data)

  28. Collect the Data: Process • Identify and document potential data sources • Servers: role, logs, files and applications • Logs from internal/external network devices that may be in the path of attack: firewalls, routers, proxy servers, network access servers, IDS systems • Internal hardware components: NICs, PCMCIA cards, external port types such asFirewire, USB, PCMCIA • Storage devices: hard disks, network storage devices, removable media, mobile devices

  29. Collect the Data: Process 4. Collecting Volatile Data • Carefully consider the order in which it is collected

  30. Collect the Data: Process • Collecting Data from Storage Media • Volatile data collection is complete before turning off the computer to remove device? • Remove device and collect data using another computer? • Create a bit-wise copy of the evidence in another location? • Use industry-accepted software, such as EnCase by Guidance Software, or FTK by AccessData • Document internal devices, configuration information, type ofdevice and condition

  31. Collect the Data: Process 6. Verify collected data • Use checksums, digital signatures • You can use the Microsoft File Checksum Integrity Verifier (FCIV) tool to compute an MD5 or SHA1 cryptographic hash of the content of a file

  32. Collect the Data: Store and Archive Best Practices • Physically secure and store in tamper-proof location • Document who has physical and network access to the evidence • Make at least two copies—one stored securely offsite • Ensure evidence is secured bothphysically and digitally • Document chain of custody, with check/in-check/out info

  33. Analyze the Data

  34. Analyze Network Data • Not always necessary • Be prepared for large amounts of data: focus on specific criteria • Examine firewall, proxy server, IDS, remote access server logs • View network sniffs where datamight help identify activities. • Encrypted sessions cannot be viewed, but time of connection,or endpoints may be valuable

  35. Analyze Host Data Host Data • Lots of data, so identify and search for what you are seeking: SysinternalsStrings may be useful • \\Windows\prefetch contains info such as when and where apps were launched • OS Data: clock drift info, data in memory, processes running or scheduledto run (SysinternalsAutoruns) • Running apps, processes, network connections (SysinternalsProcessExplorer, LogonSession,PSFile.)

  36. Analyze the Data: Storage Media • If possible use offline analysis • Create a diagram of the directorystructure • Determine if encryption was used (EFS). See "Encrypting File System in Windows XP and Windows Server 2003" on Microsoft TechNet. • If necessary, uncompress files • Identify files of interest • Use file viewers to view contents

  37. Analyze the Data: Storage Media • File Resources: • Hash sets for well-known software: National Software Reference Library • Filespecs.com • Wotsit’s Format: wotsit.org • ProcessLibrary.com • Microsoft's DLL Help • SysinternalsStreams for Alternate Data Streams • Metadata: Encase by Guidance Software, The Forensic Toolkit (FTK) by AccessData, or ProDiscover by Technology Pathways. • Registry Resources: • Windows Server 2003 Resource Kit Registry Reference • RegEdit, Windows SysinternalsRegMonfor Windows, and Registry Viewer by AccessData

  38. Report

  39. Report: Gather and Organize • Identify parts of the documentation that are relevant to the investigation. • Identify facts to support the conclusions you will make in the report. • Create a list of all evidence to be submitted with the report. • List any conclusions you wish to make in your report. • Organize and classify

  40. Report: Write the Report • Purpose of Report. • Author(s) of Report. • Incident Summary. Introduce the incident and explain its impact. The summary should be written so that a non-technical person such as a judge or jury would be able to understand what occurred and how it occurred. • Evidence • Details: evidence, analysis methods, findings, etc. • Conclusion. • Supporting documents.

  41. Report

  42. Resources • Fundamental Computer Investigation Guide for Windows: http://www.microsoft.com/technet/security/guidance/disasterrecovery/computer_investigation/default.mspx • Windows Sysinternals: http://www.microsoft.com/technet/sysinternals/default.mspx • Channel 9: Mark Russinovich, chat re: Windows Security • Microsoft Windows Security Resource Kit: http://www.microsoft.com/mspress/books/6418.aspx • Microsoft Security Risk Management Guide: http://www.microsoft.com/technet/security/guidance/complianceandpolicies/secrisk/default.mspx

  43. Other Resources • Microsoft Security Awareness Toolkit and Guide

  44. © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

More Related