GOOGLE DESKTOP FORENSICS WIN!

Transcription

1 The Quarterly Magazine for Digital Forensics Practitioners WIN! A STEGALYZER USB FROM SARC ISSUE 15 MAY 2013 INSIDE / Cryptographic Key Recovery / Tunnelling Out: Data Extraction / Fuzzing Risks in Software Tools / Timeline Creation & Review GOOGLE DESKTOP FORENSICS Google desktop use in Digital Forensic examinations Issue 15 / TR Media / REGULARS NEWS, 360, irq, LEGAL & more / INTRODUCING Registry Recon HOW IT WAS DEVELOPED / FROM THE LAB StegAlyzer: DETECTING Steganography IN THE FIELD / Book Reviews Windows Forensic Analysis Toolkit

2 / FEATURE RAISING THE BAR IN WINDOWS REGISTRY FORENSICS Mark Spencer explains the story behind the development of Registry Recon. / INTERMEDIATE The Microsoft Windows Registry ( Registry ) is a complex database containing valuable evidence related to hardware, software, and users. At a very basic level, the Registry is composed of hives that contain keys and values which are similar in some ways to folders and files. The Registry is continually referenced during Windows operation so large volumes of Registry information can always be found both on disk and in live memory. Digital forensics and incident response ( DFIR ) practitioners have been digging into the Registry in various forms for over 20 years. You might be surprised by that given the archaic state of Registry forensics that continues to persist in many ways to this day. I m sure I m not the only member of our community whose pleas to vendors to improve the Registry functionality of their tools went unanswered. Generally speaking, DFIR tools have allowed us to analyse one Registry hive at a time. If we are only concerned with the active Registry, as it exists in a handful of hives on disk, this type of workflow is frustrating but manageable. It quickly devolves into complete insanity if we concern ourselves with the vast number of hives which exist in live memory, swap, hibernation, backups, and unallocated space. Should we be concerned with what often amounts to thousands of hives that exist beyond the active SAM, SECURITY, SOFTWARE, SYSTEM, and NTUSER.DAT/UsrClass.Dat files on disk? Perhaps a better question is, how can DFIR practitioners disregard thousands of hives, case after case? Would you go to a car wash that only cleaned your front bumper? I hope my analogy is so absurd that you consider very carefully what I am asking here. By taking all the hives in a piece of evidence into account, we are able to gain insight into how Registries from both the current and previous installations (to the extent their hives still exist in unallocated space) of Windows have changed over time. / Registry Recon Development I never thought my company would be involved in software development, but we were left with no choice. We decided to develop Registry Recon upon realizing no one else was going to address the fundamental issue that thousands of hives in countless pieces of evidence were being left untapped by existing tools and methodologies. Our first priority was to seamlessly harvest as many hives as possible from a piece of evidence to lay a solid foundation for processing and analysis. This ended up being more difficult than we envisioned, and eventually required building our own image mounter so that Volume Shadow Copies ( VSCs ) could be parsed properly. The end result allows users to simply click Add on a piece of evidence and active, backed up (restore points, VSCs, etc.), temporary (swap) and deleted (unallocated) hives are then ingested into the database. Our second priority involved Hive Association and Registry rebuilding. It was very important to us that regardless of how many hives we found and where we found them, our tool had to be able to connect those hives and rebuild all the Registries they represented in a historical fashion. We had two cases within months of each other which involved IT departments that had re-imaged and re-deployed laptops to new employees, before it became apparent that the former employees would In the pursuit of readability, when I refer to hive in this article I am referring to the files that support hives e.g. SAM, SECURITY, SOFTWARE, SYSTEM, and NTUSER.DAT/UsrClass.dat. Recon Registries 67

