2. If a Bear Breaks into Your Computer, and No One Is There to See It, Does It Leave A Clue? Incident Response, Forensics, and Looking for Bear Tracks. Troy Larson, Principal Forensics Program ManagerNetwork Security—Investigations March 29, 2011
3. About This Presentation Overview Some forensic fundamentals. Dissecting Windows 7 for malware, compromise and intrusions.
4. What is Digital Forensics? The identification, preservation, collection, analysis, examination, . . . , and presentation of digital data in a reliable manner. To collect admissible evidence. Authentication. Complete. To answer questions about data or files. Metadata. Context. To determine what has occurred on a system.
5. Digital Forensics in the Enterprise At least two general types of forensics work: Content focused. Find email, documents, graphics, or other types of files that match some criteria. eDiscoveryand litigation support. Activity focused. Determine what somebody or something did on a computer system. Unauthorized activity. Malware. Compromise or intrusion.
6. Digital Forensics in the Enterprise When trust is questioned. Can this _______ still be trusted?
51. Forensics in Incident Response Incident response immediate goals: Technical assessment—what happened, when, how, etc.? Risk assessment—what systems or data at risk? Containment. Incident Response end goals: Remediation. Compliance. Prevention. Prosecution or litigation.
52. Forensics in Incident Response Applications RAM Processes Services Drivers Ports Network OS Artifacts File Systems Fvevol.sys Partition & Volume Managers Disk
53. Forensics in Incident Response Digital vivisection —collecting “live” data from a Windows system to determine what happened, when, and how. Memory dump. Processes. Services. Drivers. Logged on users. Ports. System reports on itself.
54. Forensics in Incident Response Digital autopsy—dissecting an offline Windows system to determine what happened, when, and how. File systems and file metadata. File signatures. Registry. Shell: links, jump lists. Wininet. Prefetch. Shadow Copies. Event and other logs.
55. Forensics in Incident Response Digital forensics heuristics. Any action on a computer changes something. Memory—programs, drivers, data, etc. Media—files and metadata. This includes the actions of incident responders. Not all changes persist, and those that do don’t have to persist forever. Data preservation should generally follow the order of volatility. There are rules governing the ways things work on any platform. Win32 APIs, NTFS, Security, etc. These rules generate artifacts—indicators of compromise.
57. Forensics in Incident Response Digital forensics practical heuristics. Compare memory dump to Windows own self-reporting. Compare memory dump and self-reports to on disk sources. Identify unknown files, mismatched files, and packed executables. Examine ASEPs for unexpected items. Examine Shell and Wininet data for indicators and correlations. Examine prefetch files for program launches and dependencies. Difference shadow copies to identify hidden files and infection times. Review event and other logs, particularly those reporting on states of applications and system.
58. Forensics in Incident Response Memory dumps Sometimes, it is easy. All Microsoft code should have symbols.* 8d793000 8d79d000 nsiproxy (private pdb symbols) C:ebuggersymsiproxy.pdb05F47CD56124B77BD71E3DFB669D4FF1siproxy.pdb 8d79d000 8d79e680 msvmmouf (private pdb symbols) C:ebuggersymsvmmouf.pdb234775836E14C2B869818BF740FE8DE1svmmouf.pdb 8d79f000 8d7a9000 mssmbios (private pdb symbols) C:ebuggersymssmbios.pdb9453B9B745D45DE974BA45D910B78481ssmbios.pdb 8d7a9000 8d7ab980 mrxnet (no symbols) 8d7ac000 8d7b0d80 mrxcls (no symbols) 8d7b1000 8d7bd000 discache (private pdb symbols) C:ebuggersymiscache.pdbF3066C30EA34CC381D3006454C11BD11iscache.pdb 8d7bd000 8d7ca000 CompositeBus (private pdb symbols) C:ebuggersymompositeBus.pdb0E80E78F49541FDB4CF0AEB667653381ompositeBus.pdb 8d7ca000 8d7dc000 AgileVpn (private pdb symbols) C:ebuggersymgileVpn.pdb9ABC733237047E898B7404203D52EDE1gileVpn.pdb 8d7dc000 8d7f4000 rasl2tp (private pdb symbols) C:ebuggersymasl2tp.pdbF6760EF4A3149DC9C430CE8A37585B12asl2tp.pdb http://www.reconstructer.org/papers/Hunting rootkits with Windbg.pdf
60. Forensics in Incident Response Compare memory dumps and self-reported information to on disk sources.
61. Forensics in Incident Response Memory dumps and self-reported information should be examined for the unknown. Unknown processes. Unknown services. Unknown drivers. Unknown ports. Etc. Which unfortunately begs the question, what is unknown? Good to build familiarity. Baseline.
62. Forensics in Incident Response To the media: Identify and exclude known good files. Industry standard: MD5 hash values of the operating system and application files.
63. Forensics in Incident Response Known good file hashes? http://www.nsrl.nist.gov/ Make as needed, based on standard load images, patched and updated as needed. Pre-incident shadow copies. (Technically, not “known good,” but good enough to use for finding new, potentially bad files.)
64. Forensics in Incident Response Recovery and scan of all files. Undelete. Check the file signatures for all files to identify mismatched signatures. Also known as a file signature/extension comparison. Scan for binaries with “packed” code.
65. Forensics in Incident Response Using file system date and time information: Follow an event of interest (this is the starting point). Sort on created dates and times. This is when files came to exist on the media. Sort on last modified dates and times. This is when files where last written to. Sort on entry modified (NTFS) for any changes in metadata or named streams. Correlate—for each important finding, examine contemporaneous events. Especially important on exploits and downloaders. Cross check date and time of significant files by comparing date and time from standard attributes to those in the name attribute. Corroborate event times with corresponding events. E.g., event logs, internal metadata, shadow copies. Build a time line.
73. Forensics in Incident Response Examine the registry for ASEPS: Auto-start Extensibility Points. http://www.usenix.org/event/lisa04/tech/full_papers/wang/wang.pdf Autoruns, either online or offline. http://technet.microsoft.com/en-us/sysinternals/bb963902
74. Forensics in Incident Response When user activity may have contributed to the infection or compromise: Registry “MRU” lists.
75. Forensics in Incident Response When user activity may have contributed to the infection or compromise: Registry, UserAssist. Ntuser.dat. Usrclass.dat.
76. Forensics in Incident Response When user activity may have contributed to the infection or compromise: Shell artifacts: Link files (also known as shortcuts).
77. Forensics in Incident Response When user activity may have contributed to the infection or compromise: Shell artifacts: A malformed link file.
78. Forensics in Incident Response The link points to a file, ~wtr4141.tmp, which is this:
79. Forensics in Incident Response When user activity may have contributed to the infection or compromise: Shell artifacts: Jump lists.
80. Forensics in Incident Response When user activity may have contributed to the infection or compromise: Shell artifacts: Jump lists.
81. Forensics in Incident Response Wininet: Internet history. Can expose browser exploit URLs and downloads. Can indicate intruder downloads. First appearance of intruder tools in the history and cache for the Default account. Multiple data sources: Internet history files (index.dat), and all fragments or deleted history files. Browser cache folders. Recovery files. Jump lists.
86. Forensics in Incident Response Records of programs being run, and their dependencies, are found in prefetch files. indowsrefetch The existence of a prefetch file indicates that the application named by the prefetch file was run. The creation date of a prefetch file can indicate when the named application was first run. The modification date of a prefetch file can indicate when the named application was last run. Prefetch file internals show last launch time, number of times run, and files called during launch.
89. Forensics in Incident Response Shadow copies. Snapshot of a volume at point in time. Can show files added, modified, or deleted over time.
90. Forensics in Incident Response Shadow copies. Can be mounted as volumes, for scanning. The command string below will mount expose each shadow copy on a volume as a symbolic link. This command will follow each symbolic link and produce a file list of all files in the shadow copy. for /f "tokens=4" %f in ('vssadmin list shadows ^| findstr GLOBALROOT') do @for /f "tokens=4 delims=quot; %g in ("%f") do @mklink /d %SYSTEMDRIVE%g %fbr />for /f "tokens=1" %f in ('dir C:/B /A:D ^| findstr HarddiskVolumeShadowCopy') do @dir C:f /B /O:N /S > E:f-fileList.txt
93. Forensics in Incident Response Differencing shadow copies file lists makes malware files stand out:
94. Forensics in Incident Response Events and other logs. Often not the best entry point into an investigation. System event log can show problems impacting system components. Unexpected shutdowns Port reassignment. Application logs can show problems impacting various applications. Unexpected terminations. Errors and failures. Value of the security event log depends on auditing policy settings. Can be noisy.
