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?

8. Default settings-NTFS, change journal.

9. Recycle Bin, no info2.

10. Built in volume and disk wiping.

11. SuperFetch & prefetch files.

12. Profile based thumbcaches.*

13. Office file format changes .docx, .pptx, .xlsx.

14. New Office files—InfoPath, Grove, OneNote.

15. EFS encrypted pagefile.

16. Windows 2008 Hyper-V.

17. Built in Defender.

18. Changed location of boot sector.

19. BitLocker, unlocking, imaging, preservation.

20. EXFAT. Transactional NTFS.

21. Event Logging changed.

22. New format-.evtx.

23. New system for collecting and displaying events.

24. New security event numbering.

25. New directory tree for account profiles.

26. Symbolic links. “Virtual” folders.

27. “Virtual” registries.

28. Volume Shadow Copies and difference files.

29. User Account Control.

31. Updated BitLocker, multiple volumes, Smartcard keys, not backwardly compatible.

32. BitLocker To Go.

33. Virtual Hard drives—Boot from, mount as “Disks.”

34. Virtual PC—integrated into the OS.

35. XP Mode.

36. Flash Media Enhancements.

37. Libraries, Sticky Notes, Jump Lists.

38. Service and Driver triggers.

39. Fewer Services on default startup.

40. I.E. 8, InPrivate Browsing, Tab and Session Recovery.

41. Changes in Volume Shadow Copy behavior.

42. New registry-like files.

43. Different WebDAV.

44. More x64 clients. X64 Windows 2008 R2 (server).

45. Changes in Hyper-V.

46. Office 2010 file format changes—OneNote.

47. Thumbnail Cache.

48. Virtual Servers, thin clients.

49. Direct Access (IPSec).

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.

56. Forensics in Incident Response.

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

59. Forensics in Incident Response Compare memory dumps to self-reported information.

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.

66. Forensics in Incident Response

67. Forensics in Incident Response

68. Forensics in Incident Response

69. Forensics in Incident Response

70. Forensics in Incident Response

71. Forensics in Incident Response

72. Forensics in Incident Response

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.

82. Forensics in Incident Response

83. Forensics in Incident Response Cache folders

84. Forensics in Incident Response Recovery folders

85. Forensics in Incident Response Recover file

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.

87. Forensics in Incident Response

88. Forensics in Incident Response Prefetch internals parsed.

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

91. Forensics in Incident Response

92. Forensics in Incident Response

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.

95. Forensics in Incident Response Events and other logs.

96. Forensics in Incident Response Events and other logs.

97. Forensics in Incident Response Events and other logs.

98. Q&A

99. © 2011 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.