3 / FEATURE Recon View be defendants in civil litigation. The amount of time our team had to spend on manually carving and associating hives from unallocated space on these laptops makes me cringe to this day. You could say that programmatically associating hives and rebuilding the Registries they belonged to, was on our minds constantly after dealing with these two cases. Our third priority was the development of additional technologies to facilitate the analysis of the large numbers of hives we knew were waiting for us. We knew that simply putting all of the information contained in these hives in front of users in the traditional ways would be overwhelming and basically dead on arrival. In addition to the hive association and Registry rebuilding I mentioned above, we developed the concepts of Recon View, Instances, and Key History. Recon View is where users view the values contained within keys. By default, we only show the user unique values (based on each value s name and data) in a key over time. We also show the user the date and times associated with each unique value s parent key, as well as the number of times (Instances) we found that value in a piece of evidence. We provide two levels of nesting (Instances) for each unique value; all the times the value is associated with, per all the instances of its parent key, and then a list of all the locations a unique value at a unique time was found. / RegRipper RegRipper (now consolidated on one site google.com/p/regripper/) has an active community building plug-ins to perform various types of analysis on particular hives. RegRipper s author, Harlan Carvey, frequently posts on his Windows Incident Response blog about Registry analysis. I recommend checking out his blog as soon as you are done with this article, particularly topics regarding registry redirection/reflection, malware, and ShellBags. Our users sometimes run RegRipper plugins against hives carved from a piece of evidence by Registry Recon. Key History allows users to see a list of all the times associated with each key in a rebuilt Registry. A user can select a key at a particular time and it will be displayed at is appeared at that time. While we envisioned most of our users would analyse Registry data using the default view which displays unique values in a historical fashion, we knew that we had the ability to show our users keys at particular points in time; so we gave them that option. We also had other priorities, which were not quite as unique as these first three. E.g. we were frustrated by how few tools were able to parse deleted keys within hives, which should have been one of the priorities for any DFIR developer. We were also irritated with databases that were difficult to move between forensic workstations and export options which were not spreadsheet friendly. You will be pleased to find that we have addressed all of these priorities. Can some of these new technologies be a bit obtuse, particularly Instances? Of course! Diving into the intricacies of new technologies often is. The reward for mastering these technologies is very significant, as you will be wielding a very unique and powerful DFIR weapon. / Good Hunting We have found over the years that DFIR practitioners digging into Registry information tend to be most interested in the analysis of document, application, network, USB storage, and malware activities. In the past, analysing a handful of readily accessible Registry hives became relatively standard practice. By taking into account what often amounts to thousands of hives, Registry Recon now provides DFIR practitioners with the ability to see vast amounts of historical Registry information related to these activities. We don t get tired of hearing that our users are reanalysing old cases to learn more about their evidence! As there are constraints related to the size of this article, I ll get into more detail regarding these types of analyses 68 Digital / ForensicS

4 using some sample Windows 7 Registry keys. Please keep in mind that Registry redirection/reflection may come into play with some of these keys e.g. without reviewing the SOFTWARE\Wow6432Node subkeys, you may be left with an incomplete picture of the application and malware activity I discuss below. / Document Activity The RecentDocs key, a/k/a Recently Used Documents, is a well-known location in the Registry related to document activity. While RecentDocs and its subkeys can be quite illuminating, keep in mind there are many other keys you may be interested in as well. Keys containing MRU (Most Recently Used) lists may be particularly helpful to you. MRU lists are maintained by Windows, Office and thirdparty applications. Explorer\RecentDocs Explorer\ComDlg32\OpenSavePidlMRU NTUSER.DAT\Software\Nico Mak Computing\WinZip\mru / Application Activity One of the first things we like to do with Registry analysis is get a feel for what applications have been installed and uninstalled over time. We recommend checking out the root of the Software hive, the Software subkeys in each NTUSER. DAT hive, and the Windows Uninstall and App Paths keys. Something we also like to do early in our Registry analysis is get a feel for which account ran each application and when by reviewing the UserAssist key. Software\ NTUSER.DAT\Software Software\Microsoft\Windows\CurrentVersion\Uninstall Software\Microsoft\Windows\CurrentVersion\App Paths Explorer\UserAssist / Network Activity Our users in law enforcement have been particularly interested in keys related to network connections, and more specifically, wireless network connections. They have always been able to see a variety of details related to the last network their suspects connected to, but now they are able to see network connections over time. In addition to network connections, we are often interested in MRUs related to remote access as well. Interfaces Software\Microsoft\Windows NT\CurrentVersion\ Software\Microsoft\Terminal Server Client\Default NTUSER.DAT\Software\RealVNC\vncviewer\MRU / USB Storage Activity Identifying not only when USB storage devices were last attached to computers, but when they were attached over time, has become very important to our cases involving intellectual property theft. Registry keys related to USB Raw Devices, Disk Devices, Volume Devices and more help us determine when these devices have been attached over time, what their volume names were, and what drive letters they were assigned. Software\Microsoft\Windows Portable Devices\Devices Explorer\MountPoints2 System\MountedDevices / Malware Activity Confirming that malware has been executed on a system may be possible by reviewing the AppCompatCache key. Malware tends to maintain persistence by using Registry keys related to autorun, so these keys may help you spot red flags. AppCompatCache Run Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ System\CurrentControlSet\Control\Session Manager\ KnownDlls USB Storage 69

5 / FEATURE USBOblivion / Registry Scrubbing Registry scrubbing features in tools such as WhiteCanyon s SecureClean and Piriform s CCleaner have been around for many years. These features have targeted Registry keys that are often useful to DFIR practitioners. While this type of scrubbing could be problematic, it has not been catastrophic in the sense that the number of targeted keys has been relatively limited. With the introduction of tools such as USB Oblivion however, particular types of Registry keys are being more carefully targeted. Straight from the USB Oblivion s Google Code site USBOblivion utility designed to erase all traces of USB connected drives and CD-ROMs from the registry in Windows 2000, Windows XP, Windows 2003, Windows Vista, Windows 7, Windows 8 32/64-bit versions. We have done some testing of USB Oblivion at Arsenal, and we can say it is very effective when it comes to the active Registry. Since Registry Recon ingests all the hives from restore points and VSCs, you might think you have defeated Registry scrubbing. To some extent, this is true. I am only aware of one tool with Registry scrubbing functionality (CCleaner) that will also delete restore points. It s only a matter of time however before more of these tools delete not only restore points but volume shadow copies (and other backups) as well. As Registry scrubbing tools become more effective in this regard, ingesting hives from live memory captures and unallocated space will become even more important. / Other Advancements We believe we have improved the state of Registry forensics in some very significant ways, but I am the first to acknowledge that the tool doesn t do everything for everyone. We still have a lot of work to do! Volatility s Technology Preview edition has a regdump module that extracts all the hives from a live memory capture. This is an awesome function and I m not aware of any other tools capable of extracting all the hives from a live memory capture. Registry Recon can ingest these hives once Volatility has extracted them and essentially rebuild the Registry, as it existed in live memory. We have been placing some spreadsheets in the Resources section ( of our website that some of you may be interested in. One set of spreadsheets is related to our Registry Key Mapping project. We are not talking about rocket science here; these spreadsheets simply track the keys added during the installation of particular applications as well as which keys are removed during their removal. We take requests; so if there are any applications you want us to hit please let me know. Another couple spreadsheets we ve published contain all the keys we know of that are related to USB storage devices and autorun functionality. Back to the work that we have to do; our development queue has become quite large. In addition to implementing our own ideas and associated R&D, we have received great suggestions from consultants, law enforcement, and the military. Some of the more straightforward improvements we have in the queue include automatic value decoding, direct support for live memory captures, greatly improving searching, bookmarking, and reporting functionality, and performance tuning. Law enforcement in particular has been interested in more pre-built reports and global shortcuts. Other features in the queue will be a bit more eye opening once we weaponise them. / In Closing Soon, rather than asking why DFIR practitioners are disregarding thousands of hives in case after case, I hope to be talking about how those same practitioners are now harnessing and leveraging them. / / Author Bio Mark Spencer is President of Arsenal Recon, where he leads the development of innovative digital forensics and incident response tools which include Registry Recon. Mark has over 15 years of law-enforcement and private-sector experience in digital forensics. He has been an adjunct professor at Bunker Hill Community College in Boston and an instructor at the Computer Security Institute. Mark is also President of Arsenal Consulting, where his team provides exceptional digital forensics services to law firms, corporations, and government agencies. Arsenal Recon and Consulting are located in the Chelsea Naval Magazine, a historic military structure which once stored arms for the USS Constitution, just outside Boston, Massachusetts. 70 Digital / ForensicS

6