Malware forensics field guide for windows systems

Eoghan Casey is a professor of Digital Forensic Science and Investigation in the School of Criminal Sciences at the University of Lausanne. For nearly two decades, he has dedicated himself to advancing the practices of digital forensics and intrusion investigation. He has extensive experience working in digital forensic laboratories in the public and private sectors, and he has analyzed many types of digital evidence to support complex cases. He has consulted with many attorneys, agencies, and police departments in the United States, South America, and Europe on a wide range of digital investigations, including fraud, violent crimes, identity theft, and on-line criminal activity. He has delivered expert testimony in civil and criminal matters, and has submitted expert reports and prepared trial exhibits for computer forensic and cyber-crime cases. He has helped organizations investigate and recover from security breaches, including network intrusions with international scope. He has helped develop new capabilities for extracting and analyzing digital evidence, including smartphones and networks.

In his former role as Chief Scientist of the Defense Cyber Crime Center (DC3), which houses one of the largest accredited digital forensic laboratories in the world, Dr. Casey prioritized research and development across multiple organizational units, and provided strategic and technical guidance to navigate evolving challenges in digital forensics and intrusion investigation. Dr. Casey also contributed directly to DC3 operations, performing advanced technical analysis of multi-faceted problems in order to determine the root cause and provide rational explanations supported by digital evidence.

Dr. Casey wrote the foundational book Digital Evidence and Computer Crime, now in its third edition, and he created advanced smartphone forensics courses taught worldwide. He has also coauthored several advanced technical books including Malware Forensics, and the Handbook of Digital Forensics and Investigation. Since 2004, he has been Editor-in-Chief of Digital Investigation: The International Journal of Digital Forensics & Incident Response, publishing cutting edge work by and for practitioners and researchers. He serves on the Digital Forensic Research Workshop (DFRWS) Board of Directors and helps organize biannual digital forensic research conferences. He also contributes to forensic science definitions, guidelines, and standards as Executive Secretary of the Digital/Multimedia Scientific Area Committee (DMSAC) of the Organization for Scientific Area Committees (OSAC).​

Book description

Malware Forensics Field Guide for Windows Systems is a handy reference that shows students the essential tools needed to do computer forensics analysis at the crime scene. It is part of Syngress Digital Forensics Field Guides, a series of companions for any digital and computer forensic student, investigator or analyst. Each Guide is a toolkit, with checklists for specific tasks, case studies of difficult situations, and expert analyst tips that will aid in recovering data from digital media that will be used in criminal prosecution.

This book collects data from all methods of electronic data storage and transfer devices, including computers, laptops, PDAs and the images, spreadsheets and other types of files stored on these devices. It is specific for Windows-based systems, the largest running OS in the world. The authors are world-renowned leaders in investigating and analyzing malicious code. Chapters cover malware incident response — volatile data collection and examination on a live Windows system; analysis of physical and process memory dumps for malware artifacts; post-mortem forensics — discovering and extracting malware and associated artifacts from Windows systems; legal considerations; file identification and profiling initial analysis of a suspect file on a Windows system; and analysis of a suspect program.

This field guide is intended for computer forensic investigators, analysts, and specialists.

• A condensed hand-held guide complete with on-the-job tasks and checklists
• Specific for Windows-based systems, the largest running OS in the world
• Authors are world-renowned leaders in investigating and analyzing malicious code

Malware Forensics Field Guide for Windows Systems

Malware Forensics Field Guide for Windows Systems Digital Forensics Field Guides

Cameron H. Malin Eoghan Casey James M. Aquilina Curtis W. Rose, Technical Editor

AMSTERDAM • BOSTON • HEIDELBERG • LONDON NEW YORK • OXFORD • PARIS • SAN DIEGO SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO Syngress is an imprint of Elsevier

SYNGRESS®

Acquiring Editor: Cris Katsaropoulos Project Manager: Paul Gottehrer Designer: Alisa Andreola Syngress is an imprint of Elsevier 225 Wyman Street, Waltham, MA 02451, USA © 2012 Elsevier, Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, ­electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek ­permission, further information about the Publisher’s permissions policies and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions. This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein). Notices Knowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods or professional practices, may become necessary. Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information or methods described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility. To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of ­products liability, negligence or otherwise, or from any use or operation of any methods, products, ­instructions, or ideas contained in the material herein. Library of Congress Cataloging-in-Publication Data Application submitted. British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library. ISBN: 978-1-59749-472-4 For information on all Syngress publications visit our website at http://store.elsevier.com Printed in the United States of America 12 13 14 15 16  10 9 8 7 6 5 4 3 2 1 Typeset by: diacriTech, Chennai, India

For our moms, who taught us determination, patience, creativity, and to live passionately.

Acknowledgments

Cameron would like to thank a number of people for their guidance, support, and ideas on this book—without them it would not have happened. James and Eoghan I appreciate your willingness to keep an open mind and embrace the format and structure of this book; it was a rewarding challenge. I’m proud to work with you both. Thanks to the Syngress crew for your patience and understanding of our vision: Steve Elliot, Angelina Ward, Laura Colantoni, Matthew Cater, Paul Gottehrer, Chris Katsaropoulos, and David Bevans. Not to be forgotten are the some terrific researchers, developers, and forensic practitioners who assisted and supported this book: Mila Parkour (contagiodump.blogspot.com), Ero Carera and Christian Blichmann (Zynamics), Matthew Shannon (F-Response), Maria Lucas (HBGary), Thorsten Holz (Assistant Professor at Ruhr-University Bochum; http://honeyblog.org/), Tark (ccso.com), and Danny Quist (offensivecomputing.net). For your friendship, camaraderie, and day-to-day hi-jinks, “Team Cyber” of the Los Angeles Cyber Division—you are a fantastic crew and I miss you. Jason, Ramyar, and Bryan—my friends and confidants—thank you for everything, we had a good run. My sister Alecia—your determination and focus are an inspiration to me. “No lying on the couch!” Finally, to my lovely wife Adrienne, I am so lucky to have you in my life— thanks for being a “team” with me—I love you. Bentley and Barkley—thanks for being Daddy’s little “writing buddies.” Malware Forensics Field Guide for Windows Systems was reviewed by a digital forensic expert who is a fantastic author in his own right. My sincerest thanks to Curtis W. Rose for your tenacity and attention to detail—we’re lucky to work with you. Cameron H. Malin My deepest thanks to Cameron Malin for taking this challenging project and team by the scruff and pulling us together over the finish line. Your vision for the future of malware forensics is awe inspiring and I look forward to seeing what you do next. Our field needs more dedicated and selfless stewards like you. Thanks to James Aquilina for your support over the years. I am grateful to my work colleagues for their support—particularly Christopher Daywalt and Brian Baskin for the constructive criticism and practitioner insights that made this guide all the more practitioner focused. Curtis Rose for sticking with it

xv

xvi

Acknowledgments

and catching my mistakes, your persistent assistance is much appreciated. My ­family, for your unconditional love and support. Eoghan Casey James warmly thanks co-authors Cameron and Eoghan and technical editor Curtis for another rewarding journey. For our Syngress team and those in the field who supported our work, grazie mille. I am forever humbled by the talent and endurance of my colleagues at Stroz, especially my staff along the West Coast who embrace a daily dose of crazy. For my family and friends who are thinking as they read this, “oh joy, more technical mumbo jumbo,” I love you all anyway. Finally, to my federal law enforcement brethren, I miss you guys. James M. Aquilina

About the Authors

Cameron H. Malin is a Supervisory Special Agent with the Federal Bureau of Investigation assigned to a Cyber Crime squad in Los Angeles, California, where he is responsible for the investigation of computer intrusion and malicious code matters. In 2010, Mr. Malin was a recipient of the Attorney General’s Award for Distinguished Service for his role as a Case Agent in Operation Phish Phry. Mr. Malin is the Chapter Lead for the Southern California Chapter of the Honeynet Project, an international non-profit organization dedicated to improving the security of the Internet through research, analysis, and information regarding computer and network security threats. Mr. Malin currently sits on the Editorial Board of the International Journal of Digital Evidence (IJDE) and is a Subject Matter Expert for the Information Assurance Technology Analysis Center (IATAC) and Weapon Systems Technology and Information Analysis Center (WSTIAC). Mr. Malin is a Certified Ethical Hacker (C|EH) and Certified Network Defense Architect (C|NDA) as designated by the International Council of Electronic Commerce Consultants (EC-Council) and a Certified Information Systems Security Professional (CISSP), as designated by the International Information Systems Security Certification Consortium ((ISC)2®). Prior to working for the FBI, Mr. Malin was an Assistant State Attorney (ASA) and Special Assistant United States Attorney (SAUSA) in Miami, Florida, where he specialized in computer crime prosecutions. During his tenure as an ASA, Mr. Malin was also an Assistant Professorial Lecturer in the Computer Fraud Investigations Masters Program at George Washington University. The techniques, tools, methods, views, and opinions explained by Cameron Malin are personal to him, and do not represent those of the United States Department of Justice, the Federal Bureau of Investigation, or the government of the United States of America. Neither the Federal government nor any Federal agency endorses this book or its contents in any way. Eoghan Casey is founding partner of cmdLabs, author of the foundational book Digital Evidence and Computer Crime, and coauthor of Malware Forensics: Investigating and Analyzing Malicious Code. For over a decade he has dedicated himself to advancing the practice of incident handling and digital ­forensics. He helps client organizations handle security breaches and analyzes digital evidence in a wide range of investigations, including network intrusions with international scope. He works at the Department of Defense Cyber Crime Center (DC3) on research and tool development. He has testified in civil and xvii

xviii

About the Authors

criminal cases, and has submitted expert reports and prepared trial exhibits for computer forensic and cyber-crime cases. As a Director of Digital Forensics and Investigations at Stroz Friedberg, he maintained an active docket of cases and co-managed the firm’s technical operations in the areas of computer forensics, cyber-crime response, incident handling, and electronic discovery. He also spearheaded Stroz Friedberg’s external and in-house forensic training programs as Director of Training. Mr. Casey has performed thousands of forensic acquisitions and examinations, including Windows and UNIX systems, Enterprise servers, smart phones, cell phones, network logs, backup tapes, and database systems. He also has extensive information security experience, as an Information Security Officer at Yale University and in subsequent consulting work. He has performed vulnerability assessments; deployed and maintained intrusion detection systems, firewalls, and public key infrastructures; and developed policies, procedures, and educational programs for a variety of organizations. Mr. Casey holds a B.S. in Mechanical Engineering from the University of California at Berkeley, and an M.A. in Educational Communication and Technology from New York University. He conducts research and teaches graduate students at Johns Hopkins University Information Security Institute, and is Editor-in-Chief of Digital Investigation: The International Journal of Digital Forensics and Incident Response. James M. Aquilina, Executive Managing Director and Deputy General Counsel, contributes to the management of Stroz Friedberg and the handling of its legal affairs, in addition to having overall responsibility for the Los Angeles, San Francisco, and Seattle offices. He supervises numerous digital forensic, Internet investigative, and electronic discovery assignments for government agencies, major law firms, and corporate management and information systems departments in criminal, civil, regulatory, and internal corporate matters, including matters involving data breach, e-forgery, wiping, mass deletion and other forms of spoliation, leaks of confidential information, computer-enabled theft of trade secrets, and illegal electronic surveillance. He has served as a neutral expert and has supervised the court-appointed forensic examination of digital evidence. Mr. Aquilina also has led the development of the firm’s online fraud and abuse practice, regularly consulting on the technical and strategic aspects of initiatives to protect computer networks from spyware and other invasive software, malware and malicious code, online fraud, and other forms of illicit Internet activity. His deep knowledge of botnets, distributed denial of service attacks, and other automated cyber-intrusions enables him to provide companies with advice and solutions to tackle incidents of computer fraud and abuse and bolster their infrastructure protection. Prior to joining Stroz Friedberg, Mr. Aquilina was an Assistant U.S. Attorney (AUSA) in the Criminal Division of the U.S. Attorney’s Office for the Central District of California, where he most recently served in the Cyber and

About the Authors

xix

Intellectual Property Crimes Section. He also served as a member of the Los Angeles Electronic Crimes Task Force, and as chair of the Computer Intrusion Working Group, an inter-agency cyber-crime response organization. As an AUSA, Mr. Aquilina conducted and supervised investigations and prosecutions of computer intrusions, extortionate denial of service attacks, computer and Internet fraud, criminal copyright infringement, theft of trade secrets, and other abuses involving the theft and use of personal identity. Among his notable cyber cases, Mr. Aquilina brought the first U.S. prosecution of malicious botnet activity against a prolific member of the “botmaster underground” who sold his armies of infected computers for the purpose of launching attacks and spamming and used his botnets to generate income from the surreptitious installation of adware; tried to jury conviction the first criminal copyright infringement case involving the use of digital camcording equipment; supervised the government’s continuing prosecution of Operation Cyberslam, an international intrusion investigation involving the use of hired hackers to launch computer attacks against online business competitors; and oversaw the collection and analysis of electronic evidence relating to the prosecution of a local terrorist cell operating in Los Angeles. During his tenure at the U.S. Attorney’s Office, Mr. Aquilina also served in the Major Frauds and Terrorism/Organized Crime Sections, where he investigated and tried numerous complex cases, including a major corruption trial against an IRS Revenue Officer and public accountants, a fraud prosecution against the French bank Credit Lyonnais in connection with the rehabilitation and liquidation of the now defunct insurer Executive Life, and an extortion and kidnapping trial against an Armenian organized crime ring. In the wake of the September 11, 2001, attacks Mr. Aquilina helped establish and run the Legal Section of the FBI’s Emergency Operations Center. Before public service, Mr. Aquilina was an associate at the law firm Richards, Spears, Kibbe & Orbe in New York, where he focused on white collar defense work in federal and state criminal and regulatory matters. He served as a law clerk to the Honorable Irma E. Gonzalez, U.S. District Judge, Southern District of California. He received his B.A. magna cum laude from Georgetown University, and his J.D. from the University of California, Berkeley School of Law, where he was a Richard Erskine Academic Fellow and served as an Articles Editor and Executive Committee Member of the California Law Review. He currently serves as an Honorary Council Member on cyber-law issues for the EC-Council, the organization that provides the C|EH and CHFI (Certified Hacking Forensic Investigator) certifications to leading security industry ­professionals worldwide. Mr. Aquilina is a member of Working Group 1 of the Sedona Conference, the International Association of Privacy Professionals, the Southern California Honeynet Project, the Los Angeles Criminal Justice Inn of Court, and the Los Angeles County Bar Association. He also serves on the Board of Directors of the Constitutional Rights Foundation, a non-profit

xx

About the Authors

e­ ducational organization dedicated to providing young people with access to and understanding of law and the legal process. Mr. Aquilina is co-author of Malware Forensics: Investigating and Analyzing Malicious Code.

About the Technical Editor

Curtis W. Rose is the President and founder of Curtis W. Rose & Associates LLC, a specialized services company in Columbia, Maryland, which provides computer forensics, expert testimony, litigation support, and computer intrusion response and training to commercial and government clients. Mr. Rose is an industry-­recognized expert with over 20 years of experience in investigations, computer forensics, and technical and information security. Mr. Rose was a co-author of Real Digital Forensics: Computer Security and Incident Response, and was a contributing author or technical editor for many popular information security books including Handbook of Digital Forensics and Investigation; Malware Forensics: Investigating and Analyzing Malicious Code; SQL Server Forensic Analysis; Anti-Hacker Toolkit, 1st Edition; Network Security: The Complete Reference; and Incident Response and Computer Forensics, 2nd Edition. He has also published whitepapers on advanced ­forensic methods and techniques including “Windows Live Response Volatile Data Collection: Non-Disruptive User and System Memory Forensic Acquisition” and “Forensic Data Acquisition and Processing Utilizing the Linux Operating System.”

xxi

Introduction

Introduction to Malware Forensics Since the publication of Malware Forensics: Investigating and Analyzing Malicious Code in 2008,1 the number and complexity of programs developed for malicious and illegal purposes has grown substantially. The 2011 Symantec Internet Security Threat Report announced that over 286 million new threats emerged in the past year.2 Other anti-virus vendors, including F-Secure, forecast an increase in attacks against mobile devices and SCADA systems in 2011.3 In the past, malicious code has been categorized neatly (e.g., viruses, worms, or Trojan horses) based upon functionality and attack vector. Today, malware is often modular and multifaceted, more of a “blended-threat,” with diverse functionality and means of propagation. Much of this malware has been developed to support increasingly organized, professional computer criminals. Indeed, criminals are making extensive use of malware to control computers and steal personal, confidential, or otherwise proprietary information for profit. In Operation Trident Breach,4 hundreds of individuals were arrested for their involvement in digital theft using malware such as ZeuS. A thriving gray market ensures that today’s malware is professionally developed to avoid detection by current AntiVirus programs, thereby remaining valuable and available to any cyber-savvy criminal group. Of growing concern is the development of malware to disrupt power plants and other critical infrastructure through computers, referred to by some as Cyber Warfare. The StuxNet malware that emerged in 2010 is a powerful demonstration of the potential for such attacks.5 Stuxnet was a sophisticated program that enabled the attackers to alter the operation of industrial systems, like those in a nuclear reactor, by accessing programmable logic controllers connected to the target computers. This type of attack could shut down a power plant or other components of a society’s critical infrastructure, potentially causing significant harm to people in a targeted region. 1

  http://www.syngress.com/digital-forensics/Malware-Forensics/.   http://www.symantec.com/connect/2011_Internet_Security_Threat_Report_Identifies_Risks_ For_SMBs. 3   http://www.f-secure.com/en_EMEA-Labs/news-info/threat-summaries/2011/2011_1.html. 4   http://krebsonsecurity.com/tag/operation-trident-breach/. 5   http://www.symantec.com/connect/blogs/stuxnet-introduces-first-known-rootkit-scada-devices; http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_ stuxnet_dossier.pdf. 2

xxiii

xxiv

Introduction

Foreign governments are funding teams of highly skilled hackers to develop customized malware to support industrial and military espionage.6 The intrusion into Google’s systems demonstrates the advanced and persistent capabilities of such attackers.7 These types of well-organized attacks, known as the “Advanced Persistent Threat (APT),” are designed to maintain long-term access to an organization’s network in order to steal information/gather intelligence and are most commonly associated with espionage. The increasing use of malware to commit espionage and crimes and launch cyber attacks is compelling more digital investigators to make use of malware analysis techniques and tools that were previously the domain of anti-virus vendors and security researchers. This Field Guide was developed to provide practitioners with the core knowledge, skills, and tools needed to combat this growing onslaught against computer systems.

HOW TO USE THIS BOOK

R This book is intended to be used as a tactical reference while in the field. This Field Guide is designed to help digital investigators identify malware on a computer system, examine malware to uncover its functionality and purpose, and determine malware’s impact on a subject system. To further advance malware analysis as a forensic discipline, specific methodologies are provided and legal considerations are discussed so that digital investigators can perform this work in a reliable, repeatable, defensible, and thoroughly documented manner. u Unlike Malware Forensics: Investigating and Analyzing Malicious Code, which uses practical case scenarios throughout the text to demonstrate techniques and associated tools, this Field Guide strives to be both tactical and practical, structured in a succinct outline format for use in the field, but with cross-references signaled by distinct graphical icons to supplemental components and online resources for the field and lab alike. u

Supplemental Components u

The supplementary components used in this Field Guide include: • Field Interview Questions: An organized and detailed interview ­question and answer form that can be used while responding to a malicious code incident. • Field Notes: A structured and detailed note-taking solution, serving as both guidance and a reminder checklist while responding in the field or in the lab.

6   “The New E-spionage Threat,” http://www.businessweek.com/magazine/content/08_16/ b4080032218430.htm; “China Accused of Hacking into Heart of Merkel Administration,” http://www.timesonline.co.uk/tol/news/world/europe/article2332130.ece. 7   http://googleblog.blogspot.com/2010/01/new-approach-to-china.html.

Introduction

xxv

• Pitfalls to Avoid: A succinct list of commonly encountered mistakes and discussion of how to avoid these mistakes. • Tool Box: A resource for the digital investigator to learn about additional tools that are relevant to the subject matter discussed in the corresponding substantive chapter section. The Tool Box icon (@—a wrench and hammer) is used to notify the reader that additional tool information is available in the Tool Box appendix at the end of each chapter, and on the book’s companion Web site, www.malwarefieldguide.com. • Selected Readings: A list of relevant supplemental reading materials relating to topics covered in the chapter.

INVESTIGATIVE APPROACH

R When malware is discovered on a system, the importance of organized methodology, sound analysis, steady documentation, and attention to evidence dynamics all outweigh the severity of any time pressure to investigate.

Organized Methodology The Field Guide’s overall methodology for dealing with malware incidents breaks the investigation into five phases: Phase 1: Forensic preservation and examination of volatile data (Chapter 1) Phase 2: Examination of memory (Chapter 2) Phase 3: Forensic analysis: examination of hard drives (Chapter 3) Phase 4: File profiling of an unknown file (Chapters 5) Phase 5: Dynamic and static analysis of a malware specimen (Chapter 6) u Within each of these phases, formalized methodologies and goals are emphasized to help digital investigators reconstruct a vivid picture of events surrounding a malware infection and gain a detailed understanding of the malware itself. The methodologies outlined in this book are not intended as a checklist to be followed blindly; digital investigators always must apply critical thinking to what they are observing and adjust accordingly. u Whenever feasible, investigations involving malware should extend beyond a single compromised computer, as malicious code is often placed on the ­computer via the network, and most modern malware has network-related functionality. Discovering other sources of evidence, such as servers the malware contacts to download components or instructions, can provide useful information about how malware got on the computer and what it did once installed. u In addition to systems containing artifacts of compromise, other network and data sources may prove valuable to your investigation. Comparing ­available backup tapes of the compromised system to the current state of the system, for example, may uncover additional behavioral attributes of the malware, tools the attacker left behind, or recoverable files containing exfiltrated data. u

xxvi

Introduction

Also consider checking centralized logs from anti-virus agents, reports from system integrity checking tools like Tripwire, and network level logs. u Network forensics can play a key role in malware incidents, but this extensive topic is beyond the scope of our Field Guide. One of the author’s earlier works8 covers tools and techniques for collecting and utilizing various sources of evidence on a network that can be useful when investigating a malware incident, including Intrusion Detection Systems, NetFlow logs, and network traffic. These logs can show use of specific exploits, malware connecting to external IP addresses, and the names of files being stolen. Although potentially not available prior to discovery of a problem, logs from network resources implemented during the investigation may capture meaningful evidence of ongoing activities. u Remember that well-interviewed network administrators, system owners, and computer users often help develop the best picture of what actually occurred. u Finally, as digital investigators are more frequently asked to conduct malware analysis for investigative purposes that may lead to the victim’s pursuit of a civil or criminal remedy, ensuring the reliability and validity of findings means compliance with an oft complicated legal and regulatory landscape. Chapter 4, although no substitute for obtaining counsel and sound legal advice, explores some of these concerns and discusses certain legal requirements or limitations that may govern the preservation, collection, movement and analysis of data and digital artifacts uncovered during malware forensic investigations.

Forensic Soundness The act of collecting data from a live system may cause changes that a digital investigator will need to justify, given its impact on other digital evidence. • For instance, running tools like Helix3 Pro9 from a removable media device will alter volatile data when loaded into main memory and create or modify files and Registry entries on the evidentiary system. • Similarly, using remote forensic tools necessarily establishes a network connection, executes instructions in memory, and makes other alterations on the evidentiary system. u Purists argue that forensic acquisitions should not alter the original evidence source in any way. However, traditional forensic disciplines like DNA analysis suggest that the measure of forensic soundness does not require that an original be left unaltered. When samples of biological material are collected, the process generally scrapes or smears the original evidence. Forensic analysis of the evidentiary sample further alters the original evidence, as DNA tests are destructive. Despite changes that occur during both preservation and processing, these u

8

  Casey, E. (2011). Digital Evidence and Computer Crime, 3rd ed. London: Academic Press.   For more information about Helix3 Pro, go to http://www.e-fense.com/helix3pro.php.

9

Introduction

xxvii

methods are nonetheless considered forensically sound and the ­evidence is regularly admitted in legal proceedings. u Some courts consider volatile computer data discoverable, thereby requiring digital investigators to preserve data on live systems. For example, in Columbia Pictures Industries v. Bunnell,10 the court held that RAM on a Web server could contain relevant log data and was therefore within the scope of discoverable information in the case.

Documentation One of the keys to forensic soundness is documentation. • A solid case is built on supporting documentation that reports on where the evidence originated and how it was handled. • From a forensic standpoint, the acquisition process should change the original evidence as little as possible, and any changes should be documented and assessed in the context of the final analytical results. • Provided both that the acquisition process preserves a complete and accurate representation of the original data, and the authenticity and integrity of that representation can be validated, the acquisition is generally considered forensically sound. u Documenting the steps taken during an investigation, as well as the results, will enable others to evaluate or repeat the analysis. • Keep in mind that contemporaneous notes are often referred to years later to help digital investigators recall what occurred, what work was conducted, and who was interviewed, among other things. • Common forms of documentation include screenshots, captured network traffic, output from analysis tools, and notes. • When preserving volatile data, document the date and time that data was preserved and which tools were used, and calculate the MD5 of all output. • Whenever dealing with computers, it is critical to note the date and time of the computer, and compare it with a reliable time source to assess the accuracy of date-time stamp information associated with the acquired data. u

Evidence Dynamics Unfortunately, digital investigators rarely are presented with the perfect digital crime scene. Many times the malware or attacker purposefully has destroyed evidence by deleting logs, overwriting files, or encrypting incriminating data. Often the digital investigator is called to an incident only after the victim has taken initial steps to remediate—and in the process, has either destroyed critical evidence, or worse, compounded the damage to the system by invoking additional hostile programs.

u

10

  2007 U.S. Dist. LEXIS 46364 (C.D. Cal. June 19, 2007).

xxviii

Introduction

This phenomenon is not unique to digital forensics. Violent crime investigators regularly find that offenders attempted to destroy evidence or EMT first responders disturbed the crime scene while attempting to resuscitate the victim. These types of situations are sufficiently common to have earned a name—­evidence dynamics. u Evidence dynamics is any influence that changes, relocates, obscures, or obliterates evidence—regardless of intent—between the time evidence is transferred and the time the case is adjudicated.11 • Evidence dynamics is a particular concern in malware incidents because there is often critical evidence in memory that will be lost if not preserved quickly and properly. • Digital investigators must live with the reality that they will rarely have an opportunity to examine a digital crime scene in its original state and should therefore expect some anomalies. • Evidence dynamics creates investigative and legal challenges, making it more difficult to determine what occurred, and making it more difficult to prove that the evidence is authentic and reliable. • Any conclusions the digital investigator reaches without knowledge of how evidence was changed may be incorrect, open to criticism in court, or misdirect the investigation. • The methodologies and legal discussion provided in this Field Guide are designed to minimize evidence dynamics while collecting volatile data from a live system using tools that can be differentiated from similar utilities commonly used by intruders. u

FORENSIC ANALYSIS IN MALWARE INVESTIGATIONS

R Malware investigation often involves the preservation and examination of volatile data; the recovery of deleted files; and other temporal, functional, and relational kinds of computer forensic analysis.

Preservation and Examination of Volatile Data Investigations involving malicious code rely heavily on forensic preservation of volatile data. Because operating a suspect computer usually changes the system, care must be taken to minimize the changes made to the system; collect the most volatile data first (aka Order of Volatility, which is described in detail in RFC 3227: Guidelines for Evidence Collection and Archiving);12 and thoroughly document all actions taken.

u

11

  Chisum, W.J., and Turvey, B. (2000). Evidence Dynamics: Locard’s Exchange Principle and Crime Reconstruction, Journal of Behavioral Profiling, Vol. 1, No. 1. 12   http://www.faqs.org/rfcs/rfc3227.html.

Introduction

xxix

Technically, some of the information collected from a live system in response to a malware incident is non-volatile. The following subcategories are provided to clarify the relative importance of what is being collected from live systems. • Tier 1 Volatile Data: Critical system details that provide the investigator with insight as to how the system was compromised and the nature of the compromise. Examples include logged-in users, active network connections, and the processes running on the system. • Tier 2 Volatile Data: Ephemeral information, while beneficial to the investigation and further illustrative of the nature and purpose of the compromise and infection, is not critical to identification of system status and details. Examples of these data include scheduled tasks and clipboard contents. • Tier 1 Non-volatile Data: Reveals the status, settings, and configuration of the target system, potentially providing clues as to the method of the compromise and infection of the system or network. Examples include registry settings and audit policy. • Tier 2 Non-volatile Data: Provides historical information and context, but is not critical to system status, settings, or configuration analysis. Examples of these data include system event logs and Web browser ­history. u The current best practices and associated tools for preserving and examining volatile data on Windows systems are covered in Chapter 1 (Malware Incident Response: Volatile Data Collection and Examination on a Live Windows System) and Chapter 2 (Memory Forensics: Analyzing Physical and Process Memory Dumps for Malware Artifacts). u

Recovering Deleted Files Specialized forensic tools have been developed to recover deleted files that are still referenced in the file system. It is also possible to salvage deleted executables from unallocated space that are no longer referenced in the file system. One of the most effective tools for salvaging executables from unallocated space is “foremost,” as shown in Figure I.1 using the “-t” option, which uses internal carving logic rather than simply headers from the configuration file. u

 Other Tools to Consider Data Carving Tools

DataLifter  http://www.datalifter.com Scalpel  http://www.digitalforensicssolutions.com/Scalpel/ PhotoRec    http://www.cgsecurity.org/wiki/PhotoRec

xxx

Introduction

Foremost version 1.5 by Jesse Kornblum, Kris Kendall, and Nick Mikus Audit File Foremost started at Tue Jan 22 05:18:19 2008 Invocation: foremost -t exe,dll host3-diskimage.dmp Output directory: /examination/output Configuration file: /usr/local/etc/foremost.conf ——————————————————————File: host3-diskimage.dmp Start: Tue Jan 22 05:18:19 2008 Length: 1000 MB (1066470100 bytes) Num 1: 2: 3: 4: 5: 6: 7:

Name (bs=512) 00001509.exe 00002965.dll 00003781.dll 00004837.dll 00005077.dll 00005133.dll 00005197.dll

Size 58 KB 393 KB 517 KB 106 KB 17 KB 17 KB 68 KB

File Offset 772861 1518333 1936125 2476797 2599677 2628349 2661117

Comment 09/13/2007 01/02/2007 08/25/2006 06/20/2003 06/20/2003 11/30/1999 06/20/2003

09:06:10 17:33:10 15:12:52 02:44:06 02:44:22 09:31:09 02:44:22

FIGURE I.1–Using foremost to carve executable files from unallocated disk space

Temporal, Functional, and Relational Analysis One of the primary goals of forensic analysis is to reconstruct the events surrounding a crime. Three common analysis techniques that are used in crime reconstruction are temporal, functional, and relational analysis. u The most common form of temporal analysis is the time line, but there is such an abundance of temporal information on computers that the different approaches to analyzing this information are limited only by our imagination and current tools. u The goal of functional analysis is to understand what actions were possible within the environment of the offense, and how the malware actually behaves within the environment (as opposed to what it was capable of doing). • One effective approach with respect to conducting a functional analysis to understand how a particular piece of malware behaves on a compromised system is to load the forensic duplicate into a virtual environment using a tool like Live View.13 Figure I.2 shows Live View being used to prepare and load a forensic image into a virtualized environment. u Relational analysis involves studying how components of malware interact, and how various systems involved in a malware incident relate to each other. • For instance, one component of malware may be easily identified as a downloader for other more critical components, and may not require further in-depth analysis. • Similarly, one compromised system may be the primary command and control point used by the intruder to access other infected computers, and may contain the most useful evidence of the intruder’s activities on the network as well as information about other compromised systems. u

13

For more information about Live View, go to http://liveview.sourceforge.net.

Introduction

xxxi

FIGURE I.2–Live View taking a forensic duplicate of a Windows XP system and launching it in VMware

Specific applications of these forensic analysis techniques are covered in Chapter 3, Post-Mortem Forensics: Discovering and Extracting Malware and Associated Artifacts from Windows Systems. u

APPLYING FORENSICS TO MALWARE

R Forensic analysis of malware requires an understanding of how an executable is complied, the difference between static and dynamic linking, and how to distinguish class from individuating characteristics of malware.

How an Executable File is Compiled Before delving into the tools and techniques used to dissect a malicious executable program, it is important to understand how source code is compiled, linked, and becomes executable code. The steps an attacker takes during the course of compiling malicious code are often items of evidentiary significance uncovered during the examination of the code. u

xxxii

Introduction

Think of the compilation of source code into an executable file like the metamorphosis of caterpillar to butterfly: the initial and final products manifest as two totally different entities, even though they are really one in the same but in different form. u

FIGURE I.3–Compiling source code into an object file

As illustrated in Figure I.3, when a program is compiled, the program’s source code is run through a compiler, a program that translates the programming statements written in a high-level language into another form. Once processed through the compiler, the source code is converted into an object file or machine code, as it contains a series of instructions not intended for human readability, but rather for execution by a computer processor.14 u After the source code is compiled into an object file, a linker assembles any required libraries and object code together to produce an executable file that can be run on the host operating system, as seen in Figure I.4. u Often, during compilation, bits of information are added to the executable file that may be relevant to the overall investigation. The amount of information present in the executable is contingent upon how it was compiled by the attacker. Chapter 5 (File Identification and Profiling: Initial Analysis of a Suspect File on a Windows System) covers tools and techniques for unearthing these useful clues during the course of your analysis. u

14

  For good discussions of the file compilation process and analysis of binary executable files, see, Jones, K.J., Bejtlich, R., and Rose, C.W. (2005). Real Digital Forensics: Computer Security and Incident Response. Reading, MA: Addison Wesley; Mandia, K., Prosise, C., and Pepe, M. (2003). Incident Response and Computer Forensics, 2nd ed. New York: McGraw-Hill/Osborne; and Skoudis, E., and Zeltser, L. (2003). Malware: Fighting Malicious Code. Upper Saddle River, NJ: Prentice Hall.

Introduction

xxxiii

FIGURE I.4–A linker creates an executable file by linking the required libraries and code to an object file

Static versus Dynamic Linking In addition to the information added to the executable during compilation, it is important to examine the suspect program to determine whether it is a static or a dynamic executable, as this will significantly impact the contents and size of the file, and in turn, the evidence you may discover. • A static executable is compiled with all of the necessary ­libraries and code it needs to successfully execute, making the program ­“self-­contained.” • Conversely, dynamically linked executables are dependent upon shared libraries to successfully run. The required libraries and code needed by the dynamically linked executable are referred to as dependencies. • In Windows programs, dependencies are most often dynamic link ­libraries (DLLs; .dll extension) that are imported from the host operating system during execution. • File dependencies in Windows executables are identified in the Import Tables of the file structure. By calling on the required libraries at runtime, rather than statically linking them to the code, dynamically linked executables are smaller and consume less system memory, among other things. u We will discuss how to examine a suspect file to identify dependencies, and delve into Important Table and file dependency analysis in greater detail in Chapter 5 (File Identification and Profiling: Initial Analysis of a Suspect File on a Windows System) and Chapter 6 (Analysis of a Malware Specimen). u

xxxiv

Introduction

CLASS VERSUS INDIVIDUATING CHARACTERISTICS It is simply not possible to be familiar with every kind of malware in all of its various forms. • Best investigative effort will include a comparison of unknown malware with known samples, as well as conducting preliminary analysis designed not just to identify the specimen, but how best to interpret it. • Although libraries of malware samples currently exist in the form of antivirus programs and hash sets, these resources are far from comprehensive. • Individual investigators instead must find known samples to compare with evidence samples and focus on the characteristics of files found on the compromised computer to determine what tools the intruder used. Further, deeper examination of taxonomic and phylogenetic relationships between malware specimens may be relevant to classify a target specimen and determine if it belongs to a particular malware “family.” u Once an exemplar is found that resembles a given piece of digital evidence, it is possible to classify the sample. John Thornton describes this process well in “The General Assumptions and Rationale of Forensic Identification”:15 u

In the “identification” mode, the forensic scientist examines an item of evidence for the presence or absence of specific characteristics that have been previously abstracted from authenticated items. Identifications of this sort are legion, and are conducted in forensic laboratories so frequently and in connection with so many different evidence categories that the forensic scientist is often unaware of the specific steps that are taken in the process. It is not necessary that those authenticated items be in hand, but it is necessary that the forensic scientist have access to the abstracted information. For example, an obscure 19th Century Hungarian revolver may be identified as an obscure 19th Century Hungarian revolver, even though the forensic scientist has never actually seen one before and is unlikely ever to see one again. This is possible because the revolver has been described adequately in the literature and the literature is accessible to the scientist. Their validity rests on the application of established tests which have been previously determined to be accurate by exhaustive testing of known standard materials. In the “comparison” mode, the forensic scientist compares a questioned evidence item with another item. This second item is a “known item.” The known item may be a standard reference item which is maintained by the laboratory for this purpose (e.g. an authenticated sample of cocaine), or it may be an exemplar sample which itself is a portion of the evidence in a case (e.g., a sample of broken glass or paint from a crime scene). This item must be in hand. Both questioned and known items are compared, characteris-

15

  Thornton, JI. (1997). The General Assumptions and Rationale of Forensic Identification. In: Faigman, D.L., Kaye, D.H., Saks, M.J., and Sanders, J., eds., Modern Scientific Evidence: The Law and Science of Expert Testimony, Vol. 2. St. Paul, MN: West Publishing Co.

xxxv

Introduction

tic by characteristic, until the examiner is satisfied that the items are sufficiently alike to conclude that they are related to one another in some manner. In the comparison mode, the characteristics that are taken into account may or may not have been previously established. Whether they have been previously established and evaluated is determined primarily by (1)  the experience of the examiner, and (2) how often that type of evidence is encountered. The forensic scientist must determine the characteristics to be before a conclusion can be reached. This is more easily said than achieved, and may require de novo research in order to come to grips with the significance of observed characteristics. For example, a forensic scientist compares a shoe impression from a crime scene with the shoes of a suspect. Slight irregularities in the tread design are noted, but the examiner is uncertain whether those features are truly individual characteristics unique to this shoe, or a mold release mark common to thousands of shoes produced by this manufacturer. Problems of this type are common in the forensic sciences, and are anything but trivial.

The source of a piece of malware is itself a unique characteristic that may differentiate one specimen from another. • Being able to show that a given sample of digital evidence originated on a suspect’s computer could be enough to connect the suspect with the crime. • The denial of service attack tools that were used to attack Yahoo! and other large Internet sites, for example, contained information useful in locating those sources of attacks. • As an example, IP addresses and other characteristics extracted from a distributed denial of service attack tool are shown in Figure I.5. u

socket bind recvfrom %s %s %s aIf3YWfOhw.V. PONG *HELLO* 10.154.101.4 192.168.76.84

FIGURE I.5–Individuating characteristics in suspect malware

• The sanitized IP addresses at the end indicated where the command and control servers used by the malware were located on the Internet, and these command and control systems may have useful digital evidence on them. u Class characteristics may also establish a link between the intruder and the crime scene. For instance, the “t0rn” installation file contained a username and port number selected by the intruder shown in Figure I.6.

xxxvi

Introduction

#!/bin/bash # t0rnkit9+linux bought to you by torn/etC!/x0rg # Define ( You might want to change these ) dpass=owened dport=31337

FIGURE I.6–Class characteristics in suspect malware

If the same characteristics are found on other compromised hosts or on  a­ ­suspect’s computer, these may be correlated with other evidence to show  that  the same intruder was responsible for all of the crimes and that the  attacks were launched from the suspect’s computer. For instance, ­examining the computer with IP address 192.168.0.7 used to break into 192.168.0.3 revealed the following traces (Figure I.7) that help establish a  link. u

[[email protected] eco]$ ls -latc -rw——1 eco eco 8868 Apr 18 -rw-rw-r-1 eco eco 540039 Apr 8 drwxrwxr-x 2 eco eco 4096 Apr 8 drwxr-xr-x 5 eco eco 4096 Apr 8 [[email protected] eco]$ less .bash_history cd unix-exploits/ ./SEClpd 192.168.0.3 brute -t 0 ./SEClpd 192.168.0.3 brute -t 0 ssh -l owened 192.168.0.3 -p 31337 [[email protected] eco]$ cd tk [[email protected] tk]$ ls -latc total 556 drwx——25 eco eco 4096 Apr 25 drwxrwxr-x 2 eco eco 4096 Apr 8 -rw——1 eco eco 28967 Apr 8 -rw——1 eco eco 380 Apr 8 -rw-rw-r-1 eco eco 507505 Apr 8 -rwx——1 eco eco 8735 Apr 8 [[email protected] tk]$ head t0rn #!/bin/bash # t0rnkit9+linux bought to you by torn/etC!/x0rg

10:30 10:38 10:37 10:37

.bash_history ftp-tk.tgz tk tornkit

18:38 10:37 10:37 10:37 10:36 10:34

.. . lib.tgz conf.tgz bin.tgz t0rn

# Define ( You might want to change these ) dpass=owened dport=31337

FIGURE I.7–Examining multiple victim systems for similar artifacts

Be aware that malware developers continue to find new ways to undermine forensic analysis. For instance, we have encountered the following anti-forensic techniques (although this list is by no means exhaustive and will certainly develop with time): • Multicomponent packing and encryption • Detection of debuggers, disassemblers, and virtual environments u

Introduction

xxxvii

• Malware that halts when the PEB Debugging Flag is set • Malware that sets the “Trap Flag” on one of its operating threads to hinder tracing analysis • Malware that uses Structured Exception Handling (SEH) protection to block or misdirect debuggers • Malware that rewrites error handlers to force a floating point error to control how the program behaves u A variety of tools and techniques are available to digital investigators to overcome these anti-forensic measures, many of which are detailed in this book. Note that advanced anti-forensic techniques require knowledge and programming skills that are beyond the scope of this book. More in-depth coverage of reverse engineering is available in The IDA Pro Book: The Unofficial Guide to the World’s Most Popular Disassembler.16 A number of other texts provide details on programming rootkits and other malware.17

FROM MALWARE ANALYSIS TO MALWARE FORENSICS

R The blended malware threat has arrived; the need for in-depth, verifiable code analysis and formalized documentation has arisen; a new forensic discipline has emerged. u In the good old days, digital investigators could discover and analyze malicious code on computer systems with relative ease. Trojan horse programs like Back Orifice and SubSeven and UNIX rootkits like t0rnkit did little to undermine forensic analysis of the compromised system. Because the majority of malware functionality was easily observable, there was little need for a digital investigator to perform in-depth analysis of the code. In many cases, someone in the information security community would perform a basic functional analysis of a piece of malware and publish it on the Web. u While the malware of yesteryear neatly fell into distinct categories based upon functionality and attack vector (viruses, worms, Trojan horses), today’s malware specimens are often modular, multifaceted, and known as blendedthreats because of their diverse functionality and means of propagation.18 And, as computer intruders become more cognizant of digital forensic techniques, malicious code is increasingly designed to obstruct meaningful analysis. u By employing techniques that thwart reverse engineering, encode and conceal network traffic, and minimize the traces left on file systems, malicious code developers are making both discovery and forensic analysis more difficult. This 16

  http://nostarch.com/idapro2.htm.   See, Hoglund, G., and Butler, J. (2005). Rootkits: Subverting the Windows Kernel. Reading, MA: Addison-Wesley; Bluden, B. (2009). The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System. Burlington, MA: Jones & Bartlett Publishers; Metula, E. (2010). Managed Code Rootkits: Hooking into Runtime Environments. Burlington, MA: Syngress. 18   http://www.virusbtn.com/resources/glossary/blended_threat.xml. 17

xxxviii

Introduction

trend started with kernel loadable rootkits on UNIX and has evolved into similar concealment methods on Windows systems. u Today, various forms of malware are proliferating, automatically spreading (worm behavior), providing remote control access (Trojan horse/backdoor behavior), and sometimes concealing their activities on the compromised host (rootkit behavior). Furthermore, malware has evolved to undermine security measures, disabling AntiVirus tools and bypassing firewalls by connecting from within the network to external command and control servers. u One of the primary reasons that developers of malicious code are taking such extraordinary measures to protect their creations is that, once the functionality of malware has been decoded, digital investigators know what traces and patterns to look for on the compromised host and in network traffic. In fact, the wealth of information that can be extracted from malware has made it an integral and ­indispensable part of computer intrusion, identity theft and counterintelligence cases. In many cases, little evidence remains on the compromised host and the majority of useful investigative information lies in the malware itself. u The growing importance of malware analysis in digital investigations, and the increasing sophistication of malicious code, has driven advances in tools and techniques for performing surgery and autopsies on malware. As more investigations rely on understanding and counteracting malware, the demand for formalization and supporting documentation has grown. The results of malware analysis must be accurate and verifiable, to the point that they can be relied on as evidence in an investigation or prosecution. As a result, malware analysis has become a forensic discipline—welcome to the era of malware forensics.

Chapter 1

Malware Incident Response Volatile Data Collection and Examination on a Live Windows System Solutions in this chapter: • Volatile Data Collection Methodology

° Local vs. Remote Collection ° Preservation of Volatile Data ° Physical Memory Acquisition ° Collecting Subject System Details ° Identifying Logged-in Users ° Current and Recent Network Connections

• Collecting Process Information • Correlate Open Ports with Running Processes and Programs

° Identifying Services and Drivers ° Determining Open Files ° Collecting Command History ° Identifying Shares ° Determining Scheduled Tasks ° Collecting Clipboard Contents

• Non-Volatile Data Collection from a Live Windows System

° Forensic Duplication of Storage Media ° Forensic Preservation of Select Data ° Assessing Security Configuration ° Assessing Trusted Host Relationships ° Inspecting Prefetch Files ° Inspect Auto-Starting Locations ° Collecting Event Logs ° Reviewing User Account and Group Policy Information ° Examining the File System ° Dumping and Parsing Registry Contents

• Examining Web Browsing Artifacts • Malware Artifact Discovery and Extraction from a Live Windows System

Malware Forensics Field Guide for Windows Systems. DOI: 10.1016/B978-1-59749-472-4.00001-9 © 2012 Elsevier, Inc. All rights reserved.

1

2

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

 Tool Box Appendix and Web Site

The “” symbol references throughout this chapter demarcate that additional utilities pertaining to the topic are discussed in the Tool Box appendix, appearing at the end of this chapter. Further tool information and updates for this chapter can be found on the companion Malware Field Guides Web site, at http://www .malwarefieldguide.com/Chapter1.html.

INTRODUCTION This chapter demonstrates the value of preserving volatile and select nonvolatile data, and how to do so in a forensically sound manner. The value of volatile data is not limited to process memory associated with malware, but can include passwords, Internet Protocol (IP) addresses, Security Event Log entries, and other contextual details that together can provide a more complete understanding of the malware and its use on a system. When powered on, a subject system contains critical ephemeral information that reveals the state of the system. This volatile data is sometimes referred to as stateful information. Incident response forensics, or live response, is the process of acquiring the stateful information from the subject system while it remains powered on. As we discussed in the introductory chapter, the Order of Volatility should be considered when collecting data from a live system to ensure that critical system data is acquired before it is lost or the system is powered down. Further, because the scope of this chapter pertains to live response through the lens of a malicious code incident, the preservation techniques outlined in this section are not intended to be comprehensive or exhaustive; instead, they are intended to provide a solid foundation relating to incident response involving malware on a live system. Often, malicious code live response is a dynamic process, with the facts and context of each incident dictating the manner and means in which the investigator will proceed with his investigation. Unlike other contexts in which simply acquiring a forensic duplicate of a subject system’s hard drive would be sufficient, investigating a malicious code incident on a subject system very often requires some degree of live response. This is because much of the information the investigator needs to identify the nature and scope of the malware infection resides in stateful information that will be lost when the computer is powered down. This chapter provides an overall methodology for preserving volatile data on a Windows system during a malware incident, and presumes that the digital investigator already has built his live response toolkit of trusted tools, or is using a tool suite specifically designed to collect digital evidence in an automated fashion from Windows systems during incident response. There are a variety of live response tool suites available to the digital investigator—many of which are discussed in the Tool Box section at the end of this chapter. Although automated collection of digital evidence is recommend as a measure to avoid mistakes and

Chapter | 1 Malware Incident Response

3

N Analysis Tip

Field Interviews Prior to conducting live response, gather as much information as possible about the malicious code incident and subject system(s) from relevant witnesses. Refer to the Field Interview Questions appendix at the end of this chapter for additional details.

inadvertent collection gaps, the aim of this chapter and associated appendices is to provide the digital investigator with a granular walk-through of the live response process and the digital evidence that should be collected.

Local versus Remote Collection

R Choose the manner in which data will be collected from the subject system. • Collecting results locally means storage media will be connected to the subject system and the results will be saved onto the connected media.

• Remote collection means establishing a network connection from the subject system, typically with a netcat or cryptcat listener, and transferring the acquired system data over the network to a collection server. This method reduces system interaction, but relies on the ability to traverse the subject network through ports established by the netcat listener.

Investigative Considerations • In some instances, the subject network will have rigid firewall and/or proxy server configurations, making it cumbersome or impractical to establish a remote collection repository. • Remotely acquiring certain data during live response—like imaging a subject system’s physical memory—may be time and resource consuming and require several gigabytes of data to traverse the network, depending on the amount of random access memory (RAM) in the target system. The following pair of commands depicted in Figure 1.1 sends the output of a live response utility acquiring data from a subject system to a remote IP address (172.16.131.32) and saves the output in a file named “20101020host1.txt” on the collection system. Subject system ->

-> Collection systems (172.16.131.32)

-e | nc 172.16.131.32 13579

nc -l -p 13579 > 20101020host1.txt

FIGURE 1.1–Netcat commands to establish a network listener to collect tool output remotely

• The netcat command must be executed on the collection system first so that it is ready and waiting to receive data from the subject system. @

4

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• Local collection efforts can be protracted in instances where a victim ­system •

is older and contains obsolete hardware, such as USB 1.1, which has a ­maximum transfer rate of 12 megabits per second (mbps). Always ensure that the media you are using to acquire live response data is pristine and do not contain unrelated case data, malicious code specimens, or other artifacts from previous investigations. Acquiring digital evidence on “dirty” or compromised media can taint and undermine the forensic soundness of the acquired data.

VOLATILE DATA COLLECTION METHODOLOGY Data should be collected from a live system in the Order of Volatility. The following guidelines give a clearer sense of the types of volatile data that can be preserved to better understand malware: • On the compromised machine, run a trusted command shell from an Incident Response toolkit • Document system date and time, and compare them to a reliable time source • Acquire contents of physical memory • Gather hostname, user, and operating system details • Gather system status and environment details • Identify users logged onto the system • Inspect network connections and open ports • Examine Domain Name Service (DNS) queries and connected hostnames • Examine running processes • Correlate open ports to associated processes and programs • Examine services and drivers • Inspect open files • Examine command-line history • Identify mapped drives and shares • Check for unauthorized accounts, groups, shares, and other system resources and configurations using Windows “net” commands • Determine scheduled tasks • Collect clipboard contents • Determine audit policy u

Preservation of Volatile Data

R After obtaining the system date/time, acquire physical memory from the subject system prior to preserving information using live response tools. • Because each version of the Windows operating system has different ways of structuring data in memory, existing tools for examining full memory captures may not be able to interpret memory structures properly in every case. • Therefore, after capturing the full contents of memory, use an Incident Response suite to preserve information from the live system, such as lists of running processes, open files, and network connections, among

Chapter | 1 Malware Incident Response

•

5

other volatile data. A number of commonly used Incident Response tool suites are discussed in the Tool Box section at the end of this ­chapter. Some information in memory can be displayed by using Commandline Interface (CLI) utilities on the system under examination. This same information may not be readily accessible or easily displayed from the memory dump after it is loaded onto a forensic workstation for examination.

Investigative Considerations • It may be necessary in some cases to capture non-volatile data from the live subject system, and perhaps even create a forensic duplicate of the entire disk. For all preserved data, remember that the Message Digest 5 (MD5) and other attributes of the output from a live examination must be documented independently by the digital investigator. • To avoid missteps and omissions, collection of volatile data should be automated.

Physical Memory Acquisition on a Live Windows System

R Before gathering volatile system data using the various tools in a live response toolkit, first acquire a full memory dump from the subject system. • Running incident response tools on the subject system will alter the contents of memory. • To get the most digital evidence out of physical memory, perform a full memory capture prior to running any other incident response ­processes. • There are a myriad of tools that can be used to acquire physical memory, and many have similar functionality. Often, choosing a tool comes down to familiarity and preference. Given that every malware incident is unique, the right tool for the job may be driven not just by the incident type but by the victim system typology.

Investigative Considerations • Remember that some tools are limited to certain operating systems and capture only up to 4 gigabytes (GB) of RAM; others can acquire memory from many different operating system versions, gather up to 64 GB of RAM, and capture the Windows pagefile. If possible, determine subject system details and select appropriate forensic tools prior to beginning incident response. Having numerous tool options available in your toolkit will avoid on-scene frustration. • In addition to assessing tool limitations based upon operating system and memory capacity, also consider whether to use a command-line utility or a graphical user interface (GUI)-based tool. • This section will explore some of the ways to acquire physical memory contents, but consult the Tool Box section at the end of this chapter for further tool discussion and comparison.

6

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Acquiring Physical Memory Locally

R Physical memory dumps can be acquired locally from a subject system using command-line or GUI utilities.

Command-line Utilities u A commonly used command-line tool for physical memory acquisition is HBGary’s FastDump.1 • FastDump Community2 version is a free version of FastDump that supports the acquisition of memory from 32-bit systems with up to 4 GB of RAM. @ • FastDump Community version does not support Vista, Windows 2003, Windows 2008, or 64-bit platforms. • Using FastDump Community version, the following command captures the contents of memory from a subject Windows system and saves it to a file on removable media (Figure 1.2):

E:WinIRmemory>FD.exe e:WinIRmemorymemdump.bin Responder FastDump v1.3.0 (c)2008 HBGary, Inc. [DM] Dumping physical memory snapshot to: e:WinIRmemorymemdump.bin… Found Microsoft Windows XP Professional Service Pack 2 (build 2600) using driver at E:WinIRmemoryFastDumpx86.sys Found 1576517632 bytes (1503.48 MB) of physical memory … 30 MB dumped (2% complete)

FIGURE 1.2–Acquiring physical memory with FastDump

• FastDump Pro3 is the commercially supported version of FastDump,

•

1

which supports all versions of Window operating systems and service packs (2000, XP, 2003, Vista, 2008 Server). @ r FastDump Pro can capture memory from both 32-bit and 64-bit ­systems, including systems with more than 4 GB of RAM (up to 64 GB of RAM), and supports acquisition of the Windows pagefile with the memory dump. Using FastDump Pro, the following command captures the contents of both memory and the pagefile from a subject Windows system and saves it to a file on removable media (Figure 1.3):

  For more information about FastDump, go to https://www.hbgary.com/products-services/ fastdump/. 2   For more information about FastDump Community version, go to https://www.hbgary.com/ community/free-tools/#fastdump. 3   For more information about FastDumpPro, go to http://www.hbgary.com/wp-content/themes/ blackhat/images/fastdumppro-faq.pdf.

Chapter | 1 Malware Incident Response

7

E:WinIRmemory>FDpro E:WinIRmemorymemdump.hpak -= FDPro v2.0.0.0986 (c)HBGary, Inc 2008 — 2010 =[+] Detected OS: Microsoft Windows XP Professional (build 2600) [+] Extracting x86 driver

[+] Driver extracted successfully [+] using driver at E:WinIRmemoryfastdumpx86.sys [+] CreateService success, driver installed [+] StartService success, driver started [+] Driver installed and running [+] Strict Mode: Disabled [+] Output Filesystem Type: FAT32 [!!!!] WARNING! You can only dump up to 4GB maximum to a FAT32 formatted volume. You may want to consider dumping to an NTFS formatted Volume. [!!!!] If the machine you’re dumping has 4GB of ram or more you must select a different output volume or the dump will be incomplete. [+] Block Read/Write Size: 0x100000 (1024k) [+] Configured PageFile: C:pagefile.sys [ Full Range = 0x0 — 0x40400000 (1028 MB)] 0 — (0x1000 — 0x9f000) Size: 0x9e000 1 — (0x100000 — 0xfff000) Size: 0xeff000 2 — (0x1000000 — 0x402f0000) Size: 0x3f2f0000 3 — (0x40300000 — 0x40400000) Size: 0x100000 [ ** Dumping from 0x0 to 0x40400000 ** ] [ Reading Memory @ 0: 3300000 — Dumped: 51 MB Complete: 4%]

FIGURE 1.3–Acquiring physical memory with FastDump Pro

 Other Tools to Consider

Additional command-line utilities to capture physical memory, including Memoryze, Mantech DD and Moonsols Memory Toolkit, are discussed in the Tool Box section at the end of this chapter and on the companion Web site for the Malware Forensic Field Guide, http://www.malwarefieldguide.com/ Chapter1.html.

GUI-based Memory Dumping Tools u

4

Agile Risk Management’s Nigilant324 is a GUI-based incident response tool. • Nigilant32 provides an intuitive interface and simplistic means of imaging a subject system’s physical memory using a drop-down menu in the tool’s user console. • To image memory from Nigilant32, select the “Image Physical Memory” option from the “Tools” menu, as shown in Figure 1.4. • At the prompt, select the location where the memory dump file will be saved; memory imaging will start thereafter.

  For more information about Nigilant32, go to http://www.agileriskmanagement.com/ publications_4.html

8

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

FIGURE 1.4–Imaging physical memory with Nigilant32

Remote Physical Memory Acquisition

R Physical memory dumps can be remotely acquired from a subject system using F-Response. u F-Response is an incident response framework that implements the Microsoft iSCSI initiator service5 to provide read-only access to the full physical disk(s) of a networked computer, as well as to the physical memory of most Microsoft Windows systems.6 • There are four versions of F-Response (Field Kit, Consultant, Enterprise, and TACTICAL) that vary in deployment method, but all provide access to a remote subject system drive as a local mounted drive. • F-Response is flexible and “vendor agnostic,” meaning that any tool can be used to acquire an image of the subject system’s hard drive and physical memory once connected to it. • F-Response Field Kit and TACTICAL are typically used in the context of live response, particularly in scenarios where the subject systems are at a third-party location and F-Response Consultant Edition or Enterprise Edition have not been deployed prior to the incident. • F-Response Field Kit requires a single USB key FOB dongle and the Field Kit executable (f-response-fk.exe), both of which are initiated on subject system. Conversely, the examiner system, which enables the digital investigator to leverage the results of F-Response, simply requires the installation and invocation of the Microsoft iSCSI initiator service. F-Response TACTICAL, which uses a distinguishable paired key FOB deployment, is discussed in the Tool Box section at the end of this chapter.  5

  For more information about the iSCSI initiator, go to http://www.microsoft.com/downloads/en/ details.aspx?familyid=12cb3c1a-15d6-4585-b385-befd1319f825&displaylang=en. 6   For more information about F-Response, go to http://www.f-response.com/.

Chapter | 1 Malware Incident Response

9

• To access the physical memory of the remote subject system with an F-Response Field Kit, connect the USB key FOB dongle to the subject system and execute F-Response. Enter the proper subject system identifiers, and enable “Physical Memory,” using the radio button, as shown in Figure 1.5.

FIGURE 1.5–Using F-Response to connect to a subject system

• On your local examiner system, invoke the iSCSI initiator service, select the “Discovery” tab, and add the subject system as a target, as shown Figure 1.6.

FIGURE 1.6–Adding the subject system as a target through the iSCSI initiator service

• Choose the “Advanced” option and provide the same username and password credentials used in the F-Response Remote Configuration (Figure 1.7).

FIGURE 1.7–Authenticating through the iSCSI initiator to acquire the target system

10

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• After authenticating, the subject system will appear as a target. Select the subject system hard drive and physical memory from the target list (requiring re-authentication) and connect to the subject system; the connection status will be displayed in the target list (Figure 1.8).

FIGURE 1.8–Connecting to the subject system

• Once connected to the subject system through F-Response, the subject system’s hard drive can be accessed locally on your examiner system, as shown in Figure 1.9.

FIGURE 1.9–Viewing the remote subject system hard drive through F-Response

• On your local examiner system, use the Disk Management snap-in to ­verify that the physical memory is also “mounted.”

• As physical memory does not have a file system or partition table, the physical memory will not be recognized as a drive, but rather as an unknown disk, as shown in Figure 1.10.

FIGURE 1.10–Identifying physical memory from a remote subject system

Chapter | 1 Malware Incident Response

11

• In Figure 1.11, Helix3 Pro7 was used to acquire the memory image from the remote subject system. The Helix3 Pro Live CD was initiated on the examiner system and identified the subject system’s physical memory as a local drive (PhysicalDrive2); acquisition was conducted by selecting PhysicalDrive2 as the item to image. 

FIGURE 1.11–Acquiring physical memory from a remote subject system

 Other Tools to Consider

Commercial remote forensics tools such as ProDiscoverIR and OnlineDFS have been developed to capture full memory contents from remote systems. These, and other remote forensics tools, are discussed further in the Tool Box section at the end of this chapter and on the companion Web site, http://www .malwarefieldguide.com/Chapter1.html.

Collecting Subject System Details

R System details are helpful for providing context to the live response and post-mortem forensic process, establishing an investigative time line, and identifying the subject system in logs and other forensic artifacts. u Obtain the following subject system details: • System date and time • System identifiers • Network configuration • Enabled protocols • System uptime • System environment

System Date and Time u After acquiring an image of the physical memory from a subject system, the first and last items that should be collected during the course of ­conducting a live response examination are the system date and time. This information will serve both as the basis of your investigative time line—providing context to your analysis of the system—as well as documentation of the examination. 7

  Helix3 Pro is a digital forensic tool suite CD that offers both a “live” and bootable forensic environment. For more information about Helix3 Pro, go to http://www.e-fense.com/helix3pro.php.

12

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• The most common method to collect system date and time is to issue the • •

date /t and time /t commands from a trusted command shell in your live response toolkit. After recording the date and time from the subject system, compare them to a reliable time source to verify the accuracy of the information. Identify and document any discrepancies for comparison to the date and time stamps of other artifacts you discover on the system.

System Identifiers u In addition to collecting the system date and time, collect as much system identification and status information from the subject host as possible prior to launching into live response examination, including:89 System Identifier

Tool/Command

Host name

Identify the name of the subject system by using a trusted version of the hostname utility, which is native to Windows operating systems.

Current user

Identify the current system user with the whoami8 ­command.

Operating system/ environment

Collect system environment identifiers by issuing the ver9 command.

IP address and related network identifiers

The ipconfig/all command is used to display the IP address assigned to the subject system, along with the system hostname, network subnet mask, DNS servers, and related details.

Network Configuration u When documenting the configuration of the subject system, keep an eye open for unusual items. • Look for a Virtual Private Network (VPN) adapter configured on a system that does not legitimately use a VPN. • Determine whether a network card of the subject system is in promiscuous mode, which generally indicates that a sniffer is running. • Several tools are available to query a network configuration, including promiscdetect10 and Microsoft’s promqry11 (which requires the .NET framework). 8   For more information about whoami, go to http://www.microsoft.com/downloads/en/details .aspx?familyid=3E89879D-6C0B-4F92-96C4-1016C187D429&displaylang=en. 9   For more information about ver, go to http://technet.microsoft.com/en-us/library/bb491028.aspx. 10   For more information about promisdetect, go to http://www.ntsecurity.nu/toolbox/promiscdetect/. 11   For more information about promqry, go to http://www.microsoft.com/downloads/en/details .aspx?familyid=4df8eb90-83be-45aa-bb7d-1327d06fe6f5&displaylang=en.

Chapter | 1 Malware Incident Response

13

Enabled Protocols u Document which protocols are enabled on the subject system to help identify potential vectors of attack. • Identify the protocols enabled on the subject system using the URLProtocolView utility from NirSoft.12 System Uptime u Determine how long the subject system has been running, or the system uptime. • Knowing that the subject system has not been rebooted since malware was installed can be important, motivating digital investigators to look more closely for deleted processes and other information in memory that otherwise might have been destroyed. • To determine system uptime, invoke the uptime13 utility from your trusted toolkit, as shown in Figure 1.12. E:WinIRSysinfo>uptime \KIM-MRKTG-WS5 has been up for: 0 day(s), 0 hour(s), 52 minute(s), 20 second(s)

FIGURE 1.12–Querying a system with the uptime command

System Environment u Documenting general details about the subject system, including operating system version, patch level, and hardware, is useful when conducting an investigation of a Windows system. • System environment information may reveal that the system is outdated and therefore susceptible to certain attacks. • Knowing the version of Windows can be helpful when performing forensic examination of a memory dump. • A granular snapshot of a subject system’s environment and status can be obtained by querying the system with psinfo,14 as shown in Figure 1.13 on the next page. 

Identifying Users Logged into the System

R After conducting initial reconnaissance of the subject system details, identify the users logged onto the subject system both locally and remotely. u Identifying logged on users serves a number of investigative purposes, such as to: • Help discover any potential intruders logged into the compromised system. 12

  For more information about URLProtocolView, go to http://www.nirsoft.net/utils/url_ protocol_view.html. 13   For more information about uptime.exe, go to http://support.microsoft.com/kb/232243. 14   For more information about psinfo, go to http://technet.microsoft.com/en-us/sysinternals/ bb897550.aspx.

14

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

E:WinIRSysinfo>psinfo PsInfo v1.74 — Local and remote system information viewer Copyright (C) 2001-2005 Mark Russinovich Sysinternals — www.sysinternals.com System information for \KIM-MRKTG-WS5: Uptime: 0 days 0 hour 52 minutes 20 seconds Kernel version: Microsoft Windows XP, Uniprocessor Free Product type: Professional Product version: 5.1 Service pack: 2 Kernel build number: 2600 Registered organization: ****** Company Registered owner: Kim Install date: 8/27/2007, 1:03:53 PM Activation status: Error reading status IE version: 6.0000 System root: C:WINDOWS Processors: 1 Processor speed: 1.8 GHz Processor type: Intel(R) Core(TM)2 CPU 6320 @ Physical memory: 1028 MB Video driver: Radeon X1300 Series

FIGURE 1.13–Collecting system information with psinfo

• Identify additional compromised systems that report to the subject system as a result of the malicious code incident.

• Provide insight into a malicious insider malware incident. • Provide additional investigative context by being correlated with other artifacts discovered.

• Obtain the following information about identified users logged onto the subject system: r Username r Point of origin (remote or local) r Duration of the login session r Shares, files, or other resources accessed by the user r Processes associated with the user r Network activity attributable to the user u There are a number of utilities that can be deployed during live response to identify users logged onto a subject system, including PsLoggedOn,15 quser,16 netusers,17 and loggonsessions.18 15

  For more information about PsLoggedOn, go to http://technet.microsoft.com/en-us/ sysinternals/bb897545.aspx. 16   For more information about quser, go to http://technet.microsoft.com/en-us/library/ cc754583%28WS.10%29.aspx. 17   For more information about netusers, go to http://www.systemtools.com/cgi-bin/download .pl?NetUsers. 18   For more information about loggonsessions, go to http://technet.microsoft.com/en-us/ sysinternals/bb896769.aspx.

Chapter | 1 Malware Incident Response

15

u PsLoggedOn is a CLI utility that is included in the PsTools suite that identifies users logged onto a subject system both locally and remotely. In addition, PsLoggedOn reveals users that have accessed a subject system from resource shares, such as shared drives.

Inspect Network Connections and Activity R Network connections and activity on the subject system can reveal vital information about an attacker’s connection to the system, including the location of an attacker’s remote data collection server and whether the subject system is beaconing to a command and control structure, among other things. u In surveying a potentially infected and compromised system, try to obtain the following information about the network activity on the subject system: • Active network connections • DNS queries made from the subject system • NetBIOS name table cache • ARP cache • Internal routing table Investigative Considerations • In addition to network activity analysis, conduct an in-depth inspection of open ports on the subject system, including correlation of the ports to associated processes. Port inspection analysis is discussed later in this chapter.

Active Network Connections u An investigator should identify current and recent network connections to determine (1) whether an attacker is currently connected to the subject system, and (2) if malware on the subject system is causing the system to call out, or “phone home,” to the attacker, such as to join a botnet ­command and control structure. • Often, malicious code specimens such as bots, worms, and Trojans have instructions embedded in them to call out to a location on the Internet, whether a domain name, Uniform Resource Locator (URL), or IP address, or to connect to another Web resource to join a collection of other compromised and “hijacked” systems and await further commands from the attacker responsible for the infection. • To examine current network connections, a common approach is to use a trusted version of the netstat19 utility on the subject system. Netstat is a utility native to the various Windows operating systems that displays information pertaining to established and “listening” network socket connections on the subject system. @ 19

  For more information about netstat, go to http://technet.microsoft.com/en-us/library/ cc940097.aspx.

16

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• For granularity of results, query with the netstat

–ano command (available on Microsoft Windows XP and subsequent versions; see Figure 1.14), which along with displaying the nature of the connections on the subject system, reveals: r Whether the session is Transmission Control Protocol (TCP) or UDP protocol r The status of the connection r The address of connected foreign system(s) r The process ID number of the process initiating the network connection

E:WinIRNetwork>netstat -ano Active Connections Proto TCP TCP TCP TCP TCP TCP UDP UDP

Local Address Foreign Address State PID 0.0.0.0:113 0.0.0.0:0 LISTENING 864 0.0.0.0:135 0.0.0.0:0 LISTENING 988 0.0.0.0:445 0.0.0.0:0 LISTENING 4 127.0.0.1:1028 0.0.0.0:0 LISTENING 1196 192.168.110.134:139 0.0.0.0:0 LISTENING 4 192.168.110.134:1040 xxx.xxx.xxx.xxx:6667 ESTABLISHED 864 0.0.0.0:445 *:* 4 0.0.0.0:500 *:* 748

FIGURE 1.14–Netstat –ano command

• Alternatively, the netstat

–an command reveals the same information but without the process ID associated with the connection.

DNS Queries from the Host System u Many malware specimens have network connectivity capabilities, whether to gather further exploits from a remote location, join a command and control structure, or await further commands from an attacker. Many times, the malware is hard coded with connectivity instructions in the form of domain names, which the program will attempt to query and resolve to identify the location of the network-based resource to which it is intended to connect. • To collect the DNS queries made from a subject system, issue the ipconfig/displaydns command from your trusted toolkit. NetBIOS Connections u When native Windows networking is involved, additional details about active network connections may be available that can be useful in an investigation. There may be volatile data showing which ­computers

Chapter | 1 Malware Incident Response

17

were recently connected to the subject system and what files were transferred. • Windows networking uses the NetBIOS protocol, which supports a variety of services, such as file and printer sharing. • Each computer that is configured with NetBIOS is assigned a unique name used to communicate with others. • The NetBIOS name cache on a subject system is a section in system memory that contains a mapping of NetBIOS names and IP addresses of other computers with which the subject system has had NetBIOS communication.20 • The NetBIOS name cache is volatile and is preserved for a limited period of time. • Capture the NetBIOS name cache using a trusted version of the native Windows utility, nbtstat with the –c option, which displays a list of cached remote machine names and their corresponding IP addresses.21  @ • Identify current NetBIOS sessions by using the nbtstat –S option and the net sessions command. @ • Identify if any files were recently transferred over NetBIOS using the net file command. @

ARP Cache u The Address Resolution Protocol (ARP) resolves Media Access Control (MAC) addresses or Ethernet addresses (residing at the Data Link Layer in the Open Systems Interconnect (OSI) model) to IP addresses (residing at the Network Layer of the OSI model).22 • The mapping of these addresses is stored in a table in memory called the ARP cache or ARP table. • Examination of a subject system’s ARP cache will identify other systems that currently or recently have established a connection to the subject system. • To display the contents of the ARP cache, issue the arp –a command23 from your trusted command shell, which will reveal the IP address assigned to the subject system, along with the IP addresses and MAC addresses assigned to suspicious systems that are currently or have recently had connections to the subject system. @ 20

  For more information about NetBIOS names, go to http://msdn.microsoft.com/en-us/library/ ms817948.aspx. 21   For more information about nbtstat, go to http://technet.microsoft.com/en-us/library/ cc940106.aspx. 22   For more information about ARP, go to http://technet.microsoft.com/en-us/library/bb490864 .aspx. 23   For more information about the arp command, go to http://www.microsoft.com/resources/ documentation/windows/xp/all/proddocs/en-us/arp.mspx?mfr=true.

18

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

COLLECTING PROCESS INFORMATION

R Collecting information relating to processes running on a subject system is essential in malicious code live response forensics. Once executed, malware specimens, such as worms, viruses, bots, key loggers, and Trojans, often manifest on the subject system as a process. u During live response, collect certain information pertaining to each running process to gain process context, or a full perspective about the process and how it relates to the system state and to other artifacts collected from the system. To gain the broadest perspective, a number of tools gather valuable details relating to processes running on a subject system. Although this chapter covers some of these tools, refer to the Tool Box section at the end of this chapter and on the companion Web site, http://www.malwarefieldguide.com/Chapter1.html, for additional tool options. @ • Start by collecting basic process information, such as the process name and Process Identification (PID), with subsequent queries to obtain the following details: r Process name and PID r Temporal context r Memory consumption r Process to executable program mapping r Process to user mapping r Child processes r Invoked libraries and dependencies r Command-line arguments used to invoke the process r Associated handles r Memory contents of the process r Relational context to system state and artifacts

Process Name and Process Identification The first step in gaining process context is identifying the running processes, typically by name and associated PID. • To collect a simple list of running processes and assigned PIDs from our subject system, use tlist,24 a multifunctional process viewer utility for Windows distributed with Debugging Tools for Windows. u

Temporal Context To gain historical context about the process, determine the period of time the process has been running. • Obtain process activity times by using pslist in the PsTools suite. • The pslist utility displays, among other details:

u

24

  For more information about tlist.exe, go to http://www.microsoft.com/downloads/en/ details.aspx?familyid=C055060B-9553-4593-B937-C84881BCA6A5&displaylang=en.

Chapter | 1 Malware Incident Response

r r r

19

The names of running processes Associated PIDs The amount of time each process has been running on a system

Memory Usage u Examine the amount of system resources that processes are consuming. Often, worms, bots, and other network-centric malware specimens are “active” and can be noticeably resource-consuming, particularly on a system with less than 2 GB of RAM. • To get output identifying running processes, associated PIDs, and the respective memory usage of the processes, use a trusted version of the tasklist utility with no switches.25  @

Process to Executable Program Mapping: Full System Path to Executable File Determine where the executable images associated with the respective processes reside on the system. This effort will provide further contextual information, including whether an unknown or suspicious program spawned the process, or if the associated program is embedded in an anomalous location on the system, necessitating a deeper investigation of the program. • To get an overview of the running processes and associated location of executable program locations, use PRCView (pv.exe)26 with the -e switch, as shown in Figure 1.15.

u

E:WinIRProcesses>pv.exe –e

PROCESS smss.exe winlogon.exe services.exe lsass.exe svchost.exe svchost.exe Explorer.EXE spoolsv.exe msmsgs.exe wscntfy.exe wuauclt.exe dllhost.exe spoolsv.exe rundll32.exe cmd.exe pv.exe

PID 520 692 736 748 908 1084 1480 1600 1760 1700 1036 804 864 1292 1644 796

PRIO Normal High Normal Normal Normal Normal Normal Normal Normal Normal Normal Normal Normal Normal Normal Normal

PATH C:WINDOWSSystem32smss.exe C:WINDOWSsystem32winlogon.exe C:WINDOWSsystem32services.exe C:WINDOWSsystem32lsass.exe C:WINDOWSsystem32svchost.exe C:WINDOWSSystem32svchost.exe C:WINDOWSExplorer.EXE C:WINDOWSsystem32spoolsv.exe C:Program FilesMessengermsmsgs.exe C:WINDOWSsystem32wscntfy.exe C:WINDOWSsystem32wuauclt.exe C:WINDOWSSystem32dllhost.exe C:WINDOWStempspoolsvspoolsv.exe C:WINDOWSsystem32rundll32.exe C:WINDOWSsystem32cmd.exe e:WinIRProcessespv.exe

FIGURE 1.15–Using PRCView to reveal the location of executables associated with running processes 25

  For more information about tasklist, go to http://technet.microsoft.com/en-us/library/ bb491010.aspx. 26   For more information about PRCView, go to http://www.teamcti.com/pview/prcview.htm.

20

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Process to User Mapping During the course of identifying the executable program that initiated a process, determine the owner of the process to gain user and security context relating to the process. Anomalous system users or escalated user privileges associated with running processes are often indicative of a rogue process. • Using tasklist with the –V switch, identify the program name, PID, memory usage, program status, and associated username. u

Child Processes Often upon execution, malware spawns additional processes, or child processes. Upon identifying a potentially hostile process during live response, analyze the running processes in such a way as to identify the hierarchy of potential parent and child processes. • Query the subject system with any of the following commands to obtain a structured and hierarchical “tree” view of processes. u

Tool

Command

Pslist

pslist –t

Tlist

tlist –t

PRCView

pv –t

Command-line Parameters u While inspecting running processes on a system, determine the ­command-line instructions, if any, that were issued to initiate the running processes. Identifying command-line parameters is particularly useful if a rogue process already has been identified, or if further information about how the program operates is sought. • The command-line arguments associated with target processes can be collected by querying a subject system with any of the following commands.

Tool

Command

Cmdline

Invoking cmdline with no switches displays the process ID number, the full system path, and the executable file associated with each process running on the system. By issuing the –pid argument and supplying the PID number of a specific process of interest, cmdline will only display information relating to that process.

Tlist

tlist –c

PRCView

pv –l

Chapter | 1 Malware Incident Response

21

File Handles u Another important aspect to examining running processes is to identify handles opened by the respective processes. System resources like files, threads, or graphic images are data structures commonly referred to as objects. Often, programs cannot directly access object data and must rely upon an object handle to do so. • Each handle has an entry in an internally maintained handle table containing the addresses of the resources and the means to identify the resource type. • To get additional context about the nature of running processes, obtain information about which handles and associated resources the processes are accessing by using the handle27 utility. • The handle utility has a number of switches that can be applied, but for the purpose of revealing all handles related to the running processes, use the handle –a command.

Dependencies Loaded by Running Processes Dynamically linked executable programs are dependent upon shared libraries to successfully run. In Windows programs, these dependencies are most often Dynamic Link Libraries (DLLs) that are imported from the host operating system during execution. Identifying and understanding the DLLs invoked by a suspicious process can potentially define the nature and purpose of the process. • Many malicious code specimens, particularly rootkits, use a technique called “DLL injection,” wherein malware “injects” code into the address space of a running process by forcing it to load a dynamic link library.28 • A great utility for viewing the DLLs loaded by a running process is listdlls,29 which identifies the modules invoked by a process and reveals the full path to the respective modules. Other utilities to consider for this task include Procinterrogate,30 PRCView,31 and List­ Modules.32  @ u

27

  For more information about handle.exe, go to http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/Handle.mspx. 28   An example of malware that implements this technique is the Vanquish Rootkit, a DLLinjection-based rootkit that hides files, folders, and registry entries and logs passwords. For more information about Vanquish Rootkit, go to https://www.rootkit.com/vault/xshadow/ReadMe.txt. 29   For more information about listdlls.exe, go to http://technet.microsoft.com/en-us/sysinternals/bb896656.aspx. 30   For more information about Procinterrogate, go to http://sourceforge.net/project/shownotes .php?release_id=122552&group_id=15870. 31   For more information about PRCView, go to http://www.teamcti.com/pview/prcview.htm. 32   For more information about ListModules, go to http://ntsecurity.nu/toolbox/listmodules/.

22

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Exported DLLs u To discover the DLLs exported by an executable program that launched a process—that is, identifying the functions or variables made usable by other executable programs—consider querying a subject system with NirSoft’s DLLExportViewer.33 • DLLExport view provides the investigator with the exported function name, address, relative address, file name, and full path of the module. Capturing the Memory Contents of a Process on a Live Windows System u During the course of examining running processes on a subject system, potentially rogue processes may be identified. In addition to locating and documenting the potentially hostile executable programs, capture the individual process memory contents of the specific processes for later analysis, as described in Chapter 2.

CORRELATE OPEN PORTS WITH RUNNING PROCESSES AND PROGRAMS

R In addition to identifying the open ports and running processes on a subject system, determine the executable program that initiated a suspicious established connection or listening port, and determine where that program resides on the system. u Examining open ports apart from active network connections is often inextricably intertwined with discoveries made during inspection of running processes on a subject system. • When examining active ports on a subject system, gather the following information, if available: r Local IP address and port r Remote IP address and port r Remote host name r Protocol r State of connection r Process name and PID r Executable program associated with process r Executable program path r User name associated with process/program • Process-to-port correlation can be conducted by querying a subject system with any of the following commands. Further details regarding the tools referenced in this table can be found in the Tool Box section at the end of the chapter and on the companion Web site, http://www .malwarefieldguide.com/[email protected] 33

  For more information about DLLExportViewer, go to http://www.nirsoft.net/utils/dll_export_ viewer.html.

23

Chapter | 1 Malware Incident Response

Tool

Command

Information Gathered

Netstat

netstat -ano netstat –anb [the “b” option requires escalation (i.e., Run As Administrator)]

Displays protocol, status of connection, foreign address in connection, PID of process initiating connection. When investigating Windows XP (SP2) and newer Windows operating systems, this command correlates open ports with associated processes and displays the executable program and related components sequentially involved in creating each connection or listening port, as shown in Figure 1.16, below.

Openports

-lines and -path

Provides a clear structured perspective of the active ports’ associated process and executable programs along with the system path where the respective programs reside.

Fport

/p /a /i /ap

Sort by port Sort by process Sort by PID Sort by process path

CurrPorts

/stext

Provides a detailed snapshot of the process name, PID, local and remote port numbers and IP addresses, port state, protocol, executable program path, and other detailed identifying information.

E:WinIRPorts>netstat –anb

Active Connections Proto Local Address TCP 0.0.0.0:113 [spoolsv.exe]

Foreign Address 0.0.0.0:0

TCP 0.0.0.0:135 0.0.0.0:0 c:windowssystem32WS2_32.dll C:WINDOWSsystem32RPCRT4.dll c:windowssystem32rpcss.dll C:WINDOWSsystem32svchost.exe C:WINDOWSsystem32ADVAPI32.dll [svchost.exe] TCP 192.168.110.134:1040 [spoolsv.exe]

198.xxx.xxx.xxx

State LISTENING

PID 864

LISTENING

988

ESTABLISHED 864

FIGURE 1.16–Results of the netstat –anb command on a subject system

Identifying Services and Drivers

R Many malware specimens will manifest on a subject system as a service or surreptitiously install driver files.

24

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Examining Running Services Microsoft Windows services are long-running executable applications that run in their own Windows sessions; they do not require user initiation or interaction.34 Services can be configured to automatically start when a computer is booted up, paused, and restarted without showing up in any user interface. Malware can manifest on a victim system as a service, silently running in the background, unbeknownst to the user. • As with the examination of running processes and ports, explore running services by first gaining an overview and then applying tools to extract information about the services with more particularity. • While investigating running services, gather the following information: r Service name r Display name r Status r Startup configuration r Service description r Dependencies r Executable program associated with service r Process ID r Executable program path r User name associated with service • Gain a good overview of the running services on a subject system by using a trusted version of tasklist with the /svc switch, which displays services in each process. • The output from this command provides a concise listing of the executable program name, PID, and description of the service, if applicable. • To gather greater detail about running services, refer to the Tool Box section at the end of this chapter and on the companion Web site, http:// www.malwarefieldguide.com/Chapter1.html. @ u

Examining Installed Drivers In addition to determining the running services on a subject system, consider examining the installed drivers on the system, including the nature and status of the drivers.35 u

34

  For more information about Microsoft Windows services, go to http://msdn.microsoft.com/ en-us/library/ms685141.aspx. 35   In 2006, a printer driver distributed by Hewlett Packard was found to be infected with the Funlove virus. Another piece of malicious code emerged in August 2007 named Trojan. Peacomm.C infects a Windows device driver named “kbdclass.sys” to force the system to load the virus each time the system is rebooted. Unfortunately, this Trojan also employs rootkit techniques to hide its presence on the infected system, becoming invisible to the operating system. In such cases, memory forensics can be employed to extract more information about the malicious code. For more information, go to http://www.symantec.com/enterprise/security_response/ weblog/2007/08/the_new_peacomm_infection_tech.html.

Chapter | 1 Malware Incident Response

25

• To explore installed system drivers, query the subject system with a trusted version of List Loaded Driver (drivers.exe)36 and [email protected] • The output provided by List Loaded Drivers (drivers.exe) is verbose and granular. Compare a thorough examination of any suspicious files acquired from the subject system against the collected data to identify artifacts of value.

Determining Open Files

R Open files may identify the nature of the malicious code that has infected a system by revealing the services or resources that the specimen requires to effectively launch or operate. • Open files may reveal other correlating or identifying information about suspicious processes identified during the course of live response. • If malware has given the attacker access into the compromised system, the attacker, during the course of intrusion, may have opened certain files. • Identifying open files may explain the purpose of the attack, whether probing financial databases, sensitive corporate information, or other unique resources on the system. • Examine files opened locally and remotely.

Identifying Files Opened Locally

• To examine files opened locally, query the subject system with Open FilesView.38 @ • OpenedFilesView displays a list of all opened files on a subject system and additional information about the accessed files, such as: r The process that opened the file r The associated handle value r Read/write/delete access times; and r File location on the system

Identifying Files Opened Remotely

• A remote connection from an anomalous system or share accessing files on the subject system are potentially indicia of compromise, so endeavor to identify files that are accessed remotely.

36

  For more information about List Loaded Drivers, go to http://support.microsoft.com/kb/927229 (available from the Windows 2000 Resource Kit Tools) and http://download.microsoft.com/download/win2000platform/drivers/1.0/NT5/EN-US/drivers.exe. 37   For more information about DriverView, go to http://www.nirsoft.net/utils/driverview.html. 38   For more information about OpenFilesView, go to http://www.nirsoft.net/utils/opened_files_ view.html.

26

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• Query the subject system with a trusted version of the native net mand or the psfile utility.39

file com-

Collecting Command History

R Keystrokes typed by an attacker (or nefarious insider) into a Windows command prompt that remains open can be retrieved during live response. • Display all of the commands that are stored in memory by issuing the doskey/history40 command from the toolkit’s trusted command prompt. • The doskey/history command can be configured to hold a maximum of approximately 61,900 bytes of data. • Command prompt history can provide valuable contextual evidentiary information, such as: r The names of files and folders accessed r Commands issued r Programs launched r Unique string names r Network identifiers such as domain names, IP addresses, shares, and resources

Identifying Shares

R Although malicious code does not always exhibit the ability to propagate through network shares, some specimens identify and affect shares on an infected system.41 • To query a subject system to identify available shares, use a trusted version of the native Windows utility, net, as seen in Figure 1.17. E:WinIRShares>net share Share name

Resource

Remark

———————————————————————ADMIN$

C:WINDOWS

Remote Admin

C$

C:

Default share

IPC$

Remote IPC

The command completed successfully.

FIGURE 1.17–Identifying shares on a subject system

39

  For more information about psfile, go to http://technet.microsoft.com/en-us/sysinternals/ bb897552.aspx. 40   For more information about doskey, go to http://technet.microsoft.com/en-us/library/ bb490894.aspx?wt.slv=3D=. 41   For example, the polymorphic file infector named W32/Bacalid, http://vil.nai.com/vil/ Content/v_140566.htm.

Chapter | 1 Malware Incident Response

27

Determining Scheduled Tasks

R Some malicious code variants are “event-driven,” meaning that until a certain date or event triggers execution, the malware remains dormant. u Event-driven malware is typically referred to as a logic bomb. Typically, most logic bomb malware specimens are planted and secreted by a malicious insider, particularly by those users with administrative access to systems.42 However, some external malicious code threats have displayed logic bomb features.43 Thus, examine a subject system for scheduled tasks to ensure that a malicious program is not hidden away waiting to execute. • Reveal discovered scheduled tasks on a subject machine using a trusted version of the native Windows utility at.44 • Confirm your findings by querying with schtasks,45 which is also native to Windows XP and subsequent versions. @

Collecting Clipboard Contents

R In the instance of a potentially compromised system wherein the infection vector is unknown, the clipboard contents can potentially provide substantial clues into the nature of an attack, particularly if the attacker is an insider “threat” and has copied bits of text to paste into tools or attack strings. • The clipboard contents may contain: r Domain names r IP addresses r E-mail addresses r Usernames and passwords r Hostnames r Instant messenger chat or e-mail content excerpts r Attack commands r Other valuable artifacts identifying the means or purpose of the attack • Examine the contents of a subject system’s clipboard with pclip,46 which collects and displays the contents of the clipboard, seen here in Figure 1.18. @

42

  For example, in early 2008, a system administrator was sentenced to 30 months in prison for embedding malicious code designed to wipe out critical data stored on more than 70 servers (http://newark.fbi.gov/dojpressrel/2007/nk091907.htm). 43   An example of such a specimen is WORM_SOHANAD.FM, which once downloaded by an unsuspecting user from a malicious Web site, installs three additional malicious code files, and uses the Windows Task Scheduler to create a scheduled task to execute the files at a later time. For more information about WORM_SOHANAD.FM, go to http://www.trendmicro.com/vinfo/ virusencyclo/default5.asp?VName=WORM%5FSOHANAD%2EFM&VSect=P. 44   For more information about the at command, go to http://support.microsoft.com/kb/313565. 45   For more information about schtasks.exe, go to http://technet2.microsoft.com/windowsserver/en/library/1d284efa-9d11-46c2-a8ef-87b297c68d171033.mspx?mfr=true. 46   For more information about pclip.exe, go to http://unxutils.sourceforge.net.

28

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

E:WinIRClipboard>pclip.exe ftp.xxxx.net gorlan www.gmail.com [email protected] Mike XXXXXXX

FIGURE 1.18–Exploring the clipboard contents with pclip.exe

NON-VOLATILE DATA COLLECTION FROM A LIVE WINDOWS SYSTEM Traditionally, forensic examiners do not access files on the hard drive of a live system because of the potential risk of altering stored data. However, some situations require selective forensic preservation and examination of data in files and within the registry of live systems. In some cases, the quantity of non-­volatile data on a computer’s system is so large that its preservation is not feasible. Expending resources to create a forensic duplicate of a server that contains terabytes of documents and other data unrelated to the malware incident may not make sense. Instead, acquiring only the information that is generally the most relevant and useful may be the better approach. Similarly, in cases involving a large number of computers, forensic duplication of only critical systems coupled with information gathering from the remaining machines may best support the victim’s needs or ability to pursue legal or other remedies.

 Analysis Tip

Handle with Care Whether to collect non-volatile data from a live system must be carefully considered. Operating a live system inevitably makes changes, like updating last accessed dates of files. Whether such changes will hinder the investigation or alternatively be deemed an acceptable loss of information for the benefit of acquiring usable digital evidence is a judgment call. In certain cases, the only option may be to collect non-volatile data from a live system. From a business interference standpoint, the system owner may be unable to accept actions that would disrupt the system (i.e., transaction server processing thousands of credit card transactions a minute). In such cases, obtain written confirmation of authorization to perform actions that could result in a reboot, temporary loss of service, or other perceived disruption. Once the decision is made to perform preservation processes on a live system, take great care to minimize changes and thoroughly document actions taken to both distinguish them from the effects of malware and defend them in court, if necessary.

Chapter | 1 Malware Incident Response

29

Forensic Duplication of Storage Media on a Live Windows System

R When dealing with high availability servers and other systems that cannot be shut down, create a forensic duplicate of the entire system while the computer is still running. u The same approaches to preserving physical memory on a live system can be used to acquire a forensic duplicate of any storage media connected to the system. • The following command takes the contents of an internal hard drive and saves it to a file on removable media along with the MD5 hash (for integrity/validation purposes) and an audit log that documents the collection process (Figure 1.19). E:WinIRnonvolatile>dd.exe if=\.PhysicalDrive0 of=»E:WinIRnonvolatileimageshost1-diskimage-20070124.dd» conv=sync,noerror —md5sum —verifymd5 -md5out=»E:WinIRnonvolatileimageshost1-diskimage20070124.dd.md5″ —log=»E:WinIRnonvolatileimageshost1-diskimage20070124.dd_audit.log» FIGURE 1.19–Forensic duplication of a hard drive using dd

Investigative Considerations • Saving a forensic duplicate of the hard drive in a live system onto another computer on the local area network is generally faster than saving to removable media, depending on the throughput. • Save the forensic duplicate on a remote computer either via an SMB share on the remote system or using the netcat command. Remote forensic tools such as EnCase Enterprise, OnlineDFS, and ProDiscoverIR also have the capability of acquiring a forensic duplicate of the hard drive from a remote system. @

Forensic Preservation of Select Data on a Live Windows System

R Certain areas of a live Windows computer commonly contain information about the installation and operation of malware. u Methodical approaches to extracting evidence from these areas are presented in the following list. These approaches are not intended to be comprehensive or exhaustive, but rather provide a solid foundation for the discovery of evidence relating to malware resident on a live Windows computer. • When more extensive forensic analysis is required, such as hash analysis and keyword searching, work should be performed on a forensic image, as discussed in Chapter 3. Although the tools covered in this section are

30

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

•

designed to run on live Windows systems, some also are useful in postmortem analysis. The following non-volatile data analysis can aid in understanding the malware: r Assess security configuration r Acquire host files r Examine prefetch r Review auto-start r Examine logs r Review user accounts r Examine file system r Examine registry

Assess Security Configuration

R Determining whether a system was well secured can help assess the risk level of the host to misuse, vulnerabilities, and possible vectors of attack. • Collect patch level and version information for a Windows system using the WinUpdatesList utility.47 • Logging level and access control lists can be extracted using auditpol48 and dumpsec.49 @ • If security logging is not enabled, there will most likely be no log entries in the Security Event Log. • When a system is configured to record security events but the Security Event Log is empty, ascertain whether the logs are stored elsewhere or were intentionally cleared.

Assess Trusted Host Relationships

R Preserve the files in “%windir%system32driversetc” that contain information about trusted hosts and networks. These files are used for localized name resolution, without relying on DNS. • The “hosts” file contains associations between IP addresses and hostnames. • The “networks” file contains associations between ranges of IP addresses and network names, which are generally assigned by network administrators. • The “lmhosts” file contains associations between the IP address and NetBIOS names. As shown in Figure 1.20, the contents of these files can be displayed without modification and saved into individual log files using a trusted version of the Windows type command. u

47

  For information about WinUpdatesList, go to http://www.nirsoft.net/utils/wul.html.   For more information about auditpol, go to http://technet.microsoft.com/en-us/library/ cc731451%28WS.10%29.aspx. 49   For more information about dumpsec, go to http://www.systemtools.com/download/ dumpacl.zip. 48

Chapter | 1 Malware Incident Response

31

E:WinIRHoststype %windir%system32driversetchosts >> e:ResultsHostshosts.log E:WinIRHoststype %windir%system32driversetcnetworks >> e:ResultsHostsnetworks.log E:WinIRHoststype %windir%system32driversetclmhosts >> e:ResultsHostslmhosts.log

FIGURE 1.20–Collecting hosts, networks, and lmhosts from a subject system

Investigative Considerations • Examine these logs for modifications. Some malware alters the contents of these files to block access to major anti-virus and Microsoft sites, thus preventing a compromised host from receiving security patches and anti-virus updates.

Inspect Prefetch Files

R To improve efficiency when a program is executed, the Windows operating system creates a “prefetch” file that enables speedier subsequent access to the program. u Anomalous prefetch files are potential artifacts evidencing compromise of the subject system. • Prefetch files are located in “%systemroot%Prefetch” and, among other information, contain the name of the program when it was executed. • The creation date of a particular prefetch file generally shows when the associated program was first executed on the system, and the last modified date indicates when it was most recently executed. @ • To document the creation and last modified dates of files in the prefetch directory, use a trusted command shell (cmd.exe) to invoke the following commands (see Figure 1.21): E:WinIRPrefetchcmd.exe /C dir «%SystemRoot%prefetch» > E:WinIRPrefetchprefetch-lastmodified.txt E:WinIRPrefetchcmd.exe /C dir /TC «%SystemRoot%prefetch» > E:WinIRPrefetchprefetch-created.txt

FIGURE 1.21–Listing prefetch files from a trusted command shell

Inspect Auto-starting Locations

R When a system is rebooted, the number of places where Windows automatically starts programs serve as persistence mechanisms for malware. u These auto-starting locations exist in particular folders, registry keys, system files, and other areas of the operating system. • References to malware embed in these auto-starting locations to increase the malware’s longevity on a computer.

32

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• One of the most effective tools for viewing auto-start locations • •

is AutoRuns,50 which has both GUI and command-line versions (autorunsc). Query a subject system for all auto-starting entries using the autorunsc –a command. @ AutoRuns has a feature to ignore legitimate, signed Microsoft items, reducing the volume of output.

Investigative Considerations • Be aware that there will generally be a large number of legitimate third-party programs in auto-start locations. Inspect most, or all, of these executables to best identify the extent of the malware on the system (see Figure 1.22). E:WinIRAutorunsautorunsc.exe -a

HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun spoolsv mIRC mIRC Co. Ltd. C:windowstempspoolsvspoolsv.exe

FIGURE 1.22–AutoRuns discovering a suspect program

Collect Event Logs

R Many activities related to a malware incident can generate entries in the Event Logs on a Windows system. u Look for failed logon attempts recorded in the Security Event Log and antivirus warning messages recorded in the Application Event Log. • These logs are stored in a proprietary Microsoft format; extract them in American Standard Code for Information Interchange (ASCII) text form for examination using log analysis tools that do not support the native Event Log format. • Collecting these logs from the live system will extract the native message strings from that system. • These logs can be collected using eldump, a utility specifically designed to process Event Logs from Windows systems. The same utility also can be used to read saved Event Log files.51 • As shown in Figure 1.23, to collect specific event logs from a subject system with eldump use the –l switch and the name of the log (security, system, or application). @ 50   For more information about AutoRuns, go to, http://technet.microsoft.com/en-us/sysinternals/ bb963902.aspx. 51   For more information about eldump, go to www.ibt.ku.dk/jesper/ELDump/default.htm.

Chapter | 1 Malware Incident Response

33

E:WinIReventlogseldump -l security > E:WinIReventlogssecurityevents.log E:WinIReventlogseldump -l system > E:WinIReventlogssystemevents.log E:WinIReventlogseldump -l application > E:WinIReventlogsapplicationevents.log

FIGURE 1.23–Collecting Event View Logs with eldump.exe

Logon and Logoff Events To obtain a list of logon and logoff events associated with associated users, use the NTlast utility.52 • This information may be particularly pertinent when a malicious insider is the suspected wrongdoer, as opposed to an “outside” attacker. u

Review User Account and Group Policy Information

R A close inspection of user accounts local to the compromised system, or domain accounts used to log in, can reveal how malware was placed on the computer. u Look for the unauthorized creation of new accounts, accounts with no passwords, or existing accounts added to Administrator groups. • Check for user accounts that are not supposed to be in local or domain level administrator groups. • The net user command can be used to list all accounts on the local system. @

Examine the File System

R A quick review of certain types of files can reveal relevant information and provide additional context to collected volatile data. u Identify hidden files, alternate data streams, and files in the Recycle Bin. • The HFind and SFind53 utilities in the Forensic Toolkit from Foundstone can be used to locate alternate data streams and files that are hidden from the general user by the operating system and can be listed using HFind. @ • A list of files that have been placed in the Recycle Bin can be obtained by reading the INFO file using a tool like Foundstone’s rifiuti.54 52   For more information about NTlast, go to http://www.foundstone.com/us/resources/proddesc/ ntlast.htm. 53   For more information about SFind, go to http://www.foundstone.com/us/resources/proddesc/ forensictoolkit.htm. 54   For more information about rifiuti, go to http://www.foundstone.com/us/resources/proddesc/ rifiuti.htm.

34

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Investigative Considerations • Also consider acquiring file system metadata relating to file time stamps for additional temporal context. r When the time frame of the malware incident is known, metadata for all files created, modified, or accessed during that period can be obtained using the macmatch.exe55 utility. r For instance, the following command (Figure 1.24) lists all files created between March 26 and 28 in 2010. E:WinIRMACtimes>macmatch C: -c 2010-03-26:00.00 2010-03-28:00.00

FIGURE 1.24–Using macmatch.exe

Dumping and Parsing Registry Contents

R Although there are tools for examining Registry files in their native format, extracting the contents in ASCII text form can facilitate examination and searching. u There are several tools for extracting information from the Registry on a live system, such as the native Windows utilities reg.exe and, regdump.exe,56 and the Systemtools.com dumpreg57 [email protected] • In addition to dumping the entire Registry contents to a text file, particular areas of interest can be processed individually. • Details about the Universal Serial Bus (USB) devices that have been plugged into the system can be extracted from the Registry with USBView.58 This information may be particularly valuable in the instance of a malicious insider, wherein the infection vector was from a physical access to a system, such as a USB device. Alternately, a user may have inadvertently used a USB device infected with malware that exploits Windows autorun functionality.59 • Examination of the Registry is covered in more depth in Chapter 3 in the context of a full post-mortem forensic examination of a compromised system. 55

  For more information about macmatch.exe, go to http://www.ntsecurity.nu/toolbox/ macmatch/. 56   For more information about regdump, go to http://social.msdn.microsoft.com/Forums/en-US/ windowscompatibility/thread/c14b5017-40ec-4978-a82c-b3758f0808c1/. 57   For more information about dumpreg, go to http://www.systemtools.com/download/dumpreg.zip. 58   For more information about USBView, go to http://www.nirsoft.net/utils/usb_devices_view .html. 59   For instance, in 2008, some USB digital picture frames were infected with various pieces of malware, and a number of Maxtor Basics Personal Storage 3200 hard drives produced by Seagate in late 2007 contained the Win32.AutoRun.ah virus. A Windows system that was configured to launch executables referenced in the “autorun.ini” configuration file stored on the digital picture frame would have installed the virus that stole passwords and sent them to a server on the Internet.

Chapter | 1 Malware Incident Response

35

Remote Registry Analysis

R Registry contents can be acquired from a live subject system remotely with F-Response. u As a discussed earlier in this chapter, F-Response provides read-only access to the full physical disk(s) of a networked computer, as well as the physical memory of most Microsoft Windows systems. • To access the Registry of a remote subject system with an F-Response Field Kit, initiate F-Response on the system, as shown in Figure 1.25.

FIGURE 1.25–Using F-Response to connect to a subject system

• On your examiner system, invoke the iSCSI initiator service and select the “Discovery” tab to add the subject system as a target, as shown Figure 1.26.

FIGURE 1.26–Adding the subject system as a target through the iSCSI initiator service

• Choose the “Advanced” option and provide the same username and password credentials used in the F-Response Remote Configuration (Figure 1.27).

36

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

FIGURE 1.27–Authenticating through the iSCSI initiator to acquire the target system

• After authenticating, the subject system will appear as a target. Select the subject system from the target list (requiring re-authentication) and connect to the subject system; the connection status will be displayed in the target list (Figure 1.28).

FIGURE 1.28–Connecting to the subject system

• Once connected to the subject system F-Response, the subject system’s hard drive can be accessed locally on your examiner system, as shown in Figure 1.29.

FIGURE 1.29–Remote subject system hard drive through F-Response

Chapter | 1 Malware Incident Response

37

FIGURE 1.30–Selecting the target NTUSER.dat from the subject system using RegRipper

• On your local analysis system, invoke RegRipper,60 a Windows Registry

•

• •

data extraction and correlation tool created and maintained by Harlan Carvey. As F-Response has made the subject system drive accessible locally, RegRipper can be pointed at the target NTUSER.dat file of the subject system for data extraction (Figure 1.30). RegRipper is a Windows Registry data extraction and correlation tool written in Perl. Unlike other Registry analysis tools, RegRipper is modular and uses plug-ins to access specific Registry hive files, and in turn, to access and extract specific keys, values, and data. RegRipper accomplishes this through bypassing the Win32API. RegRipper’s plug-in-based architecture allows users to develop custom plug-ins, many of which are shared with the digital forensic community on the RegRipper Web site.61 Examination of the Registry is covered in more depth in Chapter 3, in the con­ text of a full post-mortem forensic examination of a compromised system.

Examine Web Browsing Activities

R With the increasing number of vulnerabilities in Web browsers and the potential for unsafe browsing practices, an examination of Web browser artifacts may reveal how malware was placed on a system. u Client-side exploits have become more and more prevalent, particularly through “drive-by-downloads.” • Drive-by-downloads often occur when a user with an insecure or improperly configured Web browser navigates to a compromised (or nefarious) Web site that is surreptitiously hosting malware, allowing the malware to silently be downloaded onto the victim system. 60

  For more information about RegRipper, go to http://regripper.wordpress.com/.   For more information about RegRipper, go to http://regripper.wordpress.com/.

61

38

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• As a result, it is always advisable to examine the subject system Web his•

•

tory to gain insight into whether a Web-based vector of attack caused the malicious code incident. Internet Explorer history files (index.dat) can be parsed with Pasco, a free multiplatform command-line utility offered by Foundstone. The results processed by Pasco are output into a field delimited text file, enabling the digital investigator to import into as spreadsheet to further analyze these data. In addition to Pasco, there are numerous utilities available to parse Web history artifacts associated with specific Web browsers, as described in detail in the Tool Box section of this chapter. @

Examine Cookie Files Similar to the correlative clues that can be gained through reviewing the Web browsing history on a subject system, cookie files also can provide insight into how malware may have been placed on a victim system. • Information from cookie files can be acquired using Galleta62 for Internet Explorer and MozillaCookiesView63 for Firefox. @ u

Inspect Protected Storage If user accounts accessed from the subject system (such as e-mail accounts and password-protected Web site logins) were discovered to be compromised after a malicious code incident, it is possible that malware may have harvested the protected storage (also referred to as “pstore”) from the subject system (or a key logger was installed). • Protected storage may contain passwords stored by Internet Explorer and other programs, providing the attacker with stored user credentials on the system. • This information can be gathered with NirSoft’s GUI and CLI utility Protected Storage PassView (pspv.exe).64 • Contents of the Firefox AutoComplete and Protected Storage areas can be extracted using the DumpAutocomplete65 utility. u

62   For more information about Galleta, go to http://www.foundstone.com/us/resources/proddesc/ galleta.htm. 63   For more information about MozillaCookiesView, go to http://www.nirsoft.net/utils/ mzcv.html. 64   For more information about Protected Storage PassView, go to http://www.nirsoft.net/utils/ pspv.html. 65   For more information about DumpAutoComplete, go to http://www.foundstone.com/us/ resources/proddesc/DumpAutoComplete.htm.

Chapter | 1 Malware Incident Response

39

Malware Artifact Discovery and Extraction from a Live Windows System

R After identifying suspicious files on a subject system, extract them for further analysis in your malicious code laboratory. Additionally, consider browsing the system in a forensically sound manner for additional artifacts of compromise. u Extraction can be accomplished with a variety or tools, including Nigilant32, F-Response, HBGary’s FGET,66 and Helix3 Pro, among [email protected]

Extracting Suspicious Files As discussed previously in the Memory Acquisition section of this chapter, Agile Risk Management’s Nigilant3267 is a GUI-based incident response tool useful for extracting and analyzing suspicious files. Valuable information about these suspicious files can be obtained using the Nigilant32 File System Review functionality. • To use this function, select the “Preview Disk” function within Nigilant32, accessible from the user console. • After selecting this option, select the partition of the subject hard drive to explore, as displayed in Figure 1.31. u

FIGURE 1.31–Previewing the hard drive of the subject system with Nigilant32

66

  For more information about FGET, go to http://www.hbgary.com/free-tools.   For more information about Nigilant32, go to http://www.agileriskmanagement.com/ publications_4.html. 67

40

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• The Preview Disk function uses code68 from Brian Carrier’s foren-

• • •

•

sic analysis framework, the Sleuth Kit,69 to examine the active file ­system and minimize any potential modifications caused by the native Windows API. Use this feature on a subject computer to explore its file system, locate hidden files or folders or recently deleted content, or extract files for additional analysis. Double click on a folder of interest, double click on a file of interest, and review the populated file contents display panels located below the main display pane, as seen in Figure 1.32. Each display panel provides different information pertaining to the selected file. r The first panel displays the hexadecimal offset for each line in the file. r The second panel shows the contents of the file in hexadecimal format. r The third and final panel reveals the contents of the file in ASCII format, similar to using a utility to display embedded strings. After discovering files of interest, you can extract the files to an external source, such as a USB ThumbDrive or external hard drive, using the Nigitlant32 “Extract File” function shown in Figure 1.33. Using this function, you can select the location and name of the suspect file you want to extract, and in turn, the location where you want to save the extracted file specimen.

FIGURE 1.32–Examining file contents with Nigilant32 68

  For more information about the code from the Sleuth Kit, go to http://www.sleuthkit.org/ sleuthkit/docs/api-docs/index.html. 69   For more information about the Sleuth Kit, go to http://www.sleuthkit.org/index.php.

Chapter | 1 Malware Incident Response

41

FIGURE 1.33–Extracting our suspect file using the Nigilant32 Extract File feature

Extracting Suspicious Files with F-Response Recall from the Memory Acquisition and Remote Registry Analysis sections of this chapter that, F-Response is an incident response framework that implements the Microsoft iSCSI initiator service to provide read-only access to the full physical disk(s) of a networked computer. • Leveraging this functionality, you can locate and extract suspicious files and associated artifacts from a suspect system drive that is mounted locally with F-Response. • After initiating F-Response, the subject system drive can be “seen” locally on your examination system, as shown in Figure 1.34. u

FIGURE 1.34–Extracting suspect files using F-Response

42

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• You can navigate the suspect drive locally to locate and extract files of interest, just as you would your local hard drive.

CONCLUSIONS

• Live Windows systems contain a significant amount of volatile data that will

•

•

•

•

be lost when the system is shut down. These volatile data can provide critical details about malicious code on the subject system, such as data that it has captured and network connections that it has established. There are a wide variety of tools for preserving such data, many of which were demonstrated in this chapter. Independent of the tools used and the operating system under examination, a preservation methodology must be established to ensure that available volatile data are captured in a manner that is as consistent and repeatable as possible. For forensic purposes, and to maintain the integrity of the data, keep detailed documentation of the steps taken on the live system. The methodology in this chapter provides a general robust foundation for the forensic preservation of volatile data on a live Windows system. It may need to be altered for certain situations. The approach is designed to ­capture ­volatile data as a source of evidence, enabling an objective observer to ­evaluate the reliability and accuracy of the preservation process and the acquired data. Collecting volatile data is a delicate process and great care must be taken to minimize the changes made to the subject system during the preservation process. Therefore, extensive examination and searching on a live system is strongly discouraged. If the system is that interesting, take the time to create a forensic duplicate of the disk for examination, as covered in Chapter 3. Do not trust the operating system of the subject system, because it may give incomplete or false information. To mitigate this risk, seek corroborating sources of evidence, such as port scans and network logs.

Chapter | 1 Malware Incident Response

43

� Pitfalls to Avoid Lacking familiarity with tools, techniques, and protocols prior to an incident  Do not wait until an actual malicious code incident to become familiar with the forensic process, techniques, and tools you are going to use to investigate a subject system. R Practice live response techniques by using your tools in a test environment to become and remain proficient.

R Attend relevant training when possible. Budget constraints, time constraints, and other factors often make it difficult to attend formal training. If you cannot attend, improvise. Attend free webinars; watch Web-based tutorials; self-study texts, whitepapers, and blogs; and attend local information security group meetings.

R Stay current with tools and techniques. Live response is a burgeoning area of digital forensics; almost daily there are new tools or tool updates released, new research, and techniques discussed. Keeping tabs on what is current will likely enhance the scope of your live response knowledge base and skills.

R Stay abreast of new threats. Similar to staying current with tools and techniques, the converse is just as important—staying current on malicious code trends, vulnerabilities, and vectors of attack.

R Utilize online resources such as social networks and listservs. It is  often difficult to find time to attend training, read a book, or attend a local information security group meeting. A great resource to stay abreast of live response tools and techniques is with social network media such as Twitter and Facebook. Joining specific lists or groups on these media can provide real-time updates on topics of interest. Failing to test and validate your tools  Do not deploy tools on a subject system without first having a clear understanding of what your tools’ functionalities, limitations, and “footprint” on a system are. R Research tools that you intend to incorporate into your live response toolkit. Are they generally accepted by the forensic community? Are there known “bugs” or limitations to be aware of? Have you read all documentation for the tools?

44

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

R Deploy the tools in a test environment to verify functionality and gain a clear understanding of how each tool works and how it impacts the target system it is deployed on.

R Document your findings—notes regarding your tools are not only a valuable reference, but can come in handy for report writing. Using improperly licensed commercial tools  Do not use “cracked” or “bootlegged” tools. R Remember that your investigation may end up in a legal proceeding, whether criminal, civil, or administrative. Having to explain that you used tools during the course of your investigation that were illegally or unethically obtained can damage your credibility—and potentially your investigation—despite how accurate and thorough your analysis and work product is. Not conducting interviews prior to conducting live response  Failing to conduct interviews of relevant parties prior to conducting live response may cause you to miss important details. R Conducting interviews of relevant parties prior to conducting live response provides you with information about the subject system, including the circumstances surrounding the incident, the context of the subject system, and intricacies about the system or network that are salient to your investigation. Running non-trusted tools directly from the subject system  Do not run Live Response tools directly from the subject system. R The subject system is an unknown and untrustworthy environment in which the collection of volatile data can be tainted as a result of the infected system. Running tools directly from a subject system relies on the system’s operating system, which may be compromised by malware, making the acquired data unreliable.

R Make sure to use a run trusted command shell/tools from an Incident Response toolkit. Not using forensically sound/clean acquisition media  Do not contaminate your data by acquiring them on “dirty” media. R Always ensure that the media you are using to acquire live response data are pristine and do not contain unrelated case data, malicious code specimens, and other artifacts from previous investigations.

R Always inspect your toolkit and acquisition media prior to deployment.

Chapter | 1 Malware Incident Response

45

R Be cognizant that USB devices are common malicious code vectors— the malware you are investigating can propagate and infect your live response media by virtue of connecting to the system. Not following the order of volatility  Losing critical evidence. R As discussed in the introduction to this book and Chapter 1, while powered on, a subject system contains critical ephemeral information that reveals the state of the system.

R The purpose of live response is to gather this volatile information in a forensically sound manner so that it is not lost. Failing to follow the Order of Volatility and gathering less volatile information impacts the state of volatile data on the system (e.g., memory contents) and increases the risk of losing the data altogether. Network connections, process states, and data caches can quickly change if not acquired in timely manner. Failing to document the system date and time  Forgetting to document the system date and time and compare them to a reliable time source at the beginning of live response can prove problematic for your investigation. R The system date and time are essential details about the suspect system that will serve as the baseline for temporal context in your investigation.

R Make sure to document the system date and time in your investigative notes in addition to acquiring the date and time through your live response toolkit. Not acquiring the contents of physical memory at the beginning of the live response process  Contaminating/impacting the evidence by leaving a “deep footprint” in it. R As demonstrated in this chapter, the contents of physical memory are impacted by running live response tools on a subject system.

R Acquire physical memory before conducting other live response processes in an effort to keep the memory contents as pristine as possible when acquired. Gathering incomplete system details  Incomplete system details can potentially affect the context surrounding your subject system. R Make sure to gather as many details about the subject system as possible, giving you deep context about and surrounding the system. For instance,

46

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

vital details such as system date/time and system uptime are foundational in establishing a time line surrounding the malicious code incident.

R Gathering the subject system’s hostname, IP address, and other network-based identifiers is critical in examining the relational context with other systems on the network. Failing to determine if the attacker is still logged into the subject system  Do not let the attacker know you are investigating them. R Conducting live response while an attacker is on the subject system will most likely alert the attacker to your investigation.

R Alerting the attacker can potentially have devastating consequences to your investigation and to the subject system (and other systems on the network), such as destruction of evidence, escalation of attacks, or additional compromises to maintain inconspicuous, undiscoverable, and continual access to the system. Failing to conduct a holistic investigation  Failing to obtain complete context about the suspect system and the malicious code event. R Conducting a “flat” or incomplete investigation into a subject system will limit your understanding about the malicious code incident, the impact on the subject system, and the nature and purpose of the attack.

R Conduct a complete and thorough investigation, gathering multiple perspectives on the data so that a complete analysis can be conducted. For example, in collecting information about running processes from a subject system, simply gathering a list of running processes without more provides the digital investigator with insufficient information about the processes and their relational context to other evidence. Incomplete or sloppy documentation  Do not jeopardize your investigation by poorly documenting it. R As discussed in the introduction to this book, one of the keys to forensic soundness is documentation.

R A solid case is built on supporting documentation that reports where the evidence originated and how it was handled.

R From a forensic standpoint, the acquisition process should change the original evidence as little as possible, and any changes should be documented and assessed in the context of the final analytical results.

47

Chapter | 1 Malware Incident Response

Live Response: Field Interview Questions Case Number: Digital Investigator: Organization/Company: Incident Type:

Date/Time: Address:

Trojan Horse Bot Logic Bomb Sniffer:

Worm Scareware/Rogue AV Keylogger Other:

Interviewee Name: Telephone Number:

Department/Section: Cell Phone Number:

Name of Main Point of Contact: Telephone Number:

Virus Rootkit Ransomware: Unknown:

E-mail Address:

Department/Section: Cell Phone Number:

Legal Counsel: Is there legal counsel for the company/organization? Name: Contact information: Does legal counsel need to be notified? Yes No Has legal counsel been notified? Yes No

E-mail Address: Yes

No

Scope of Authorities and Privacy Interests: Is there an individual with overall authority/responsibility for the subject system/network? Yes No Name: Contact information: Does this individual need to be notified? Yes No Has this person been notified? Yes No Are there other individuals who have authority over the system/network? Yes No Name: Contact information: Is the system shared? (i.e., is it a system hosting multiple servers with multiple privacy interests) Yes No Details (if yes):

Position/Occupation: Job responsibilities/duties /objectives : Number of years employed in this position: Context in relationship to the subject system: Scope of authority on systems/network: Incident Notification: How did you learn about the infection incident/subject system?: When did you learn about the infection incident/subject system?: What did you learn about the incident/subject system?: Was anyone else notified about the incident/subject system?: Discovered/noti ceable symptoms of the subject system?: System Details: Make/Model: Operating System: Service Pack/Patch Level: How often is the system patched/updated: How are the patches/updates deployed: Primary system user: Who else has access to the system?: What users are authorized to be on the system?: Who is the System Administrator/Who maintains the system?: Is the system shared (i.e., is it a system hosting multiple servers with multiple privacy interests)?: Purpose/function of the subject system:

48

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS What level of privileges does the subject system have?: How is the subject system networked?: IP address of the subject system:_________._________.___________._________ Host Name/Network Name of the system: System Classification: Top Secret Secret Confidential Unclassified Other:________________ Sensitive information on the system?: Have there been previous incidents/instances of malware on the system?: Pre-Incident System/Network Baseline & Evidence Map: What programs are known to be running on the system: Do any of the programs have particular network connectivity?: What is the baseline software build out of the system (e.g., what Web browser, etc.)?: What are the software programs expected to be discovered on the system?: Does the system have host-based security software: Anti-virus: Anti-spyware: Software Firewall: Internet security suite (e.g., anti-virus and firewall): Host-based Intrusion Detection Software (HIDS): Host-based Intrusion Prevention System (HIPS): File Integrity Monitoring: Other:__________________________________ Network-based security software/appliances: Proxy server cache: Firewall: Router: DNS Queries monitored/logged: Intrusion Detection System: Intrusion Prevention System: Incident Response/Network Forensics Appliance: Other:_____________________ Logs: What system and network logs are collected and maintained?: Where are the logs maintained?: Do you have a copy of the logs that can be provided for the purpose of this investigation?: Who is responsible for monitoring and analyzing the logs?: How often are the logs reviewed?: How are the logs reviewed?: When were the logs last reviewed?: How far back are the logs maintained/archived?: Security Policy: Are particular physical devices disallowed from being connected to the system?: What types of physical devices are allowed to be connected to the system?: To your knowledge what physical devices have been connected to the system?: Are certain programs prohibited from being run on the system?: Are certain protocols prohibited from being run on the system (i.e., file sharing, p2p)?: Previous Indicators of Infection or Compromise: System anomalies identified?: What were those anomalies?: Has the system been accessed or logged into at unusual times?: Network anomalies associated with the subject system?: Has there been network traffic to or from the system at unusual times?: Has there been an unusual volume of network traffic to or from the system?: Have there been unusual protocols calling to or regressing from the system?: Has similar anomalous traffic occurred from other systems?: Incident Response/Investigation: Who reported the subject system?: What occurred once the system was reported?: Was the system taken offline?: Was the system boot down?:

Chapter | 1 Malware Incident Response

What live response steps, if any, were taken?: Physical Memory Acquired Volatile Data Collected Hard drive(s) imaged Other:___________________________ What tools were used?: Who conducted the live response forensics?: Is there a report associated with the incident response?: Is there an incident response protocol in place?: Were any suspicious files collected and maintained?: Was any analysis done on the suspicious file(s)?: Was an image of the hard drive made and maintained?: Was any analysis done on the drive?: What software was used for the imaging and analysis?: Were any third parties involved in the incident response, analysis, or remediation?: Are the third-party reports available for review?: Was the suspect file/malware submitted to any online malware scanning/sandbox services?: What other investigative or remediation steps were taken?: Where is the evidence related to this incident maintained?: Was a chain of custody form used?: During the course of the investigation were any other systems identified as being involved or connected with this incident?: What do you believe the vector of attack to be?: Did any other users experience the same type of attack?: Incident Findings: During the course of incident response were any system anomalies identified? What were those anomalies? Was any anomalous network traffic discovered that was associated with the subject system?

49

50

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Live Response: Field Notes Date/Time:

Case Number: Digital Investigator: Organization/Company: Incident Type:

Address:

Trojan Horse Bot Logic Bomb Sniffer:

Worm Scareware/Rogue AV Keylogger Other:

System Information:

Virus Rootkit Ransomware: Unknown:

Make/Model:

Serial Number:

Physical Location of the System:

Operating System:

System State: Powered up Hibernating Powered down

Network State: Connected to Internet Connected to Intranet Disconnected

VOLATILE DATA Physical Memory: Acquired Date/Time: File Name: Size: MD5 Value: SHA1 Value: Tool used:

Not Acquired [Reason]:

System Details: Date/Time: IP Address:_________._________.___________._________ Host Name/Network Name: Current System User: Network Interface Configuration: Promiscuous Other: Enabled Protocols: System Uptime: System Environment: Operating System: Service Pack/Patch Level: Processor: Users Logged into the System: User_________________ logged into the system: User Point of origin: Remote Login Local login Duration of the login session: Shares, files, or other resources accessed by the user: Processes associated with the user: Network activity attributable to the user: User_________________ logged into the system: User Point of origin: Remote Login Local login Duration of the login session: Shares, files, or other resources accessed by the user: Processes associated with the user: Network activity attributable to the user:

Chapter | 1 Malware Incident Response

Network Connections and Activity: System is connected to the network: Network connections: Protocol: TCP UDP Local Port: Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Foreign Connection Address: Foreign Connection Port: Process ID Associated with Connection:

Protocol: TCP UDP Local Port: Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Foreign Connection Address: Foreign Connection Port: Process ID Associated with Connection:

Protocol: TCP UDP Local Port: Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Foreign Connection Address: Foreign Connection Port: Process ID Associated with Connection:

Protocol: TCP UDP Local Port: Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Foreign Connection Address: Foreign Connection Port: Process ID Associated with Connection:

Protocol: TCP UDP Local Port: Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Foreign Connection Address: Foreign Connection Port: Process ID Associated with Connection:

Protocol: TCP UDP Local Port: Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Foreign Connection Address: Foreign Connection Port: Process ID Associated with Connection:

Notable DNS Queries made from subject system: ___________________________________________ __________________________________________ ___________________________________________ __________________________________________ ___________________________________________ __________________________________________ NetBIOS connections: NetBIOS Name: Host Address: Recently Transferred Files: NetBIOS Name: Host Address: Recently Transferred Files: NetBIOS Name: Host Address: Recently Transferred Files:

ARP Cache Collected: NetBIOS Name: Host Address: Recently Transferred Files: NetBIOS Name: Host Address: Recently Transferred Files: NetBIOS Name: Host Address: Recently Transferred Files:

51

52

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Running Processes: Running processes: Suspicious Process Identified:

Running processes: Suspicious Process Identified:

Process Name: Process Identification (PID): Duration process has been running: Memory used: Path to Associated executable file: ________________________________________________ Associated User: Child Process(es): __________________________ __________________________ __________________________ Command-line parameters: ________________________________________________ ________________________________________________ File Handles: __________________________ __________________________ __________________________ __________________________ Loaded Modules: __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ Exported Modules: __________________________ __________________________ __________________________ Process Memory Acquired: File Name: File Size: MD5 Hash Value: ____________________________

Process Name: Process Identification (PID): Duration process has been running: Memory used: Path to Associated executable file: ________________________________________________ Associated User: Child Process(es): __________________________ __________________________ __________________________ Command-line parameters: ________________________________________________ ________________________________________________ File Handles: __________________________ __________________________ __________________________ __________________________ Loaded Modules: __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ Exported Modules: __________________________ __________________________ __________________________ Process Memory Acquired: File Name: File Size: MD5 Hash Value: ____________________________

Chapter | 1 Malware Incident Response

Running processes: Suspicious Process Identified:

Running processes: Suspicious Process Identified:

Process Name: Process Identification (PID): Duration process has been running: Memory used: Path to Associated executable file: ________________________________________________ Associated User: Child Process(es): __________________________ __________________________ __________________________ Command-line parameters: ________________________________________________ ________________________________________________ File Handles: __________________________ __________________________ __________________________ __________________________ Loaded Modules: __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ Exported Modules: __________________________ __________________________ __________________________ Process Memory Acquired: File Name: File Size: MD5 Hash Value: ____________________________

Process Name: Process Identification (PID): Duration process has been running: Memory used: Path to Associated executable file: ________________________________________________ Associated User: Child Process(es): __________________________ __________________________ __________________________ Command-line parameters: ________________________________________________ ________________________________________________ File Handles: __________________________ __________________________ __________________________ __________________________ Loaded Modules: __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ Exported Modules: __________________________ __________________________ __________________________ Process Memory Acquired: File Name: File Size: MD5 Hash Value: ____________________________

53

54

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Running processes: Suspicious Process Identified:

Running processes: Suspicious Process Identified:

Process Name: Process Identification (PID): Duration process has been running: Memory used: Path to Associated executable file: ________________________________________________ Associated User: Child Process(es): __________________________ __________________________ __________________________ Command-line parameters: ________________________________________________ ________________________________________________ File Handles: __________________________ __________________________ __________________________ __________________________ Loaded Modules: __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ Exported Modules: __________________________ __________________________ __________________________ Process Memory Acquired: File Name: File Size: MD5 Hash Value: ____________________________

Process Name: Process Identification (PID): Duration process has been running: Memory used: Path to Associated executable file: ________________________________________________ Associated User: Child Process(es): __________________________ __________________________ __________________________ Command-line parameters: ________________________________________________ ________________________________________________ File Handles: __________________________ __________________________ __________________________ __________________________ Loaded Modules: __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ Exported Modules: __________________________ __________________________ __________________________ Process Memory Acquired: File Name: File Size: MD5 Hash Value: ____________________________

55

Chapter | 1 Malware Incident Response

Port and Process Correlation: Suspicious Port Identified:

Suspicious Port Identified:

Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___Port Number: ___ Remote Host Name:_____________________________ Protocol: TCP UDP Connection Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Process name and ID (PID) associated with open port: Executable program associated with the process and port: Path to Associated Executable File:

Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___Port Number: ___ Remote Host Name:_____________________________ Protocol: TCP UDP Connection Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Process name and ID (PID) associated with open port: Executable program associated with the process and port: Path to Associated Executable File:

Associated User:

Associated User:

Suspicious Port Identified:

Suspicious Port Identified:

Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___Port Number: ___ Remote Host Name:_____________________________ Protocol: TCP UDP Connection Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Process name and ID (PID) associated with open port: Executable program associated with the process and port: Path to Associated Executable File:

Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___Port Number: ___ Remote Host Name:_____________________________ Protocol: TCP UDP Connection Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Process name and ID (PID) associated with open port: Executable program associated with the process and port: Path to Associated Executable File:

Associated User:

Associated User:

Suspicious Port Identified:

Suspicious Port Identified:

Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___Port Number: ___ Remote Host Name:_____________________________ Protocol: TCP UDP Connection Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Process name and ID (PID) associated with open port: Executable program associated with the process and port: Path to Associated Executable File:

Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___Port Number: ___ Remote Host Name:_____________________________ Protocol: TCP UDP Connection Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Process name and ID (PID) associated with open port: Executable program associated with the process and port: Path to Associated Executable File:

Associated User:

Associated User:

56

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Services: Suspicious Service Identified:

Suspicious Service Identified:

Service Name: Display Name: Status: Running Stopped Startup Configuration: Description: Dependencies: Executable Program Associated with Service: Process ID (PID): Description: Executable Program Path: Username associated with Service:

Service Name: Display Name: Status: Running Stopped Startup Configuration: Description: Dependencies: Executable Program Associated with Service: Process ID (PID): Description: Executable Program Path: Username associated with Service:

Suspicious Service Identified:

Suspicious Service Identified:

Service Name: Display Name: Status: Running Stopped Startup Configuration: Description: Dependencies: Executable Program Associated with Service: Process ID (PID): Description: Executable Program Path: Username associated with Service:

Service Name: Display Name: Status: Running Stopped Startup Configuration: Description: Dependencies: Executable Program Associated with Service: Process ID (PID): Description: Executable Program Path: Username associated with Service:

Suspicious Service Identified:

Suspicious Service Identified:

Service Name: Display Name: Status: Running Stopped Startup Configuration: Description: Dependencies: Executable Program Associated with Service: Process ID (PID): Description: Executable Program Path: Username associated with Service:

Service Name: Display Name: Status: Running Stopped Startup Configuration: Description: Dependencies: Executable Program Associated with Service: Process ID (PID): Description: Executable Program Path: Username associated with Service:

57

Chapter | 1 Malware Incident Response

Drivers: List of installed drivers acquired Suspicious Driver: Name: Location: Link Date:

Suspicious Driver: Name: Location: Link Date:

Suspicious Driver: Name: Location: Link Date:

Suspicious Driver: Name: Location: Link Date:

Suspicious Driver: Name: Location: Link Date:

Suspicious Driver: Name: Location: Link Date:

Open Files: Open File Identified:

Open File Identified:

Opened Remotely/ Opened Locally

Opened Remotely/ Opened Locally

File Name: Process that opened file: Handle Value: File location on system:

File Name: Process that opened file: Handle Value: File location on system:

Open File Identified: Opened Remotely/

Opened Locally

File Name: Process that opened file: Handle Value: File location on system:

Open File Identified: Opened Remotely/

Opened Locally

File Name: Process that opened file: Handle Value: File location on system:

Open File Identified: Opened Remotely/ Opened Locally File Name: Process that opened file: Handle Value: File location on system:

Open File Identified: Opened Remotely/ Opened Locally File Name: Process that opened file: Handle Value: File location on system:

Command History: Command history acquired Commands of interest identified

Commands of Interest:

Yes No

Network Shares: Network Shares Inspected Suspicious Share Identified Share Name: Location: Description:

Suspicious Share Identified Share Name: Location: Description:

Suspicious Share Identified Share Name: Location: Description:

Suspicious Share Identified Share Name: Location: Description:

Suspicious Share Identified Share Name: Location: Description:

Suspicious Share Identified Share Name: Location: Description:

58

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Scheduled Tasks: Scheduled Tasks Examined Tasks Scheduled on the System Yes No Suspicious Task(s) Identified: Yes No Clipboard Contents: Clipboard Contents Examined Suspicious Contents Identified: Yes No

Suspicious Task(s) Task Name:

Scheduled Run Time: Status: Description:

Task Name:

Scheduled Run Time: Status: Description:

Clipboard Contents

Non-Volatile Data Forensic Duplication of Storage Media: Acquired Not Acquired [Reason]: Date/Time: File Name: Size: MD5 Value: SHA1 Value: Tool used: Notes: System Security Configuration: Operating System Version: Service Pack: Patch Level:

Trusted Host Relationships: etchosts file contents collected: Suspicious entries identified: ___________________________________: ___________________________________: ___________________________________: ___________________________________:

etcnetworks file contents collected:

Suspicious entries identified:

___________________________________: ___________________________________: ___________________________________: ___________________________________:

Identified Insecure Configurations: ___________________________________: ___________________________________: ___________________________________: ___________________________________: ___________________________________: ___________________________________: ___________________________________: ___________________________________: ___________________________________: ___________________________________: ___________________________________: ___________________________________: ___________________________________: ___________________________________:

etclmhosts file contents collected:

Suspicious entries identified:

___________________________________: ___________________________________: ___________________________________: ___________________________________:

59

Chapter | 1 Malware Incident Response

Prefetch Files: Suspicious Prefetch Identified: Prefetch File Name: Associated Application: Embedded Date: Created: Written: Runs:

Suspicious Prefetch Identified: Prefetch File Name: Associated Application: Embedded Date: Created: Written: Runs:

Suspicious Prefetch Identified: Prefetch File Name: Associated Application: Embedded Date: Created: Written: Runs:

Suspicious Prefetch Identified: Prefetch File Name: Associated Application: Embedded Date: Created: Written: Runs:

Auto-starting Locations: Suspicious Autorun Entry Identified: Associated Registry Location:

Suspicious Autorun Entry Identified: Associated Registry Location:

Program Name: Program Description: Program Metadata/Publisher: Program Executable Path:

Program Name: Program Description: Program Metadata/Publisher: Program Executable Path:

Suspicious Autorun Entry Identified: Associated Registry Location:

Suspicious Autorun Entry Identified: Associated Registry Location:

Program Name: Program Description: Program Metadata/Publisher: Program Executable Path:

Program Name: Program Description: Program Metadata/Publisher: Program Executable Path:

Event Logs: Security Event Log Acquired Not Acquired [Reason]: Suspicious Entry Identified

Application Event Log Acquired Not Acquired [Reason]: Suspicious Entry Identified

Suspicious Entry Identified

Suspicious Entry Identified

Suspicious Entry Identified

Suspicious Entry Identified

System Event Log Acquired Not Acquired [Reason]: Suspicious Entry Identified

Other Logs Acquired: __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________

Event ID: Event Type: Event ID: Event Type: Event ID: Event Type:

Event ID: Event Type:

Suspicious Entry Identified Event ID: Event Type:

Suspicious Entry Identified Event ID: Event Type:

Event ID: Event Type: Event ID: Event Type: Event ID: Event Type:

60

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

User and Group Policy Information: User Accounts: __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ Notes:

Groups: __________________________________

Member names:

_____________________________________ _____________________________________ _____________________________________

__________________________________

Member names:

_____________________________________ _____________________________________ _____________________________________

__________________________________

Member names:

_____________________________________ _____________________________________ _____________________________________

File System: Suspicious Hidden File Identified: File Location:

ADS Discovered: File Location:

Suspicious Hidden File Identified: File Location:

ADS Discovered: File Location:

File Name: Created Date: Modified Date: Accessed Date:

File Name: Created Date: Modified Date: Accessed Date:

Registry: Registry contents extracted Web Browsing Activities: Web Browser: Internet History Collected: Cookie Files Collected: Other:

File Name: Created Date: Modified Date: Accessed Date:

File Name: Created Date: Modified Date: Accessed Date:

Suspicious Recycle Bin File(s) Discovered:

61

Chapter | 1 Malware Incident Response

Malware Extraction: Suspicious File Identified: File Name:

Suspicious File Identified: File Name:

Size: Location: MAC Times:

Size: Location: MAC Times:

Associated Process/PID: Associated Network Activity: Associated Artifacts:

Associated Process/PID: Associated Network Activity: Associated Artifacts:

Suspicious File Extracted: Yes No: Reason:

Suspicious File Extracted: Yes No: Reason:

Suspicious File Identified: File Name:

Suspicious File Identified: File Name:

Size: Location: MAC Times:

Size: Location: MAC Times:

Associated Process/PID: Associated Network Activity: Associated Artifacts:

Associated Process/PID: Associated Network Activity: Associated Artifacts:

Suspicious File Extracted: Yes No: Reason:

Suspicious File Extracted: Yes No: Reason:

Suspicious File Identified: File Name:

Suspicious File Identified: File Name:

Size: Location: MAC Times:

Size: Location: MAC Times:

Associated Process/PID: Associated Network Activity: Associated Artifacts:

Associated Process/PID: Associated Network Activity: Associated Artifacts:

Suspicious File Extracted: Yes No: Reason:

Suspicious File Extracted: Yes No: Reason:

62

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

 Malware Forensic Tool Box

Live Response Tools for Investigating Windows Systems In this chapter we discussesd a myriad of tools that can be used during the course of live response investigation. Throughout the chapter, we deployed many tools to demonstrate their functionality and output when used on an infected system; however, there are a number of tool alternatives that you should be aware of and familiar with. In this section, we explore these tool alternatives. This section can also simply be used as a “tool quick reference” or “cheat sheet,” as there will inevitably be times during an investigation where having an additional tool that is useful for a particular function would be beneficial, since you may have little time to conduct research for or regarding the tool(s) while responding in the field. As the digital forensic tool landscape is constanly evolving, the companion Web site for this Field Guide, www.malwarefieldguide.com, will strive to maintain a comprehensive, dynamic, and up-to-date listing of tools. We welcome tool suggestions via the Web site http://www.malwarefieldguide.com/Contact_Us.html. The tools in this section (and on the companion Web site) are identified by overall “tool type”—deliniating the scope of how the respective tools can be incorporated in your malware forensic live response toolkit. Further, each tool description includes a cross-reference to the page number in Chapter 1 in which the relevant substantive discussion is provided, along with details about the tool author/distributor, associated URL, description of the tool, and helpful command switches, when applicable.

INCIDENT RESPONSE TOOL SUITES In Chapter 1 we examined the incident response process step by step, using certain tools to acquire different aspects of stateful data from a subject system. There are a number of tool suites specifically designed to collect digital evidence in an automated fashion from Windows systems during incident response and generate supporting documentation of the preservation process. • Some of these local incident response tool suites execute commands on the compromised computer and rely on system libraries on the compromised system. • Other programs, commonly known as “remote forensics tools,” address some of the limitations of local incident response suites and use a servlet that enables remote evidence gathering while trying to rely on the compromised operating system as little as possible (with varying degrees of success). • Using remote forensic tools, digital investigators can access many machines from a central console, making your expertise more effective. • Furthermore, using a remote forensics tool is more subtle than running various commands on the system, and it is less likely to alert the subject of investigation. • These tool options, including the strengths and weakness of these tools, are covered in this section.

Chapter | 1 Malware Incident Response

Name: Windows Forensic Toolchest Page Reference: 11 Author/Distributor: Monty McDougal/FoolMoon Available From: http://www.foolmoon.net/security/wft/ Description: Older free versions of the Helix Live CD provide a powerful suite of tools for incident response and forensic preservation of volatile data for both Windows and UNIX systems. In addition to dumping RAM, as discussed earlier in this chapter, the older versions of the Helix CD come with the Windows Forensic Toolchest (WFT). The WFT provides a framework for performing consistent information gathering using a variety of utilities. The WFT can be configured to run any utilities in an automated fashion and in a specific sequence. In addition, the WFT generates MD5 values and supporting audit information to document the collection process and integrity of the acquired data. However, the WFT cannot list deleted files.

A significant limitation of the WFT is that it relies on the operating system of the compromised host. Some malware hides information from incident response tools that rely on the operating system. For instance, the following figure shows file listing results on a live system on which the HackerDefender rootkit is concealing certain files from the operating system. As such, if a rootkit is installed on the subject system, even trusted commands in the WFT can provide incorrect results.

63

64

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Name: +HOL[3UR Page Reference: 11 Author/Distributor: E-Fense Available From: http://www.e-fense.com/helix3pro.php Description: Helix3 Pro is a live response CD that contains a bootable Linux environment (known as the “bootable side”) and a live response framework for use in Windows environments (known as a the “live side”). Until 2009, Helix CD was a freeware tool set, and the live side was a graphical framework that invoked third-party utilities to collect volatile data from Windows systems. In early 2009, E-Fense announced the release of a new proprietary version of Helix, known as Helix3 Pro, which no longer relies upon the third-party applications and utilities. Instead, it relies on a proprietary code. Rich with features, Helix3 Pro, depicted in the following figure, allows the digital investor to image physical memory, collect volatile data, and acquire physical devices, among other live response tasks. The results acquired with Helix3 Pro can be saved locally to external media or transferred remotely over the network using a proprietary remote collection utility called the “Helix3 Pro Imager Receiver.”

Acquiring Physical Memory with Helix3 Pro

Volatile Data Acquisition with Helix3 Pro

Helix3 Pro Image Receiver

Chapter | 1 Malware Incident Response

Name: OnlineDFS/LiveWire Page Reference: 11 Author/Distributor: Cyber Security Technologies Available From: http://www.onlinedfs.com/products_dfs.asp; Description: The Online Digital Forensics Suite (OnlineDFS) has the capability to capture volatile data from a remote Windows computer, and can be used to capture a full memory dump and a forensic duplicate of the hard drive on a remote computer, as shown in the following figure.

Rather than running a servlet on the evidentiary machine, OnlineDFS/LiveWire uses the SMB protocol to execute commands on the remote system, because this approach relies on components of the compromised system; therefore, it could conceivably be undermined by malware.

Name: ProDiscoverIR Page Reference: 11 Author/Distributor: Technology Pathways Available From: http://www.techpathways.com/ProDiscoverIR.htm Description: Live response forensic tool suites that do not rely upon the subject operating system, but run agents on the subject system at the bit level, such as PRoDiscoverIR (a commercial forensic utility), are often capable of unearthing stealth files. In the following figure, PRoDiscoverIR was able to identify the HackerDefender rootkit.

Keep in mind that some rootkits or anti-forensic techniques may still successfully conceal some information, such as hidden processes, from a remote forensic tool like ProDiscoverIR. Another risk of running utilities on a live system is that they may crash and overwrite valuable digital evidence on the compromised system. This risk emphasizes the importance of capturing a full memory dump and forensic image prior to performing such analysis on a live system. As noted previously, ProDiscoverIR can capture volatile data from a remote computer via a servlet running on the compromised computer. The following figure illustrates part of the process list obtained from a remote computer using ProDiscoverIR.

65

66

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Although the servlet attempts to provide a complete and accurate view of the compromised computer, it can be tricked by some rootkits. For instance, current versions of ProDiscoverIR cannot see processes and open ports that are hidden by the HackerDefender rootkit.

Name: EnCase Enterprise Page Reference: 11 Author/Distributor: Guidance Software Available From: http://www.guidancesoftware.com/computer-forensics-fraud-investigation-software.htm Description: EnCase Enterprise can capture full memory contents, and it can be used to inspect volatile data on a remote computer and preserve some high level information such as lists of running processes, network connections, listening ports, and open files. The following figure illustrates the Snapshot module in EnCase Enterprise as it is used to view information about processes running on a remote computer.

Chapter | 1 Malware Incident Response

Name: RPIER (aka The Rapid Assessment and Potential Incident Examination Report; RAPIER) Page Reference: 11 Author/Distributor: Steve Mancini and Joseph Schwendt Available From: http://sourceforge.net/projects/rpier; http://code.google.com/p/rapier/downloads/list. A number of whitepapers and PowerPoint presentations regarding RPIER/RAPIER are also available: http://www.first.org/conference/2006/papers/mancini-steve-papers.pdf: http://www.first.org/conference/2006/program/rapier_ _a_1st_responders_info_collection_tool.html, http://code.google.com/p/rapier/downloads/list, http://crime.zotconsulting.com/slides/2007_Q1_CRIME_presentation.pdf: http://www.first.org/conference/2006/papers/mancini-steve-slides.pdf Description: RPIER was developed by Steve Mancini and Joe Schwendt of Intel. It serves as a framework, or “engine” for the automatic acquisition of volatile and non-volatile system state data from a subject system. In particular, the RPIER framework is intended to be run on a subject machine in a running state from an external media, such as a USB thumb drive. Upon execution, the RPIER runs a series of individual modules that invoke numerous third-party utilities to collect information from a subject system. The collected information is then uploaded to a central secured repository or deposited on local external media where analysts can examine the output from the program. RPIER can be used on Windows 2000, XP, 2003, and Vista systems, but requires the Microsoft.NET framework 1.1 or higher to be installed on the subject system. The RPIER framework can be used in three different scanning modes: Fast, Slow, and Special. The Fast scan takes approximately 10 minutes to complete and gathers a variety of volatile and non-volatile system data, depending upon the modules selected by the investigator. The Slow mode includes a more in-depth acquisition of system data, including acquisition of physical memory, and process memory acquisition for every running process on the system. Lastly, the Special Scan includes a series of more invasive probes, which can potentially alter system data, such as anti-virus scanning, networking monitoring, and steganography detection.

For in-depth discussions about the different scan modes, see Mancini and Schwendt’s whitepaper, “RAPIER: A 1st Responders Information Acquisition Framework”and PowerPoint presentations discussing RPIER that are available online (URLs provided above). Once the investigator selects the scan mode, he or she must select the individual modules to deploy, using the RPIER user interface, as shown in the following figure.

Once the investigator has selected the modules, the tool is deployed by clicking the Run Rapier button on the user interface. The results from each module are deposited into a main “Results” folder, which can be sent over the network to a secure server or directed to a local external media, such as a USB thumb drive or external hard drive enclosure.

67

68

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

REMOTE COLLECTION TOOLS Recall that in some instances, to reduce system interaction, it is preferable to deploy live response tools from your trusted toolkit locally on a subject system but collect the acquired data remotely. This process requires establishing a network connection, typically with a netcat or cryptcat listener, and transferring the acquired system data over the network to a collection server. Remember, although this method reduces system interaction, it relies on the ability to traverse the subject network through the ports established by the netcat listener.

Name: Netcat Page Reference: 3 Author/Distributor: Hobbit Available From: http://netcat.sourceforge.net Description: Commonly referred to as the “Swiss Army Knife” of tools, netcat is a versatile networking utility that reads and writes data across network connections using the TCP/IP protocol. Netcat is commonly used by digital investigators during live response as a network-based transfer solution. Helpful Switches: Switch

Function

-l

Listen mode, for inbound connections

-p

Local port number

-h

Help menu

Name: Cryptcat Page Reference: 3 Author/Distributor: L0pht Available From: http://cryptcat.sourceforge.net/ Description: Netcat enhanced with twofish encryption Helpful Switches: Switch

Function

-l

Listen mode, for inbound connections

-p

Local port number

-h

Help menu

Chapter | 1 Malware Incident Response

69

Name: F-Response TACTICAL Page Reference: 8 Author/Distributor: Matthew Shannon/F-Response Available From: http://www.f-response.com/ Description: A stream lined solution for onsite live response, F-Response TACTICAL uses a unique dual-dongle/storage device solution to quickly and seamlessly allow the digital investigator to conduct remote forensic acquisition with limited knowledge of the subject network typology. The dual-dongles—one for the subject sytem, one for the examiner system (shown in the following figure)—work as a pair to connect the remote subject system to the digital investigator’s examination system. TACITCAL runs directly from the dongles and no installation is required on the subject system. Like other versions of F-Response, TACTICAL can acquire both Linux and Apple OS X subject systems, in addition to windows systems.

Shown in the following story-board figure, the TACTICAL “subject” dongle, when plugged into the subject system, houses the “TACTICAL Subject” directory, which contains the exectuables for Windows, Linux, and Apple OS X systems.

Once invoked, the TACTICAL subject executable brings up the TACTICAL subject interface, which allows the digital investigator to configure the acquisition parameters, including host network details, and the option to acquire physical memory, as shown in the followng figure.

70

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

On the examiner system (the system in which the digital investigator conducts his or her collection of data), the companion “Examiner” dongle is connected. Depicted in the following storyboard figure, the TACTICAL “Examiner” dongle houses the “TACTICAL Examiner” directory, which contains the Windows executable to invoke the Examiner interface.

Once invoked, the digital investigator has the option of connecting to the subject system manually by providing the details of the subject system (shown in the following figure), or using the “auto-connection” feature, which automatically trys to identify and acquire the subject system.

Once acquired, the TACTICAL Examiner interface provides the details regarding the acquired subject system. Similar to with other versions of F-Response, once connected to the subject system, the digitial investigator can use tools of his or her choice to collect data from the system.

Chapter | 1 Malware Incident Response

71

Volatile Data Collection and Analysis Tools PHYSICAL MEMORY ACQUISITION Chapter 1 emphasized the importance of first acquiring a full memory dump from the subject system prior to gathering data using the various tools in your live response toolkit. This is important, particularly due to the fact that running incident response on the subject system will alter the contents of memory. To get the most digital evidence out of physical memory, it is advisable to perform a full memory capture prior to running any other incident response processes. There are a variety of tools to accomplish this task, as described next.

Name: Forensic Acquisition Utilities (FAU)/dd (“dd.exe”) Page Reference: 7 Author/Distributor: George M. Garger, Jr. Available From: http://gmgsystemsinc.com/fau/ Description: A commonly used approach to capture the physical memory of a Windows system running the “dd” (dd.exe) command from removable media and gathering the contents locally to external media or over a remote collection utility, such as netcat. Unlike *nix distributions, dd is not a native utility to Windows systems. George M. Garner, Jr., ported dd and included it in his freely available Forensic Acquisition Utilities in 2007; versions of the utility were included in older versions of the Helix Live Response CD. The following command takes the contents of memory from a Windows system and saves it to a file on removable media along with the MD5 hash for integrity validation purposes and to audit log documents in the collection process. E:WinIRmemory>dd.exe if=\.PhysicalMemory of=»E:imageshost1 memoryimage-20070124.dd» conv=sync,noerror —md5sum —verifymd5 —md5out=»E:imageshost1-memoryimage-20070124.dd.md5″ —log=»E:imageshost1-memoryimage-20070124.dd_audit.log»

To ensure consistency and avoid typographical errors, the same command can be launched via an older version of the Helix graphical user interface:

72

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Name: FastDump/FastDump Pro Page Reference: 6 Author/Distributor: HBGary Available From: FastDump Community version is available from https://www.hbgary.com/community/free-tools/; FastDump Pro is available from https://www.hbgary.com/products-services/fastdump/ Description: Command-line physical memory acquisition tools. The FastDump community version (FD.exe) is a free version of FastDump that supports the acquisition of memory from 32-bit systems with up to 4 gigabytes of RAM (does not support Vista, Windows 2003, Windows 2008, or 64-bit platforms). FastDump Pro (FDPro.exe) is the commercially supported version of FastDump, which supports all versions of Windows operating systems and service packs and can acquire memory from both 32- and 64-bit systems, including systems with more than 4 gigabytes of RAM (up to 64 gigs of RAM), including the Windows pagefile. Memory dumps acquired by both versions are saved as .bin files; FastDump Pro memory file dump files, including pagefile acquisition, are saved as .hpak files and the command switches associated with creating .hpak files slightly vary. Helpful Switches: FastDump Community Switch

Function

-v

Verbose output

-q

Skip percent complete output

-f

Ignore OS type and architecture and force dump attempt Use old-style memory acquisition (XP/2k only); attempt to dump physical memory without installing the FastDump driver

-nodriver

FastDump Pro Switch

Function

-probe -nodriver

Pre-dump memory probing Use old-style memory acquisition (XP/2k only); attempt to dump physical memory without installing the FastDump driver

-strict

Use Strict IO: Utilizes 4k reads and writes

-nopage

Skip pagefile collection (.hpak only)

-compress

Create archive compressed (.hpak only)

-nocompress

Create archive uncompressed (.hpak only)

Name: Memoryze Page Reference: 7 Author/Distributor: Mandiant Available From: http://www.mandiant.com/products/free_software/memoryze/ Description: Memoryze is a physical memory acquistion and analysis tool for Windows systems. Unlike other memory acquisition tools, Memoryze allows the digital investigator to perform advanced analysis of memory from a live subject system or from an acquired memory dump. Memoryze officially supports memory acquisition from the following operating systems: Windows 2000 Service Pack 4 (32-bit) Windows XP Service Pack 2 and Service Pack 3 (32-bit) Windows Vista Service Pack 1 and Service Pack 2 (32-bit) Windows 2003 Service Pack 2 (32-bit) Windows 2003 Service Pack 2 (64-bit) Windows 7 Service Pack 0 (32-bit) [Beta] Windows 7 Service Pack 0 (64-bit) Windows 2008 Service Pack 0 (64-bit) [Beta] The official Memoryze User Guide (version 1.4.2900 as of this writing) is available from http://www.mandiant.com/ products/free_software/memor y ze/.

Chapter | 1 Malware Incident Response

To acquire a physical memory image with Memoryze, invoke the memoryzeDD.bat script from your live response tool kit. Helpful Switches: Switch

Function

-output

Directory in which the results will be written.

Name: Mantech DD (MDD) Page Reference: 7 Author/Distributor: Ben Stotts/Mantech Available From: http://cybersolutions.mantech.com/products.htm; http://sourceforge.net/projects/mdd/files/ Description: MantechDD is a physical memory acquistion tool for Windows systems. MDD is capable of acquiring memory images (up to 4 gigabytes) from the following operating systems: Windows 2000 Windows Server 2003 Windows XP Windows Vista Windows Server 2008 Helpful Switches: Switch

Function

-o OUTPUT -q

Memory dump output file Quiet (no tool output except when there is an error)

-v

Verbose output

73

74

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Name: MoonSols Windows Memory Toolkit/Win32dd Page Reference: 7 Author/Distributor: Matthieu Suiche/MoonSols Available From: http://moonsols.com/product Description: The MoonSols Memory Toolkit (MMT) is a physical memory acquisition, conversion, and analysis toolkit that is available in Professional (commercial) and Community (freeware) versions. Included in the MMT is Win32dd, a command-line-based tool used to acquire physical memory images. The Community edition of Win32dd supports memory acquisition from the following Windows operating systems: Microsoft Windows XP, 2003, 2008, Vista, 2008 R2, and 7 32-bit Editions. The Community edition of Win64dd supports memory acquisition from the following operating systems: Microsoft Windows XP, 2003, 2008, Vista, 2008 R2, and 7 64-bit (x64) Editions. The Professional editions of Win32dd and Win63dd support memory acquisition from all Windows operating systems. In the following figure, we used Win32dd Community edition to acquire a physical memory image from a subject system: E:WinIRmemoryMMT>win32dd.exe /r /f E:WinIRmemoryMMTmemdump.mem win32dd — 1.3.1.20100417 — (Community Edition) Kernel land physical memory acquisition Copyright (C) 2007 — 2010, Matthieu Suiche Copyright (C) 2009 — 2010, MoonSols Name Value ——-File type: Raw memory dump file Acquisition method: PFN Mapping Content: Memory manager physical memory block Destination path: E:WinIRmemoryMMTmemdump.mem O.S. Version: Microsoft Windows XP Professional (build 2600) Computer name: KIM-MRKTG-WS5 Physical memory in use: 16% Physical memory size: 1052144 Kb ( 1027 Mb) Physical memory available: 882732 Kb ( 862 Mb) Paging file size: 1346160 Kb ( 1314 Mb) Paging file available: 1278972 Kb ( 1248 Mb) Virtual memory size: 2097024 Kb ( 2047 Mb) Virtual memory available: 2084016 Kb ( 2035 Mb) Extented memory available: 0 Kb ( 0 Mb) Physical page size: 4096 bytes Minimum physical address: 0x0000000000001000 Maximum physical address: 0x00000000403FF000 Address space size: 1077936128 bytes (1052672 Kb) —> Are you sure you want to continue? [y/n] y Acquisition started at: [11/10/2010 (DD/MM/YYYY) 23:17:11 (UTC)] Processing….Done. Acquisition finished at: [2010-10-11 (YYYY-MM-DD) 23:18:46 (UTC)] Time elapsed: 1:34 minutes:seconds (94 secs) Created file size: 1077936128 bytes ( 1028 Mb)

Helpful Switches: Switch

Function

/f

File destination

/r

Create a Raw memory dump file (default) Create a Microsoft memory crash dump file (WinDbg compliant, XP and later only) Create a Microsoft hibernation file (local only, reboot) Create a Microsoft memory crash dump file (BSOD). (local only, reboot)

/d /e /k

75

Chapter | 1 Malware Incident Response

COLLECTING SUBJECT SYSTEM DETAILS System details are a fundamental aspect of understanding a malicious code crime scene. In particular, system details inevitably will be crucial in establishing an investigative time line and identifying the subject system in logs and other forensic artifacts. In addition to the tools mentioned earlier in the chapter, others tools to consider include the following. Name: DumpWin Page Reference: 13 Author/Distributor: NII Consulting Available From: http://www.niiconsulting.com/innovation/tools.html Description: Another tool to consider implementing while collecting subject system details is NII Consulting’s DumpWin, a multipurpose utility that can assist in collecting general system information among other items, such as a list of all software installed on the system, shares present, startup programs, active processes, list and status of services, and list of local Group Accounts and User Accounts, among g other things.

IDENTIFYING USERS LOGGED INTO THE SYSTEM Remember, identifying users logged into the subject system serves a number of investigative purposes: (1) to help discover any potential intruders logged into the compromised system; (2) to identify additional compromised systems; and (3) to provide insight into a malicious insider malware incident, and provide additional investigative context by being correlated with other artifacts. Some other tools to consider for this task include the following. Name: Quser (Query User Utility) Page Reference: 14 Author/Distributor: Microsoft Available From: http://technet.microsoft.com/en-us/library/cc754583%28WS.10%29.aspx Description: A useful tool for identifying logged-in users is the Microsoft Query User utility, or quser, which reveals logged-in users, the time and date of logon time, and the session type and state among other details, as seen below. Quser USERNAME >Kim

SESSIONNAME console

ID 0

STATE Active

IDLE TIME .3/18/2008

Helpful Switches: Switch

Function

-username

Identifies the username

-sessionname

Identifies the session name

-sessionid

Identifies the session ID

LOGON TIME 8:15 AM

76

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Name: LoggonSessions Page Reference: 14 Author/Distributor: Microsoft Available From: http://technet.microsoft.com/en-us/sysinternals/bb896769.aspx Description: Logonsessions is a CLI utility, developed by Bryce Cogswell, that is a part of the PSTools suite. Querying the subject system with logonsessions with the -p argument reveals the processes running in the logged-on session, which is helpful information in a malicious code incident. Helpful Switches: Switch No switches

Function Displays logged-on users

-p

Displays processes running on the logged-on session

NETWORK CONNECTIONS AND ACTIVITY Malware network connectivity is a critical factor for identifying a document; connectivity from a subject system may be to communicate with an attacker’s command and control structure, to download additional malicious files, or to exfiltrate data from the system, among other things. Trusted versions of netstat, arp, and nbtstat are essential in the digital investigator’s toolkit for probing internal and external network connections. In addition to these tools and others mentioned in this chapter, tcpvcoan, described next, is another to consider. Further, for utilities specifically geared for providing insight into port-­ to-process mapping, see the section of this chapter called Correlate Open Ports with Running Processes and Programs appearing on page 22.

Name: Netstat Page Reference: 19-20; 23 Author/Distributor: Microsoft Available From: Clean and trusted version of Windows OS Description: Netstat is the de facto command-line utility for examining network connections to and from a subject Windows system. Netstat enables the digital investigator to identify current and recent network connections if malware on the subject system is connecting to a command and control structure or other remote resource needed by the malware. It is recommended to have different trusted versions of the utility in one’s toolkit that correspond with the various Windows operating systems—particularly because the functionality and features of netstat are distinctly more robust on Windows XP SP2 and higher.

Chapter | 1 Malware Incident Response

Helpful Switches: Switch

Function

-a -b

Displays all connections and listening ports Path-to-executable that created network connection or listening port

-e

Displays Ethernet statistics

-n -o

Displays address and port numbers in numerical form Displays the process (PID) associated to a network connection or listening port

-p proto

Shows connections for the protocol specified

-r

Displays routing table

-s

Displays per-protocol statistics Used in conjunction with the –b switch; displays detailed listing of .dlls associated with the executable file involved in creating a network connection or listening port Redisplays selected data in intervals

-v Interval

Name: ARP Page Reference: 17 Author/Distributor: Microsoft Available From: Clean and trusted version of Windows OS Description: The arp utility is geared toward collecting data regarding internal network connections using the Address Resolution Protocol (ARP). This is particularly useful when examining the subject network for internal network malware propagation; examination of a subject system’s ARP cache will identify other systems that are currently or have recently established a connection to the subject system. Helpful Switches: Switch

Function

-a

Displays current ARP entries

-g

Same as –a option

-inet_addr -N inet_add

Specifies an Internet address Displays the ARP entries for the network interface identified by the if_addr switch

-eth_addr

Specifies a physical network address

77

78

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Name: Nbtstat Page Reference: 17 Author/Distributor: Microsoft Available From: Clean and trusted version of Windows OS Description: Just as netstat is the de facto utility for examining network connections, nbtstat is the de facto tool for examining NetBIOS connections. In particular, nbtstat can be used to acquire the NetBIOS cache or reveal current sessions, identifying the NetBIOS names and IP addresses of other computers that have recently or are currently connected to the subject system. Helpful Switches: Switch

-c

Function Lists the remote machine’s name table when supplied its name Lists the remote machine’s name table when supplied its IP address Lists NBT’s cache of remote machine names and their IP addresses

-n

Lists local NetBIOS names

-r

Lists names resolved by broadcast and via WINS

-S -s

Lists sessions table with the destination IP addresses Lists sessions table converting destination IP addresses to computer NETBIOS names

RemoteName

Remote host machine name

-a -A

Name: Net Page Reference: 17, 26 Author/Distributor: Microsoft Available From: Trusted Windows system Description: Net is a multipurpose native Windows utility. Helpful Switches: Switch file

Function Identify file names and locations of files recently transferred over NetBIOS

sessions

Identify current NetBIOS sessions

user

Lists user accounts

start

Displays list of running services by name only

Name: TCPVcon Page Reference: 22 Author/Distributor: Mark Russinovich/Microsoft (formerly Sysinternals) Available From: http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx Description: TCPVcon is a command-line utility that is bundled with the Microsoft utility TCPView, a graphical based utility that diplays TCP/IP and UDP connections and end points in real time. TCPVcon provides granular and structured output, identifying the protocol of the connection, the path of the executable spawning the network connection, the process ID, the network connection state, the local address, and the address of the remote connection. E:WinIRNetwork>tcpvcon.exe -a TCPView v2.34 — TCP/UDP endpoint lister Copyright (C) 1998-2003 Mark Russinovich Sysinternals — www.sysinternals.com

Chapter | 1 Malware Incident Response

79

[TCP] C:WINDOWStempspoolsvspoolsv.exe PID: 864 State: LISTENING Local: Kim-mrktg-ws5:auth Remote: xxx.xxx.xxx.xxx:6667 [TCP] C:WINDOWSsystem32svchost.exe PID: 1004 State: LISTENING Local: Kim-mrktg-ws5:epmap

Helpful Switches: Switch -a

Function Show all end points (default is to show established TCP connections)

-c

Print output as CSV

Only show end points owned by a target process

PROCESS ANALYSIS As many malware specimens (such as worms, viruses, bots, key loggers, and Trojans) will often manifest on the subject system as a process, collecting information relating to processes running on a subject system is essential in malicious code live response forensics. Process analysis should be approached holistically— examine all relevant aspects of a suspicious process, as outlined in the chapter. Listed next are additional tools to consider for your live response toolkit. Name: pmon Page Reference: 18 Author/Distributor: Microsoft Available From: http://www.microsoft.com/downloads/en/details.aspx?familyid=9d467a69-57ff-4ae796ee-b18c4790cffd&displaylang=en Description: Pmon is very similar to the top command in *Nix systems, providing for a real-time granular look at the statistics relating to running processes such as memory usage and duration.

Name: pulist Page Reference: 18 Author/Distributor: Microsoft Available From: http://support.microsoft.com/kb/927229; (http://download.microsoft.com/download/win2000platform/pulist/1.00.0.1/nt5/en-us/pulist_setup.exe); also available from the Windows2000 Resource Kit Description: Similar to tlist, pulist displays processes that are running on local or remote computers, but also lists the user name that is associated with each process on a local computer. Helpful Switches: Switch

Function

\Server

Queries targeted remote system If no server name is specified, pulist will attempt to display the username associated with each process running on the local system

No switches

80

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

HANDLES Name: OpenHandles Page Reference: 21 Author/Distributor: Microsoft Available From: http://support.microsoft.com/kb/927229 and http://download.microsoft.com/download/win2000platform/oh/1.00.0.1/nt5/en-us/oh_setup.exe. Description: In addition to handle, another utility that can be used to inspect file handles is Microsoft’s Open Handles (oh.exe) utility, which is available as part of the Windows 2000 Resource Kit Tools for administrative tasks.

Loaded DLLs Name: Procinterrogate Page Reference: 21 Author/Distributor: Kirby Kuehl/WinFingerprint Available From: http://winfingerprint.sourceforge.net/wininterrogate.php Description: Procinterrogate allows the digital investigator to identify all DLLs imported by running processes, but also gives the investigator the ability to query individual processes by PID using the -pid switch. Further, the procinterrogate output provides the entry point address of each loaded module. Helpful Switches: Switch -list — pid -ver -md5

Function Lists all processes, process IDs and their associated DLLs Lists DLLs associated with a process ID Obtain version information of associated DLLs Calculate MD5 sums of processes and their associated DLL

Name: PRCView (pv.exe) Page Reference: 21 Author/Distributor: Igor Nys/CTI Available From: http://www.teamcti.com/pview/prcview.htm Description: PRCView is a powerful process viewing suite of tools that comes with both a GUI-based utility and a command-line functional equivalent named pv.exe. Using the pv -m switch provides very similar output to procinterrogate, and reveals the module, base, size, and path of the DLLs associated with the queried process. Helpful Switches: Switch Function Get extended list of running processes; displays path where executable -e associated with process resides on the subject system -s Show usage for the specified module -g Get startup environment for target process -m -m –e Get extended information about specified process’ modules List of all processes that use matching DLL -u

Name: ListModules Page Reference: 21 Author/Distributor: Arne Vidstrom Available From: http://ntsecurity.nu/toolbox/listmodules/ Description: List Modules reveals the modules loaded into a process in memory on the subject system in a clean and intutive format. Helpful Switches: Function Switch

Lists loaded modules in target process

Chapter | 1 Malware Incident Response

81

CORRELATE OPEN PORTS WITH RUNNING PROCESSES AND PROGRAMS Name: Fport Page Reference: 23 Author/Distributor: Foundstone (a division of McAfee) Available From: http://www.mcafee.com/us/downloads/free-tools/fport.aspx Description: Fport is a command-line utility that can map open ports to associated processes and the respective executable programs on the subject system. Helpful Switches: Switch Function /a Sort by application /p Sort by port /i Sort by PID /ap Sort by application/executable path Name: OpenPorts Page Reference: 23 Author/Distributor: DiamondCS Available From: http://majorgeeks.com/OpenPorts_d3950.html Description:Openports is a command-line utility that maps TCP and UDP ports to the owner processes. Openports provides a variety of different viewing options allowing for calibration of detail and format. Helpful Switches: Switch Function -lines Adds lines between processes for easier viewing -path Processes are displayed with full path to executable -netstat Results are displayed similar to Window XP′s netstat -fport Results are displayed similar to FPort -csv Results are displayed in CSV format (comma separated values) Name: CurrPorts Page Reference: 23 Author/Distributor: NirSoft Available From: http://www.nirsoft.net/utils/cports.html Description: A GUI and CLI-based tool that provides the digital investigator with a detailed snapshot of the process name, PID, and local and remote port numbers, along with IP addresses, port state, executable program path, and other detailed information. Helpful Switches: Switch Function /text /stab

Save the list of all opened TCP/UDP ports into a tab-delimited text file Save the list of all opened TCP/UDP ports into a tab-delimited text file

Command-line Arguments Name: tlist Page Reference: 26 Author/Distributor: Microsoft Available From: http://www.microsoft.com/downloads/en/details.aspx?familyid= C055060B-9553-4593-B937-C84881BCA6A5&displaylang=en Description: tlist, referenced above in the Loaded DLLs section, can also be used to display the command-line arguments associated with all running processes on a subject system. Helpful Switches: Switch Function -c Show command lines for each process

SERVICES Malware can manifest on a victim system as a service, silently running in the background, unbeknownst to the user. As with the examination of running processes and open ports, explore running services by first gaining an overview,

82

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

and then apply tools to extract information about the services with more particularity. Some other service analysis tools include: Name: psservice Page Reference: 24 Author/Distributor: Mark Rusinovich/Microsoft (formerly Sysinternals) Available From: http://technet.microsoft.com/en-us/sysinternals/bb897542.aspx Description: Provides a very detailed view of the services on a subject system. Helpful Switches: Switch -query -config -find

Function Queries the status of a service Queries the configuration Searches for an instance of a service on the network

Name: ServiWin Page Reference: 24 Author/Distributor: Available From: http://www.nirsoft.net/utils/serviwin.html Description: GUI and CLI tool ServiWin, which when used with the /stext > switch, provides a detailed description of each individual service. Helpful Switches: Switch Function /stext Saves the list of all drivers/services into a regular text file /stab Saves the list of all drivers/services into a tab-delimited text file /scomma Saves the list of all drivers/services into a comma-delimited text file

DRIVERS In addition to determining the running services on a subject system, consider examining the installed drivers on the system, including the nature and status of the drivers. A reminder of the importance of this step is the recent sophisticated malware variant, Stuxnet, which installs drivers used to inject code into system processes and to conceal the malware. In addition to the tools discussed in Chapter 1, another tool to consider is ListDrivers. Name: ListDrivers Page Reference: 25 Author/Distributor: Arne Vidstrom Available From: http://ntsecurity.nu/toolbox/ Description: ListDrivers is a lightweight command-line utility that lists the loaded kernel drivers and associated memory addresses on a subject system. This tool does not require (nor have) any command switches to invoke.

OPENED FILES Open files on a subject system may provide clues about the nature and purpose of the malware involved in an incident, as well as correlative artifacts for your investigation. In Chapter 1 we examined the tool OpenFilesView; another tool to consider is openfiles.

Chapter | 1 Malware Incident Response

83

Name: openfiles Page Reference: 25 Author/Distributor: Microsoft Available From: Trusted Windows system; user reference is available from http://technet.microsoft.com/en-us/library/bb490961.aspx Description: An alternative to OpenedFilesView is openfiles, a command-line utility that can query and display files that are opened locally or by network users. Helpful Switches: Switch Function /query Displays files opened locally or from shared folders /fo Displays the output in the specified format /query To query and display all open files in list format with /fo list /v detailed information

DETERMINING SCHEDULED TASKS Recall that some malicious code variants are “event-driven,” meaning that until a certain date or event triggers execution, the malware will remain dormant. In Chapter 1, we referenced the Microsoft utility schtasks, which is described in further detail below. Name: schtasks Page Reference: 27 Author/Distributor: Microsoft Available From: Trusted system; information regarding the utility is available from http://technet.microsoft.com/en-us/library/cc772785%28WS.10%29.aspx. Description: Schtasks is a native Microsoft utility that provides detailed information regarding any tasks scheduled on the subject system; the level of granularlity in the output can be calibrarted using a combination of swtiches. To dentify whether there are any tasks scheduled on the system, simply invoke the schtasks/query command; if you identify a scheduled task, detailed information can be extracted using the command string schtasks/query/fo/LIST/v. Helpful Switches: Switch Function /query Displays all scheduled tasks /fo Displays the output in the specified for mat /query /fo To query and display all scheduled tasks on the subject system in list format with detailed LIST /v information

CLIPBOARD CONTENTS Remember that an attacker, whether remotely logged into a system or a nefarious insider, may cut and paste information while on a subject system. This information may provide valuable investigative leads and correlate other artifacts found on the system, in network traffic, or in the malicious code itself. Name: InsideClipboard Page Reference: 27 Author/Distributor: NirSoft Available From: http://www.nirsoft.net/utils/inside_clipboard.html Description: Another tool that can be used to harvest clipboard contents is NirSoft’s InsideClipboard, which is a GUI and CLI utility that displays the binary content of all formats that are currently stored in the clipboard, and allows you to save the content of specific format into a binary file. InsideClipboard can be invoked from the command prompt, and the results of the query can be saved in multiple report formats including standard text, Hypertext Markup Language (HTML), and eXtensible Markup Language (XML), among others. Helpful Switches: Switch Function /stext Save the clipboard items list into a regular text file /stab Save the list of all startup items into a tab-delimited text file

84

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Non-Volatile Data Collection and Analysis Tools SYSTEM SECURITY CONFIGURATION Name: Microsoft Baseline Security Analyzer Page Reference: 30 Author/Distributor: Microsoft Available From: http://msdn2.microsoft.com/en-us/library/aa302360.aspx Description: Microsoft Baseline Security Analyzer (MBSA), available in both a GUI (Mbsa.exe) and command-line (Mbsacli.exe) utility, scans a subject system for insecure configurations and checks for available updates, service packs, and patches for the operating system, among other things. Helpful Switches: Switch

/nd /xmlout

Function Instructs MBSA to not download any files from the Microsoft Web site during the course of performing a scan, emulating offline mode Useful for performing a basic security scan on a subject system without having to install all MBSA features

PREFETCH FILE ANALYSIS Name: Windows File Analyzer Page Reference: 31 Author/Distributor: Mitec Available From: http://www.mitec.cz/wfa.html. Description: Recall that when a program is executed, the Windows operating system creates a “Prefetch” file that enables speedier subsequent access to the program. Embedded within the Prefetch files are the most recent time a program was executed (bytes 120–128) and the number of times it was executed (bytes 144–148). This embedded information can be extracted manually, or using a tool like Windows File Analyzer. The following figure shows Windows File Analyzer as it is used to view the Prefetch information on a subject system. Another approach to viewing this information is to mount the forensic duplicate using a tool like MountImage Pro and directing Windows File Analyzer to read the Prefetch folder on the mounted drive, as discussed in Chapter 3. The right most column shows the number of times the executable was run, but this number is not incremented when an executable is automatically run from an autostart location when the system boots.

Chapter | 1 Malware Incident Response

85

AUTO-START LOCATIONS As was discussed in this chapter, malware often has a persistence mechanism to ensure longevity on a computer. A frequent method used for this purpose is the creation of an auto-start location (also referred to as an “autorun”) in the registry. In addition to the Microsoft Autoruns tool, another option for discovering and analyzing autorun locations is StartupRun. Name: StartupRun (strun) Page Reference: 32 Author/Distributor: NirSoft Available From: http://www.nirsoft.net/utils/strun.html Description: StartupRun is an alternative GUI and command-line utility available from NirSoft for displaying applications that are loaded automatically when Windows boots up, including the registry key associated with program. Helpful Switches: Switch /stext

/stab

Function Save the list of all startup items into a regular text file Save the list of all startup items into a tab-delimited text file

EVENT LOGS On Windows systems, many activities related to a malware incident can generate entries in the Event Logs. Some other Event Log dumping tools to consider for your live response toolkit include: Name: psloglist Page Reference: 32 Author/Distributor: Mark Russinovich/Microsoft (formerly Sysinternals) Available From: http://technet.microsoft.com/en-us/sysinternals/bb897544.aspx Description: Psloglist is a function-rich Windows Event Log dumping tool, providing the digital investigator with numerous options to customize the scope, breadth, and presentation of the data output. Helpful Switches: Switch -i

Function Show only events with the specified ID or IDs (up to 10)

-r

Dump log from least recent to most recent

-l

Dump the contents of the specified saved event log file

86

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Name: Dump Event Log (dumpel) Page Reference: 32 Author/Distributor: Microsoft Available From: Windows 2000 Resource Kit; http://download.microsoft.com/download/win2000platform/WebPacks/1.00.0.1/NT5/EN-US/Dumpel.exe Description: Dump Event Log (dumpel) is a command-line utility that dumps a specified Windows Event Log for a local system or a remote system into a tab-separated text file; the tool also provides numerous event-filtering switches. Helpful Switches: Switch -l -f

-e nn

Function Dumps the specified log (system, application, security) Output filename (default stdout) Filters for even id nn (up to 10 may be specified)

GROUP POLICIES Remember to closely inspect user accounts that are local to the subject system or domain accounts that were used to log in—these can reveal how malware was placed on the computer. Below are additional tools that assist in examining user and group policy details. Name: GPList Page Reference: 33 Author/Distributor: Arne Vidstrom Available From: http://ntsecurity.nu/toolbox/ Description: Displays information about the following Group Policies applied to a system: Folder Redirection, Microsoft Disk Quota, QoS Packet Scheduler, Scripts, Security, Internet Explorer Branding, EFS recovery, Software Installation, and IP Security. This tool does not require (nor have) any command switches to invoke. Name: GPResult Page Reference: 33 Author/Distributor: Microsoft Available From: Windows Resource Kit or trusted system Description: GP Result is a command-line tool that verifies all policy settings for a specific user or computer. Helpful Switches: Switch -z -v

Function Specifies that the output display all available information about Group Policy Specifies that the output display verbose policy information

FILE SYSTEM: HIDDEN FILES AND ALTERNATE DATA STREAMS Malware and associated artifacts often manifest as hidden files. Similarly, certain malware specimens abuse the NTFS Alternate Data Stream feature— which allows you to hide data in an existing file name with the use of a stream name—to hide the malware or associated files. Consider adding tools to your live response toolkit to discover these files.

Chapter | 1 Malware Incident Response

Name: HFind Page Reference: 33 Author/Distributor: Foundstone Available From: http://www.foundstone.com/us/resources/proddesc/forensic-toolkit.htm Description: HFind is a command-line utility included in the Foundstone Forensic Toolkit 2.0 — a collection of freeware command-line utilities that allows the digital investigator to investigate a subject system (NTFS only) for metadata and artifacts. In particular, HFind can be used to scan the target system for hidden files. If hidden files are detected, HFind lists the last access times to the files. Querying our subject system (targeting what we have learned through our investigation to be a suspicious directory) with HFind we discover numerous hidden files, as shown in the following output: E:WinIRHiddenfilesForensicToolkit20>HFind.exe C:WINDOWSTemp Searching… C:WINDOWSTempspoolsv a.reg 14/10/2010 05:52:36 aliases.ini 14/10/2010 05:52:36 com.mrc 14/10/2010 05:52:37 control.ini 14/10/2010 05:52:39 Desktop.ini 14/10/2010 05:52:36 C:WINDOWSTempspoolsvdownload ident.txt 14/10/2010 05:52:36 C:WINDOWSTempspoolsvlogs mirc.ico 14/10/2010 05:52:36 mirc.ini 14/10/2010 05:57:28 popups.txt 14/10/2010 05:52:36 remote.ini 14/10/2010 05:52:39 run.bat 14/10/2010 05:52:36 servers.ini 14/10/2010 05:52:36 C:WINDOWSTempspoolsvsounds spoolsv.exe 14/10/2010 05:52:39 users.ini 14/10/2010 05:52:37 Finished

Helpful Switches: Switch -ns

Function Skip subdirectories

Name: LADS (List Alternate Data Streams) Page Reference: 33 Author/Distributor: Frank Heyne Software Available From: www.heysoft.de Description: As the name of the tool suggests, LADS lists files on Windows NT file systems that contain alternate data streams (ADS). LADS provides the digital investigator with an intuitive menu and command switch options. To invoke LADS, simply excute the utility at the command line and identify the target directory: LADS ; additional command switches can dig deeper into subdirectories. Helpful Switches: Switch -s -A -Xname

Function Includes subdirectories Give a summary of all bytes used in the scanned directories Exclude any ADS “name”

-Pfile

Read parameters from “file”

87

88

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Name: streams Page Reference: 33 Author/Distributor: Mark Russinovich/Microsoft (formerly Sysinternals) Available From: to http://technet.microsoft.com/en-us/sysinternals/bb897440.aspx Description: Another helpful tool for identifying NTFS alternate data streams is Mark Russinovich’s streams. Similar to LADS, streams provides the digital investigator with the option of scanning subdirectories of interest with a command switch (-s). The only required command parameter needed to invoke streams is a target file or directory name: streams.exe . Helpful Switches: Switch

Function

-s

Recurse subdirectories

Dumping and Parsing Registry Contents Name: RegDump Page Reference: 34 Author/Distributor: Microsoft Available From: http://download.microsoft.com/download/d/2/5/d2522ce4-a441-459d-8302be8f3321823c/LogoToolsv1.0.msi Description: RegDump (regdump.exe) is a command-line tool included in the Microsoft Logo Tools suite that enables the digital investigator to dump the contents of Registry Hives into a text file. Helpful Switches: Switch /o

Function

/r /acls /detail

WEB HISTORY Client-side exploits are becoming more and more prevalent, particularly through “drive-by-downloads.” Drive-by-downloads often occur when a user with an insecure or improperly configured Web browser navigates to a compromised (or nefarious) Web site that is surreptitiously hosting malware, allowing the malware to silently be downloaded onto the victim system. As a result, it is always advisable to examine the subject system Web history to gain insight into whether a Web-based vector of attack caused the malicious code incident.

Name: Pasco Page Reference: 38 Author/Distributor: Foundstone Available From: http://www.foundstone.com/us/resources/proddesc/pasco.htm Description: Pasco is multi-platform command-line utility that parses Internet Explorer history files (Index.dat), the results of which are output into a field delimited text file, enabling the digital investigator to import into a spreadsheet to further analyze the data.

Chapter | 1 Malware Incident Response

89

Name: NirSoft Web History Tools Page Reference: 38 Author/Distributor:NirSoft Author/Distributor: NirSoft Available From: http://www.nirsoft.net/utils/ http://www.nirsoft.net/utils/ Description: NirSoft offers a variety of free dual functional GUI/command-line tools that can extract and help resconstruct the Web browsing history on a subject system. Some of these tools include: IEHistoryView—Extracts information from the history file (index.dat) of Internet Explorer; stores only one record for every Web page visit. IECacheviewer—Similar to IEHistoryView, the cache file stores multiple records for every Web page, including all images and other files loaded by the Web page. IECookieView—Extracts the content of all cookie files stored by Internet Explorer. MozillaHistoryView—Extracts the details of all browsing history stored by Mozilla Firefox. MozillaCacheView—Extracts the details of all cache files stored by Mozilla Firefox. MozillaCookieView—Extracts the content of all cookie files stored by Mozilla Firefox. FavoritesView—Extracts the list of Favorites/Bookmarks. ChromeCacheView—Extracts the details of all cache files stored by Google Chrome Web browser. OperaCacheView—Extracts the details of all cache files stored by Opera Web browser. MyLastSearch—Scans the cache files for the four Web browsers (IE, Mozilla, Opera, and Chrome), and extracts recent search queries made from the subject sub ject system. system.

MALWARE EXTRACTION As discussed in this chapter, once a suspicious file is identified through live response, safely extracing and preserving the files for further analysis is an essential aspect of malware forensics. Another tool to consider for this process is HBGary’s FGET. Name: FGET Page Reference: 39 Author/Distributor: HBGary Available From: https://www.hbgary.com/community/free-tools/; https://www.hbgary.com/wpcontent/themes/blackhat/images/fget.rar Description: FGET is a command-line utility that can acquire files from local and remote subject systems. Using FGET from your trusted live response toolkit locally on a subject, you can quickly acquire a suspicious file by invoking the tool using the “–extract” switch, identifying the target file and the location of where to copy the file, as shown in the following output: E:WinIRExtractionFGET>FGET.exe -extract c:WINDOWSTempspoolsvspoolsv.exe E:WinIRExtractionEvidencespoolsv.exe -= FGET v1.0 — Forensic Data Acquisition Utility — (c)HBGary, Inc 2010 =[+] Extracting File From Volume …SUCCESS!

FGET is also intended for acquisition of files over a network, with varying degrees of difficulty and system preparation. To use FGET on remote systems, the local acquisition system must have a repository directory created (by default the directory is C:FGETREPOSITORY). Using the remote acquisition capabilities of FGET, we can copy the suspicious file from the subject system over the network from our analysis system, as shown in the followng output. Note that FGET places the target files in the FGETREPOSITORY directory, and in turn, in an auto-generated subdirectory name to comport with the target system IP address in an effort to easily parse acquisition results.

90

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

E:WinIRExtractionFGET>FGET.exe-scan192.168.79.130-extract c:WINDOWSTempspoolsvspoolsv.exe -= FGET v1.0 — Forensic Data Acquisition Utility — (c)HBGary, Inc 2010 =[+] Operation STARTED for: “Forensic Get 1.0” … [+] Actions: REPORT ************************************************ [+] Setting maximum scanner thread count to: 1 [+] Capturing Machine: «192.168.79.130» The command completed successfully. [+] Authentication to C$ Successful! A subdirectory or file C:FGETREPOSITORY192.168.79.130 already exists. 1 file(s) copied. [+] Scanned: 1 of 1 nodes. (1 active scan threads) 1 file(s) copied.scan threads to finish … [+] Copied file locally to: “C:FGETREPOSITORY192.168.79.130” [!] Evidence Acquisition Completed for Host: «192.168.79.130» in 1 seconds @ Wed Oct 13 20:02:48 2010 [+] Machine: “192.168.79.130” Successfully Captured ************************************************ [+] Operation FINISHED for: «Forensic Get 1.0» … ************************************************ [!] Attempted Node Checks: 1 [!] Pingable Nodes: 1 [!] Authenticated: 1 [S] Successful: 1 — SUCCESS: 192.168.79.130 [+] Scan completed in 2 seconds

A full description of FGET functionality is available from http://www.hbgary.com/wpcontent/themes/blackhat/images/fget-faq-v1.docx.

Helpful Switches: Local System Commands Switch

Function

-extract file_to_get_path copy_to_path -unpack my.hpak unpack_to_directory_path Remote System Commands

Extract file Upack files acquired by FGET

Switch -scan target_name [-extract remote_filepath local_filepath]

Function Remote acquisition of a target file from a single remote target system Remote acquisition of a target file from a list of remote target systems Remote acquisition of a target file from a list of remote target systems

-list targetlist.txt [-extract remote_filepath] -range start_ip end_ip [-extract remote_filepath]

Chapter | 1 Malware Incident Response

91

SELECTED READINGS Books Carvey, H. (2009). Windows Forensic Analysis DVD Toolkit, Second edition. Burlington, MA. ­Syngress. Jones, K., Bejtlich, R., and Rose, C.W. (2005). Real Digital Forensics. Reading, MA: Addison-­ Wesley. Prosise, C., Mandia, K., and Pepe, M. (2003). Incident Response and Computer ­Forensics, Second edition. New York: McGraw-Hill/Osborne.

Papers Kent, K. et. al. (2006). Guide to Integrating Forensic Techniques into Incident Response. National Institute of Standards and Technology, Special Publication 800–86. Mancini, S. (2006). RAPIER: A 1st Responders Information Acquisition Framework. First ­Conference 2006. Pär Österberg Medina, S. (2008). Detecting Intrusions: The Latest Forensics Tools and Techniques to Identify Windows Malware Infections. First Conference 2008. Waits, C. et. al. (2008). Computer Forensics: Results of Live Response Inquiry vs. Memory Image Analysis. Carnegie Melon Software Engineering Institute.

JURISPRUDENCE/RFCS/TECHNICAL SPECIFICATIONS Columbia Pictures Indus. v. Bunnell, 2007 U.S. Dist. LEXIS 46364 (C.D. Cal. June 19, 2007). RFC 3227—Guidelines for Evidence Collection and Archiving.

Chapter 2

Memory Forensics Analyzing Physical and Process Memory Dumps for Malware Artifacts Solutions in this chapter: • Memory Forensics Overview • Old School Memory Analysis • How Windows Memory Forensic Tools Work • Windows Memory Forensic Tools • Dumping Windows Process Memory • Dissecting Windows Process Memory

INTRODUCTION The importance of memory forensics in malware investigations cannot be overstated. A complete capture of memory on a compromised computer ­generally bypasses the methods that malware uses to trick operating systems, providing digital investigators with a more comprehensive view of the ­malware. In some cases, malware leaves little trace elsewhere on the compromised ­system and the only clear indications of compromise are in memory. In short, memory forensics can be used to recover information about malware that was not ­otherwise ­obtainable. Digital investigators often find useful information in memory dumps simply by reviewing readable text and performing keyword searches. However, as the size of physical memory in modern computers continues to increase, it is inef­ ficient and ineffective to review an entire memory dump manually. In addition, much more contextual information can be obtained using specialized knowledge of data structures in memory and associated tools. Specialized forensic tools are evolving to extract and interpret a growing amount of structured data in memory dumps, enabling digital investigators to recover substantial evidence pertaining to malware incidents. Such digital evidence includes recovery of deleted or hidden processes, including the executables and associated data in memory and the page­ file. More sophisticated analysis techniques are being codified in memory forensic tools to help digital investigators find malicious code in an automated manner. Malware Forensics Field Guide for Windows Systems. DOI: 10.1016/B978-1-59749-472-4.00002-0 © 2012 Elsevier, Inc. All rights reserved.

93

94

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Investigative Considerations

• There is still information available during the live response that cannot be extracted from memory dumps, for instance, network configuration and enabled protocols, ARP cache, and NetBIOS sessions. Therefore, it is impor­ tant to implement the process described in Chapter 1 and not just acquire a physical memory dump. With the increasing power and automation of memory forensic tools, it is becoming more important for digital investigators to understand how the tools work in order to validate the results. Without this knowledge, digital investigators will find themselves reaching incorrect conclusions based on faulty tool output or missing important information entirely. In addition, digital investigators need to know the strengths and weaknesses of various memory forensic tools in order to know when to use them and when their results may not be entirely reliable. Ultimately, digital investigators must have some knowledge of how mal­ ware can manipulate memory and need to be familiar with a variety of memory forensic tools and how they interpret underlying data structures. This chapter provides a comprehensive approach for analyzing malicious code in memory dumps from a Windows system and covers associated techniques and tools. Details about the underlying data structures are beyond the scope of this field guide and are discussed in the text Malware Forensics: Investigating and Analyzing Malicious Code (hereinafter Malware Forensics).1

MEMORY FORENSICS OVERVIEW

R After memory is preserved in a forensically sound manner, employ a strategy and associated methods to extract the maximum amount of information relating to the malware incident. u A memory dump can contain a wide variety of data, including malicious executables, associated system-related data structures, and remnants of related user activities and malicious events. Some of this information has associated date-time stamps. The purpose of memory forensics in malware incidents is to find and extract data directly relating to malware and associated informa­ tion that can provide context, such as when certain events occurred and how ­malware came to be installed on the system. Specifically, in the context of ­analyzing malicious code, the main aspects of memory forensics include: • Harvest available metadata including process details, network ­connections, and other information associated with potential malware for analysis and comparison with volatile data preserved from the live system. • Perform keyword searches for any specific known details relating to a malware incident, and look through strings for any suspicious items. • Look for common indicators of malicious code including memory ­injection and hooking. 1

  http://www.syngress.com/digital-forensics/Malware-Forensics/.

Chapter | 2 Memory Forensics

95

• For each process of interest, if feasible, recover the executable code from memory for further analysis.

• For each process of interest, extract associated data from memory, including related encryption keys and captured data such as usernames and passwords.

• Extract contextual details such as Event Logs, URLs, MFT entries, and Registry values pertaining to the installation and activities associated with malicious code. • Perform temporal and relational analysis of information extracted from memory, including a time line of events and a process tree diagram. u These processes are provided as a guideline and not as a checklist for perform­ ing memory forensics. No single approach can address all situations, and some of these goals may not apply in certain cases. In addition, the specific implemen­ tation will depend on the tools that are used and the type of malware involved. Ultimately, the success of the investigation depends on the abilities of the digital investigator to apply digital forensic techniques and adapt them to new challenges.

Investigative Considerations • The completeness and accuracy of the above steps depend heavily on the tools used and your familiarity with the data structures in memory. Some tools will only provide limited information or may not work on memory acquired from certain versions of Windows. • In one case, digital investigators ran a tool on a memory dump and extracted a limited list of IP addresses that had communicated with the compromised system. Another digital investigator looked at the same memory dump and used his knowledge of memory structures to recover hundreds of additional connections that were relevant to the investigation. • To avoid mistakes and missed opportunities, it is necessary to compare the results of multiple tools and to verify important findings manually.

N Analysis Tip Field Interviews

Most incidents have a defining moment when malicious activity was recognized. The more information that digital investigators have about that moment, the more they can focus their forensic analysis and increase the chances of solving the case. Simply knowing the rough time period of the incident and knowing what evidence of malware was observed can help digital investigators develop a strategy for scouring memory dumps for relevant digital evidence. Without any such background information, forensic analysis can be like trying to find a needle in the haystack, which can result in wasted time and lost opportunities (e.g., relevant network logs being overwritten). Therefore, prior to performing forensic analysis of a memory dump, it is advisable to gather as much information as possible about the malicious code incident and subject system from relevant witnesses. The Field Interview Questions in Chapter 1 provide a solid foundation of context to support a strong forensic analysis of malware in memory.

96

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Old School Memory Analysis

R In addition to using specialized memory forensic tools to interpret specific data structures, look through the data in raw, uninterpreted form for information that is not extracted automatically. u Although the memory forensic tools covered in this chapter have advanced considerably over the past few years, there is still a substantial amount of ­useful information in memory dumps that many specialized tools do not extract ­automatically. Therefore, it is generally still productive to employ “old school” memory analysis, which was essentially limited to a manual review of the memory dump, keyword searching, file carving, and use of text extraction utili­ ties such as the strings command (with Unicode support). These old school ­techniques can uncover remnants of activities or data that may be related to malicious code, including but not limited to the following: • File fragments such as Web pages and Word documents no longer ­present on disk • Commands run at the Windows command line • Prefetch file names • E-mail addresses and message contents • URLs, including search engine queries • Filenames and even full MFT entries of deleted files • IP packets, including payload Unexpected information can be found in memory dumps such as intruder’s commands and communications that are not saved elsewhere on the computer, making a manual review necessary in every case. u For instance, in a case involving the ZeuS Trojan program, entire HTTP GETs and POSTs are visible along with the entire encrypted data sections of the communications as shown in Figure 2.1, a benefit particularly when ­network traffic was not previously captured.2

FIGURE 2.1–Encrypted packet contents associated with the ZeuS Trojan communications ­captured in memory dump 2

  Cheval and Oxley (2011), Masters Thesis, Johns Hopkins University Information Security Institute.

Chapter | 2 Memory Forensics

97

Memory dumps can also capture command and control activities such as instructions executed by the attacker and portions of network communications associated with an attack. Figure 2.2 shows an example of an IP packet and payload captured in a target memory dump. u

FIGURE 2.2–IP packet in memory with source IP address 172.16.157.136 (ac 10 9d 88), ­destination IP 172.16.157.1 (“AC 10 9D 01”) starting at offset 0x0263B01A and payload ­visible in ASCII

It is often desirable to extract certain files from a memory dump for further analysis. • One approach to extracting executables and other types of files for fur­ ther analysis is to employ file carving tools such as Foremost and Scalpel to run on the full memory dump or on extracted memory regions relating to a specific process (Figure 2.3). • The results of file carving can be more comprehensive than the more sur­ gical file extraction methods used by specialized memory forensic tools. • However, current file carving tools only salvage contiguous data, whereas the contents of physical memory may be fragmented. Therefore, the ­executables that are salvaged using this method may be incomplete. u

$ foremost -i -o memory-carve -t all

FIGURE 2.3–Carving memory with foremost

Even when sophisticated memory forensic tools are available, digital inves­ tigators benefit from spending some time looking through readable text in a memory dump or process memory dump. • When clues such as IP addresses are available from other aspects of a digital investigation, keyword searching is another efficient approach to locating specific information of interest. • Given the widespread use of Unicode by the Windows operating system, it is critical to use a tool that can extract Unicode strings, such as the strings utility available from Microsoft.

u

Investigative Considerations • These old school approaches to extracting information from memory dumps  do not provide surrounding context. For instance, the time ­associated

98

•

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

with a URL or IP packet will not be displayed automatically, and may not be available at all. For this reason, it is important to combine the results of old school analysis with those of specialized memory forensic tools to obtain a more complete understanding of activities pertaining to a malware incident. Although memory forensic tools provide a mechanism to perform precise extraction of executables by reconstructing memory structures, there can be a benefit to using file carving tools such as Foremost and Scalpel. File carv­ ing generally extracts a variety of file fragments that might include graphics files, reviewed document fragments showing an intruder’s collection inter­ est, and data that may have been stolen.

HOW WINDOWS MEMORY FORENSIC TOOLS WORK Understanding the underlying operations that memory forensic tools ­perform can help you select the right tool for a specific task and assess the accuracy and completeness of results. • Some tools will only list active processes, whereas others will scan for all executive process (EPROCESS) structures. • Some tools only extract certain areas of process memory, whereas others can extract related information from the pagefile as well as the execut­ able associated with a process. • Some tools will detect memory injection and hooking correctly, whereas others will identify such features incorrectly (false positive) or not at all (false negative). • Additional details about how memory forensic tools work are provided in the Malware Forensics text. u

Investigative Considerations • Although many memory forensic tools can be used without understanding the operations that the tool uses to interpret data structures in memory, a lack of understanding will limit your ability to analyze relevant information and will make it more difficult to assess the completeness and accuracy of the information. Therefore, it is important for digital investigators to become familiar with data structures in memory.

WINDOWS MEMORY FORENSIC TOOLS

R Choose the tool(s) that are most suitable for the type of memory analysis you are going to perform. Whenever feasible, use multiple tools and compare their results for completeness and accuracy. u Different memory forensic tools have different features and may only ­support specific versions of Windows. Therefore, it is necessary to be familiar with the strengths and weaknesses of multiple memory forensic tools. The types

Chapter | 2 Memory Forensics

99

of information that most memory forensic tools provide are summarized in the following list. • Processes and threads • Modules and libraries • Open files and sockets • Various data structures u Some tools provide additional functionality such as extracting executables and process memory, detecting memory injection and hooking, recovering Registry values and MFT entries, and extracting URLs and e-mail addresses. Commercial forensic tools such as FTK and EnCase have adapted to include memory analysis capabilities. These and other malware forensic tools are dis­ cussed further in the Tool Box section at the end of this chapter.

Investigative Considerations • Memory forensic tools are in the early stages of development and may contain bugs and other limitations that can result in missed information. To increase the chance that you will notice any errors introduced by an analysis tool, whenever feasible, compare the output of a memory forensic tool with that of another tool as well as volatile data collected from the live system.

Processes and Threads

R Obtain as much information as possible relating to processes and associated threads, including hidden and terminated processes, and analyze the details to determine which processes relate to malware. u When a system is running malware, information (what, where, when, how) about the processes and threads is generally going to be significant in several ways. • What processes are hidden or injected in memory may be of interest, and where they are located in memory or on disk may be noteworthy. • When they were executed can provide useful clues, and how they are being executed may be relevant. • Deleted processes may also be important in an investigation. To begin with, a comparison of processes visible through the operating system with all EPROCESS structures that exist in memory can reveal deleted and hidden processes.

Command-line Memory Analysis Utilities • The Volatility psscan plug-in scans a memory dump for the signature of an EPROCESS data structure to provide a list of active, exited, and ­hidden pro­ cesses. The following output shows the psscan option being used to carve

100

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

EPROCESS structures out of a memory dump from the FUTo rootkit sce­ nario in Malware Forensics (Figure 2.4).3 @ E:Volatility>E:Python25python volatility psscan -f FUTo-memory-20070909.dd PID PPID Time created Time exited Offset PDB —— —— ———————— ———————— ———- ———0 0 0x00544640 0x00039000 0x0104ab50 0x03f49000 664 592 2007-09-09 18:12:25 0x0104c818 0x0aa13000 1852 688 2007-09-09 18:12:00 0x0106f788 0x02f2b000 592 4 2007-09-09 18:12:23 0x01168a18 0x0001b000 1204 412 2007-09-09 18:17:32 4 0 0x01218020 0x00039000 0 0 0x01e72640 0x00039000 688 2007-09-09 18:12:29 736 0x020cd7d8 0x05649000 688 2007-09-09 18:12:29 748 2007-09-09 18:17:50 0x02151668 0x05689000 372 2007-09-09 18:19:56 1808 0x026c7420 0x0e906000 592 2007-09-09 18:12:27 688 0x03cf0850 0x04e5f000 688 2007-09-09 18:12:29 756 0x05683da8 0x0566f000 736 2007-09-09 18:12:34 928 0x05cc9da8 0x06208000 736 2007-09-09 18:12:34 956 0x0626bd80 0x06299000 736 2007-09-09 18:12:34 1080 0x063d46a0 0x06467000 736 2007-09-09 18:12:36 1228 0x06b00020 0x06aec000 736 2007-09-09 18:12:36 1260 0x06cb0728 0x06ce5000 736 2007-09-09 18:12:38 1452 0x07509da8 0x075a6000 736 2007-09-09 18:12:44 1604 0x07daec18 0x07d94000 736 2007-09-09 18:12:45 0 0x07e26b50 0x07e8f000 388 2007-09-09 18:13:05 412 0x08df4da8 0x08ded000 412 2007-09-09 18:13:07 632 0x09783c48 0x09897000 412 2007-09-09 18:13:08 280 0x098b2960 0x098fb000 412 2007-09-09 18:13:08 656 0x099da6a8 0x09a4a000 412 2007-09-09 18:13:08 828 0x09afb288 0x09b82000 1080 2007-09-09 18:14:15 404 0x09afb508 0x0e27a000 412 2007-09-09 18:13:08 1024 0x09c3fda8 0x09ba9000 412 2007-09-09 18:13:09 1236 0x09cec2c0 0x09fed000 412 2007-09-09 18:13:09 1100 0x09e4da28 0x09e6d000 372 0x09f05020 0x09774000 1204 2007-09-09 18:19:56 412 2007-09-09 18:13:09 1284 0x09f6b6a8 0x0a093000 412 2007-09-09 18:13:10 0 0x0a10fbe8 0x0a039000 412 2007-09-09 18:13:16 976 0x0bc35898 0x0c03b000

Remarks —————Idle csrss.exe logonui.exe smss.exe helix.exe System Idle services.exe savedump.exe dd.exe winlogon.exe lsass.exe ibmpmsvc.exe svchost.exe svchost.exe svchost.exe svchost.exe spoolsv.exe QCONSVC.EXE skls.exe explorer.exe igfxtray.exe hkcmd.exe LTSMMSG.exe tp4serv.exe wuauclt.exe rundll32.exe Qctray.exe TPHKMGR.exe cmd.exe dirx9.exe skl.exe msmsgs.exe

FIGURE 2.4–Volatility psscan option carving EPROCESS structures out of a memory dump

• Comparing the output of the psscan output with a list of running processes •

•

(e.g., using Volatility pslist option) can reveal discrepancies caused by malware, or may reveal anomalies that relate to the behavior of malware. The psdiff Volatility plug-in automatically performs this comparison. In this example, two processes, “skls.exe” and “skl.exe,” that were not dis­ played in the pslist output are visible in the psscan output (shown in bold in Figure 2.4) with a process ID of zero that is generally reserved for the Windows system Idle process. The setting of the process identifier (PID) to zero is an artifact of the FUTo rootkit, making it difficult for digital forensic tools to reference the hidden pro­ cesses by PID. To address this challenge, tools such as Volatility have added the ability to run analysis on a process by the location (offset) of the EPROCESS structure in the memory dump as shown here for the hidden “skls.exe” process to list loaded DLLs associated with this hidden process (Figure 2.5). volatility dlllist -o 0x07e26b50 -f FUTo-memory-20070909.dd

FIGURE 2.5–Using the Volatility dlllist option 3

  Malin, C., Casey, E., and Aquilina, J. (2008). Malware Forensics: Investigating and Analyzing Malicious Code, Chap. 3, p. 147. Burlington, MA: Syngress.

101

Chapter | 2 Memory Forensics

• Another approach to finding hidden processes is to extract process details from the Windows “csrss” process as demonstrated by the Volatility plug-in (Figure 2.6).4

csrpslist

E:Volatility>E:Python25python volatility csrpslist -f FUTo-memory-20070909.dd RootList Hndls Pslist Pid Name 0 1 0 0 skl.exe 0 1 1 1024 rundll32.exe 0 1 1 1284 dirx9.exe 0 0 1 748 savedump.exe 0 1 0 1808 dd.exe 0 0 1 664 csrss.exe 0 1 1 404 wuauclt.exe 0 1 1 280 hkcmd.exe 0 0 1 4 System 0 1 1 412 explorer.exe 0 1 1 928 ibmpmsvc.exe 0 1 1 1452 spoolsv.exe 0 1 1 688 winlogon.exe 0 1 1 1204 helix.exe 0 1 1 1080 svchost.exe 0 1 1 756 lsass.exe 0 1 1 828 tp4serv.exe 0 1 1 1604 QCONSVC.EXE 0 1 1 1100 TPHKMGR.exe 0 1 1 1228 svchost.exe 0 1 1 976 msmsgs.exe 0 1 1 1236 Qctray.exe 0 0 1 592 smss.exe 0 1 1 736 services.exe 0 1 1 656 LTSMMSG.exe 0 1 1 956 svchost.exe 0 1 1 1260 svchost.exe 0 1 0 372 cmd.exe 0 1 1 632 igfxtray.exe

FIGURE 2.6–Results of parsing a memory dump with the csrpslist plug-in

• The output of this plug-in is provided below for the FUTo rootkit example,

•

with a zero in the second column when a process was not present in the pslist output (e.g., skl.exe). Unfortunately, this list does not show the “skls. exe” process found using psscan. Another free command-line tool is Memoryze from Mandiant. The ­command-line options for this tool are summarized in the Tool Box ­section at the end of this chapter. A sample command line is provided here that extracts processes and associated ports from a memory dump (Figure 2.7). @ D:Memoryze>process.bat –input -ports true -output E:tools

FIGURE 2.7–Processing a memory dump file with Memoryze

• The output from Memoryze is in XML format and can be viewed in raw form or using any XML viewer or using the AuditViewer program described [email protected] 4

  http://code.google.com/p/volatility/wiki/Plugins.   For more information about AuditViewer, go to http://www.mandiant.com/products/free_­ software/mandiant_audit_viewer/. 5

102

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

The threads associated with a given process identified can also be examined to provide additional information about a malware incident. • The thrdscan and thrdscan2 plug-ins in Volatility will carve and dis­ play all of the ETHREAD structures it can find in a memory dump. • Looking for threads that have a PID that was not displayed in the process list may uncover hidden processes. The orphanthreads Volatility plug-in attempts to find such hidden processes in memory dumps. @ Additional command-line utilities such as PTFinder to extract process and thread details from physical memory dumps are discussed in the Tool Box section at the end of this chapter. u

GUI-based Memory Analysis Tools • A number of tools have been developed to facilitate forensic analysis of Windows memory. These tools can be particularly useful for detecting arti­ facts of malware in memory such as memory injection. Although Memoryze is a command-line utility, it can be configured and run, and its output can be viewed using a GUI program named AuditViewer. Figure 2.8 shows one of the configuration screens in AuditViewer used to configure Memoryze. @ • Figure 2.9 shows processes and associated details viewed using AuditViewer, focusing on the “skl.exe” process mentioned previously that was hidden using the FUTo rootkit.

FIGURE 2.8–AuditViewer configuration options screenshot

• Tabs within AuditViewer provide easy access to the information that •

Memoryze extracts associated with each process and driver including files, Registry keys, and open ports. In addition, certain features in a memory dump that commonly relate to mal­ ware such as memory injection will be highlighted in red in the Memoryze results as detailed in the Dissecting Windows Process Memory section toward the end of this chapter.

Chapter | 2 Memory Forensics

103

FIGURE 2.9–AuditViewer showing output of Memoryze

Another GUI tool for examining memory is HBGary Responder,6 as shown in Figure 2.10, which lists processes and associated details. @

u

FIGURE 2.10–HBGary Responder used to list processes and associated metadata

• This tool provides various details relating to processes and drivers, and can be used to perform keyword searches within a memory dump. 6

  For more information about HBGary Responder, go to http://www.hbgary.com/responder-field.

104

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• For an additional cost, advanced features are available as add-ons to this

•

tool, such as integrated debugging/disassembly and automated detec­ tion of features commonly found in malware (called Digital DNA or DDNA).7 This tool can also be used to associate ports with a particular process as shown in Figure 2.11 with the same “skl.exe” processes selected, reveal­ ing that it has port 1900 open.

FIGURE 2.11–HBGary used to list ports associated with a particular process

Relational Reconstruction u When examining processes in Windows memory, it can also be fruitful to perform a relational reconstruction, depicting the parent and child relationships between processes as shown in the following section. • For instance, malware will sometimes exploit a system vulnerability and cause a system process to launch a command shell. • The Metasploit penetration testing framework8 has an option to launch a remote command shell after exploiting vulnerability in the Windows Local Security Authority Subsystem Service (LSASS). 7

  For more information about HBGary Responder Pro and Digital DNA, go to http://www.hbgary .com/responder-pro-2/; http://www.hbgary.com/digital-dna. 8   For more information about the Metasploit penetration testing framework, go to http://www .metasploit.com/.

Chapter | 2 Memory Forensics

105

FIGURE 2.12–Graphical depiction of relationship between processes in the Hacker Defender rootkit scenario

• Figure 2.12 shows how this looks in memory using the Hacker Defender

s­ cenario from the Malware Forensics text,9 with the “lsass.exe” process launching Metasploit, which in turn launched the program “UMGR32.exe” that turns out to be Back Orifice. u Another anomaly to look for in this type of relational reconstruction is a user process that is the parent of what resembles a system process. • Because malware attempts to blend in with the legitimate processes on a system, digital investigators might see the “cmd.exe” process spawning a process named “lsass.exe” to resemble the legitimate Windows LSASS process. • Conversely, suspicious activities can be found by looking for system ­processes spawning an unknown process or executable that is usually only started by a user.

9

  Malin, C., Casey, E., and Aquilina, J. (2008). Malware Forensics: Investigating and Analyzing Malicious Code, Chap. 3, pp. 130–131. Burlington, MA: Syngress.

106

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• For instance, the ZeuS Trojan program is commonly injected into the “svchost.exe” process and, therefore, any remotely executed commands appear to be spawned by the “svchost.exe” process.10

Investigative Considerations • Some legitimate processes such as AntiVirus and other security tools can have characteristics that are commonly associated with malware. Therefore, it is advisable to determine which processes are authorized to run on the subject system. However, intruders may assign their malware the same name as these legitimate processes to misdirect digital investigators. Therefore, do not dismiss seemingly legitimate processes simply because they have a familiar name. Take the time to examine the details of a seemingly legitimate process before excluding it from further analysis.

N Analysis Tip

Temporal and Relational Analysis Analysis techniques from other forensic disciplines can be applied to malware forensics to provide insights into evidence and associated actions. In memory analysis the most common form of temporal analysis is a time line and the most common form of relational analysis is a process tree diagram. A time line and process tree diagram should be created in all cases to determine whether any processes were started substantially later than standard system processes, or whether there are unusual relationships between processes as previously discussed. The full path of an executable and any files that a process has open may also provide clues that lead to malware. Digital investigators should look for other creative ways to analyze date-time stamps and relationships found in memory not just for processes but for all data structures.

Modules and Libraries

R Extract details associated with modules (aka drivers) and libraries in memory, and analyze them to determine which relate to malware. u Malware may create drivers or load libraries to perform core functions such as concealment and keylogging. Therefore, in addition to processes and threads, it is important to examine drivers and libraries that are loaded on a Windows system.

Memory Analysis Utilities • The Volatility modules and modscan2 plug-ins provide a list of modules run­ ning on a system, and the driverscan plug-in searches memory for specific driver objects. 10

  Cheval and Oxley (2011), Masters Thesis, Johns Hopkins University Information Security Institute.

Chapter | 2 Memory Forensics

107

• For example, Figure 2.13 shows a list of loaded modules extracted from memory using the Volatility modules option, with the module named “­ msdirectx.sys” associated with the FUTo rootkit highlighted in bold. (?!YRODWLOLWPRGXOHVI)87RPHPRUGG FXWIRUEUHYLW! ?»»?&?:,1’2:6?VVWHP?ZLQNVV[EI[EZLQNVV ?»»?&?:,1’2:6?VVWHP?ZDWFKGRJVV[IEDD[ZDWFKGRJVV ?6VWHP5RRW?6VWHP?GULYHUV?G[JVV[EII[G[JVV ?6VWHP5RRW?6VWHP?GULYHUV?G[JWKNVV[IFH[G[JWKNVV ?6VWHP5RRW?6VWHP?LDOPGQWGOO[EIE[LDOPGQWGOO ?6VWHP5RRW?6VWHP?LDOPGHY’//[EIFG[LDOPGHY’// ?6VWHP5RRW?6VWHP?LDOPGG’//[EIH[ELDOPGG’// ?6VWHP5RRW?6VWHP?GULYHUV?DIGVV[ID[DIGVV ?6VWHP5RRW?6VWHP?’5,9(56?LUGDVV[I[HLUGDVV ?6VWHP5RRW?6VWHP?’5,9(56?QGLVXLRVV[IE[QGLVXLRVV ?6VWHP5RRW?6VWHP?’5,9(56?PU[GDYVV[I[EPU[GDYVV ?6VWHP5RRW?6VWHP?’ULYHUV?3DU9GP6userdump.exe 1936 e:WinIRProcess DumpingResults1936.dmp User Mode Process Dumper (Version 8.1.2929.4) Copyright (c) Microsoft Corp. All rights reserved. Dumping process 1936 (tywv.exe) to e:WinIRProcessDumpingResults1936.dmp … The process was dumped successfully.

FIGURE 2.29–Dumping suspicious process “tywv” with userdump

17

  For more information about pmdump, go to http://www.ntsecurity.nu/toolbox/pmdump/.   For more information about RAPIER, go to http://code.google.com/p/rapier/. 19   For more information about Microsoft User Mode Process Dumper, go to http://www .microsoft.com/downloads/en/details.aspx?FamilyID=E089CA41-6A87-40C8-BF6928AC08570B7E&displaylang=en. 18

Chapter | 2 Memory Forensics

121

DISSECTING WINDOWS PROCESS MEMORY

R Delve into the specific arrangements of data in memory to find malicious code and to recover specific details pertaining to the configuration and operation of malware on the subject system. u When there is a specific process that you are interested in analyzing, there are various things you will want to look for, including: • Command-line arguments • IP addresses • Hostnames • Passphrases and encryption keys associated with malicious code u Some of this information can be found by extracting strings or perform­ ing keyword searches. Volatility can be used to extract strings from an entire memory dump or a specific process for further analysis.  HBGary Responder can be used to perform keyword searches for both ASCII and Unicode, presenting any search hits in the context of which process or module they were found. Figure 2.30 shows the results of a keyword search for “sploit” on a target memory dump file, revealing 8 keyword hits in several processes.

FIGURE 2.30–Keyword search results for sploit using HBGary Responder

Some tools look for specific keywords in memory automatically when initially processing a memory dump in an effort to recover potentially useful information such as passwords. For instance, Figure 2.31 shows the Keys and Passwords recovery feature of HBGary Responder displaying the password from the Hacker Defender rootkit. u

122

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

FIGURE 2.31–Keys and Passwords function of HBGary Responder showing password ­associated with rootkit extracted from memory dump

Some memory forensic tools can provide additional insights into memory that are specifically designed for malware forensics. • As more malware uses concealment techniques such as injection and hooking, memory forensic tools are being developed to detect new con­ cealment methods. • Attempts to detect specific malware concealment techniques have been codi­ fied in tools such as Memoryze, HBGary Responder, and Volatility plug-ins. u

Some Volatility plug-ins have been developed to look for concealment tech­ niques commonly used by malware. • These plug-ins include apihooks, driverirp, ssdt_ex, and malfind.20 • A portion of output from the malfind plug-in relating to the ZeuS Trojan is provided in Figure 2.32, listing and extracting portions of memory that may be related to malware. • The output of these Volatility plug-ins is not as focused or intuitive as memory forensic tools such as Memoryze or HBGary Responder. • Furthermore, these plug-ins and others that attempt to detect conceal­ ment techniques in memory often result in many false positives. Therefore, the output of these tools should be treated as a starting point for digital investigators rather than a final answer relating to malware. Other tools and techniques should be employed to validate the results of the ­plug-ins. u

Memoryze has several functions for detecting injected code and hooks in memory dumps, all of which can be enabled using the AuditViewer ­program. • Figure 2.33 shows a suspicious memory section highlighted by AuditViewer that is associated with the Trojan horse program Back Orifice. u

20

  http://code.google.com/p/volatility/wiki/Plugins.

Chapter | 2 Memory Forensics

123

svchost.exe 868 0x00AA0000 0x00AB6FFF VadS 0 24 (MM_EXECUTE_UNKNOWN) Dumped to: /malfind-zeus/svchost.exe.23ac458.00aa0000-00ab6fff.dmp 0x00aa0000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ………… 0x00aa0010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 [email protected] 0x00aa0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ………….. 0x00aa0030 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 ………….. 0x00aa0040 0e 1f ba 0e 00 b4 09 cd 12 b8 01 4c cd 21 54 68 …!..L.!Th is 0x00aa0050 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f program cannot 0x00aa0060 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 be run in DOS 0x00aa0070 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00 mode….$….. svchost.exe 868 0x03450000 0x0346FFFF VadS 0 24 (MM_EXECUTE_UNKNOWN) Dumped to: /malfind-zeus/svchost.exe.23ac458.03450000-0346ffff.dmp 0x03450000 01 00 00 00 00 00 00 00 50 44 f7 02 00 20 45 03 ……PD… E. 0x03450010 00 00 00 00 00 00 00 00 e0 1f 00 00 00 00 00 00 ………….. 0x03450020 d0 44 f7 02 00 00 00 00 00 00 00 00 00 00 00 00 .D………… 0x03450030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ………….. 0x03450040 00 00 00 00 00 00 00 00 00 00 01 83 00 00 00 00 ………….. 0x03450050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ………….. 0x03450060 00 00 00 00 40 00 45 03 00 14 01 12 00 00 00 00 [email protected] 0x03450070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ………….. Disassembly: 0x03450000 add [eax],eax 0x03450002 add [eax],al 0x03450004 add [eax],al 0x03450006 add [eax],al 0x03450008 push eax 0x03450009 inc esp 0x0345000a test dword [edx],0x3452000 0x03450010 add [eax],al 0x03450012 add [eax],al 0x03450014 add [eax],al 0x03450016 add [eax],al 0x03450018 loopne 0x3450021 0x0345001a add [eax],al 0x0345001c add [eax],al 0x0345001e add [eax],al

FIGURE 2.32–Parsing memory with the Volatility malfind plug-in

FIGURE 2.33–AuditViewer showing suspicious memory sections associated with the Back Orifice Trojan horse program highlighted

• Memoryze (using the AuditViewer front end) has strong memory injec­ •

tion detection capabilities as shown in Figure 2.34, identifying an injected memory section in the “Excel.exe” process, highlighted. Although Memoryze is a powerful tool for detecting potential conceal­ ment techniques in memory, the supporting documentation is careful to point out that not all concealment techniques will be detected using the automated tool. This again demonstrates the importance in malware

124

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

FIGURE 2.34–Identifying memory injection with AuditViewer

•

forensics of ­utilizing multiple analysis tools and performing a compre­ hensive reconstruction (temporal, relational, and functional, as discussed earlier in this chapter) to ensure that a more complete understanding of the malware is obtained. Figure 2.35 shows HBGary Responder examining a system infected with the ZeuS Trojan, which makes extensive use of process injection. Potentially malicious objects in memory are highlighted and given a severity score in an effort to help digital investigators focus on areas of greatest potential concern.

FIGURE 2.35–Processes with code injected by the ZeuS Trojan viewed using HBGary Responder

Chapter | 2 Memory Forensics

125

FIGURE 2.36–Portions of HBGary Responder report of suspicious module injected into svchost.exe process

• Figure 2.36 provides additional details about a specific module that • •

HBGary Responder has rated as suspicious because of its ability to inject code into other processes. Tools such as HBGary DDNA automatically extract some characteristics of executable code that can be useful for malware forensics. For instance, Figure 2.37 shows the traits extracted by DDNA for a mali­ cious process. However, this approach can result in a false positive and generally requires additional analysis by a skilled digital investigator.

FIGURE 2.37–Traits of a malicious process automatically extracted using Digital DNA (DDNA) module

126

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

N Analysis Tip

Finding the Hidden in Memory Digital investigators should not be overly reliant on automated methods for detecting hidden information and concealment techniques in memory. Free and commercial tools alike cannot detect every concealment method. As such, automated detection methods are simply one aspect of the overall process of examining volatile data in memory as described in Chapter 1, as well as the comprehensive examination and reconstruction methods discussed earlier in this chapter.

CONCLUSIONS

• As memory forensics evolves, an increasing amount of information can be •

• •

•

•

extracted from full memory dumps, providing critical evidence and context related to malware on a system. The information that can be extracted from memory dumps includes hidden and terminated processes, traces of memory injection, and hooking tech­ niques used by malware, metadata, and memory contents associated with specific processes, executables, and network connections. In addition, impressions and trace evidence such as those discussed in Chapter 6 may be present in memory dumps, waiting for digital investiga­ tors to find and interpret them. However, because memory forensics is in the early stage of development, it may not be able to recover the desired information from a memory dump in all cases. Therefore, it is important to take precautions to acquire the mem­ ory contents of individual processes of interest on the live system. Even when memory forensic tools can be employed in a particular case, acquiring individual process memory from the live system allows digital investigators to compare the two methods to ensure they produce consistent results. Furthermore, because malware can manipulate memory, it is important to correlate critical findings with other sources of data such as the file system, live response data, and external sources such as logs from firewalls, routers, and Web proxies.

Chapter | 2 Memory Forensics

127

� Pitfalls to Avoid Failing to validate your findings  Do not rely on just one tool. R Learn the strengths and limitations of your tools through testing and research.

R Keep in mind that tools may report false positives when attempting to detect suspicious code.

R Use more than one tool and compare the results to ensure that they are consistent.

R Verify important findings manually by examining items as they exist in memory, and review their surrounding context for additional ­information that may have been missed by the tools. Failing to understand underlying data structures  Do not trust results of memory forensic tools without verification. R Learn the data structures that are being extracted and interpreted by memory forensic tools in order to validate important findings.

R When a tool fails to extract certain items of interest, interpret the data yourself.

R Find additional information in memory that memory forensic tools are not currently programmed to recover.

128

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

MEMORY FORENSICS: FIELD NOTES Note: This document is not intended as a checklist, but rather as a guide to increase consistency of forensic examination of memory. When dealing with mul­ tiple memory dumps, it may be necessary to tabulate the results of each individual examination into a single document or spreadsheet. Case Number:

Date/Time:

Organization/Company: Incident Type:

System Information:

Operating System:

Trojan Horse Bot Logic Bomb Sniffer:

Address: Worm Scareware/Rogue AV Keylogger Other:

Virus Rootkit Ransomware: Unknown:

Make/Model:

Memory Capture Method: Live acquisition Hibernation mode Virtual Machine (vmem)

Network State: Connected to Internet Connected to Intranet Disconnected

Memory Dump Physical Memory: Acquired Date/Time: File Name: Size: MD5 Value: SHA1 Value: Tool Used:

Not Acquired [Reason]:

System Details: Date/Time: IP Address:_________._________.___________._________ Host Name/Network Name: Current System User: Network Interface Configuration: Promiscuous Other: Enabled Protocols: System Uptime: System Environment: Operating System: Service Pack/Patch Level: Processor:

129

Chapter | 2 Memory Forensics

Users Accounts/Passphases: User account _________________ on the system: User point of origin: Remote login Local login Duration of the login session: Shares, files, or other resources accessed by the user account: Processes associated with the user account: Network activity attributable to the user account: Passphrases associated with the user account: User_________________ on the system: User point of origin: Remote login Local login Duration of the login session: Shares, files, or other resources accessed by the user account: Processes associated with the user account: Network activity attributable to the user account: Passphrases associated with the user account:

Network Connections and Activity: System is connected to the network: Network connections: Protocol: TCP UDP Local Port: DELETED Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Foreign Connection Address: Foreign Connection Port: Process ID Associated with Connection:

Protocol: TCP UDP Local Port: DELETED Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Foreign Connection Address: Foreign Connection Port: Process ID Associated with Connection:

Protocol: TCP UDP Local Port: DELETED Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Foreign Connection Address: Foreign Connection Port: Process ID Associated with Connection:

Protocol: TCP UDP Local Port: DELETED Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Foreign Connection Address: Foreign Connection Port: Process ID Associated with Connection:

Protocol: TCP UDP Local Port: DELETED Status:

Protocol: TCP UDP Local Port: DELETED Status:

130

LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Foreign ConnectionMALWARE Address: FORENSICS Foreign Connection Port: Process ID Associated with Connection: Protocol: TCP UDP Local Port: DELETED Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Foreign Connection Address: Foreign Connection Port: Process ID Associated with Connection:

LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Foreign Connection FIELD GUIDE FORAddress: WINDOWS SYSTEMS Foreign Connection Port: Process ID Associated with Connection: Protocol: TCP UDP Local Port: DELETED Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Foreign Connection Address: Foreign Connection Port: Process ID Associated with Connection:

Notable DNS Queries made from subject system:

NetBIOS connections: NetBIOS Name: Host Address: Recently Transferred Files:

NetBIOS Name: Host Address: Recently Transferred Files:

NetBIOS Name: Host Address: Recently Transferred Files:

NetBIOS Name: Host Address: Recently Transferred Files:

NetBIOS Name: Host Address: Recently Transferred Files:

NetBIOS Name: Host Address: Recently Transferred Files:

ARP Cache

Chapter | 2 Memory Forensics

Running/Hidden/Terminated Processes: Suspicious Process Identified:

Process State: TERMINATED HIDDEN Process Name: Process Identification (PID): Process Creation Time: Duration process has been running: Process End Time: Memory used: Path to Associated executable file: ________________________________________________ Memory Offset: Associated User: Child Process(es): __________________________ __________________________ __________________________ Command-line parameters: ________________________________________________ ________________________________________________ File Handles: __________________________ __________________________ __________________________ __________________________ Loaded Modules: __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ Exported Modules: __________________________ __________________________ __________________________ Process Memory Acquired File Name: File Size: MD5 Hash Value: ____________________________

131

132

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Suspicious Process Identified:

Process State: TERMINATED HIDDEN Process Name: Process Identification (PID): Process Creation Time: Duration process has been running: Process End Time: Memory used: Path to Associated executable file: ________________________________________________ Memory Offset: Associated User: Child Process(es): __________________________ __________________________ __________________________ Command-line parameters: ________________________________________________ ________________________________________________ File Handles: __________________________ __________________________ __________________________ __________________________ Loaded Modules: __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ Exported Modules: __________________________ __________________________ __________________________ Process Memory Acquired File Name: File Size: MD5 Hash Value: ____________________________

Chapter | 2 Memory Forensics

Suspicious Process Identified:

Process State: TERMINATED HIDDEN Process Name: Process Identification (PID): Process Creation Time: Duration process has been running: Process End Time: Memory used: Path to Associated executable file: ________________________________________________ Memory Offset: Associated User: Child Process(es): __________________________ __________________________ __________________________ Command-line parameters: ________________________________________________ ________________________________________________ File Handles: __________________________ __________________________ __________________________ __________________________ Loaded Modules: __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ Exported Modules: __________________________ __________________________ __________________________ Process Memory Acquired File Name: File Size: MD5 Hash Value: ____________________________

133

134

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Suspicious Process Identified:

Process State: TERMINATED HIDDEN Process Name: Process Identification (PID): Process Creation Time: Duration process has been running: Process End Time: Memory used: Path to Associated executable file: ________________________________________________ Memory Offset: Associated User: Child Process(es): __________________________ __________________________ __________________________ Command-line parameters: ________________________________________________ ________________________________________________ File Handles: __________________________ __________________________ __________________________ __________________________ Loaded Modules: __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ Exported Modules: __________________________ __________________________ __________________________ Process Memory Acquired File Name: File Size: MD5 Hash Value: ____________________________

Chapter | 2 Memory Forensics

Suspicious Process Identified:

Process State: TERMINATED HIDDEN Process Name: Process Identification (PID): Process Creation Time: Duration process has been running: Process End Time: Memory used: Path to Associated executable file: ________________________________________________ Memory Offset: Associated User: Child Process(es): __________________________ __________________________ __________________________ Command-line parameters: ________________________________________________ ________________________________________________ File Handles: __________________________ __________________________ __________________________ __________________________ Loaded Modules: __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ Exported Modules: __________________________ __________________________ __________________________ Process Memory Acquired File Name: File Size: MD5 Hash Value: ____________________________

135

136

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Suspicious Process Identified:

Process State: TERMINATED HIDDEN Process Name: Process Identification (PID): Process Creation Time: Duration process has been running: Process End Time: Memory used: Path to Associated executable file: ________________________________________________ Memory Offset: Associated User: Child Process(es): __________________________ __________________________ __________________________ Command-line parameters: ________________________________________________ ________________________________________________ File Handles: __________________________ __________________________ __________________________ __________________________ Loaded Modules: __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ __________________________ Exported Modules: __________________________ __________________________ __________________________ Process Memory Acquired File Name: File Size: MD5 Hash Value: ____________________________

Notable DNS Queries made from subject system:

Process-Child Relationship Diagram Generated

Chapter | 2 Memory Forensics

Port and Process Correlation Suspicious Port Identified: Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _____________________________ Protocol: TCP UDP Connection Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Process name and ID (PID) associated with open port: Executable program associated with the process and port: Path to Associated Executable File: ________________________________________________ Associated User:

Suspicious Port Identified: Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _____________________________ Protocol: TCP UDP Connection Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Process name and ID (PID) associated with open port: Executable program associated with the process and port: Path to Associated Executable File: ________________________________________________ Associated User:

137

138

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Suspicious Port Identified: Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _____________________________ Protocol: TCP UDP Connection Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Process name and ID (PID) associated with open port: Executable program associated with the process and port: Path to Associated Executable File: ________________________________________________ Associated User:

Suspicious Port Identified: Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _____________________________ Protocol: TCP UDP Connection Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Process name and ID (PID) associated with open port: Executable program associated with the process and port: Path to Associated Executable File: ________________________________________________ Associated User:

Chapter | 2 Memory Forensics

Suspicious Port Identified: Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _____________________________ Protocol: TCP UDP Connection Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Process name and ID (PID) associated with open port: Executable program associated with the process and port: Path to Associated Executable File: ________________________________________________ Associated User:

Suspicious Port Identified: Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _____________________________ Protocol: TCP UDP Connection Status: ESTABLISHED LISTEN SYN_SEND SYN_RECEIVED TIME_WAIT Other: Process name and ID (PID) associated with open port: Executable program associated with the process and port: Path to Associated Executable File: ________________________________________________ Associated User:

139

140

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Services: Suspicious Service Identified: Service Name: Display Name: Status: Running Stopped Startup Configuration: Description: Dependencies: Executable Program Associated with Service: Process ID (PID): Description: Executable Program Path: Username associated with Service:

Suspicious Service Identified: Service Name: Display Name: Status: Running Stopped Startup Configuration: Description: Dependencies: Executable Program Associated with Service: Process ID (PID): Description: Executable Program Path: Username associated with Service:

Suspicious Service Identified: Service Name: Display Name: Status: Running Stopped Startup Configuration: Description: Dependencies: Executable Program Associated with Service: Process ID (PID): Description: Executable Program Path: Username associated with Service:

Suspicious Service Identified: Service Name: Display Name: Status: Running Stopped Startup Configuration: Description: Dependencies: Executable Program Associated with Service: Process ID (PID): Description: Executable Program Path: Username associated with Service:

Suspicious Service Identified: Service Name: Display Name: Status: Running Stopped Startup Configuration: Description: Dependencies: Executable Program Associated with Service: Process ID (PID): Description: Executable Program Path: Username associated with Service:

Suspicious Service Identified: Service Name: Display Name: Status: Running Stopped Startup Configuration: Description: Dependencies: Executable Program Associated with Service: Process ID (PID): Description: Executable Program Path: Username associated with Service:

141

Chapter | 2 Memory Forensics

Drivers: List of Installed Drivers acquired Suspicious Driver: Name: Location: Link Date:

Suspicious Driver: Name: Location: Link Date:

Suspicious Driver: Name: Location: Link Date:

Suspicious Driver: Name: Location: Link Date:

Suspicious Driver: Name: Location: Link Date:

Suspicious Driver: Name: Location: Link Date:

Open Files: Open File Identified: Opened Remotely/

Opened Locally

File Name: Process that opened file: Handle Value: File location on system:

Open File Identified: Opened Remotely/

Opened Locally

File Name: Process that opened file: Handle Value: File location on system:

Open File Identified: Opened Remotely/

Opened Locally

File Name: Process that opened file: Handle Value: File location on system:

Open File Identified: Opened Remotely/

Opened Locally

File Name: Process that opened file: Handle Value: File location on system:

142

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Open File Identified: Opened Remotely/

Opened Locally

File Name: Process that opened file: Handle Value: File location on system:

Open File Identified: Opened Remotely/

Opened Locally

File Name: Process that opened file: Handle Value: File location on system:

Command History:

Commands of Interest:

Command history extracted Commands of interest identified Yes No

Network Shares: Network Shares Inspected Suspicious Share Identified Share Name: Location: Description: Suspicious Share Identified Share Name: Location: Description: Suspicious Share Identified Share Name: Location: Description:

Suspicious Share Identified Share Name: Location: Description:

Suspicious Share Identified Share Name: Location: Description:

143

Chapter | 2 Memory Forensics

Scheduled Tasks: Scheduled Tasks Examined Tasks Scheduled on the System Yes No

Suspicious Task(s) Identified: Yes No

Memory Concealment: Injection Suspicious Code/DLL Injection Identified Name: Location: Description: Suspicious Code/DLL Injection Identified Name: Location: Description:

Hooking Suspicious Hooking Identified Name: Location: Description: Suspicious Hooking Identified Name: Location: Description: Suspicious Hooking Identified Name: Location: Description:

File System Clues Artifacts to Look for on Storage Media: Notes:

Suspicious Task(s) Task Name: Scheduled Run Time: Status: Description:

Task Name: Scheduled Run Time: Status: Description:

144

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

MFT Entries: File/Folder Identified: Opened Remotely/

Opened Locally

File Name: Creation Date stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Opened Remotely/

Opened Locally

File Name: Creation Date stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Opened Remotely/

Opened Locally

File Name: Creation Date stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Opened Remotely/

Opened Locally

File Name: Creation Date stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Opened Remotely/

Opened Locally

File Name: Creation Date stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Opened Remotely/

Opened Locally

File Name: Creation Date stamp: File location on system (path): File location on system (clusters):

Chapter | 2 Memory Forensics

Prefetch Files: Suspicious Prefetch Identified: Prefetch File Name: Associated Application: Embedded Date: Created: Written: Runs:

Suspicious Prefetch Identified: Prefetch File Name: Associated Application: Embedded Date: Created: Written: Runs:

Suspicious Prefetch Identified: Prefetch File Name: Associated Application: Embedded Date: Created: Written: Runs:

Suspicious Prefetch Identified: Prefetch File Name: Associated Application: Embedded Date: Created: Written: Runs:

Registry Extraction Suspicious Registry Key Identified: Key Name: Location: Last Written Time: Associated Process/PID: Associated Network Activity: Associated Artifacts:

Suspicious Registry Key Identified: Key Name: Location: Last Written Time: Associated Process/PID: Associated Network Activity: Associated Artifacts:

145

146

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Suspicious Registry Key Identified: Key Name: Location: Last Written Time: Associated Process/PID: Associated Network Activity: Associated Artifacts:

Suspicious Registry Key Identified: Key Name: Location: Last Written Time: Associated Process/PID: Associated Network Activity: Associated Artifacts:

Suspicious Registry Key Identified: Key Name: Location: Last Written Time: Associated Process/PID: Associated Network Activity: Associated Artifacts:

Suspicious Registry Key Identified: Key Name: Location: Last Written Time: Associated Process/PID: Associated Network Activity: Associated Artifacts:

Network Clues IP Packet Found: Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___ Port Number: ____ Remote Host Name:_____________________________ Protocol: TCP UDP

IP Packet Found: Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name:_____________________________ Protocol: TCP UDP

Chapter | 2 Memory Forensics

IP Packet Found: Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name:_____________________________ Protocol: TCP UDP

IP Packet Found: Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name:_____________________________ Protocol: TCP UDP

IP Packet Found: Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name:_____________________________ Protocol: TCP UDP

IP Packet Found: Local IP Address: ___.___.___.___ Port Number: ____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name:_____________________________ Protocol: TCP UDP

WebSite/URLs/E-mailAddresses: Suspicious Web Site/URL/E-mail Identified: Name: Description

Suspicious Web Site/URL/E-mail Identified: Name: Description

Suspicious Web Site/URL/E-mail Identified: Name: Description

Suspicious Web Site/URL/E-mail Identified: Name: Description

147

148

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

 Malware Forensic Tool Box

Memory Analysis Tools for Windows Systems In this chapter we discussed approaches to interpreting data structures in memory. There are a number of memory analysis tools that you should be aware of and familiar with. In this section, we explore these tool alternatives, often demonstrating their functionality. This section can also simply be used as a “tool quick ­reference” or “cheat sheet,” as there will inevitably be times during an investigation where having an additional tool that is useful for a particular function would be beneficial, since you may have little time to conduct research for or regarding the tool(s). It is important to perform your own testing and validation of these tools  to ensure that they work as expected in your environment and for your specific needs.

Name: EnCase EnScripts

Author/-Distributor: Guidance Software Available From: http://www.guidancesoftware.com/ Description: Memory analysis capabilities have been developed for EnCase using EnScripts. These are currently maintained at http://cci.cocolog-nifty.com/blog/ and have some basic functions similar to Volatility. The output of the PsScan component of the Memory Forensic EnScript is shown in the following figure:

Chapter | 2 Memory Forensics

Name: FTK Author/Distributor: AccessData Available From: https://www.accessdata.com Description: FTK has basic memory parsing capabilities, which can be utilized by importing a memory dump and reviewing the parsed information under the Volatile tab. Name: Memoryze/AuditViewer Author/Distributor: Mandiant Available From: http://www.mandiant.com/products/free_software/memoryze/ Description: Memoryze and the associated AuditViewer are used to analyze physical memory acquired from many versions of Windows. Several batch scripts are provided with Memoryze to facilitate common analysis tasks. • Process.bat extracts details about processes, including malicious code injection. • DriverSearch.bat extracts details about drivers. • HookDetection.bat looks for common hooking methods. • DriverWalkList .bat provides a linked list of modules and drivers. These batch scripts rely on XML configuration files and require the command-line options to be explicity set to true or false to produce desired results in XML format. An example of the command line for Process.bat is provided here. C:>Process.bat -input E:FUTo-Rootkit.dmp -output E:Analysis -handles true -ports true -sections true -injected true

Customized scripts can be created to perform specific combinations of analysis. Audit Viewer provides a graphical user interface for examining the XML output created by Memoryze as shown in the following figure.

Helpful Switches: Switch

Function

-input

Memory dump to analyze

-output

Directory in which the results will be written

-ports true

List ports associated with processes

-injected true

Look for memory injection

149

150

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Name: PTFinder Author/Distributor: Andreas Schuster Available From: http://computer.forensikblog.de/files/ptfinder/ Description: PTFinder Perl scripts was developed by Andreas Schuster to methodically search a memory dump for the signature of EPROCESS and ETHREAD data structures. No conversion between virtual and physical addresses (http://computer.forensikblog.de/en/2006/03/ptfinder_0_2_00.html). E:PTFinder>ptfinder_xpsp2.pl —nothreads FUTo-memory-20070909.dd No. Type PID TID Time created Offset PDB Remarks —- —- —— —— ——————- ——————- ———1 Proc 0 0x00544640 0x00039000 Idle 2 Proc 664 2007-09-09 18:12:25 0x0104ab50 0x03f49000 csrss.exe 3 Proc 1852 2007-09-09 18:12:00 0x0104c818 0x0aa13000 logonui.exe 4 Proc 592 2007-09-09 18:12:23 0x0106f788 0x02f2b000 smss.exe 5 Proc 1204 2007-09-09 18:17:32 0x01168a18 0x0001b000 helix.exe 6 Proc 4 0x01218020 0x00039000 System 7 Proc 736 2007-09-09 18:12:29 0x020cd7d8 0x05649000 services.exe 8 Proc 748 2007-09-09 18:12:29 0x02151668 0x05689000 savedump.exe 9 Proc 1808 2007-09-09 18:19:56 0x026c7420 0x0e906000 dd.exe 10 Proc 688 2007-09-09 18:12:27 0x03cf0850 0x04e5f000 winlogon.exe 11 Proc 756 2007-09-09 18:12:29 0x05683da8 0x0566f000 lsass.exe 12 Proc 928 2007-09-09 18:12:34 0x05cc9da8 0x06208000 ibmpmsvc.exe 13 Proc 956 2007-09-09 18:12:34 0x0626bd80 0x06299000 svchost.exe 14 Proc 1080 2007-09-09 18:12:34 0x063d46a0 0x06467000 svchost.exe 15 Proc 1228 2007-09-09 18:12:36 0x06b00020 0x06aec000 svchost.exe 16 Proc 1260 2007-09-09 18:12:36 0x06cb0728 0x06ce5000 svchost.exe 17 Proc 1452 2007-09-09 18:12:38 0x07509da8 0x075a6000 spoolsv.exe 18 Proc 1604 2007-09-09 18:12:44 0x07daec18 0x07d94000 QCONSVC.EXE 19 Proc 0 2007-09-09 18:12:45 0x07e26b50 0x07e8f000 skls.exe 20 Proc 412 2007-09-09 18:13:05 0x08df4da8 0x08ded000 explorer.exe 21 Proc 632 2007-09-09 18:13:07 0x09783c48 0x09897000 igfxtray.exe 22 Proc 280 2007-09-09 18:13:08 0x098b2960 0x098fb000 hkcmd.exe 23 Proc 656 2007-09-09 18:13:08 0x099da6a8 0x09a4a000 LTSMMSG.exe 24 Proc 828 2007-09-09 18:13:08 0x09afb288 0x09b82000 tp4serv.exe 25 Proc 404 2007-09-09 18:14:15 0x09afb508 0x0e27a000 wuauclt.exe 26 Proc 1024 2007-09-09 18:13:08 0x09c3fda8 0x09ba9000 rundll32.exe 27 Proc 1236 2007-09-09 18:13:09 0x09cec2c0 0x09fed000 Qctray.exe 28 Proc 1100 2007-09-09 18:13:09 0x09e4da28 0x09e6d000 TPHKMGR.exe 29 Proc 372 2007-09-09 18:19:56 0x09f05020 0x09774000 cmd.exe 30 Proc 1284 2007-09-09 18:13:09 0x09f6b6a8 0x0a093000 dirx9.exe 31 Proc 0 2007-09-09 18:13:10 0x0a10fbe8 0x0a039000 skl.exe 32 Proc 976 2007-09-09 18:13:16 0x0bc35898 0x0c03b000 msmsgs.exe

Chapter | 2 Memory Forensics

Name: Responder Author/Distributor: HBGary Available From: http://www.hbgary.com/ Description: Responder facilitates forensic analysis of physical memory acquired from many versions of Windows by automatically extracting various details. In addition to providing a list of processes and open handles, Responder extracts URLs, usernames, passwords, keys, and other information from memory dumps. The graphical user interface enables a digital investigator to navigate memory dumps in various ways, and has a keyword search feature.

The professional version of Responder has some more advanced features for malware analysis, effectively supporting integrated dissassembly of executables in memory dumps. The Digital DNA (DDNA) feature attempts to identify malicious code automatically based on various characteristics and provides associated weight values.

Helpful Input Options: There are two options available when loading a memory dump into HBGary Responder that can provide additional insight from a forensic perspective: — Word list: words relevant to an investigation to search for while parsing the memory dump — Binary log:

151

152

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Name: Volatility Page Reference: Author/Distributor: Volatile Systems Available From: https://www.volatilesystems.com/default/volatility Description: Volatility grew out of the FATK it project and is written in Python, with development being led by Aaron Walters. Volatility can be used to extract information about processes, network connections, open handles, and other system-related details. Volatility also supports plug-ins for customized operations such as detecting malware, extracting Registry information, and recovering encryption keys. C:>python volatility –f E:FUTo-Rootkit–psscan Name Pid PPid Thds Hnds Time System 4 0 53 265 Thu Jan 01 00:00:00 1970 smss.exe 592 4 3 21 Sun Sep 09 18:12:23 2007 csrss.exe 664 592 11 385 Sun Sep 09 18:12:25 2007 winlogon.exe 688 592 20 502 Sun Sep 09 18:12:27 2007 services.exe 736 688 19 385 Sun Sep 09 18:12:29 2007 savedump.exe 748 688 0 -1 Sun Sep 09 18:12:29 2007 lsass.exe 756 688 19 310 Sun Sep 09 18:12:29 2007 ibmpmsvc.exe 928 736 3 29 Sun Sep 09 18:12:34 2007 svchost.exe 956 736 8 226 Sun Sep 09 18:12:34 2007 svchost.exe 1080 736 72 1025 Sun Sep 09 18:12:34 2007

A list and description of Volatility plug-ins is available at http://code.google.com/p/volatility/wiki/Plugins. Helpful Plug-ins: Options: Print information about all registered objects —info Sets the timezone for displaying timestamps —tz=TZ -f FILENAME, —filename=FILENAME Filename to use when opening an image —output-file=OUTPUT_FILE Write output in this file -v, —verbose Verbose information Supported Plug-in Commands: apihooks [MALWARE] Find API hooks bioskbd Reads the keyboard buffer from Real Mode memory connections Print list of open connections connscan2 Scan Physical memory for _TCPT_OBJECT objects (TCP connections) crashdump Dumps the crashdump file to a raw file crashinfo Dump crash-dump information csrpslist [MALWARE] Find hidden processes with csrss handles and CsrRootProcess datetime Get date/time information for image dlldump Dump a DLL from a process address space dlllist Print list of loaded DLLs for each process driverirp [MALWARE] Driver IRP hook detection driverscan Scan for driver objects (_DRIVER_OBJECT) files Print list of open files for each process filescan Scan Physical memory for _FILE_OBJECT pool allocations getsids Print the SIDs owning each process hashdump Dumps passwords hashes (LM/NTLM) from memory hibdump Dumps the hibernation file to a raw file hibinfo Dump hibernation file information hivedump Prints out a hive hivelist Print list of registry hives hivescan Scan Physical memory for _CMHIVE objects (registry hives) idt [MALWARE] Display Interrupt Descriptor Table imageinfo Identify information for the image impscan [MALWARE] Scan a module for imports (API calls) inspectcache Inspect the contents of a cache kpcrscan Search for and dump potential KPCR values ldrmodules [MALWARE] Detect unlinked DLLs lsadump Dump (decrypted) LSA secrets from the registry malfind [MALWARE] Find hidden and injected code memdump Dump the addressable memory for a process memmap Print the memory map moddump Dump a kernel driver to an executable file sample modscan2 Scan Physical memory for _LDR_DATA_TABLE_ENTRY objects modules Print list of loaded modules mutantscan Scan for mutant objects (_KMUTANT) mutantscandb [MALWARE] Mutantscan extension for highlighting suspicious mutexes notifyroutines [MALWARE] Print system-wide notification routines orphanthreads [MALWARE] Locate hidden threads patcher Patches memory based on page scans printkey Print a registry key, and its subkeys and values procexedump Dump a process to an executable file sample procmemdump Dump a process to an executable memory sample psdiff Produce a process diff pslist Print all running processes by following the EPROCESS lists psscan Scan Physical memory for _EPROCESS objects pstree Print process list as a tree

lsadump malfind memdump memmap moddump modscan2

Dump (decrypted) LSA secrets from the registry [MALWARE] Find hidden and injected code Dump the addressable memory for a process Print the memory map Dump a kernel driver to an executable file sample Scan Physical memory for _LDR_DATA_TABLE_ENTRY

objects Chapter | 2modules Memory Forensics Print mutantscan mutantscandb suspicious mutexes notifyroutines routines orphanthreads patcher printkey procexedump procmemdump psdiff pslist lists psscan pstree regobjkeys sockets sockscan sockets) ssdt ssdt_by_threads ssdt_ex thread) strings a while, VERY verbose) svcscan testsuite thrdscan thrdscan2 vaddump vadinfo vadtree vadwalk verinfo

list of loaded modules Scan for mutant objects (_KMUTANT) [MALWARE] Mutantscan extension for highlighting [MALWARE] Print system-wide notification [MALWARE] Locate hidden threads Patches memory based on page scans Print a registry key, and its subkeys and values Dump a process to an executable file sample Dump a process to an executable memory sample Produce a process diff Print all running processes by following the EPROCESS Scan Physical Print process Print list of Print list of Scan Physical

memory for _EPROCESS objects list as a tree open regkeys for each process open sockets memory for _ADDRESS_OBJECT objects (TCP

Display SSDT entries [MALWARE] SSDT hooks by thread [MALWARE] SSDT Hook Explorer for IDA Pro (and SSDT by Match physical offsets to virtual addresses (may take [MALWARE] Scan for Windows services Run unit test suit using the Cache Scan Physical memory for _ETHREAD objects Scan physical memory for _ETHREAD objects Dumps out the vad sections to a file Dump the VAD info Walk the VAD tree and display in tree format Walk the VAD tree Prints out the version information from PE images

153

154

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

SELECTED READINGS Books Eagle, C. (2008). The IDA Pro Book: The Unofficial Guide to the World’s Most Popular Disassembler. San Francisco, CA: No Starch Press. Ligh, M., Adair, S., Hartstein, B., and Richard, M. (2010). Malware Analysis Cookbook: Tools and Techniques for Fighting Malicious Code. New York: Wiley. Malin, C., Casey, E., and Aquilina, J. (2008). Malware Forensics: Investigating and Analyzing ­Malicious Code. Burlington, MA: Syngress. Skoudis, E., and Zeltser, L. (2003) Malware: Fighting Malicious Code. Upper Saddle River, NJ: Prentice Hall. Szor, P. (2005), The Art of Computer Virus Research and Defense. Mountain View, CA: Symantec Press.

Papers Dolan-Gavitt, B. (2007). The VAD Tree: A Process-Eye View of Physical Memory. Proceedings of the Seventh Annual DFRWS Conference, Digital Investigation, Vol. 4, Suppl. 1, pp. 62–64. Dolan-Gavitt, B. (2008). Forensic Analysis of the Windows Registry in Memory. Proceedings of the Eighth Annual DFRWS Conference, Digital Investigation, Vol. 5, Suppl. 1, pp. S26–S32. Hejazia, S.M., Talhia, C., and Debbabi, M. (2009). Extraction of Forensically Sensitive Information from Windows Physical Memory. Proceedings of the Ninth Annual DFRWS Conference, Digital Investigation, Vol. 6, Suppl. 1, pp. S121–S131. Kang, M., Poosankam, P., and Yin, H. (2007). Renovo: A Hidden Code Extractor for Packed ­Executables. WORM ’07, Proceedings of the 2007 ACM Workshop on Recurring Malcode. New York: ACM. Murphey. R. (2007). Automated Windows event log forensics in DFRWS2007 proceedings (Avail­ able online at http://www.dfrws.org/2007/proceedings/p92-murphey.pdf) Petroni Jr., N.L., Walters, A., Fraser, T., and Arbaugh, W.A. (2006). FATKit: A Framework for the Extraction and Analysis of Digital Forensic Data from Volatile System Memory. Digital Investigation, Vol. 3, Issue 4, pp. 197–210. Royal, P. (2006). PolyUnpack: Automating the Hidden-Code Extraction of Unpack-Executing Malware. Annual Computer Security Applications Conference, Miami Beach, FL, December 11–15. Saur, K., and Grizzard, J.B. (2010). Locating ×86 Paging Structures in Memory Images. Digital Investigation, Vol. 7, Issues 1–2, pp. 28–37. Stevens, R.M., and Casey, E. (2010). Extracting Windows Command Line Details from Physical Memory. Proceedings of the Tenth Annual DFRWS Conference, Digital Investigation, Vol. 7, Suppl. 1, pp. S57–S63. Yegneswaran, V. et. al. (2008). Eureka: A Framework for Enabling Static Analysis on Malware. Technical Report Number SRI-CSL-08-01, SRI Project 17382.

JURISPRUDENCE/RFCS/TECHNICAL SPECIFICATIONS Columbia Pictures Indus. v. Bunnell, 2007 U.S. Dist. LEXIS 46364 (C.D. Cal. June 19, 2007). RFC 3227—Guidelines for Evidence Collection and Archiving.

Chapter 3

Post-Mortem Forensics Discovering and Extracting Malware and Associated Artifacts from Windows Systems Solutions in this chapter: • Windows Forensic Analysis Overview • Forensic Examination of Compromised Windows Systems • Malware Discovery and Extraction from Windows Systems • Examine Windows File System • Examine Windows Registry • Keyword Searching • Forensic Reconstruction of Compromised Windows Systems • Advanced Malware Discovery and Extraction from a Windows System

INTRODUCTION If live system analysis can be considered surgery, forensic examination of Windows systems can be considered an autopsy of a computer impacted by malware. Trace evidence relating to a particular piece of malware may be found in various places on the hard drive of a compromised system, including files, Registry entries, records in event logs, and associated date stamps. Such trace evidence is an important part of analyzing malicious code by providing context and additional information that help us understand the functionality and origin of malware. This chapter provides a repeatable approach to conducting forensic examinations in malware incidents by increasing the consistency across multiple computers and enabling others to evaluate the process and results. Employing this approach, with a measure of critical thinking on the part of a digital investigator, can uncover information necessary to discover how malware was placed on the system (aka the intrusion vector), to determine malware functionality and its primary purpose (e.g., password theft, data theft, remote control) and to detect other infected systems. This forensic examination process can be applied to both a compromised host and a test system purposely infected with malware in order to learn more about the behavior of the malicious code. Malware Forensics Field Guide for Windows Systems. DOI: 10.1016/B978-1-59749-472-4.00003-2 © 2012 Elsevier, Inc. All rights reserved.

155

156

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Investigative Considerations • In the past, it was relatively straightforward to uncover traces of malware on the file system and in the Registry of a compromised Windows computer. Recently, attackers have been employing more anti-forensic techniques to conceal their activities. Modern malware is being designed to leave limited traces on the compromised host and to misdirect forensic examiners. A methodical approach to forensic examination, looking carefully at the system from all perspectives, increases the chances of uncovering footprints that the intruder failed to hide.

WINDOWS FORENSIC ANALYSIS OVERVIEW

R After a forensic duplicate of a compromised system has been acquired, employ a consistent forensic examination approach to extract the maximum amount of information relating to the malware incident. u The hard drive of a Windows computer can contain traces of malware in various places and forms, including malicious files, Registry entries, log files, Web browser history and remnants of installation, and execution and manipulation such as Prefetch files and date-time tampering. Some of this information has associated date-time stamps that can be useful for determining when the initial compromise occurred and what happened subsequently. The following general approach is designed to extract the maximum amount of information related to a malware incident: • Search for known malware • Survey installed programs • Examine prefetch • Inspect executables • Review auto-start • Review scheduled jobs • Examine logs (system logs, AntiVirus logs, Web browser history, etc.) • Review user accounts • Examine file system • Examine registry • Restore points • Perform keyword searches for any specific, known details relating to a malware incident. Useful keywords may come from other forms of analysis, including memory forensics and analysis of the malware. • Harvest available metadata including file system date-time stamps, modification times of Registry entries, e-mails, Prefetch file details and entries in Web browser history, and Windows Event logs and other logs such those created by AntiVirus programs. Use this information to ­determine when the malware incident occurred and what else was done to the ­system around that time, ultimately generating a time line of ­potentially malicious events.

Chapter | 3 Post-Mortem Forensics

157

• Look for common indicators of anti-forensics including file system ­date-time stamp manipulation and log deletion.

• Look for links to other systems that may be involved. These goals are provided as a guideline and not as a checklist for ­performing Windows forensic analysis. No single approach can address all situations, and some of these goals may not apply in certain cases. In addition, the specific implementation will depend on the tools that are used and the type of malware involved. Some malware may leave traces in novel or unexpected places on a Windows computer, including in the Master Boot Record (MBR) or within other files. Ultimately, the success of the investigation depends on the abilities of the digital investigator to apply digital forensic techniques and adapt them to new challenges. u

 Analysis Tip

Correlating Key Findings

As noted in prior chapters, knowing the time period of the incident and knowing what evidence of malware was observed can help digital investigators develop a strategy for scouring compromised computers for relevant digital evidence. Therefore, prior to performing forensic analysis of a compromised computer, it is advisable to review all information from the Field Interview Questions in Chapter 1 to avoid wasted effort and missed opportunities. Findings from other data sources such as memory dumps and network logs can also help focus the forensic analysis (i.e., the compromised computer was sending packets to a Russian IP address, providing an IP address to search for in a given time frame). Similarly, the results of static and dynamic analysis covered in later chapters can help guide forensic analysis of a compromised computer. So, the analysis of one malware specimen may lead to further forensic examination of the compromised host that uncovers additional malware that requires further analysis; this cyclical analysis ultimately leads to a comprehensive reconstruction of the incident. In addition, as new traces of malicious activity are uncovered through forensic examination of a compromised system, it is important to document them in a manner that facilitates forensic analysis. One effective approach is to insert new findings into a time line of events that gradually expands as the forensic analysis proceeds. This is particularly useful when dealing with multiple compromised computers. By generating a single time line for all systems, forensic analysts are more likely to observe ­relationships and gaps that need to be filled with further analysis.

Investigative Considerations • It is generally unrealistic to perform a blind review on certain structures that are too large or too complex to analyze without some investigative leads. Therefore, it is important to use all of the information available from other sources to direct a forensic analysis of the compromised system, including interview notes, spearfishing e-mails, volatile data, memory dumps, and logs from the system and network.

158

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• Most file system forensic tools do not provide full metadata from an NTFS. When dealing with malware that likely manipulated date-time stamps, it may be necessary to extract additional attributes such as the FILETIME details for comparison with the standard attributes. Tools for extracting attributes from MFT entries such as TSK and analyzeMFT are presented in the Tool Box appendix.  • It is important to look in all areas of a Windows system where traces of malware might be found, even if a quick look in a few common places reveals obvious signs of infection. There may be multiple types of malware on a computer, with more obvious signs of infection presenting a kind of smoke screen that may distract from more subtle signs of infection. Being thorough reduces the risk that more subtle items will be overlooked. • No one approach or tool can serve all needs in a forensic examination. To avoid mistakes and missed opportunities, it is necessary to compare the results of multiple tools, to employ different analysis techniques, and to verify important findings manually. R In addition to employing forensic tools, mount the forensic duplicate as a logical volume to support additional analysis. u Although forensic tools can support sophisticated analysis, they cannot solve every problem relating to a malware incident. For instance, running AntiVirus software against files on the compromised system is an important step in examining a compromised host. Figure 3.1 shows MountImage Pro1 being used to mount a forensic duplicate so that it is accessible as a logical volume on the forensic examination system without altering the original evidential data. 

FIGURE 3.1–MountImage Pro used to mount a forensic duplicate 1

  http://www.mountimage.com.

Chapter | 3 Post-Mortem Forensics

159

 Additional utilities such as FTK Imager, EnCase modules, and Daemon Tools (www.daemon-tools.cc) for mounting a forensic duplicate are discussed in the Tool Box section at the end of this chapter.

MALWARE DISCOVERY AND EXTRACTION FROM ­WINDOWS SYSTEMS Employing a methodical approach to examining areas of the compromised system that are most likely to contain traces of malware installation and use increases the chances that all traces of a compromise will be uncovered, especially when performed with feedback from the static and dynamic analysis covered in Chapters 5 and 6. u

Search for Known Malware

R Use characteristics from known malware to scour the file system for the same or similar items on the compromised computer. u Many intruders will use easily recognizable programs such as known rootkits, keystroke-monitoring programs, sniffers, and components from the PSTools package (e.g., psexec for starting a service remotely). There are several approaches to locating known malware on a forensic duplicate of a compromised computer. • Hashes: Searching a forensic duplicate of a compromised system for hash values matching known malware may identify other files with the same data but different names. The hash value of the full file will only reveal exact matches (see Figure 3.2), but an alternate approach involves searching for hash values of smaller parts of malware.

FIGURE 3.2–AFX Rootkit found using MD5 Hash

160

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

One tool that is specifically designed to detect known malware is Gargoyle Forensic Pro (see Figure 3.3).2 This program contains a database of known malware that is regularly updated and can be used to scan a forensic duplicate.

FIGURE 3.3–Scanning a target drive image with Gargoyle

• Piecewise Hashes: A piecewise hashing tool such as ssdeep3 may reveal

•

•

•

2

malware files that are largely similar with slight variations. Using the matching mode, with a list of fuzzy hashes of known ­malware, may find specimens that are not detected with an exact hash match or by current anti-virus definitions (e.g., when embedded IP addresses change). AntiVirus: Scanning files within a forensic duplicate of a compromised system using updated AntiVirus programs may identify known malware. To increase the chances of detecting malware, multiple AntiVirus programs can be used with any heuristic capabilities enabled. Such scanning is commonly performed by mounting a forensic duplicate on the examination system and configuring AntiVirus software to scan the mounted volume as shown in Figure 3.4 using Avira.4 In addition to scanning logical files, it can be worthwhile to carve all executables out of unallocated space and scan them using AntiVirus software as well, particularly when malware has been deleted by the intruder (or by AntiVirus software that was running on the compromised system). Keywords: Searching for IRC commands and other traits commonly seen in malware, and any characteristics that have been uncovered during the digital investigation (e.g., IP addresses observed in network-level logs) may uncover malicious files on the system.

  http://wetstonetech.com/cgi-bin/shop.cgi?view,2.   http://ssdeep.sourceforge.net. 4   http://www.avira.com/. 3

Chapter | 3 Post-Mortem Forensics

161

FIGURE 3.4–Avira A/V software scanning a mounted forensic duplicate

 Analysis Tip

Existing AntiVirus Logs

Given the prevalence of AntiVirus software, it is advisable to review any logs that were created by AntiVirus software that was running on the compromised system for indications of malware that was detected and deleted as discussed in the “Examine Logs” section later in this chapter. Many AntiVirus programs have Quarantine features that back up detected malware in a specially formatted file. Some vendors provide utilities for ­decoding these quarantine backup files to enable recovery of the actual malware for analysis.

Investigative Considerations • Some malware is specifically designed to avoid detection using hash values, AntiVirus signatures, or other similarity characteristics. Therefore, the absence of evidence in an AntiVirus scan or hash analysis should not be interpreted as evidence that no known malware is on the system. • Keyword searches for common characteristics in malware can also trigger AntiVirus definition files, resulting in false positives.

Survey Installed Programs

R Review the programs that are installed on the compromised system for potentially malicious applications. u Surveying the names and installation dates of programs that were installed on the compromised computer may reveal ones that are suspicious, as well as legitimate programs that can be used to gain remote access or to facilitate data theft. • This process does not require in-depth analysis of each program. Instead look for items that are unexpected, questionable, or were installed around the time of the incident.

162

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• Folders under “Program Files” show only some of the programs that are

•

installed on a Windows system. Subfolders under each user profile can reveal applications installed under specific user accounts. There are also locations in the Registry where digital investigators look for traces of installed programs and applications that were installed but have since been removed from the computer, as discussed in the section Examine Windows Registry later in this chapter. A malicious program may be apparent from a folder in the file system (e.g., keyloggers, WinRAR) or from a Registry entry. Figure 3.5 shows subfolders under Program Files on a Windows system, which include a keylogger program.

FIGURE 3.5–Program Files contains SpyKeyLogger

• Legitimate programs installed on a computer can also play a role in malware incidents. For instance, WinRAR or remote desktop programs (e.g., RDP, VNC) installed on a system may be normal in certain environments, but their availability may have enabled intruders to use them for malicious purposes such as packaging sensitive information before stealing it over the network.5 Coordination with the victim organization can help determine if these are legitimate typical business use ­applications. Even so, keep in mind that they could be abused/utilized by the intruder and associated log review may be fruitful. 5   Fellows, G. (2010). WinRAR Temporary Folder Artefacts, Digital Investigation, Vol. 7, no. 1–2, pp. 9–13.

Chapter | 3 Post-Mortem Forensics

163

 Analysis Tip Registry Remnants

The SOFTWARE Registry hive contains configuration information for installed applications and has a key “MicrosoftWindowsCurrentVersionApp Paths” that contains a list of executable paths for installed applications. The Windows Registry Database (WiReD) project being developed by NIST NSRL is currently working on a library of Registry remnants left by common programs to help digital investigators determine what programs were installed on a computer.

Examine Prefetch Files

R Inspect the creation date and other attributes of Prefetch files on the compromised system to determine whether they relate to execution of malware. u When malware, or any executable for that matter, is launched on a Windows system it may generate a Prefetch file. The creation date of a particular Prefetch file generally shows when the associated program was first executed on the system, and the last modified date indicates when it was most recently executed. Tools for parsing Prefetch files include Prefetch Parser6 and WinPrefetchView.7 • In addition to providing temporal information, Prefetch files contain information about the location of the associated executable on the file system as well as the number of times that the executable was run as shown in Figure 3.6.

FIGURE 3.6–Example of Prefetch related to Poison Ivy malware viewed using WinPrefetchView

6

  http://redwolfcomputerforensics.com/downloads/parse_prefetch_info_v1.4.zip.   http://www.nirsoft.net/utils/win_prefetch_view.html.

7

164

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Investigative Considerations • Examining the NTOSBOOT-BOODFAAD.pf file can help identify what is being loaded at boot time on a Windows system. • A Prefetch file can remain on a compromised system long after the originating executable is gone, and can be the only remaining indication that a particular executable existed on the system. • Keep in mind that not all actions on a Windows computer will result in a Prefetch file being created, and that Prefetch files may be deleted. Therefore, the lack of a Prefetch file does not mean that a particular program was not executed (absence of evidence is not evidence of absence).

Inspect Executables

R Determine whether any executables on the compromised system exhibit suspicious or unusual characteristics that might be used to conceal their presence. u Attackers commonly try to make malware more difficult to find and detect, so often digital investigators can look for common concealment techniques by carefully inspecting executables. This inspection can involve looking for misleading file extensions, packed executables, and alternate data streams. • Extension renaming: One of the simplest approaches used to conceal executables on a Windows system is to change the extension to something else. • Packing: Modern malware is often encoded (aka packed) to thwart detection and forensic analysis. • Alternate data streams: Look for executables in an ADS of other files or folders. Investigative Considerations • Reviewing every potential executable on a computer is a time-consuming process, and an important file may be missed in the mass of information. Fortunately, in many cases, there are known time periods of interest or other clues that focus forensic analysis and reduce the number of files that need to be reviewed for suspicious characteristics. • The increase in “spearfishing attacks” that employ social engineering to trick users to click on e-mail attachments, combined with malware embedded in Microsoft Office documents and Adobe PDFs as discussed in Chapter  5, means that digital investigators need to expand searches for malware to include objects embedded in documents and e-mail ­attachments.

Chapter | 3 Post-Mortem Forensics

165

Inspect Services, Drivers, Auto-starting Locations, and ­Scheduled Jobs

R Look for references to malware in the various startup routines on the compromised system to determine how malware managed to remain running on a Windows system after reboots. u To remain running after reboots, malware is usually re-launched using some of the various startup routines on a Windows system, including services, drivers, scheduled tasks, and other startup locations. • Schedule Tasks: Some modern malware uses the Task Scheduler to periodically execute and maintain persistence on the system. Therefore, it is necessary to examine scheduled jobs that are stored in the “Windows Tasks” folder in data files with the name of the application and the file extension .job. • Services: It is extremely common for malware to entrench itself within a new, unauthorized service or by inserting itself as the ImagePath or ServiceDll for an existing service. • Drivers: Drivers are commonly used as rootkit components to malware packages, and may be started via a variety of means. • AutoRun locations: Locations that Windows uses to automatically launch an executable as the system starts up may contain traces of malware. The AutoRuns tool can be used to examine auto-start items as shown in Figure 3.7, directing it to analyze a mounted forensic image via the File -> Analyze Offline System. Items displayed by AutoRuns that are missing or are unsigned and do not have a publisher description may be of interest in malware incident.

FIGURE 3.7–AutoRuns used to analyze an offline system

166

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Investigative Considerations • Be aware that not all methods used by malware to entrench itself on a Windows computer will be detected by AutoRuns or similar tools. For instance, the order in which Windows searches for dependencies may be used to execute malware. Therefore, even if nothing unusual is found during this inspection of auto-start locations, there may still be persistent malware on the system. • It may not be a simple matter to distinguish between legitimate system processes and malware in Windows auto-start locations. Therefore, it may be necessary to combine multiple tools and analysis techniques. For example, inspecting all changes to the file system and Registry during the period of interest can lead digital investigators to the pertinent file names and auto-start entries used by malware. In addition, looking for unsigned executables referenced in a startup routine may reveal unauthorized code.

Examine Logs

R Look in all available log files on the compromised system for traces of malicious execution and associated activities such as creation of a new service. u Log files can provide some of the most useful historical detail relating to a malware incident, giving visibility into past events, the sequence of activities related to an attack, and clues about what the intruder did on the compromised system. The logs that are available on a Windows system will depend on its configuration and installed programs. Some of the more common log files are summarized here with examples of their usefulness. • Windows Event Logs: Logon events recorded in the security event log, including logons via the network, Remote Desktop, and Remote Authentication Services, can reveal that malware or an intruder gained access to a compromised system via a given account at a specific time. Other events around the time of a malware infection can be captured in Windows Event logs, including the creation of a new service or new accounts around the time of an incident. Windows Event logs can be examined using tools such as Log Parser8 and Event Log Explorer9 as shown in Figure 3.8 with the ability to filter on specific types of events. Additional information about Log Parser and its flexibility is available in Microsoft Log Parser Toolkit from Syngress.10 8

  http://www.microsoft.com/downloads/en/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2f8d975cf8c07. 9   http://www.eventlogxp.com/. 10   http://www.syngress.com/information-security-and-system-administrators/Microsoft-LogParser-Toolkit/.

Chapter | 3 Post-Mortem Forensics

167

FIGURE 3.8–Windows System Event log being examined using Event Log Explorer, filtering on errors associated with services (Event IDs 7026 and 7030)

• Web browser history: The records of Web browsing history on a com-

• •

•

promised computer can reveal access to malicious Web sites and subsequent download of malware. In addition, some malware leaves traces in the Web browser history when it spreads to other machines on the network. Desktop firewall logs: Windows firewall and other desktop security programs may be configured to record access attempts and other activities on the compromised system. AntiVirus logs: When a Windows system is compromised, AntiVirus software may detect and even block malicious activities. Such events will be recorded in a proprietary log file with associated date-time stamps, and any quarantined items may still be stored by the AntiVirus software in a holding area. Dr. Watson: The Dr. Watson log, located in “Drwtsn32.log,” can contain information about programs that crashed and produced debug information. When Dr. Watson traps a crashing program, it can create a file named “User.dmp” containing memory contents from the crash, which may provide additional information.

Investigative Considerations • Log files can reveal connections from other systems that provide links to other systems on the network that may be compromised. • It is common to extract Windows event logs from a forensic duplicate for examination. However, message details that were unique to the compromised system may not be available when performing this type of analysis. Therefore,

168

•

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

it may be necessary to reconstruct the event details or review specific log entries of interest on a resuscitated clone of the compromised system as discussed in the “Forensic Reconstruction of Compromised Windows Systems” section later in this chapter. Windows event logs may be deleted in a malware incident, requiring a search of unallocated space for important entries.

 Analysis Tip

Domain Controller Security Event Logs

In some enterprise environments domain controllers are relied on for security logging, so local security event logging is disabled on the Windows computers that are part of the domain. In addition, DNS logs from a domain controller can be extremely important when tracking beacons to DNS host names. Given the volume of event logs on domain controllers, there may be a retention period of just a few days and digital investigators must preserve those logs quickly or risk losing this information.

Review User Accounts and Logon Activities

R Verify that all accounts used to access the system are legitimate accounts and determine when these accounts were used to log onto the compromised system. u Look for the unauthorized creation of new accounts on the compromised system, accounts with no passwords, or existing accounts added to Administrator groups. • Unauthorized account creation: This is identified by unusual names or accounts created in close proximity to known unauthorized events. • Administrator groups: It is advisable to check for user accounts that are not supposed to be in local or domain level administrator groups. • Weak passwords: In some situations it may be necessary to look for accounts with no passwords or easily guessed passwords. A variety of tools are designed for this purpose, including PRTK,11 John the Ripper,12 and Cain & Abel.13 Rainbow tables are created by precomputing the hash representation of passwords and creating a lookup table to accelerate the process of checking for weak passwords. Investigative Considerations

• Failed logon attempts can be important when repeated efforts were made to guess the passwords. 11

  http://accessdata.com/products/computer-forensics/decryption.   www.openwall.com/john/. 13   http://www.oxid.it/cain.html. 12

Chapter | 3 Post-Mortem Forensics

169

 Analysis Tip

Correlation with Logons

Combine a review of user accounts with a review of Windows Security Event Logs on the system to determine logon times, dates of account creation, and other activities related to user account activity on the compromised system. This can reveal unauthorized access, including logons via Remote Desktop.

EXAMINE WINDOWS FILE SYSTEM

R Explore the file system for traces left by malware. File system data structures can provide substantial amounts of information related to a malware incident, including the timing of events and the actual content of malware. However, malware is increasingly being designed to thwart file system analysis. Some malware alters date-time stamps on malicious files to make it more difficult to find them with time line analysis. Other malware is designed to download modular components from the Internet and only store them in memory to minimize the amount of data stored in the file system. To deal with such anti-forensic techniques, it is necessary to pay careful attention to time line analysis of file system date-time stamps and to files stored in common locations where malware might be found.14 • Search for file types that attackers commonly use to aggregate and exfiltrate information. For example, if RAR files are not commonly used in the victim environment, searching for .RAR file extensions and headers may reveal activities related to the intrusion. • Time line analysis is one of the most powerful techniques for organizing and analyzing file system information. Combining date-time stamps of malware-related files and system-related files such as link files and Prefetch files can lead to an illuminating reconstruction of events surrounding a malware incident, including the initial vector of attack and subsequent entrenchment and data theft. • Review the contents of the “%systemroot%system32” folder for files with date-time stamps around the time of the incident, or executables not associated with Windows or any known application (hash analysis can assist in this type of review to exclude known files). • When one piece of malware is found in a particular folder (e.g., C: WINNTJava, or a Temp folder), an inspection of other files in that folder may reveal additional malware. • Shadow Volumes on Windows Vista and 7 can contain copies of files that have since been deleted from the file system. u

14

  Pittman R., and Shaver D. (2009). Windows Forensic Analysis in Handbook of Digital Forensics and Investigation (Casey, E, ed.) Burlington, MA: Elsevier.

170

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Investigative Considerations • Although it is becoming more common for Standard Information Attribute (SIA) date-time stamps to be modified by malware, the File Name Attribute (FNA) is not typically updated. Therefore, discrepancies between the SIA and FNA may indicate that date-time stamps have been artificially ­manipulated. • The NTFS journal ($LogFile) contains references to MFT records that can be found by searching for the record header strings FILE0 or FILE* (case sensitive). Some forensic suites such as EnCase have the ability to parse $LogFile entries. • The increasing use of anti-forensic techniques in malware is making it more difficult to find traces on the file system. To mitigate this challenge, use all of the information available from other sources to direct a forensic analysis of the file system, including memory and logs. • It is often possible to narrow down the time period when that malicious activity occurred on a computer, in which case digital investigators can create a time line of events on the system to identify malware and related components, such as keystroke capture logs.

EXAMINE WINDOWS REGISTRY

R Scour Registry hives for information related to malware and associated activities. u Registry hives on a compromised system can contain information directly related to the operation of malware (e.g., auto-start on boot, configuration parameters), and can contain traces of activities related to malware. • UserAssist: The UserAssist key contains a list of programs run by user accounts on a compromised system that can provide details about malicious activities along with a date-time stamp of most recent ­execution. • Common locations: In addition to auto-start locations, Registry hives on a compromised system can contain configuration information and other trace evidence created by malware. For instance, names of files that were created or opened in relation to the malware may be retained in most recently used (MRU) lists and Windows Explorer shell bags in the Registry. RegRipper has standard templates that can be applied to common Registry hives to extract information that is generally useful when investigating a malware incident as shown in Figure 3.9. • Temporal analysis: Search the Registry for items with LastWritten date-time stamps around the time of the incident. The RegistryViewer from AccessData has a feature for finding all alteration in a Registry hive within a specific date range as shown in Figure 3.10.

Chapter | 3 Post-Mortem Forensics

171

FIGURE 3.9–RegRipper used to extract items from a System Registry hive, noting errors in the process that should be reviewed in the log file

FIGURE 3.10–Registry Viewer used to search for all items in the Software Registry hive on a specific date

Restore Points Some versions of Windows make routine backups of Registry hives that can contain information that is no longer present in the current Registry. In addition to looking in backup Registry hives for the same information as in the current hives as summarized earlier, there are unique types of analysis that the Restore Point backups can support. u

172

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• Look back: Information from past states of the system that is captured in • •

a Restore Point can be useful in an intrusion and malware investigation.15 Comparative analysis: Comparing the Registry from prior states of a compromised system can uncover important changes.16 Temporal analysis: The LastWritten date-time stamps within the backup Registry hives can help develop the time line of malicious activities on a compromised system.

KEYWORD SEARCHING

R Search for distinctive keywords each time such an item is uncovered during forensic analysis. u Searching for keywords is effective when you know what you are looking for but do not know where to find it on the compromised system. There are certain features of a malware incident that are sufficiently distinctive to warrant a broad search of the system for related information. Such distinctive items include: • Command-line arguments: Looking for commands that malware uses to execute processes on or obtain from other systems on the network (e.g., psexec, net use) or to exfiltrate data can reveal additional information related to the intrusion. • IP addresses: These may be stored in the human readable dot decimal format (e.g., 172.16.157.136) in both ASCII and Unicode formats, and may be represented in hex (e.g., ac 10 9d 88) both in little and big endian formats. Therefore, it may be necessary to construct multiple keywords for a single IP address. • Computer hostnames: Used to establish remote connections with a compromised system, these may be found in various locations, including Windows event logs. • Passphrases and encryption keys: Searching for these when associated with malicious code can uncover additional information related to malware. • File extensions and headers of file types: These are commonly used to steal data (e.g., .RAR) and can find evidence of data theft.

 Analysis Tip Search Smart

Significant time can be wasted searching for overly general or incorrectly encoded keywords. Therefore, care must be taken to construct an effective keyword list that considers how data will be represented on the system.

15

  Harms, K. (2006). Forensic Analysis of System Restore Points in Microsoft Windows XP, Journal of Digital Investigation, Vol. 3, no. 3, pp. 107–184. 16   Zhu, Y., James, J., and Gladyshev, P. (2009). A Comparative Methodology for the Reconstruction of Digital Events Using Windows Restore Points, Digital Investigation, Vol. 6, no. 1–2, pp. 8–15.

Chapter | 3 Post-Mortem Forensics

173

FORENSIC RECONSTRUCTION OF COMPROMISED ­WINDOWS SYSTEMS

R Performing a comprehensive forensic reconstruction can provide digital investigators with a detailed understanding of the malware incident. u Although it may seem counterintuitive to start creating a time line before beginning a forensic examination, there is a strong rationale for this practice. Performing temporal analysis of available information related to a malware incident should be treated as an analytical tool, not just a by-product of a forensic examination. Even the simple act of developing a time line of events can reveal the method of infection and subsequent malicious actions on the system. Therefore, as each trace of malware is uncovered, any temporal information should be inserted into a time line until the analyst has a comprehensive reconstruction of what occurred. u Functional analysis of a compromised Windows system involves creating a bootable clone of the system and examining it in action. One approach to ­creating a bootable clone is using LiveView,17 as shown in Figure 3.11. The snapshot feature in VMWare gives digital investigators a great degree of latitude for dynamic analysis on the actual victim clone image. In this instance, malware was found in the “C:I386SYSTEM32” folder and the digital investigator used a bootable clone of the compromised system to observe the functionality of two associated utilities. The interaction in Figure 3.11 shows vgalist (renamed pslist) looking for a malicious process named skls, then help for vgautils (rootkit named “fu”), and then using the rootkit to hide the skls process and confirm it is hidden by checking again with vgautils (pslist).

FIGURE 3.11–Forensic duplicate loaded into VMWare using LiveView 17

  http://liveview.sourceforge.net/.

174

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• Another approach is to restore a forensic duplicate onto a hard drive and

•

insert the restored drive into a computer. This is necessary when malware detects that it is running in a virtualized environment and takes evasive action to thwart forensic examination. In some situations, malware defense mechanisms may utilize characteristics of the hardware on a compromised computer such as MAC address, in which case it may be necessary to use a clone hard drive in the exact hardware of the compromised system that the forensic duplicate was obtained from.

ADVANCED MALWARE DISCOVERY AND ­EXTRACTION  FROM A WINDOWS SYSTEM Since the Malware Forensics textbook was published in 2008, more tools have been developed to address the increasing problem of malware designed to circumvent information security best practices and propagate within a network, enabling criminals to steal data from corporations despite intrusion detection systems and firewalls. Some tools, such as the Microsoft Malware Removal Tool18 shown in Figure 3.12, can be used to check every computer that is managed by an organization for certain malware and report the scan results to a central location.

FIGURE 3.12–Microsoft Malware Removal Tool

Keep in mind that this approach is not targeted—it checks for a variety of different malware rather than one specific malware. In some situations, this broader net can be advantageous by finding malware that was not the focus of the investigation. Keep in mind also that this approach is designed to remove malware from the system, which may not be desirable if the goal is to perform further forensic analysis of the system. 18

  http://www.microsoft.com/security/pc-security/malware-removal.aspx.

Chapter | 3 Post-Mortem Forensics

175

Other COTS remote forensic tools such as FTK Enterprise, EnCase Enterprise, and F-Response can be configured to examine files, memory, and Registry entries on remote systems for characteristics related to specific malware (see Figure 3.13).

FIGURE 3.13–AccessData FTK Enterprise extracting information from remote systems

In addition, some consulting companies that specialize in intrusion investigation have developed proprietary tools to examine remote systems for traces of malicious code.

CONCLUSIONS If malware is present on a system, it can be found by applying the forensic examination approach outlined in this chapter. Following such a methodical, documented approach will uncover the majority of trace evidence relating to malware incidents and has the added benefit of being repeatable each time a forensic examination is performed. By conducting each forensic examination in a consistent manner, documenting each step along the way, digital investigators will be in a better position when their work is evaluated by others in court. As more trace evidence is found on a compromised system, it can be combined to create a temporal, functional, and relational reconstruct of the malware incident. In addition, information recovered from compromised hosts can be correlated with network-level logs and memory, as well as the malicious code itself, to obtain a full picture of the malware incident. • Use characteristics extracted from one compromised host to search other systems on the network for similar traces of compromise.

176

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

M Pitfalls to Avoid Stepping in evidence  Don’t perform the steps outlined in this chapter on the original system. R Create a forensic duplicate of the hard drive from the original system and perform all analysis on a working copy of this data. In this way, no alterations are made to the original evidence during the forensic examination.

R Make working copies of the forensic duplicate to ensure that any corruption or problems that arise during a forensic examination do not ruin the only copy of the forensic duplicate. Missed or forgotten evidence  Do not skip a step in the forensic examination process for the sake of ­expediency. R Make an investigative plan, and then follow it. This will ensure that you include all necessary procedures.

R Be methodical, reviewing each area of the system that may contain trace evidence of malware.

R Document what you find as you perform your work so that it is not lost of forgotten later. Waiting to complete documentation later generally leads to failure because details are missed or forgotten in the fast pace of an ­investigation. Failure to incorporate relevant information from other sources  Do not assume that you have full information about the incident or that a single person performed the initial incident review and response. R Determine all of the people who performed field interviews, volatile data preservation, and log analysis, and obtain any information they gathered.

R Review documentation such as the Field Interview notes for information that can help focus and direct the forensic examination. If a particular individual did not maintain documentation of their work and findings, speak with them to obtain details.

177

Chapter | 3 Post-Mortem Forensics

WINDOWS SYSTEM EXAMINATION: FIELD NOTES Note: This document is not intended as a checklist, but rather as a guide to increase consistency of forensic examination of compromised Windows systems. When dealing with multiple compromised computer systems, it may be necessary to tabulate the results of each individual examination into a single document or spreadsheet. Case Number:

Date/Time:

Examiner name:

Client name:

Organization/Company:

Address:

Incident Type:

Trojan Horse Bot Logic Bomb Sniffer:

Worm Scareware/Rogue AV Keylogger Other:

System Information:

Operating System:

Virus Rootkit Ransomware: Unknown:

Make/Model:

Forensic Duplication Method: Post-mortem acquisition Live console acquisition Live remote acquisition

Network State: Connected to Internet Connected to Intranet Disconnected

Role of System: Workstation:

Credit Card Processing System:

Web Server:

Other:

Forensic Duplicate: Physical Hard Drive Acquisition : Acquired Date/Time: File Name: Size: MD5 Value: SHA1 Value: Tool Used:

Not Acquired [Reason]:

Known Malware: Note: AntiVirus software may quarantine known malware in a compressed/encoded format. File/Folder Identified: Method of identification (e.g., Hashset, AntiVirus):

___________________________________________ File name: Creation date-time stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Method of identification (e.g., Hashset, AntiVirus):

___________________________________________ File name: Creation date-time stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Method of identification (e.g., Hashset, AntiVirus):

___________________________________________ File name: Creation date-time stamp: File location on system (path): File location on system (clusters):

178

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Suspicious Installed Programs: Application name and description: ___________________________________________ Software installation path: Registry path:

Application name and description: ___________________________________________ Software installation path: Registry path:

Suspicious E-mails and Attachments: E-mail:

Sender address: Originating IP: Attachment name: Attachment description: ______________________________________ ______________________________________

E-mail:

Sender address: Originating IP: Attachment name: Attachment description: __________________________________________ __________________________________________

Suspect Executable Files (e.g., .exe, .dll, .sys): File/Folder Identified: Method of identification (e.g., packing, extension renaming): ___________________________________________ File name: Creation date-time stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Method of identification (e.g., packing, extension renaming): ___________________________________________ File name: Creation date-time stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Method of identification (e.g., packing, extension renaming): ___________________________________________ File name: Creation date-time stamp: File location on system (path): File location on system (clusters):

Malicious Auto-starts: Auto-start description:

___________________________________________ ___________________________________________ Auto-start location:

Auto-start description:

___________________________________________ ___________________________________________ Auto-start location:

179

Chapter | 3 Post-Mortem Forensics

Questionable User Accounts: User account _________________ on the system: Date of account creation: Login date: Shares, files, or other resources accessed by the user account: Processes associated with the user account: Network activity attributable to the user account: Passphrases associated with the user account:

User account _________________ on the system: Date of account creation: Login date: Shares, files, or other resources accessed by the user account: Processes associated with the user account: Network activity attributable to the user account: Passphrases associated with the user account:

Scheduled Tasks: Scheduled Tasks Examined Tasks Scheduled on the System Yes No

Suspicious Task(s) Identified: Yes No

Suspicious Task(s) Task Name:

Scheduled Run Time: Status: Description:

Task Name:

Scheduled Run Time: Status: Description:

Suspicious Services: Services Examined Suspicious Services(s) Identified: Yes No

Suspicious Service Identified: Service Name:

Associated executable path: Associated Registry entry last written date:

Suspicious Service Identified: Service Name: Associated executable path: Associated Registry entry last written date:

File System Clues : Artifacts to Look for on Storage Media: Notes:

MFT Entries: File/Folder Identified: Opened Remotely/ Opened Locally File name: Creation date-time stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Opened Remotely/ Opened Locally File name: Creation date-time stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Opened Remotely/ Opened Locally File name: Creation date-time stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Opened Remotely/ Opened Locally File name: Creation date-time stamp: File location on system (path): File location on system (clusters):

180

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

File/Folder Identified: Opened Remotely/ Opened Locally File name: Creation date-time stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Opened Remotely/ Opened Locally File name: Creation date-time stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Opened Remotely/ Opened Locally File name: Creation date-time stamp: File location on system (path): File location on system (clusters):

File/Folder Identified: Opened Remotely/ Opened Locally File name: Creation date-time stamp: File location on system (path): File location on system (clusters):

Prefetch Files: Suspicious Prefetch Identified: Prefetch File Name: Associated Application: Embedded Date: Created: Written: Runs:

Suspicious Prefetch Identified: Prefetch File Name: Associated Application: Embedded Date: Created: Written: Runs:

Restore Points: Restore Points Examined Restore point location examined: File name examined: Examined file description:

Restore point location examined: File name examined: Examined file description:

Restore point location examined: File name examined: Examined file description:

Shadow Volumes: Shadow Volumes Examined Shadow volume examined: File name examined: Examined file description:

Shadow volume examined: File name examined: Examined file description:

Shadow volumes examined: File name examined: Examined file description:

Suspicious Prefetch Identified: Prefetch File Name: Associated Application: Embedded Date: Created: Written: Runs:

Suspicious Prefetch Identified: Prefetch File Name: Associated Application: Embedded Date: Created: Written: Runs:

181

Chapter | 3 Post-Mortem Forensics

Registry Extraction : Potentially Malicious Registry Keys: Suspicious Registry Key Identified: Key Name: Location: Last Written Time: Associated Process/PID: Associated Network Activity: Associated Artifacts:

Suspicious Registry Key Identified: Key Name: Location: Last Written Time: Associated Process/PID: Associated Network Activity: Associated Artifacts:

Suspicious Registry Key Identified: Key Name: Location: Last Written Time: Associated Process/PID: Associated Network Activity: Associated Artifacts:

Suspicious Registry Key Identified: Key Name: Location: Last Written Time: Associated Process/PID: Associated Network Activity: Associated Artifacts:

Suspicious Registry Key Identified: Key Name: Location: Last Written Time: Associated Process/PID: Associated Network Activity: Associated Artifacts:

Suspicious Registry Key Identified: Key Name: Location: Last Written Time: Associated Process/PID: Associated Network Activity: Associated Artifacts:

Most Recently Used Entries (MRU): Suspicious MRU Identified: Key Name:

Suspicious MRU Identified: Key Name:

Associated File: Associated Date:

Associated File: Associated Date:

Suspicious MRU Identified: Key Name:

Suspicious MRU Identified: Key Name:

Associated File: Associated Date:

Associated File: Associated Date:

Host-based Logs : AntiVirus Logs: AntiVirus Type: AntiVirus log location: AntiVirus log entry description:

___________________________________________ Detection date: File name: Malware name: AntiVirus action: AntiVirus log entry description:

___________________________________________ Detection date: File name: Malware name: AntiVirus action: AntiVirus log entry description:

___________________________________________ Detection date: File name: Malware name: AntiVirus action:

182

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Windows Event Logs: Log Entry Identified: Security/ System/ Application

Log Entry Identified: Security/ System/ Application

Log Entry Identified: Security/ System/ Application

Log Entry Identified: Security/ System/ Application

Log Entry Identified: Security/ System/ Application

Log Entry Identified: Security/ System/ Application

Event type: Event ID: Source: Creation date-time stamp: Associated account/computer: Description:

Event type: Event ID: Source: Creation date-time stamp: Associated account/computer: Description:

Event type: Event ID: Source: Creation date-time stamp: Associated account/computer: Description:

Event type: Event ID: Source: Creation date-time stamp: Associated account/computer: Description:

Event type: Event ID: Source: Creation date-time stamp: Associated account/computer: Description:

Event type: Event ID: Source: Creation date-time stamp: Associated account/computer: Description:

Web Browser History: Suspicious Web Site Identified: Name: URL: Last visited date-time stamp: Description:

Suspicious Web Site Identified: Name: URL: Last visited date-time stamp: Description:

Suspicious Web Site Identified: Name: URL: Last visited date-time stamp: Description:

Suspicious Web Site Identified: Name: URL: Last visited date-time stamp: Description:

Host-based Firewall Logs: IP Address Found:

Local IP Address: ___.___.___.___ Port Number: _____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _________________ _________________ Protocol: TCP UDP

IP Address Found:

Local IP Address: ___.___.___.___ Port Number: _____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _________________ _________________ Protocol: TCP UDP

IP Address Found:

Local IP Address: ___.___.___.___ Port Number: _____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _________________ _________________ Protocol: TCP UDP

IP Address Found:

Local IP Address: ___.___.___.___ Port Number: _____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _________________ _________________ Protocol: TCP UDP

IP Address Found:

Local IP Address: ___.___.___.___ Port Number: _____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _________________ _________________ Protocol: TCP UDP

IP Address Found:

Local IP Address: ___.___.___.___ Port Number: _____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _________________ _________________ Protocol: TCP UDP

183

Chapter | 3 Post-Mortem Forensics

Crash Dump Logs: Crash dump: File name: Creation date-time stamp: File location on system (path): File location on system (cluster): Description:

___________________________________________ Crash dump: File name: Creation date-time stamp: File location on system (path): File location on system (cluster): Description:

___________________________________________

Network Clues: IP Address Found:

Local IP Address: ___.___.___.___ Port Number: _____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _________________ _________________ Protocol: TCP UDP

IP Address Found:

Local IP Address: ___.___.___.___ Port Number: _____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _________________ _________________ Protocol: TCP UDP

IP Address Found:

Local IP Address: ___.___.___.___ Port Number: _____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _________________ _________________ Protocol: TCP UDP

IP Address Found:

Local IP Address: ___.___.___.___ Port Number: _____ Remote IP Address: ___.___.___.___ Port Number: ___ _________________ Remote Host Name: _________________ Protocol: TCP UDP

IP Address Found:

Local IP Address: ___.___.___.___ Port Number: _____ Remote IP Address: ___.___.___.___ Port Number: ___ _________________ Remote Host Name: _________________ Protocol: TCP UDP

IP Address Found:

Local IP Address: ___.___.___.___ Port Number: _____ Remote IP Address: ___.___.___.___ Port Number: ___ Remote Host Name: _________________ _________________ Protocol: TCP UDP

Web Site/URLs/E-mail Addresses: Suspicious Web Site/URL/E-mail Identified: Name:

Suspicious Web Site/URL/E-mail Identified: Name:

Description

Suspicious Web Site/URL/E-mail Identified: Name:

Description

Suspicious Web Site/URL/E-mail Identified: Name:

Description

Description

184

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Linkage to Other Compromised Systems: Association with other compromised system: IP address: Name:

Association with other compromised system: IP address: Name:

Association with other compromised system: IP address: Name:

Association with other compromised system: IP address: Name:

Description

Description

Description

Description

Search for Keywords/Artifacts : Keyword Search Results: Keyword: Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____

Keyword: Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____

Keyword:

Keyword:

Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____

Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____

Keyword:

Keyword:

Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____

Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____ Search hit description: _____________ Location: ____

Recycle Bin Records: File/Folder Identified: INFO2 File/ Unallocated File name: Deletion date-time stamp: File location on system (path):

Recycle Bin Records: File/Folder Identified: INFO2 File/ Unallocated File name: Deletion date-time stamp: File location on system (path):

 Windows Analysis Tool Box

Forensic Analysis Tools for Windows Systems

In this chapter we discussed approaches to conducting a forensic examination of Windows systems for malware and associated artifacts. There are a number of forensic analysis tools that you should be aware of and familiar with. In this section, we explore these tool alternatives, often demonstrating their functionality. This section can also simply be used as a “tool quick reference” or “cheat sheet,” as there will inevitably be an instance during an investigation where having an additional tool that is useful for a particular function would be beneficial, but while responding in the field you will have little time to conduct research for or regarding the tool(s). It is important to perform your own testing and validation of these tools to ensure that they work as expected in your environment and for your specific needs.

Chapter | 3 Post-Mortem Forensics

MOUNTING FORENSIC DUPLICATES

185

186

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

directly and

Chapter | 3 Post-Mortem Forensics

187

Name: ImDisk Author/Distributor: LTR Data Available From: http://www.ltr-data.se/opencode.html/#ImDisk Description: This is a simple free utility for Windows computers to mount a forensic duplicate as a virtual drive letter. The following command options effectively mount a forensic duplicate read-only on drive letter W: C:Windowssystem32>imdisk -a -o ro -f E:Forensicsimage-001.dd -s 1 30000K -m W: Creating device… Created device 1: W: -> E:Forensicsimage-001.dd Notifying applications… Done.

The following command options unmount a forensic duplicate read-only on drive letter W:ImDisk C:Windowssystem32>imdisk -d -m W: Notifying applications… Flushing file buffers… Locking volume… Dismounting filesystem… Removing device… Removing mountpoint… Done.

FORENSIC EXAMINATION OF WINDOW SYSTEMS

Description: FTK is a commercial integrated digital forensic examination program that has a wide range of features for examining forensic duplicates of storage media. The most basic use of FTK is to perform forensic examinations of file systems as shown in the following figure. In addition to parsing and displaying common file systems, FTK recovers deleted files, performs indexing to facilitate keyword searching, and interprets specific file formats in order to extract additional information.

188

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Description: EnCase is a commercial integrated digital forensic examination program that has a wide range of features for examining forensic duplicates of storage media. The most basic use of EnCase is to perform forensic examinations of file systems as shown in the following figure. In addition to parsing and displaying common file systems, EnCase recovers deleted files, can perform keyword searching, interprets specific file formats in order to extract additional information, and has a scripting language that can be used to add customized functionality and automate routine tasks.

Chapter | 3 Post-Mortem Forensics

189

Name: The Sleuthkit & Autopsy Author/Distributor: Brian Carrier and Open Source Collaborators Available From: http://www.sleuthkit.org Description: The Sleuthkit (TSK) is a free open source package of command-line utilities for conducting forensic examination of file systems. Although TSK is designed to run on UNIX/Linux systems, it can be used to examine FAT, NTFS, and HFS+ file systems. These utilities include fls to list files and directories in the file system and display associated metadata. In addition, a simple Web-based graphical user interface called Autopsy is provided to facilitate use of TSK utilities.

190

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Name: X-Ways Author/Distributor: WinHex Available From: http://www.x-ways.com Description: X-Ways is a commercial program for performing forensic examination of storage media and files. The most basic use of X-Ways is to perform forensic examinations of file systems as shown in the figure below. In addition, X-Ways can be used to recovered deleted files and perform keyword searches.

TIMELINE GENERATION Name: log2timeline Author/Distributor: Kristinn Gudjonsson Available From: http://log2timeline.net/ Description: Log2timeline is a free, open source tool that extracts information from a variety of logs and other date-time stamped data sources and consolidates the information into a comprehensive time line for review. This tool can be used to process individual files or an entire mounted file system to extract information from supported file formats. For example, the following command processes a Security Event log from a Vista system. # log2timeline -f evtx -z EST5EDT SecEvents.evtx Start processing file/dir [SecEvents.evtx] … Starting to parse using input modules(s): [evtx] Loading output file: csv date,time,timezone,MACB,source,sourcetype,type,user,host,short,desc,version,filename,inode,notes,format extra 07/27/2011,12:45:28,EST5EDT,MACB,EVTX,Security,Event Logged,-,Rozilla,Event ID Security/Microsoft-Windows-Security-Auditing:4616,Security/Microsoft-Windows-Security-Auditing ID [4616] :EventData/Data -> SubjectUserSid = S-1-5-21-406733884-1130205496-191468519-1001 SubjectUserName = Yacker SubjectDomainName = Rozilla SubjectLogonId = 0x0000000000146ece PreviousDate = 7/27/2011 PreviousTime = 12:45:29 AM NewDate = 7/27/2011 NewTime = 12:45:28 PM ProcessId = 5096 ProcessName = C:/Windows/System32/dllhost.exe 2,SecEvents.evtx,199745,Description of EventIDs can be found here: http://support.microsoft.com/default.aspx?scid=kb;EN-US;947226 URL: http://eventid.net/display.asp?eventid=4616&source=Microsoft-Windows-SecurityAuditing,Log2t::input::evtx, The following commands determine the offset of partitions using mmls, mounts the second partition using the loopback interface, and extracts information from files on a mounted Windows XP image using log2timeline with the winxp module. The winxp module includes these file formats explained below: chrome, evt, exif, ff_bookmark, firefox3, iehistory, iis, mcafee, opera, oxml, pdf, prefetch, recycler, restore, setupapi, sol, win_link, xpfirewall, wmiprov, ntuser, software, system. # mmls infected-winxp-image.dd 00: —— 0000000000 0000000000 0000000001 Primary Table (#0) 01: —— 0000000001 0000000062 0000000062 Unallocated 02: 00:00 0000000063 0000259259 0000259197 NTFS (0x07) # mount -t ntfs-3g -o ro,loop,show_sys_files,offset=32256 infected-winxp-image.dd /mnt/evidence

PreviousDate = 7/27/2011 PreviousTime = 12:45:29 AM NewDate = 7/27/2011 NewTime = 12:45:28 PM ProcessId = 5096 ProcessName = C:/Windows/System32/dllhost.exe 2,SecEvents.evtx,199745,Description of EventIDs can be found here: http://support.microsoft.com/default.aspx?scid=kb;EN-US;947226 URL: http://eventid.net/display.asp?eventid=4616&source=Microsoft-Windows-Security191 Chapter | 3 Post-Mortem Forensics Auditing,Log2t::input::evtx, The following commands determine the offset of partitions using mmls, mounts the second partition using the loopback interface, and extracts information from files on a mounted Windows XP image using log2timeline with the winxp module. The winxp module includes these file formats explained below: chrome, evt, exif, ff_bookmark, firefox3, iehistory, iis, mcafee, opera, oxml, pdf, prefetch, recycler, restore, setupapi, sol, win_link, xpfirewall, wmiprov, ntuser, software, system. # mmls infected-winxp-image.dd 00: —— 0000000000 0000000000 0000000001 Primary Table (#0) 01: —— 0000000001 0000000062 0000000062 Unallocated 02: 00:00 0000000063 0000259259 0000259197 NTFS (0x07) # mount -t ntfs-3g -o ro,loop,show_sys_files,offset=32256 infected-winxp-image.dd /mnt/evidence # log2timeline -z EST5EDT -f winxp -w output.csv -r -p /mnt/evidence Log Formats Supported: The following log formats are processed by log2timeline.

————————————————————————Name Ver. Description ————————————————————————apache2_access 0.3 Parse the content of a Apache2 access log file apache2_error 0.2 Parse the content of a Apache2 error log file chrome 0.3 Parse the content of a Chrome history file encase_dirlisting 0.2 Parse the content of a CSV file that is exported from FTK Imager (dirlisting) evt 0.2 Parse the content of a Windows 2k/XP/2k3 Event Log evtx 0.5 Parse the content of a Windows Event Log File (EVTX) exif 0.4 Extract metadata information from files using ExifTool ff_bookmark 0.3 Parse the content of a Firefox bookmark file firefox2 0.3 Parse the content of a Firefox 2 browser history firefox3 0.8 Parse the content of a Firefox 3 history file ftk_dirlisting 0.2 Parse the content of a CSV file that is exported from FTK Imager (dirlisting) generic_linux 0.3 Parse content of Generic Linux logs that start with MMM DD HH:MM:SS iehistory 0.7 Parse the content of an index.dat file containg IE history iis 0.5 Parse the content of a IIS W3C log file isatxt 0.4 Parse the content of a ISA text export log file jp_ntfs_change 0.1 Parse the content of a CSV output file from JP (NTFS Change log) mactime 0.6 Parse the content of a body file in the mactime format mcafee 0.3 Parse the content of a log file mft 0.1 Parse the content of a NTFS MFT file mssql_errlog 0.2 Parse the content of an ERRORLOG file produced by MS SQL server ntuser 1.0 Parses the NTUSER.DAT registry file opera 0.2 Parse the content of an Opera’s global history file oxml 0.4 Parse the content of an OpenXML document (Office 2007 documents) pcap 0.5 Parse the content of a PCAP file pdf 0.3 Parse some of the available PDF document metadata prefetch 0.7 Parse the content of the Prefetch directory recycler 0.6 Parse the content of the recycle bin directory restore 0.9 Parse the content of the restore point directory safari 0.3 Parse the contents of a Safari History.plist file sam 0.1 Parses the SAM registry file security 0.1 Parses the SECURITY registry file setupapi 0.5 Parse the content of the SetupAPI log file in Windows XP skype_sql 0.1 Parse the content of a Skype database software 0.1 Parses the SOFTWARE registry file sol 0.5 Parse the content of a .sol (LSO) or a Flash cookie file squid 0.5 Parse the content of a Squid access log (http_emulate off) syslog 0.2 Parse the content of a Linux Syslog log file system 0.1 Parses the SYSTEM registry file tln 0.5 Parse the content of a body file in the TLN format volatility 0.2 Parse the content of a Volatility output files (psscan2, sockscan2, …) win_link 0.7 Parse the content of a Windows shortcut file (or a link file) wmiprov 0.2 Parse the content of the wmiprov log file xpfirewall 0.4 Parse the content of a XP Firewall log

192

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

FORENSIC EXAMINATION OF COMMON SOURCES OF INFORMATION ON WINDOWS SYSTEMS

Chapter | 3 Post-Mortem Forensics

Name: Prefetch Parser Author/Distributor: Redwolf Available From: http://redwolfcomputerforensics.com/downloads/parse_prefetch_info_v1.4.zip Description: Prefetch Parser is a program that extracts information from Prefetch files and outputs the results in a simple format for examination. The following screenshots show Pretch file being extracted in HTML report format.

193

194

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Name: Autoruns Author/Distributor: Microsoft Available From: http://www.sysinternals.com Description: Autoruns is a program that can run against a live system or a forensic duplicate to extract details from various locations that will launch programs when a Windows computer starts up. In addition to providing a categorized interface to this information, Autoruns can be useful for identifying unusual startup entries. For example, Autoruns can show executables that have not been signed, which may be an indication of malware. As another example, Autoruns can reveal startup entries that are missing the associated executable on the disk as shown in the following figure, which may be an indication of malicious activity or be a reference to malware that was deleted by AntiVirus software:

Name: Log Parser Author/Distributor: Microsoft Available From: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=890cd06b-abf8-4c2591b2-f8d975cf8c07 Description: Log Parser is a versatile utility for parsing common types of data on Microsoft Windows systems, including file system entries, Registry entries, Event logs, and IIS Web server logs. In addition to simply parsing files, Log Parser provides a SQL query interface to the support file formats that can be useful for extracting specific information. For example, the following use of Log Parser extracts all logon records from a Windows Security Event log and displays a list of usernames and the date and time they were used to log onto the system. C:>LogParser «SELECT TimeGenerated AS LogonDate, EXTRACT_TOKEN(Strings, 0, ‘|’) AS Username FROM ‘SecEvent.Evt’ WHERE EventID NOT IN (541;542;543) AND EventType = 8 AND EventCategory = 2 AND Username NOT LIKE ‘IUSR_%’“ LogonDate Username —————— ————2002-05-06 21:03:31 esmith 2002-05-09 17:42:06 adoe 2002-05-09 19:56:53 esmith 2002-05-12 00:12:32 esmith

Chapter | 3 Post-Mortem Forensics

Name: Event Log Explorer Author/Distributor: FSPro Labs Available From: http://www.eventlogxp.com/ Description: Event Log Explorer is a useful program for examining Windows Event Logs. This tool can be used to filter on specific events as shown in the following figure, enabling forensic examiners to focus on a subset of events that may be relevant to a malware incident. In additon, Event Log Explorer supports keyword searching of Event log entries, which can be useful for finding specific events related to malware incidents.

Name: Registry Viewer Author/Distributor: AccessData Available From: http://www.accessdata.com Description: Registry Viewer is a program for examining Registry hives from Windows systems. This program displays Registry values and associated data, and has the ability to decode certain values that would otherwise be obfuscated. Registry Viewer also has features for filtering specific Registry keys and performing keyword searches. In addition, Registry Viewer has a feature for finding all alterations in a Registry hive within a specific date range as shown in the following figure.

195

196

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Name: RegRipper Author/Distributor: Harlan Carvey Available From: http://regripper.wordpress.com/regripper/ Description: Registry Ripper (aka RegRipper) is a utility for extracting specific information from Windows Registry hives. This tool uses plug-in files to specify which items will be extracted from Registry hives. These plug-ins can be run against a suitable Registry hive from a command line or using the Registry Ripper graphical user interface shown here for a System Registry hive.

Chapter | 3 Post-Mortem Forensics

197

198

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Name: NetAnalysis Author/Distributor: Digital Detective Group Available From: http://www.digital-detective.co.uk/ Description: NetAnalysis extracts information from a wide variety of Web browsers, including Internet Explorer, Firefox, Safari, Mozilla, Google Chrome, Orca, Flock, Yahoo!, AOL ARL files, and other file types. This tools processes and displays browsing history, cookies, and cache data with associated datetime stamps. NetAnalysis also has features for filter ing specific entries and performing keyword searches.

Chapter | 3 Post-Mortem Forensics

Name: Restore Point Analyzer Author/Distributor: Mandiant Available From: http://www.mandiant.com/ Description: The Restore Point Analyzer utility processes the change.log in Windows Restore Points to provide a list of files that were included in the restore point.

199

200

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Name: Mandiant Web Historian Author/Distributor: Mandiant Available From: http://www.mandiant.com/ Description: Mandiant Web Historian extracts browsing history associated with several Web browsers (Firefox 2, Firefox 3+, Chrome 3+, Internet Explorer 5−8, Safari 3+). This tool processes history, temporary cache data and cookies with associated date-time stamps. However, it presents this information in separate tabs as shown here.

Chapter | 3 Post-Mortem Forensics

Name: Gargoyle Author/Distributor: Wetstone Available From: http://wetstonetech.com/cgi-bin/shop.cgi?view,2 Description: Gargoyle is a tool for scanning file systems for artifacts of known malware as shown here.

201

202

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

SELECTED READINGS Books Altheide, C., and Carvey, H. (2011). Digital Forensics with Open Source Tools. Burlington, MA: Syngress. Carrier, B. (2005). File System Forensic Analysis. Reading, MA: Addison-Wesley Professional. Carvey, H. (2011). Windows Registry Forensics: Advanced Digital Forensic Analysis of the ­Windows Registry. Burlington, MA: Syngress. Carvey, H. (2009). Windows Forensic Analysis DVD Toolkit, Second Edition. Burlington, MA: Syngress. Casey, E. (2011). Digital Evidence and Computer Crime, Third Edition: Forensic Science, ­Computers, and the Internet. San Diego, CA: Academic Press. Casey, E. (2009). Handbook of Digital Forensics and Investigation. San Diego, CA: Academic Press. Jones, K., Bejtlich, R., and Rose, C. (2005). Real Digital Forensics: Computer Security and Incident Response. Reading, PA: Addison-Wesley Professional.

Papers Bang, J., Yoo, B., and Lee, S. (2011). Analysis of Changes in File Time Attributes with File ­Manipulation, Digital Investigation, Vol. 7, no. 3–4, pp. 135–144. Fellows, G. (2007). NTFS Volume Mounts, Directory Junctions and $Reparse, Digital ­Investigation, Vol. 4, no. 3–4, pp. 116–118. Fellows, G.H. (2005). The Joys of Complexity and the Deleted File, Digital Investigation, Vol. 2, no. 2, pp. 89–93. Harms, K. (2006). Forensic Analysis of System Restore Points in Microsoft Windows XP, Digital Investigation, Vol. 3, no. 3, pp. 151–158. Huebner, E., Bem, D., and Kai Wee, C. (2006). Data Hiding in the NTFS File System, Digital ­Investigation, Vol. 3, no. 4, pp. 211–226. Kent, K. et al., National Institute of Standards and Technology (2006). Guide to Integrating ­Forensic Techniques into Incident Response. http://csrc.nist.gov/publications/nistpubs/800-86/SP80086.pdf. Mee, V., Tryfonas, T., and Sutherland, I. (2006). The Windows Registry as a Forensic ­Artefact: ­Illustrating Evidence Collection for Internet Usage, Digital Investigation, Vol. 3, no. 3, pp. 166–173. National Institute of Justice (NIJ) (2004). Forensic Examination of Digital Evidence: A Guide for Law Enforcement. http://www.ncjrs.gov/pdffiles1/nij/199408.pdf. Nolan, R. et al., Carnegie Mellon Software Engineering Institute, Computer Emergency Response Team (CERT) (2005). First Responders Guide to Computer Forensics. www.cert.org/archive/ pdf/FRGCF_v1.3.pdf. Nolan, R. et al., Carnegie Mellon Software Engineering Institute, Computer Emergency Response Team (CERT) (2005). First Responders Guide to Computer Forensics: Advanced Topics. www. cert.org/archive/pdf/05hb003.pdf. Scientific Working Group on Digital Evidence (SWGDE) (2010). SWGDE Technical Notes on ­Microsoft Windows 7. http://www.swgde.org/documents/current-documents/SWGDE%20 Technical%20Notes%20on%20Microsoft%20Windows%207.pdf. Scientific Working Group on Digital Evidence (SWGDE) (2008). SWGDE Technical Notes on Microsoft Vista v1.0. http://www.swgde.org/documents/current-documents/2008-02-08%20 SWGDE%20Technical%20Notes%20on%20Windows%20Vista%20v1.0.pdf. Zhu, Y., Gladyshev, P., and James, J. (2009). Using ShellBag Information to Reconstruct User ­Activities DFRWS2009. http://www.dfrws.org/2009/proceedings/p69-zhu.pdf. Zhu, Y., James, J., and Gladyshev, P. (2009). A Comparative Methodology for the Reconstruction of Digital Events Using Windows Restore Points, Digital Investigation, Vol. 6, no. 1–2, pp. 8–15.

Chapter 4

Legal Considerations Solutions in this chapter: • Framing the Issues • General Considerations

°° The Legal Landscape

• Sources of Investigative Authority

°° Jurisdictional Authority °° Private Authority °° Statutory/Public Authority

• Statutory Limits on Authority

°° Stored Data °° Real-time Data °° Protected Data

• Tools for Acquiring Data

°° Business Use °° Investigative Use °° Dual Use

• Acquiring Data Across Borders

°° Workplace Data in Private or Civil Inquiries °° Workplace Data in Government or Criminal Inquiries

• Involving Law Enforcement

°° Victim Reluctance °° Victim Misperception °° The Law Enforcement Perspective °° Walking the Line

• Improving Chances for Admissibility

°° Documentation °° Preservation °° Chain of Custody

 Legal Considerations Appendix and Web Site

The  symbol references throughout this chapter denote the availability of additional related materials appearing in the Legal Considerations appendix at the end of this chapter. Further updates for this chapter can be found on the companion Malware Field Guides Web site, at http://www.malwarefieldguide.com/Chapter4.html. Malware Forensics Field Guide for Windows Systems. DOI: 10.1016/B978-1-59749-472-4.00004-4 © 2012 Malin. All rights reserved.

203

204

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

FRAMING THE ISSUES This chapter endeavors to explore the legal and regulatory landscape when conducting malware analysis for investigative purposes, and to discuss some of the requirements or limitations that may govern the access, preservation, collection, and movement of data and digital artifacts uncovered during malware forensic investigations. This discussion, particularly as presented here in abbreviated Field Guide format, does not constitute legal advice, permission, or authority, nor does this chapter or any of the book’s contents confer any right or remedy. The goal and purpose instead is to offer assistance in critically thinking about how best to gather malware forensic evidence in a way that is reliable, repeatable, and ultimately admissible. Because the legal and regulatory landscape surrounding sound methodologies and best practices is admittedly complicated, evolving, and often unclear, do identify and consult with appropriate legal counsel and obtain necessary legal advice before conducting any malware forensic investigation.

GENERAL CONSIDERATIONS

R Think early about the type of evidence you may encounter. • Seek to identify, preserve, and collect affirmative evidence of responsibility or guilt that attributes knowledge, motive, and intent to a suspect, whether an unlikely insider or an external attacker from afar. • Often as important is evidence that exculpates or excludes from the realm of possible liability for the actions or behavior of a given subject or target. • The lack of digital artifacts suggesting that an incident stemmed from a malfunction, misconfiguration, or other non-human initiated ­systematic or automated process is often as important to identify, preserve, and ­collect as affirmative evidence. R Be dynamic in your investigative approach. • Frame and re-frame investigative objectives and goals early and often. • Design a methodology ensuring that investigative steps will not alter, delete, or create evidence, tip off a suspect, or otherwise compromise the ­investigation. • Create and maintain at all times meticulous step-by-step analytical and chain of custody documentation. • Never lose control over the evidence.

The Legal Landscape

R Navigate the legal landscape by understanding legal permissions or restrictions as they relate to the investigator, the victim, the digital evidence, the investigatory tools, and the investigatory findings.

Chapter | 4 Legal Considerations

u

u

u

u

u

205

The Investigator • The jurisdiction where investigation occurs may require special certification or licensing to conduct digital forensic analysis. • Authority to investigate must exist, and that authority is not without limit. • The scope of the authorized investigation will likely be defined and must be well understood. The Victim • Intruding on the privacy rights of relevant victim data custodians must be avoided. • Other concerns raised by the victim might limit access to digital evidence stored on stand-alone devices. • With respect to network devices, collection, preservation, and analysis of user-generated content (as compared to file or system metadata analysis) are typically handled pursuant to a methodology defined or approved by the victim. • It is important to work with the victim to best understand the circumstances under which live network traffic or electronic communications can be monitored. The Data • Encountered data, such as personal, payment card, health, financial, educational, insider, or privileged information, may be protected by state or federal law in some way. • Methods exist to obtain overseas evidence necessary to forensic analysis. • In certain jurisdictions, restrictions may exist that prohibit the movement or transportation of relevant data to another jurisdiction. The Tools • In certain jurisdictions, limitations relating to the types of investigative tools available to conduct relevant forensic analysis may exist. • The functionality and nature of the use of investigative tools implicate these limitations. The Findings • Understanding evidentiary requirements early on will improve chances for admissibility of relevant findings down the road. • Whether and when to involve law enforcement in the malware investigation is an important determination.

SOURCES OF INVESTIGATIVE AUTHORITY Jurisdictional Authority

R Because computer forensics, the discipline, its tools, and training, have grown exponentially in recent years, legislation has emerged in the United States that often requires digital investigators to obtain state-issued licensure before engaging in computer forensic analysis within a state’s borders.

206

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Jurisdictional

Private

Sources of investigative authority

Public

Statutory

FIGURE 4.1–Sources of investigative authority

u

1

When Private Investigation Includes Digital Forensics • Approximately 45 states maintain private investigation laws that ­generally require the investigator to submit an application, pay a fee, possess ­certain experience requirements, pass an examination, and ­periodically renew the license once granted.1 • Many state laws generally define private investigation to broadly include the “business of securing evidence to be used before investigating committees or boards of award or arbitration or in the trial of civil or criminal cases and the preparation therefore.”2 • Although such laws do not appear to implicate digital forensics conducted for investigatory purposes by internal network administrators or IT departments on data residing within a corporate environment or domain,3 once the investigation expands beyond the enterprise environment (to other networks or an Internet service provider, or involves the preservation of ­evidence for the pursuit of some legal right or remedy), licensing regulation appears to kick in within several state jurisdictions.

 See, e.g., California’s “Private Investigator Act,” codified at Cal. Bus. & Prof. Code § 7521 et seq.   See, e.g., Arizona Revised Statutes 32-2401-16. See also Cal. Bus. & Prof. Code 7521(e); Nev. Rev. Stat. Ann. § 648.012. 3   See, e.g., Michigan’s “Private Detective License Act,” MCLS 338.24(a) (specifically excluding a “person employed exclusively and regularly by an employer in connection with the affairs of the employer only and there exists a bona fide employer–employee relationship for which the employee is reimbursed on a salary basis”); Cal. Bus. & Prof. Code § 7522 (same). 2

Chapter | 4 Legal Considerations

u

u

207

Where Digital Forensics Requires PI Licensure • Roughly 32 states’ statutes can be interpreted to include digital forensic investigators, like those in force in Florida, Georgia, Michigan, New York, Nevada, Oregon, Pennsylvania, South Carolina, Texas, Virginia, and Washington. • On the other hand, some states exempt “technical experts”4 or “any expert hired by an attorney at law for consultation or litigation purposes”5 from private investigation licensing requirements. Indeed, at least one state, Delaware, has specifically excluded from regulation “computer forensic specialists,” defined as “persons who interpret, evaluate, test, or analyze pre-existing data from computers, computer systems, networks, or other electronic media, provided to them by another person where that person owns, controls, or possesses said computer, computer systems, networks, or electronic media.”6 A subcommittee of the American Bar Association (ABA) has urged the same result.7 • Given that most state licensing requirements vary and may change on a fairly regular basis, consult the appropriate state agency in the jurisdiction where you will perform digital forensic analysis early and often. Navigate to http://www.crimetime.com/licensing.htm or http://www.pimagazine.com/ private_investigator_license_requirements.html to find relevant links pertaining to your jurisdiction and obtain qualified legal advice to be sure.  Potential Consequences of Unlicensed Digital Forensics • Some legislation contains specific language creating a private right of action for licensing violations. • Indirect penalties may include equitable relief stemming from unlawful business practice in the form of an injunction or restitution order, exclusion of any evidence gathered by the unlicensed investigator, or a client’s declaration of breach of contract and refusal to pay for the investigator’s services.

4   See Louisiana’s “Private Investigators Law,” LA.R.S. 37:3503(8)(a)(iv). See also Kennard v. Rosenberg, 127 Cal.App.3d 340, 345-46 (1954) (interpreting California’s Private Investigator Act) (“it was the intent of the Legislature to require those who engage in business as private investigators and detectives to first procure a license so to do; that the statute was enacted to regulate and control this business in the public interest; that it was not intended to apply to persons who, as experts, were employed as here, to make tests, conduct experiments and act as consultants in a case requiring the use of technical knowledge”). 5   Ohio Revised Code § 4749.01(H)(2). 6   See Delaware’s “Private Investigators and Private Security Agencies Act,” codified at 24 Del. Code §§ 1301 et seq. 7   See American Bar Association, Section of Science & Technology Law, Resolution 301 (August 11–12, 2008), available at www.americanbar.org/content/dam/aba/migrated/scitech/301.doc (“RESOLVED, That the American Bar Association urges State, local and territorial legislatures, State regulatory agencies, and other relevant government agencies or entities, to refrain from requiring private investigator licenses for persons engaged in: computer or digital forensic services or in the acquisition, review, or analysis of digital or computer-based information, whether for purposes of obtaining or furnishing information for evidentiary or other purposes, or for providing expert testimony before a court; or network or system vulnerability testing, including network scans and risk assessment and analysis of computers connected to a network”).

208

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Private Authority

R Authorization to conduct digital forensic analysis, and the limits of that authority, depend not just on how and where the data to be analyzed lives, but also on the person conducting the analysis. The digital investigator derives authority to investigate from different sources with different constraints on the scope and methodology governing that investigation. u Company Employee • Internal investigators assigned to work an investigative matter on behalf of their corporation often derive authority to investigate from well-defined job descriptions tied to the maintenance and security of the ­corporate computer network. • Written incident response policies may similarly inform the way in which a network administrator or corporate security department uses network permissions and other granted resources to launch and carry out corporate investigative objectives. • Chains of corporate command across information security, human resources, legal, and management teams will inform key investigative decisions about containment of ongoing network attacks, how best to ­correct damage to critical systems or data, whether and the extent to which alteration of network status data for investigative purposes is appropriate, or even the feasibility of shutting down critical network components or resources to facilitate the preservation of evidence. u Retained Expert • Internal considerations also indirectly source the authority of the ­external investigator hired by corporate security or in-house counsel or outside counsel on behalf of the victim corporation. • More directly, the terms and conditions set forth in engagement letters, service agreements, or statements of work often specifically authorize and govern the external investigator’s access to and analysis of relevant digital evidence. • Non-disclosure provisions with respect to confidential or proprietary corporate information may not only obligate the digital investigator to certain confidentiality requirements, but also may proscribe the way in which relevant data can be permissibly transported (i.e., hand-carried not couriered or shipped) or stored for analysis (i.e., on a private network with no externally facing connectivity). • Service contracts may require special treatment of personal, payment card, health, insider, and other protected data that may be relevant to forensic investigation (a topic addressed later in the “Protected Data” section of this chapter). • A victim corporation’s obligations to users of the corporate network may further limit grants of authority to both the internal and external digital investigator.

Chapter | 4 Legal Considerations

209

An employee’s claims of a reasonable expectation of privacy  to data subject to digital forensic analysis may be defeated if the employer—through an employment manual, policy, or contract, a banner displayed at user login, or some other means—has provided notice to the employee otherwise.8 ❒ Whether analysis may be conducted of a suspect file residing on a workstation dedicated for onsite use by the company’s third party auditors will depend on the written terms of a third-party service or user agreement. Sanctions ranging from personnel or administrative actions, to civil breach of contract or privacy actions, to criminal penalties can be imposed against investigators who exceed appropriate authority. ❒

•

Statutory/Public Authority

R Law enforcement conducted digital forensic investigations are authorized from public sources. u The Special Case of Law Enforcement • Federal and state statutes authorize law enforcement to conduct malware forensic investigations with certain limitations.9 • Public authority for digital investigators in law enforcement comes with legal process, most often in the form of grand jury subpoenas, search warrants, or court orders. • The type of process often dictates the scope of authorized investigation, both in terms of what, where, and the circumstances under which electronic data may be obtained and analyzed. • Attention to investigating within the scope of what has been authorized is particularly critical in law enforcement matters where evidence may be suppressed and charges dismissed otherwise.10 u Acting in Concert with Law Enforcement • Retained experts may be deemed to be acting in concert with law enforcement—and therefore similarly limited to the scope of the authorized investigation—if the retained expert’s investigation is conducted at the direction of, or with substantial input from, law enforcement. • For more information, refer to the discussion of whether, when, and how to involve law enforcement in conducting malware forensic investigations, appearing later in the “Involving Law Enforcement” section of this chapter. 8

  See, e.g., TBG Insurance Services Corp. v. Superior Court, Cal.App.4th 443 (2002) (employee’s explicit consent to written corporate monitoring policy governing company home computer used for personal purposes defeated reasonable expectation of privacy claim). 9   See. e.g.. 18 U.S.C. § 2703. 10   See, e.g., United States v. Carey, 172 F.3d 1268 (10th Cir. 1999) (law enforcement may not expand the scope of a computer search beyond its original justification by opening files believed would constitute evidence beyond the scope of the warrant).

210

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

STATUTORY LIMITS ON AUTHORITY In addition to sources and limits of authority tied to the person conducting the analysis, authority also comes from regulations that consider aspects of the relevant data itself; namely the type of data, the quality of the data, the location of the data, when the data will be used, and how the data will be shared.

Stored Data

R Stored data relevant to a malware-related investigation may not be available under some circumstances, depending on the type of data, the type of network, and to whom disclosure of the data is ultimately made. Authorization to access stored data depends on whether the data is stored by a private or public provider, and if by a public provider, whether the data sought to be accessed constitutes content or non-content information.11 u Private Provider • Authorized access to stored e-mail data on a private network that does not provide mail service to the public generally would not implicate Electronics Communications Privacy Act (ECPA) prohibitions against access and voluntary disclosure, even to law enforcement.12 • E-mail content, transactional data relating to e-mail transmission, and information about the relevant user on the network can be accessed and voluntarily disclosed to anyone at will. u Public Provider—Non-Content • If the network is a public provider of e-mail service, like AOL or Yahoo! for example, content of its subscribers’ e-mail, or even non-content subscriber or transactional data relating to such e-mails in certain circumstances, ­cannot be disclosed, unless certain exceptions apply. • A public provider can voluntarily disclose non-content customer subscriber and transactional information relating to a customer’s use of the public ­provider’s mail service: 1. To anyone other than law enforcement 2. To law enforcement: a. With the customer’s lawful consent; or b. When necessary to protect the public provider’s own rights and property; or c. If the public provider reasonably believes an emergency involving immediate danger of death or serious bodily injury requires disclosure.13 11

  See Electronic Communications Privacy Act (“ECPA”), codified at 18 U.S.C. §§ 2701 et seq.   See 18 U.S.C. § 2701. 13   See 18 U.S.C. § 2702(c). 12

Chapter | 4 Legal Considerations

u

211

Public Provider—Content • With respect to the content of a customer subscriber’s e-mail, a public provider can voluntarily disclose to law enforcement: a. With the customer’s lawful consent; or b. When necessary to protect the public provider’s own rights and property; or c. If the public provider inadvertently obtains content and learns that it pertains to the commission of a crime; or d. If the public provider reasonably believes an emergency involving immediate danger of death or serious bodily injury requires disclosure.14 • Of course, if the public provider is served with a grand jury subpoena or other legal process compelling disclosure, that is a different story. • Otherwise, through the distinctions between content and non-content and disclosure to a person and disclosure to law enforcement, ECPA endeavors to balance private privacy with public safety.

Real-time Data

R For digital investigators who need to real-time monitor the content of Internet communications as they are happening, it is important to understand the requirements of and exceptions to the federal Wiretap Act, the model for most state statutes on interception as well. u Content • The Wiretap Act, often referred to as “Title III,” protects the privacy of electronic communications by prohibiting any person from intentionally intercepting, or attempting to intercept, their contents by use of a device.15 • In most jurisdictions, electronic communications are “intercepted” within the meaning of the Wiretap Act only when such communications are acquired contemporaneously with their transmission, as opposed to stored after transmittal.16 • There are three exceptions to the Wiretap Act relevant to the digital investigator: the provider exception; consent of a party; and the computer trespasser exception. u Content—The Provider Exception • The provider exception affords victim corporations and their retained digital investigators investigating the unauthorized use of the corporate network fairly broad authority to monitor and disclose to others (including law enforcement) evidence of unauthorized access and use, so long 14

  See 18 U.S.C. § 2702(b).   See 18 U.S.C. § 2511; in re Pharmatrak, Inc. Privacy Litigation, 329 F.3d 9, 18 (1st Cir. 2003). 16   Interception involving the acquisition of information stored in computer memory has in at least one jurisdiction been found to violate the Wiretap Act. See United States v. Councilman, 418 F.3d 67 (1st Cir. 2005) (en banc). 15

212

u

17

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

as that effort is tailored to both minimize interception and avoid disclosure of private communications unrelated to the investigation.17 • In practical terms, while the installation of a sniffer to record the intruder’s communication with the victim network in an effort to combat ongoing fraudulent, harmful, or invasive activity affecting the victim entity’s rights or property may not violate the Wiretap Act, the provider exception does not authorize the more aggressive effort to “hack back” or otherwise intrude on an intruder by gaining unauthorized access to the attacking system (likely an innocent compromised machine anyway). • Do not design an investigative plan to capture all traffic to the victimized network; instead avoid intercepting traffic communications known to be innocuous. Content—The Consent Exception • The consent exception authorizes interception of electronic communications where one of the parties to the communication18 gives explicit consent or is deemed upon actual notice to have given implied consent to the interception.19 • Guidance from the Department of Justice recommends that “organizations should consider deploying written warnings, or “banners,” on the ports through which an intruder is likely to access the organization’s system and on which the organization may attempt to monitor an intruder’s communications and traffic. • If a banner is already in place, it should be reviewed periodically to ensure that it is appropriate for the type of potential monitoring that could be used in response to a cyber attack.20 • If banners are not in place at the victim company, consider whether the obvious notice of such banners would make monitoring of the ongoing activities of the intruder more difficult (and unnecessarily so where the provider exception remains available) before consulting with counsel to tailor banner content best suited to the type of monitoring proposed. • Solid warnings often advise users that their access to the system is being monitored, that monitoring data may be disclosed to law enforcement, and that use of the system constitutes consent to surveillance. • Keep in mind that while the more common network ports are bannerable, the less common (the choice of the nimble hacker) often are not.

  See 2511(2)(a)(i).   Note that some state surveillance statutes, like California’s, require two-party consent. 19   18 U.S.C. § 2511(2)(d); United States v. Amen, 831 F.2d 373, 378 (2d Cir. 1987) (consent may be explicit or implied); United States v. Workman, 80 F.3d 688, 693 (2d Cir. 1996) (proof that the consenting party received actual notice of monitoring but used the monitored system anyway established implied consent). 20   Appendix C, “Best Practices for Victim Response and Reporting,” to “Prosecuting Computer Crimes,” U.S. Department of Justice Computer Crime & Intellectual Property Section (February 2007), available at http://www.cybercrime.gov/ccmanual/appxc.html. 18

Chapter | 4 Legal Considerations

u

u

213

Content—The Computer Trespasser Exception— Acting in Concert with Law Enforcement • The computer trespasser exception gives law enforcement the ability with the victim provider’s consent to intercept communications exclusively between the provider and an intruder who has gained unauthorized access to the provider’s network.21 • This exception is not available to digital investigators retained by the provider, but only to those acting in concert with law enforcement. • Do not forget the interplay of other limits of authority discussed elsewhere in this chapter, bearing in mind that such limitations may trump exceptions otherwise available under the Wiretap Act to digital investigators planning to conduct network surveillance on a victim’s network. Non-Content • For digital investigators who need only collect real-time the non-­content portion of Internet communications—the source and destination IP address associated with a network user’s activity, the header and “hop” information associated with an e-mail sent to or received by a network user, the port that handled the network user’s communication a network user uses to communicate—be mindful that an exception to the federal Pen Registers and Trap and Trace Devices statute22 nonetheless must apply for the collection to be legal. • Although the statute generally prohibits the real-time capture of traffic data relating to electronic communications, provider and consent exceptions similar and broader to those found in the Wiretap Act are available. • Specifically, corporate network administrators and the digital investigators they retain to assist have fairly broad authority to use a pen/trap device on the corporate network without court order so long as the collection of non-content: ❒ Relates to the operation, maintenance, and testing of the network ❒ Protects the rights or property of the network provider ❒ Protects network users from abuse of or unlawful use of service ❒ Is based on consent • Remember that surveillance of the content of any communication would implicate the separate provisions and exceptions of the Wiretap Act.

Protected Data

R For the digital investigator tasked with performing forensic analysis on malicious code designed to access, copy, or otherwise remove valuable sensitive, confidential, or proprietary information, understanding the nature of federal and state protections of this data will help inform necessary investigative and evidentiary determinations along the way. 21

  18 U.S.C. § 2511(2)(i).   18 U.S.C. §§ 3121–3127.

22

214

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

u

Federal Protection of Financial Information • Responding to an incident at a financial institution that compromises customer accounts may implicate the provisions of the Gramm Leach Bliley Act, also known as the Financial Services Modernization Act of 1999, which protects the privacy and security of consumer financial information that financial institutions collect, hold, and process.23 • The Act generally defines a “financial institution” as any institution that is significantly engaged in financial activities.”24 • The regulation only protects consumers who obtain financial products and services primarily for person, family, or household purposes. • The regulation: ❒ Requires a financial institution in specified circumstances to provide notice to customers about its privacy policies and practices; ❒ Describes the conditions under which a financial institution may disclose non-public personal information about consumers to nonaffiliated third parties; and ❒ Provides a method for consumers to prevent a financial institution from disclosing that information to most non-affiliated third parties by “opting out” of that disclosure, subject to certain limited exceptions. • In addition to these requirements, the regulations set forth standards for how financial institutions must maintain information security programs to protect the security, confidentiality, and integrity of customer information. Specifically, financial institutions must maintain adequate administrative, technical, and physical safeguards reasonably designed to: ❒ Ensure the security and confidentiality of customer information; ❒ Protect against any anticipated threats or hazards to the security or integrity of such information; and ❒ Protect against unauthorized access to or use of such information that could result in substantial harm or inconvenience to any customer. • Be careful when working with financial institution data to obtain and document the scope of authorization to access, transport, or disclose such data to others.25

23

  Public Law 106-12, 15 U.S.C. § 6801 et seq., hereinafter sometimes referred to as “GLB” or “the Act.” The names in the popular GLB title of this statute refer to three members of Congress who were its instrumental sponsors, Senator Phil Gramm (R-TX), Chairman of the Senate Banking Committee; Representative Jim Leach (R-IA), Chairman of the House Banking Committee; and Representative Thomas Bliley (R-VA), Chairman of the House Commerce Committee. 24   16 CFR § 313(k)(1). For a list of common examples, see 16 CFR § 313(k)(2) of the Act, available at http://edocket.access.gpo.gov/cfr_2003/16cfr313.3.htm. 25   In addition to GLB, the Fair Credit Reporting Act, the Internal Revenue Code, and a variety of state laws and regulations provide consumers with protection in the handling of their credit report and tax return information by financial service providers. Pay particular attention to the handling of this type of financial data. For a terrific summary of the consumer protection laws that apply to financial institutions, see http://www.dfi.wa.gov/cu/summary.htm.

Chapter | 4 Legal Considerations

u

26

215

Federal Protection of Health Information • The Health Insurance Portability and Accountability Act (HIPAA)26 applies generally to covered entities (health plans, health-care clearinghouses, and health-care providers who transmit any health information in electronic form),27 and provides rules designed to ensure the privacy and security of individually identifiable health information (“protected health information”), including such information transmitted or maintained in electronic media (“electronic protected health information”). • HIPAA specifically sets forth security standards for the protection of electronic protected health information. ❒ The regulation describes the circumstances in which protected health information may be used and/or disclosed, as well as the circumstances in which such information must be used and/or disclosed. ❒ The regulation also requires covered entities to establish and maintain administrative, physical, and technical safeguards to: m Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity creates, receives, maintains, or transmits; m Protect against any reasonably anticipated threats or hazards to the security or integrity of such information; m Protect against any reasonably anticipated uses or disclosures of such information that are not otherwise permitted or required by the regulation; and m Ensure compliance with the regulation by the covered entity’s ­workforce. • In February 2009, the American Recovery and Reinvestment Act (ARRA) became law, subjecting business associates—vendors, professional service providers, and others that perform functions or activities involving protected health information for or on behalf of covered entities—to many of the health information protection obligations that HIPAA imposes on covered entities.28 • Given these stringent requirements, investigative steps involving the need to access, review, analyze, or otherwise handle electronic protected health information should be thoroughly vetted with counsel

  42 USC §§ 1302, 1320d, 1395; 45 CFR §§ 160, 162, 154.   Retail pharmacies are another perhaps less obvious example of a “covered entity” required to comply with HIPAA requirements. Pharmacies regularly collect, handle, and store individually identifiable health information during the ordinary course of business. 28   Public Law 111–5 (February 2009), codified at 2 CFR § 176, available at http://www.gpo.gov/ fdsys/pkg/PLAW-111publ5/content-detail.html. 27

216

u

u

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

to ensure compliance with the HIPAA and ARRA security rules and obligations.29 Federal Protection of Public Company Information • The Sarbanes-Oxley Act (SOX)30 broadly requires public companies to institute corporate governance policies designed to facilitate the prevention, detection, and handling of fraudulent acts or other instances of corporate malfeasance committed by insiders. • Other provisions of SOX were clearly designed to deter and punish the intentional destruction of corporate records. • In the wake of SOX, many public companies overhauled all kinds of ­corporate policies that may also implicate more robust mechanisms for the way in which financial and other digital corporate data is handled and stored. • During the early assessment of the scope and limits of authority to conduct any internal investigation at a public company, be mindful that a SOX-compliant policy may dictate or limit investigative steps. Other Federally Protected Information • Information About Children: The Child Online Privacy Protection Act (COPPA)31 prohibits unfair or deceptive acts or practices in connection with the collection, use, and/or disclosure of personal information from and about children on the Internet. The Juvenile Justice and Delinquency Prevention Act,32 governing both the criminal prosecution and the delinquent adjudication of minors in federal court, protects the juvenile defendant’s identity from public disclosure.33 If digital investigation leads to a child, consult counsel for guidance on the restrictions imposed by these federal laws. • Child Pornography: 18 U.S.C. § 1466A proscribes among other things the possession of obscene visual representations of the sexual abuse of children. Consider including in any digital forensic services contract language that reserves the right to report as contraband to appropriate authorities any digital evidence encountered that may constitute child pornography. • Student Educational Records: The Family Education Rights and Privacy Act34 prevents certain educational institutions from disclosing a student’s “personally identifiable education information,” including grades and student loan information, without the student’s written permission. Again, authority to access and disclose this type of ­information

29   An excellent summary of the detailed provisions of HIPAA is available at http://www.omh.state .ny.us/omhweb/hipaa/phi_protection.html. A thorough discussion of the ARRA extensions of HIPAA is available at http://www.cerner.com/uploadedFiles/Assessment_of_OCR_Proposed_ HIPAA_Security_and_Privacy_ARRA_HITECH_Updates.pdf. 30   17 CFR §§ 210, 228-29, 240, 249, 270. 31   16 CFR § 312. 32   18 U.S.C. §§ 5031 to 5042. 33   See 18 U.S.C. § 5038 (provisions concerning sealing and safeguarding of records generated and maintained in juvenile proceedings). 34   20 U.S.C. § 1232g.

Chapter | 4 Legal Considerations

u

35

217

should be properly vetted with the covered educational institution or its counsel. • Payment Card Information: The Payment Card Industry Data Security Standards (PCI DSS) established common industry security standards for storing, transmitting, and using credit card data, as well as managing computer systems, network devices, and the software used to store, process, and transmit credit card data. According to these established guidelines, merchants who store, process, or transmit credit card information, in the event of a security incident, must take immediate action to investigate the incident, limit the exposure of cardholder data, make certain disclosures, and report investigation findings. When handling PCI data during the course of digital investigation, be sure to understand these heightened security standards and requirements for disclosure and reporting. • Privileged Information: Data relevant to the digital investigator’s analysis may constitute or be commingled with information that is protected by the attorney–client privilege or the attorney work product doctrine. Digital investigator access to or disclosing of that data, if not performed at the direction of counsel, may be alleged to constitute a waiver of these special protections. State Law Protections • Forty-four states have passed a data breach notification law requiring owners of computerized data that include consumer personal information to notify any affected consumer following a data breach that compromises the security, confidentiality, or integrity of that personal information. • The statutes generally share the same key elements, but vary in how those elements are defined, including the definitions of “personal information,” the entities covered by the statute, the kind of breach triggering notification obligations, and the notification procedures required.35 • Personal information has been defined across these statutes to include some or all of the following: r Social Security, Alien Registration, tribal, and other federal and state government issued identification numbers r Drivers’ license and non-operating license identification numbers r Date of birth r Individuals’ mothers’ maiden names r Passport number r Credit card and debit card numbers

  A helpful chart updated as of July 1, 2009, that summarizes existing state breach notification laws is available at http://www.digestiblelaw.com/files/upload/securitybreach.pdf.

218

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Financial account numbers (checking, savings, other demand deposit accounts) r Account passwords or personal identification numbers (PINs) r Routing codes, unique identifiers, and any other number or information that can be used to access financial resources r Medical information or health insurance information r Insurance policy numbers r Individual taxpayer identification numbers (TINs), employer taxpayer identification number (EINs), or other tax information r Biometric data (fingerprints, voice print, retina or iris image) r Individual DNA profile data r Digital signature or other electronic signature r Employee identification number r Voter identification numbers r Work-related evaluations Most statutes exempt reporting if the compromised information is “encrypted,” although the statues do not always set forth the standards for such encryption. Some states exempt reporting if, under all circumstances, there is no reasonable likelihood of harm, injury, or fraud to customers. At least one state requires a “reasonable investigation” before concluding no reasonable likelihood of harm. Notification to the affected customers are ordinarily made in writing, ­electronically, telephonically, or, in the case of large-scale breaches, through publication. Under most state statutes, Illinois being an ­exception, notification can be delayed if it is determined that the ­disclosure will impede or compromise a criminal investigation. Understanding the breach notification requirements of the state jurisdiction in which the investigation is conducted is important to the integrity of the digital examiner’s work, as the scope and extent of permissible authority to handle relevant personal information may be different than expected. Consult counsel for clear guidance on how to navigate determinations of encryption exemption and assess whether applicable notice requirements will alter the course of what otherwise would have been a more covert operation designed to avoid tipping the subject or target.  r

•

•

•

TOOLS FOR ACQUIRING DATA The digital investigator’s selection of a particular tool often has legal implications. Nascent judicial precedent in matters involving digital evidence has yielded no requirement that a particular tool be used for a particular purpose. Instead, reliability, a theme interwoven throughout this chapter and this entire Field Guide, often informs whether and the extent to which the digital investigator’s findings are considered.

Chapter | 4 Legal Considerations

219

Business Use

R Output from tools used during the ordinary course of business is commonly admitted as evidence absent some showing of alteration or inaccuracy. u Ordinary Course • Intrusion detection systems • Firewalls, routers, VPN appliances • Web, mail, and file servers u Business Purpose • Output from ordinary course systems, devices, and servers constitutes a record generated for a business—a class of evidence for which there exists recognized indicia of reliability. • Documentation and custodial testimony will support admissibility of such output.

Investigative Use

R Output from tools deployed for an investigatory purpose is evaluated differently. Which tool was deployed, whether the tool was deployed properly, and how and across what media the tool was deployed are important considerations to determinations of reliability. u Tool • Simple traceroutes • WHOIS lookups • Other network-based tools u Deployment • Inside the victim network r Was deployment in furtherance of maintaining the integrity and safety of the victim network environment? r Was deployment consistent with documented internal policies and procedures? • Outside the victim network r Did deployment avoid the possibility of unauthorized access or damage to other systems? r Did deployment avoid violating other limits of authority discussed earlier in this chapter? u Findings • Repeatable • Supported by meticulous note taking • Investigative steps were taken consistent with corporate policy and ­personal, customary, and best practice. • Investigative use of tools was consistent without sound legal advice.

220

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Dual Use

R Hacker tools and tools to affect security or conduct necessary investigation are often one in the same. The proliferation of readily downloadable “hacker tools” packaged for wide dispersion has resulted in legal precedent in some jurisdictions that inadequately addresses this “dual use,” causing public confusion about where the line is between the two and what the liabilities are when that line is crossed. u Multiple Countries—Council of Europe Convention of Cybercrime36 • What It Is: r Legally binding multilateral instrument that addresses computerrelated crime. r Forty-three countries have signed or ratified it, including the United States.37 r Each participating country agrees to ensure that its domestic laws criminalize several categories of computer-related conduct. r One such category, titled “Misuse of Devices,” intends to criminalize the intentional possession of or trafficking in “hacker tools” designed to facilitate the commission of a crime. • The Problem: r Software providers, research and security analysts, and digital investigators might get unintentionally but nonetheless technically swept up in less than carefully worded national laws implemented by participating countries. r The official Commentary on the substantive provisions of the Convention that include Article 6 provides little further illumination,38 but it does seem to exclude application to tools that might have both legitimate and illegitimate purposes. u United Kingdom—Computer Misuse Act/Police and Justice Act • What It Is: r Proposed amendments to the Computer Misuse Act of 1990 to be implemented through the Police and Justice Act of 2006.39 r Designed to criminalize the distribution of hacker tools. 36

  The complete text of the Convention is available at http://conventions.coe.int/Treaty/en/ Treaties/Html/185.htm. 37   For a complete list of the party and signatory countries to the Convention, see the map available at http://www.coe.int/t/dc/files/themes/cybercrime/worldmap_en.pdf. 38   The complete text of the Convention Commentary is available at http://conventions.coe.int/ Treaty/en/Reports/Html/185.htm. 39   The prospective version of the Police and Justice Act of 2006 is available at http://www .statutelaw.gov.uk/content.aspx?LegType=All+Legislation&title=Police+and+Justice+Act+2006 &searchEnacted=0&extentMatchOnly=0&confersPower=0&blanketAmendment=0&sortAlpha=0 &TYPE=QS&PageNumber=1&NavFrom=0&parentActiveTextDocId=2954345&ActiveTextDocI d=2954404&filesize=24073.

Chapter | 4 Legal Considerations

u

u

40

221

• The Problem: r No dual-use exclusion. r Simple sharing of common security tools with someone other than a known and trusted colleague could violate the law. r “Believed likely to be misused” standard of liability is vague. r Prosecution guidance40 is similarly vague. Germany—Amendments to Section 202c • What It Is r Amendments to the German Code41 broadly prohibiting unauthorized users from disabling or circumventing computer security measures in order to access secure data. r The amendments also proscribe the manufacturing, programming, installing, or spreading of software that has the primary goal of circumventing security measures. • The Problem r Security analysts throughout the globe have criticized the law as vague, overbroad, and impossible to comply with. r German security researchers have pulled code and other tools offline for fear of prosecution. United States—Computer Fraud and Abuse Act • The Issue r Despite the United States’ participation in the Council of Europe Convention on Cybercrime, Congress has not amended the Computer Fraud and Abuse Act (CFAA) to include “devices.” r The CFAA does create misdemeanor criminal liability for “knowingly and with intent to defraud traffic[king] in any password or similar information through which a computer may be accessed without authorization.”42 • The Problem r What does “similar information” mean? Does it include the software and tools commonly used by digital investigators to respond to a security incident? Is the statute really no different than the British and German statutes? r Here is the party line, appearing in a document titled “Frequently Asked Questions about the Council of Europe Convention on Cybercrime,”43 released by the U.S. Department of Justice when ratification of the Convention was announced:

  That guidance is available at http://www.cps.gov.uk/legal/a_to_c/computer_misuse_act_1990/ index.html. 41   The relevant provisions of the German Code can be found (in German) at http://www.bmj .bund.de/files/-/1317/RegE%20Computerkriminalit%C3%A4t.pdf. 42   See 18 U.S.C. §§ 1030(a)(6), (c)(2)(A). 43   See http://www.justice.gov/criminal/cybercrime/COEFAQs.htm#topicE.

222

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Q: Does the Convention outlaw legitimate security testing or research? A: Nothing in the Convention suggests that States should criminalize the legitimate use of network security and diagnostic tools. On the contrary, Article 6 obligates Parties to criminalize the trafficking and possession of “hacker” tools only where conduct is (i) intentional, (ii) “without right”, and (iii) done with the intent to commit an offense of the type described in Articles 2-5 of the Convention. Because of the criminal intent element, fears that such laws would criminalize legitimate computer security, research, or education practices are unfounded. Moreover, paragraph 2 of Article 6 makes clear that legitimate scientific research and system security practices, for example, are not criminal under the Article. ER paragraphs 47-48, 58, 62, 68 and 77 also make clear that the use of such tools for the purpose of security testing authorized by the system owner is not a crime. Finally, in practice, the existing U.S. laws that already criminalize use of, possession of, or trafficking in “access” or “interception” tools have not led to investigations of network security personnel. FIGURE 4.2–U.S. Department of Justice, “Frequently asked questions about the Council of Europe Convention on Cybercrime” u

The Lesson • Pay close attention to the emerging laws on misuse of devices, particularly when conducting forensic analysis in the 43 countries that have committed to implement the Convention and its provisions. • When in doubt, obtain appropriate legal advice.

ACQUIRING DATA ACROSS BORDERS In the United States, subject to the sources and limitations of authority discussed earlier in this chapter, digital investigators are often tasked early in the course of internal investigations to thoroughly preserve, collect, and analyze electronic data residing across corporate networks. At times, however, discovery and other data preservation obligations reach outside domestic borders to, for example, a foreign subsidiary’s corporate network, and may conflict with foreign data protection laws that treat employee data residing on company computers, servers, and equipment as the personal property of the individual employee and not the corporation.

Workplace Data in Private or Civil Inquiries

R Handling of workplace data depends on the context of the inquiry. Although more formal mechanisms exist for the collection of digital evidence pursuant to government or criminal inquiries, country-specific data privacy laws will govern private or civil inquiries. u Europe • Although inapplicable to data efforts made in the context of criminal law enforcement or government security matters, the 1995 European Union

Chapter | 4 Legal Considerations

•

44

223

Data Protection Directive,44 a starting point for the enactment of countryspecific privacy laws within the 27 member countries that ­subscribe to it,45 sets forth 8 general restrictions on the handling of workplace data46: r Limited Purpose: Data should be processed for a specific purpose and subsequently used or communicated only in ways consistent with that purpose. r Integrity: Data should be kept accurate, up to date, and no longer than necessary for the purposes for which collected. r Notice: Data subjects should be informed of the purpose of any data processing and the identity of the person or entity determining the purposes and means of processing the data. r Access/Consent: Data subjects have the right to obtain copies of personal data related to them, rectify inaccurate data, and potentially object to the processing. r Security: Appropriate measures to protect the data must be taken. r Onward Transfer: Data may not be sent to countries that do not afford “adequate” levels of protection for personal data. r Sensitive Data: Additional protections must be applied to special categories of data revealing the data subject’s racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, health, or sex life. r Enforcement: Data subjects must have a remedy to redress violations. With respect to the restriction on onward transfer, no definition of “adequate” privacy protection is provided in the European (EU) Directive. Absent unambiguous consent obtained from former or current employee data subjects that affords the digital investigator the ability to transport the data back to the lab,47 none of the other

  Directive 95/46EC of the European Parliament and of the Council of 24 October 1995 on the Protection of Individuals with Regard to the Processing of Personal Data and on the Free Movement of Such Data, available at http://europa.eu/legislation_summaries/information_society/ data_protection/l14012_en.htm. 45   The following 27 countries of the EU are required to implement legislation under the Directive: Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, and the United Kingdom. In addition, a number of other countries have data protection statutes that regulate access to employees’ data and cross-border data transfers, with ramifications for the conduct of internal investigations by U.S.-based digital investigators. For example, Iceland, Liechtenstein, and Norway (together comprising the European Economic Area); Albania, Andorra, Bosnia and Herzegovina, Croatia, Macedonia, and Switzerland (European Union neighboring countries); and the Russian Federation have laws similar to the EU Data Protection Directive. See Wugmeister, M., Retzer, K., and Rich, C. (2007). Global Solution for Cross-Border Data Transfers: Making the Case for Corporate Privacy Rules, Geo. J. Intl L., 449, 455. 46   Boyd, V. (2006). Financial Privacy in the United States and the European Union: A Path to Transatlantic Regulatory Harmonization, Berkeley J. Intl L., 939, 958–959. 47   Directive, Art. 26(1) (a) (transfer “may take place on condition that: (a) the data subject has given his consent unambiguously to the proposed transfer”).

224

u

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

e­ xceptions to the “onward transfer” prohibition in the EU Directive appear to apply to internal investigations voluntarily conducted by a victim corporation responding to an incident of computer fraud or abuse. As  such, the inability to establish the legal necessity for data transfers for fact finding in an internal inquiry may require the digital investigator to preserve, collect, and analyze relevant data in the European country where it is found. Data Transfers from Europe to the United States • When the EU questioned whether “adequate” legal protection for personal data potentially blocked all data transfers from Europe to the United States, the U.S. Department of Commerce responded by setting up a Safe Harbor framework imposing safeguards on the handling of personal data by certified individuals and entities.48 • In 2000, the EU approved the Safe Harbor framework as “adequate” legal protection for personal data, approval that binds all the member states to the Directive.49 • A Safe Harbor certification by the certified entity amounts to a representation to European regulators and individuals working in the EU that “adequate” privacy protection exists to permit the transfer of personal data to that U.S. entity.50 • Safe Harbor certification may nonetheless conflict with the onward transfer restrictions of member state legislation implemented under the Directive, as well as “blocking statutes,” such as the one in France that prohibits French companies and their employees, agents, or officers from disclosing to foreign litigants or public authorities information of an “economic, commercial, industrial, financial, or technical nature.”51

Workplace Data in Government or Criminal Inquiries

R Other formal and informal mechanisms to obtain overseas digital evidence may be useful in the context of an internal investigation, to comply with U.S. regulatory requirements, or when a victim company makes a criminal referral to law enforcement.

48

  The Safe Harbor framework is comprised of a collection of documents negotiated between the U.S. Department of Commerce and the EU, including 7 privacy principles http://export.gov/safeharbor/eu/eg_main_018475.asp and 15 FAQs http://export.gov/safeharbor/eu/eg_main_018493.asp. 49   See http://www.export.gov/static/SH_EU_Decision.pdf. 50   Over 1300 U.S. companies from over 100 industry sectors have registered and been ­certified under the Safe Harbor framework. See http://web.ita.doc.gov/safeharbor/SHList.nsf/WebPages/ Search+by+Industry+ Sector. 51   See, e.g., Law No. 80-538 of July 16, 1980, Journal Officiel de la Republique Francaise. The United Kingdom, Canada, Australia, Sweden, the Netherlands, and Japan have less restrictive blocking statutes as well.

Chapter | 4 Legal Considerations

u

u

u

225

Mutual Legal Assistance Request (MLAT) • Parties to a bilateral treaty that places an unambiguous obligation on each signatory to provide assistance in connection with criminal and in some instances regulatory matters may make requests between central authorities for the preservation and collection of computer media and digital evidence residing in their respective countries.52 • The requesting authority screens and forwards requests from its own local, state, or national law enforcement entities, and the receiving authority then has the ability to delegate execution of the request to one of its entities. • For foreign authorities seeking to gather evidence in the United States, the U.S. Department of Justice is the central authority, working through its Office of International Affairs. • The central authority at the receiving end of an MLAT request may be  very reluctant to exercise any discretion to comply. That being said, most central authorities are incentivized to fulfill MLAT requests so that similar accommodation will accompany requests in the other ­direction. Letter Rogatory • A less reliable, more time-consuming mechanism of the MLAT is the letter rogatory or “letter of request,” which is a formal request from a court in one country to “the appropriate judicial authorities” in another country requesting the production of relevant digital evidence.53 • The country receiving the request, however, has no obligation to assist. • The process can take a year or more. Informal Assistance • In addition to the widely known Council of Europe and G8, a ­number of international organizations are attempting to address the ­difficulties digital investigators face in conducting network ­investigations that so often involve the need to preserve and analyze overseas evidence. • Informal assistance and support through the following organizations may prove helpful in understanding a complicated international landscape: r Council of Europe Convention of Cybercrime http://conventions.coe.int/Treaty/Commun/QueVoulezVous .asp?NT=185&CM=1&CL=ENG (and more generally) http://www .coe.int/t/dc/files/themes/cybercrime/default_EN.asp? r G8 High-Tech Crime Subgroup (Data Preservation Checklists)

52   For a list of bilateral mutual legal assistance treaties in force, see http://travel.state.gov/law/ info/judicial/judicial_690.html. 53   The U.S. State Department offers guidance on the procedural requirements for a letter rogatory at http://travel.state.gov/law/judicial/judicial_683.html.

226

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

r

r

r

r

r

http://www.coe.int/t/dg1/legalcooperation/economiccrime/ cybercrime/Documents/Points%20of%20Contact/24%208%20 DataPreservationChecklists_en.pdf Interpol Information Technology Crime—Regional Working Parties http://www.interpol.int/public/TechnologyCrime/Default.asp European Network of Forensic Science Institutes (Memorandum signed for International Cooperation in Forensic Science) http://www.enfsi.eu/page.php?uid=1&nom=153 Asia-Pacific Economic Cooperation Electronic Commerce Steering Group http://www.apec.org/apec/apec_groups/committee_on_trade/­ electronic_commerce.html Organization for Economic Cooperation & Development Working Party on Information Security & Privacy (APEC-OECD Workshop on Malware—Summary Record—April 2007) http://www.oecd.org/dataoecd/37/60/38738890.pdf Organization of American States Inter-American Cooperation Portal on Cyber-Crime http://www.oas.org/juridico/english/cyber.htm

INVOLVING LAW ENFORCEMENT Whether a victim company chooses to do nothing, pursue civil remedies, or report an incident to law enforcement affects the scope and nature of the work of the digital investigator. Analysis of identified malware might become purely academic once the intrusion is contained and the network secured. Malware functionality might be the subject of written or oral testimony presented in a civil action when the victim company seeks to obtain monetary relief for the damage done. The possibility of criminal referral adjusts the investigative landscape as well. Understanding the process victim corporations go through to decide about whether and when to involve law enforcement will help realize relevant consequences for the digital investigator.

Victim Reluctance

R Victim companies are often reluctant to report incidents of computer

crime.54 • The threat of public attention and embarrassment, particularly to shareholders, often casts its cloud over management. 54   Magee, B. (2008). Firms Fear Stigma of Reporting Cybercrime. business.scotsman.com (April 13, 2008), available at http://business.scotsman.com/ebusiness/Firms-fear-stigma-ofreporting.3976469.jp.

Chapter | 4 Legal Considerations

227

• Nervous network administrators, fearful of losing their jobs, perceive • •

themselves as having failed to adequately protect and monitor relevant systems and instead focus on post-containment and prevention. Legal departments, having determined that little or no breach ­notification to corporate customers was required in the jurisdictions where the ­business operates, would rather not rock the boat. Audit committees and boards often would rather pay the cyber extortionist’s ransom demand in exchange for a “promise” to destroy the stolen sensitive data, however unlikely, and even when counseled otherwise, rather than involve law enforcement.

Victim Misperception

R Many companies misperceive that involving law enforcement is simply not worth it. • Victims are confused about which federal, state, or local agency to ­contact.  • Victims are concerned about law enforcement agent technical inexperience, agency inattention, delay, business interference, and damage to network equipment and data. • Victims fear the need to dedicate personnel resources to support the referral. • Victims exaggerate the unlikelihood that a hacker kid living in a foreign country will ever see the inside of a courtroom.

The Law Enforcement Perspective

R Cybercrime prosecution and enforcement have never been of higher priority among federal, state, and local government. • Because the present proliferation of computer fraud and abuse is unparalleled,55 domestic and foreign governments alike have invested significant resources in the development and training of technical officers, agents, and prosecutors to combat cybercrime in a nascent legal environment. • Law enforcement understands that internal and external digital investigators are the first line of defense and in the best positions to detect, initially investigate, and neatly package some of the best evidence necessary for law enforcement to successfully seek and obtain real deterrence in the form of jail time, fines, and restitution. 55   The “2007 Internet Crime Complaint Report,” available at www.ic3.gov/media/annualreports .aspx, suggests a $40 million year-end increase in reported losses from the 206,884 complaints of crimes perpetrated over the Internet reported to the FBI’s Internet Crime Complaint Center during 2007.

228

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• Evidence collected by internal and external digital investigators is only

•

enhanced by the legal process (grand jury subpoena, search warrants) and data preservation authority (pen registers, trap and traces, wiretaps) available to law enforcement and not available to any private party. International cooperation among law enforcement in the fight against cybercrime has never been better, as even juveniles are being hauled into federal court for their cyber misdeeds.56

Walking the Line

R Often the investigative goals of the victim company and law enforcement diverge, leaving the digital investigator at times in the middle. Stay out of it. • The victim company may be more interested in protecting its network or securing its information than, for example, avoiding containment to allow law enforcement to obtain necessary legal process to real-time monitor future network events caused by the intruder. • Despite misimpressions to the contrary, victim companies rarely lose control over the investigation once a referral is made; rather, law enforcement often requires early face time and continued cooperation with the administrators and investigators who are most intimate with and knowledgeable of the affected systems and relevant discovered data. Constant consultation is the norm. • Although law enforcement will be careful not to direct any future actions by the digital investigator, thereby creating the possibility that a future court deems and suppresses the investigator’s work as the work of the government conducted in violation of the heightened legal standards of process required of law enforcement, the digital investigator may be required to testify before a grand jury impaneled to determine if probable cause that a crime was committed exists, or even to testify before a trial jury on returned and filed charges. • Remember the scope and limitations of authority that apply, and let the victim company and law enforcement reach a resolution that is mutually beneficial. • Staying apprised of the direction of the investigation, whether it stays private, becomes public, or proceeds on parallel tracks (an option less favored by law enforcement once involved), will help the digital investigator focus on what matters most—repeatable, reliable, and admissible findings under any circumstance. 56

  See United States Attorney’s Office for the Central District of California, Press Release No. 08-013, February 11, 2008, “Young ‘Botherder’ Pleads Guilty to Infecting Military Computers and Fraudulently Installing Adware,” available at http://www.usdoj.gov/usao/cac/ pressroom/pr2008/013.html. For added color, see Goodin, D. (2008). “I Was A Teenage Bot Master: The Confessions of SoBe Owns,” The Register (May 8, 2008), available at http://www .theregister.co.uk/2008/05/08/downfall_of_botnet_master_sobe_owns/.

Chapter | 4 Legal Considerations

229

IMPROVING CHANCES FOR ADMISSIBILITY Thorough and meticulous recordkeeping, an impeccably supportable and uninterrupted chain of custody, and a fundamental understanding of basic notions governing the reliability and integrity of evidence will secure best consideration of the work of the digital investigator in any context, in any forum, before any audience. Urgency tied to pulling off a quick, efficient response to an emerging attack often makes seem less important at the outset of any investigation the implementation of these guiding principles. However, waiting until the attack is under control and until the potentially exposed systems are secured often makes it too difficult to recreate events from memory with the same assurance of integrity and reliability as an ongoing written record of every step taken.

Documentation

R Concerns that recordkeeping creates potentially discoverable work product, impeachment material, or preliminary statements that may prove inconsistent with ultimate findings are far outweighed by the future utility to be in the best position to well evidence the objectivity, completeness, reasonableness of those opinions. • Document in sufficient technical detail each early effort to identify and confirm the nature and scope of the incident. • Keep, for example, a list of the specific systems affected, the users logged on, the number of live connections, and the processes running. • Note when, how, and the substance of observations made about the ­origin of attack; the number of files or logs that were created, deleted, last accessed, modified, or written to; user accounts or permissions that have been added or altered; machines to which data may have been sent; and the identity of other potential victims. • Record observations about the lack of evidence—ones that may be ­inconsistent with what was expected to be found based on similar ­incident handling experiences. • Keep a record of the methodology employed to avoid altering, deleting, or modifying existing data on the network. • Track measures taken to block harmful access to, or stop continuing ­damage on the affected network, including filtered or isolated areas. • Remember early on to begin identifying and recording the extent of ­damage to systems and the remediative costs incurred—running notations that will make future recovery from responsible parties and for any subsequent criminal investigation that much easier.

Preservation

R Careful preservation of digital evidence further promotes repeatable, defensible, and reliable findings.

230

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• At the outset, create forensically sound redundant hashed images of original

• • • • •

•

media, store one with the original evidence, and use the remaining image as a working copy for analysis. Do not simply logically copy data, even server level data, when avoidable. Immediately preserve backup files and relevant logs. When preserving data, hash, hash, hash. Hash early to correct potentially flawed evidence handling later. During analysis, hash to find or exclude from examination known files. Consider using Camatasia or other screen capture software to preserve live observations of illicit activity before containment. This is a way to supplement evidence obtained from enabled and extended network logging. If legal counsel has approved the use of a “sniffer” or other monitoring device to record communications between the intruder and any server that is under attack, be careful to preserve and document relevant information about those recordings. The key is to use available forensic tools to enhance the integrity, reliability, and repeatability of the work.

Chain of Custody

R Meticulous chain of custody practices can make or break the success of a digital forensic investigation. • Although chain of custody goes to the weight not the admissibility of the ­evidence in most court proceedings, the concept remains nonetheless ­crucial, particularly where evidence may be presented before grand juries, arbitrators, or in similar alternative settings where evidentiary rules are relaxed, and as such, inexplicable interruptions in the chain may leave the evidence more susceptible to simply being overlooked or ignored. • The ability to establish that data and the investigative records ­generated ­during the process are free from contamination, misidentification, or alteration between the time collected or generated and when offered as evidence goes not just to the integrity of evidence but its very ­relevance— no one will care about an item that cannot be established as being what it is characterized to be, or a record that cannot be placed in time or ­attributed to some specific action.  • For data, the chain of custody form need not be a treatise; simply record unique identifying information about the item (serial number), note the date and description of each action taken with respect to the item (placed in storage, removed from storage, mounted for examination, returned to storage), and identify the actor at each step (presumably a limited universe of those with access). • A single actor responsible for generated records and armed with a proper chain of custody form for data can lay sufficient evidentiary foundation without having to present every actor in the chain before the finder of fact.

231

Chapter | 4 Legal Considerations

 STATE PRIVATE INVESTIGATOR AND BREACH ­NOTIFICATION STATUTES State

PI Licensing Statute

State Breach Notification Statute

Alabama

N/A

N/A

Alaska

N/A

ALASKA STAT. § 45.48.010

Arizona

ARIZ. REV. STAT. § 32-2401

ARIZ. REV. STAT. § 44-7501

Arkansas

ARK. CODE § 17-40-350

ARK. CODE §§ 4-110-103-108

California

CAL. BUS. & PROF. CODE § 7520

CAL. CIV. CODE §§ 1798.82

Colorado

N/A

COLO. REV. STAT. § 6-1-716

Connecticut

CONN. GEN. STAT. § 29-154

CONN. GEN. STAT. § 36a-701b

Delaware

24 DEL. C. § 1303

6 DEL. C. § 12B-101

District of Columbia 17 DCMR § 2000.7

D.C. CODE § 28-3851–§28-3853

Florida

FLA. STAT. § 493.6100

FLA. STAT. § 817.5681

Georgia

GA. CODE § 43-38-6

GA. CODE § 10-1-912

Hawaii

HRS § 463-5

HRS § 487N-2

Idaho

N/A

I.C. § 28-51-105

Illinois

225 ILCS § 447/10-5

815 ILCS § 530/10

Indiana

IC § 25-30-1-3

IC § 24-4.9-3-1

Iowa

I.C.A § 80A.3

I.C.A. § 715C.2

Kansas

K.S.A. § 75-7b02

K.S.A. § 50-7a02

Kentucky

KRS § 329A.015

N/A

Louisiana

LSA-R.S. § 37:3501

LSA-R.S. § 51.3074

Maine

32 M.R.S.A § 8104

10 M.R.S.A § 1348

Maryland

MD BUS OCCUP & PROF § 13-301

MD COML §14-3504

Massachusetts

M.G.L.A. 147 § 23

M.G.L.A 93H § 3

Michigan

M.C.L.A § 338.823

M.C.L.A § 445.72

Minnesota

M.S.A. § 326.3381

M.S.A. § 325E.61

Mississippi

N/A

MS ST § 75-24-29 (Continued)

232

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

State

PI Licensing Statute

State Breach Notification Statute

Missouri

MO ST § 324.1104

MO ST § 407.1500

Montana

MCA § 37-60-301

MCA § 30-14-1704

Nebraska

NEB. REV. STAT. § 71-3202

NEB. REV. STAT. §§ 87-801

Nevada

NEV. REV. STAT. § 648.060

NEV. REV. STAT. § 603A.220

New Hampshire

N.H. REV. STAT. § 106-F:5

N.H. REV. STAT. § 359-C:19

New Jersey

N.J. STAT. § 45:19-10

N.J. STAT. § 56:8-163

New Mexico

16.48.1.10 NMAC

N/A

New York

N.Y. GEN. BUS. LAW § 70.2

N.Y. GEN. BUS. LAW § 899-aa

North Carolina

N.C. GEN. STAT. § 74C-2

N.C. GEN. STAT. § 75-65

North Dakota

N.D. ADMIN. R. 93-02-01

N.D. CENT. CODE §§ 51-30-01 et seq

Ohio

OHIO REV. CODE § 4749.13

OHIO REV. CODE § 1349.19

Oklahoma

59 OKLA. STAT. § 1750.4

74 OKLA. STAT. § 3113.1

Oregon

OR. REV. STAT. § 703.405

OR. REV. STAT. §§ 646A.600, 646A.602, 646A.604, 646A.624, and 646A.626

Pennsylvania

22 PA. STAT. § 13

73 PA. STAT. §§ 2301–2308, 2329

Rhode Island

R.I. GEN. LAWS § 5-5-21

R.I. GEN. LAWS §§ 11-49.2-1–1149.2-7

South Carolina

S.C. CODE § 40-18-70

S.C. CODE § 39-1-90

South Dakota

N/A

N/A

Tennessee

62 TENN. CODE § 117504-.06 (2)

TENN. CODE § 47-18-2107

Texas

TEX. OCC. CODE §1702.101

TEX. BUS. & COM. CODE § 521.053

Utah

UTAH CODE §§ 53-9-107 2 (a) (i) and (ii)

UTAH CODE §§ 13-44-101, 13-44201, 13-44-202, and 13-44-301

Vermont

26 V.S.A. § 3179

9 V.S.A. § 2430 and 9 V.S.A. § 2435

Virginia

VA CODE § 9.1-139 C

VA CODE § 18.2-186.6

Washington

WASH. REV. CODE § 18.165.150

WASH. REV. CODE § 19.255.010

233

Chapter | 4 Legal Considerations

State

PI Licensing Statute

State Breach Notification Statute

West Virginia

W. VA. CODE § 30-18-8

W. VA. CODE § 46A-2A-101–105

Wisconsin

WIS. RL § 31.01 (2)

WIS. STAT. § 134.98

Wyoming

Regulated by local jurisdictions

WYO. STAT. §§ 40-12-501 and 40-12-502

 INTERNATIONAL RESOURCES Cross-Border Investigations Treaties in Force: A List of Treaties and Other International Agreements of the United States in Force http://www.state.gov/documents/organization/89668.pdf Preparation of Letters Rogatory http://travel.state.gov/law/judicial/judicial_683.html Organization of American States Inter-American Cooperation Portal on Cyber-Crime http://www.oas.org/juridico/english/cyber.htm Council of Europe Convention of Cybercrime http://conventions.coe.int/Treaty/Commun/QueVoulezVous.asp?NT=185& CM=1&CL=ENG (and more generally) http://www.coe.int/t/dc/files/themes/ cybercrime/default_EN.asp? European Commission 2010 Directive On Attacks Against Information Systems http://ec.europa.eu/home-affairs/policies/crime/1_EN_ACT_part1_ v101.pdf European Network of Forensic Science Institutes (Memorandum signed for International Cooperation in Forensic Science) http://www.enfsi.eu/page.php?uid=1&nom=153 G8 High-Tech Crime Subgroup (Data Preservation Checklists) http://www.coe.int/t/dg1/legalcooperation/economiccrime/cybercrime/ Documents/Points%20of%20Contact/24%208%20DataPreservation Checklists_en.pdf Interpol Information Technology Crime—Regional Working Parties http://www.interpol.int/public/TechnologyCrime/Default.asp Asia-Pacific Economic Cooperation Electronic Commerce Steering Group http://www.apec.org/Groups/Committee-on-Trade-and-Investment/ Electronic-Commerce-Steering-Group.aspx

234

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Organization for Economic Cooperation & Development Working Party on Information Security & Privacy (APEC-OECD Workshop on Malware—Summary Record—April 2007) http://www.oecd.org/dataoecd/37/60/38738890.pdf The Organisation for Economic Co-operation and Development (OECD) Guidelines on the Protection of Privacy and Transborder Flows of Personal Data http://www.oecd.org/document/18/0,3746,en_2649_34255_1815186_ 1_1_1_1,00.html The International Cyber Security Protection Alliance (ICSPA) CyberSecurity News Feed https://www.icspa.org/nc/media/cyber-security-news-feed/ Maurushat, A. (2010). Australia’s Accession to the Cybercrime Convention: Is the Convention Still Relevant in Combating Cybercrime in the Era of Botnets and Obfuscation Crime Tools?, University of New South Wales Law Journal, Vol. 33(2), pp. 431–473. Available at http://www.austlii.edu.au/au/journals/UNSWLRS/2011/20.txt/ cgi-bin/download.cgi/download/au/journals/UNSWLRS/2011/20.rtf.

THE FEDERAL RULES: EVIDENCE FOR DIGITAL ­INVESTIGATORS Relevance All relevant evidence is admissible. “Relevant evidence” means evidence having any tendency to make the existence of any fact that is of consequence to the determination of the action more probable or less probable than it would be without the evidence. Although relevant, evidence may be excluded if its probative value is substantially outweighed by the danger of unfair prejudice, confusion of the issues, misleading the jury, or by considerations of undue delay, waste of time, or ­needless presentation of cumulative evidence.

Authentication The requirement of authentication or identification as a condition precedent to admissibility is satisfied by evidence sufficient to support a finding that the matter in question is what its proponent claims.

Best Evidence A duplicate is admissible to the same extent as an original unless (1) a genuine question is raised as to the authenticity of the original or (2) in the circumstances it would be unfair to admit the duplicate in lieu of the original.

Chapter | 4 Legal Considerations

235

Expert Testimony If scientific, technical, or other specialized knowledge will assist the trier of fact to understand the evidence or to determine a fact in issue, a witness qualified as an expert by knowledge, skill, experience, training, or education may testify thereto in the form of an opinion or otherwise, if (1) the testimony is based upon sufficient facts or data, (2) the testimony is the product of reliable principles and methods, and (3) the witness has applied the principles and methods reliably to the facts of the case. The expert may testify in terms of opinion or inference and give reasons therefore without first testifying to the underlying facts or data, unless the court requires otherwise. The expert may in any event be required to disclose the underlying facts or data on cross-examination.

Limitations on Waiver of the Attorney—Client Privilege Disclosure of attorney—client privilege or work product does not operate as a waiver in a Federal or State proceeding if the: 1. Disclosure is inadvertent; 2. Holder of the privilege or protection took reasonable steps to prevent ­disclosure; and 3. Holder promptly took reasonable steps to rectify the error.

Chapter 5

File Identification and Profiling Initial Analysis of a Suspect File on a Windows System Solutions in this chapter: • Overview of the File Profiling Process • Profiling a Suspicious File • File Similarity Indexing • File Visualization • File Signature Identification and Classification • Embedded Artifact Extraction • Symbolic and Debug Information • Embedded File Metadata • File Obfuscation: Packing and Encryption Identification • Embedded Artifact Extraction Revisited • Profiling Suspect Document Files • Profiling Suspect Portable Document Format (PDF) Files • Profiling Suspect Microsoft (MS) Office Files • Profiling Suspect Compiled HTML Help Files

INTRODUCTION This chapter addresses the methodology, techniques, and tools for ­conducting an initial analysis of a suspect file. Some of the techniques ­covered in this and other chapters may constitute “reverse engineering” and thus fall within the proscriptions of certain international, federal, state, or local laws. Similarly, some of the referenced tools are considered ­“hacking tools” in some jurisdictions, and are subject to similar legal ­regulation or use restriction. Some of these legal limitations are set forth in Chapter 4. In addition to careful review of these considerations, ­consultation with ­appropriate legal counsel prior to implementing any of the techniques and tools discussed in these and subsequent chapters is strongly advised and encouraged.

Malware Forensics Field Guide for Windows Systems. DOI: 10.1016/B978-1-59-749472-4.00005-6 © 2012 Malin. All rights reserved.

237

238

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

N Analysis Tip Safety First

Forensic analysis of a potentially dangerous file specimen requires a safe and secure lab environment. After extracting a suspicious file from a system, place the file on an isolated or “sandboxed” system or network to ensure that the code is contained and unable to connect to, or otherwise affect, any production system. Even though only a cursory static analysis of the code is contemplated at this point of the investigation, executable files nonetheless can be accidentally executed fairly easily, potentially resulting in the contamination of, or damage to, production systems.

OVERVIEW OF THE FILE PROFILING PROCESS

R File profiling is essentially malware analysis reconnaissance, an effort necessary to gain enough information about the file specimen to render an informed and intelligent decision about what the file is, how it should be categorized or analyzed, and, in turn, how to proceed with the larger investigation. Take detailed notes during the process, not only about the suspicious file but also about each investigative step taken. u A suspicious file may be fairly characterized as: • Of unknown origin • Unfamiliar • Seemingly familiar, but located in an unusual place on the system • Unusually named and located in an unusual folder on the system (e.g., C:Documents and Settings[USER]TEMPaxx.exe) • Similarly named to a known or familiar file, but misspelled or otherwise slightly varied (a technique known as file camouflaging) • File contents are hidden by obfuscation code • Determined during the course of a system investigation to conduct ­network connectivity or an other anomalous activity u After extracting the suspicious file from the system, determining its ­purpose and functionality is often a good starting place. This process, called file ­profiling, should answer the following questions: • What type of file is it? • What is the intended purpose of the file? • What is the functionality and capability of the file? • What does the file suggest about the sophistication level of the attacker? • What is the target of the file—is it customized to the victim system/­ network or a general attack? • What affect does this file have on the system? • What is the extent of the infection or compromise on the system or ­network? • What remediation steps are necessary because the file exists on the system?

Chapter | 5 File Identification and Profiling

239

The file profiling process entails an initial or cursory static analysis of the suspect code (Figure 5.1). Static analysis is the process of analyzing executable binary code without actually executing the file. A general approach to file ­profiling involves the following steps: • Detail: Identify and document system details pertaining to the system from which the suspect file was obtained. • Hash: Obtain a cryptographic hash value or “digital fingerprint” of the suspect file. • Compare: Conduct file similarity indexing of the file against known samples. • Classify: Identify and classify the type of file (including the file format and the target architecture/platform), the high-level language used to author the code, and the compiler used to compile it. • Visualize: Examine and compare suspect files in graphical representation, revealing visual distribution of the file contents. • Scan: Scan the suspect file with anti-virus and anti-spyware software to determine if the file has a known malicious code signature. • Examine: Examine the file with executable file analysis tools to ascertain whether the file has malware properties. • Extract and Analyze: Conduct entity extraction and analysis on the suspect file by reviewing any embedded American Standard Code for Information Interchange (ASCII) or Unicode strings contained within the file, and by identifying and reviewing any file metadata and symbolic information. u

FIGURE 5.1–The file profiling process

240

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• Reveal: Identify any code obfuscation or armoring techniques protecting the file from examination, including packers, wrappers, or encryption.

• Correlate: Determine whether the file is dynamically or statically linked, and identify whether the file has dependencies.

• Research: Conduct online research relating to the information you gath-

p

ered from the suspect file and determine whether the file has already been identified and analyzed by security consultants, or conversely, whether the file information is referenced on hacker or other nefarious Web sites, forums, or blogs. Although all of these steps are valuable ways to learn more about the suspect file, they may be executed in varying order or in modified form, depending upon the preexisting information or circumstances surrounding the code. • Be thorough and flexible. • Familiarity with a wide variety of both command-line interface (CLI) and Graphical User Interface (GUI) tools will further broaden the scope of investigative options. • Familiarity and comfort with a particular tool, or the extent to which the reliability or efficacy of a tool is perceived as superior, often dictate whether the tool is incorporated into any given investigative arsenal. • Further tool discussion and comparison can be found in the Tool Box section at the end of this chapter. @

Profiling a Suspicious File

R This section presumes a basic understanding of how Windows Portable Executable (PE) files are compiled. A detailed discussion of this process can be found in the Introductory Chapter.

p

System Details If the suspicious file was extracted or copied from a victim system, be certain to document the details obtained through the live response techniques mentioned in Chapter 1, including information about: • The system’s operating system, version, service pack, and patch level • The file system • The full system path where the file resided prior to discovery • Associated file system metadata, such as created, modified, and accessed dates/times • Details pertaining to any security software, including personal firewall, anti-virus, or anti-spyware programs Collectively, this information provides necessary file context, as malware often manifests differently depending on the permutations of the operating system and patch and software installation.

p

Chapter | 5 File Identification and Profiling

241

File Name R Acquire and document the full file name u Identifying and documenting the suspicious file name is a foundational step in file profiling. The file name, along with the respective file hash value, will be the main identifier for the file specimen. • Be mindful to disable the Windows Folder View Option “Hide extensions for known file types” on your analysis system so that the file extension associated with the file is visible and can be documented. • Attackers often try to conceal their malicious programs by using pseudo file extensions in an effort to trick victims into executing the malicious program. • Miss Identify (missidentify.exe)1 is a utility for finding Win32 executable programs, regardless of file extension, allowing the digital investigator to detect misnamed executable files or hidden extensions. • In Figure 5.2, Miss Identify is used to reveal two executable files that appear to be image files as a result of hidden file extensions and icons embedded into the PE Resources (discussed later in this chapter and in Chapter 6).

C:Documents and SettingsMalware Lab>missidentify.exe -ar c:Documents and SettingsMalware Labsuspicious-files c:Documents and SettingsMalware Labsuspicious-filesnowayyyy.jpg.exe c:Documents and SettingsMalware Labsuspicious-files uncensored pic.exe

FIGURE 5.2–Using Miss Identify to uncover misnamed executable files

Investigative Considerations • Although the full file path in which a suspect file was discovered on the victim system is not a part of the file name per se, it is a valuable detail that can provide further depth and context to a file profile. The full file path should be noted during live response and post-mortem forensic analysis, as discussed in Chapters 1 and 3, respectively. 1

For more information about Miss Identify, go to http://missidentify.sourceforge.net/.

242

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

File Size R Acquire and document the specimen’s file size u File size is a unique file variable that should be identified and noted for each suspect file. • Although file size in no way can predict the contents or functionality of a file specimen, it can be used as a gauge as to determine payload. For instance, a malware specimen that contains its own SMTP engine or server function will likely be larger than other specimens that are modular and will likely connect to a remote server to download additional files. File Appearance R Note or screenshot a suspect file’s appearance as an identifier for your report and catalog it for reference with other samples. u Attackers often manipulate the icon associated with a file to give a malicious file a harmless and recognizable appearance, tricking users into executing the file. • Documenting the file appearance is useful for reports and for comparison and correlation with other malware samples. • An intuitive and flexible tool to assist in obtaining screen captures of files is MWSnap (Figure 5.3).2

FIGURE 5.3–MWSnap capturing the appearance of a suspicious file

Hash Values R Generate a cryptographic hash value for the suspect file to both serve as a unique identifier or digital “fingerprint” for the file throughout the course of analysis, and to share with other digital investigators who already may have encountered and analyzed the same specimen. u The Message-Digest 5 (MD5)3 algorithm generates a 128-bit hash value based upon the file contents and typically is expressed in 32 hexadecimal ­characters. 2

  For more information about MWSnap, go to http://www.mirekw.com/winfreeware/mwsnap.html.   For more information on the MD5 algorithm, go to http://www.faqs.org/rfcs/rfc1321.html.

3

Chapter | 5 File Identification and Profiling

243

• MD5 is widely considered the de facto standard for generating hash values for malicious executable identification.

• Other algorithms, such as Secure Hash Algorithm Version 1.0 (SHA1)4 can be used for the same purpose. Investigative Considerations • Generating an MD5 hash of the malware specimen is particularly helpful for subsequent dynamic analysis of the code. Whether the file copies itself to a new location, extracts files from the original file, updates itself from a remote Web site, or simply camouflages itself through renaming, comparison of MD5 values for each sample will enable determination of whether the samples are the same or new specimens that require independent analysis.

Command-Line Interface MD5 Tools CLI hashing tools provide a simple and effective way to collect hash values from suspicious files, the results of which can be saved to a log file for later analysis. • md5deep is a powerful MD5 hashing and analysis tool suite written by Jesse Kornblum that gives the user granular control over the hashing options, including piecewise and recursive modes (Figure 5.4).5

u

C:Documents and SettingsMalware Lab>md5deep.exe C:Documents and SettingsMalware LabMalwareVideo.exe ff67ed53eb836022dcfb3df4a717ca94 C:Documents and SettingsMalware LabMalwareVideo.exe

FIGURE 5.4–Hashing a suspicious file with md5deep

• In addition to the MD5 algorithm, the md5deep suite provides for alternative algorithms by providing additional utilities such as sha1deep, tigerdeep, sha256deep, and whirlpooldeep, all of which come included in the md5deep suite download. @

GUI MD5 Tools Despite the power and flexibility offered by these CLI MD5 tools, many digital investigators prefer to use GUI-based tools during analysis, because they provide drag-and-drop functionality and easy-to-read output. Similarly,

u

4 5

For more information on the SHA1 algorithm, go to http://www.faqs.org/rfcs/rfc3174.html. For more information about md5deep, go to http://md5deep.sourceforge.net.

244

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

tools that enable a Windows Explorer shell extension, or “right-click” hashing, ­provide a simple and efficient way to generate hash values during analysis. A useful utility that offers a variety of scanning options to acquire both MD5 and SHA1 hash values for suspect files is Nirsoft’s HashMyFiles,6 depicted in Figure 5.5. @

FIGURE 5.5–Using HashMyFiles to recursively scan a directory for hash values

 Other Tools to Consider CLI Hashing Tools

Microsoft File Checksum Integrity Verifier (FCIV)—http://www.microsoft.com/ downloads/en/details.aspx?FamilyID=B3C93558-31B7-47E2-A663-7365C 1686C08&displaylang=en GNU Core Utilities—http://gnuwin32.sourceforge.net/packages/coreutils.htm GUI Hashing Tools

Hash Quick—http://www.lindseysystems.com/contact.php WinMD5—http://www.blisstonia.com/software/WinMD5/ MD5Summer—http://www.md5summer.org/ HashonClick—http://www.2brightsparks.com/onclick/hoc.html Graphical MD5sum—http://www.toast442.org/md5/ Malcode Analyst Pack—http://labs.idefense.com/software/malcode.php#more_ malcode+analysis+pack Visual MD5—http://www.tucows.com/preview/505450 (previously available from http://www.protect-folder.com/) SSDeepFE—http://sourceforge.net/project/showfiles.php?group_id=215906& package_id=267714 Further tool discussion and comparison can be found in the Tool Box section at the end of this chapter and on the companion Web site, http://www.malwarefieldguide .com/Chapter5.html.

6

  For more information about HashMyFiles, go to http://www.nirsoft.net/utils/hash_my_files.html.

Chapter | 5 File Identification and Profiling

245

FILE SIMILARITY INDEXING

R Comparing the suspect file to other malware specimens collected or maintained in a private or public repository is an important part of the file identification process. u An effective way to compare files for similarity is through a process known as fuzzy hashing or Context Triggered Piecewise Hashing (CTPH), which computes a series of randomly sized checksums for a file, allowing file association between files that are similar in file content but not identical. • Use ssdeep,7 a file hashing tool that utilizes CTPH to identify homologous files, to query suspicious file specimens. @ • Ssdeep can be used to generate a unique hash value for a file, or ­compare an unknown file against a known file or list of file hashes. • In the vast arsenal of ssdeep’s file comparison modes exists a “pretty matching mode,” wherein a file is compared against another file and scored based upon similarity (a score of 100 constituting an identical match). • In Figure 5.6, a file that has been changed by one byte and saved to a new file is scanned in conjunction with the original file with ssdeep in “pretty matching mode.” Although the one byte modification changes the MD5 hash values of the respective files, ssdeep detects the files as nearly ­identical. • Through these and other similar tools employing the CTPH functionality, valuable information about a suspect file may be gathered during the file identification process to associate the suspect file with a particular specimen of malware, a “family” of code, or a particular attack or set of attacks. Further discussion regarding malware “families,” or phylogeny, can be found in Chapter 6.

¿ Online Resources Hash Repositories

Online hash repositories serve as a valuable resource for querying hash values of suspect files. The hash values and associated files maintained by the operators of these resources are acquired through a variety of sources and methods, including online file submission portals. Keep in mind that by submitting a file or a search term to a third-party Web site, you are no longer in control of that file or the data associated with that file. Team Cymru Malware Hash Registry—http://www.team-cymru.org/Services/MHR/ Zeus Tracker—https://zeustracker.abuse.ch/monitor.php viCheck.ca Malware Hash Query—https://www.vicheck.ca/md5query.php VirusTotal Hash Search—http://www.virustotal.com/search.html

7

  For more information about ssdeep, go to http://ssdeep.sourceforge.net.

246

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

C:Documents and SettingsMalware Lab>ssdeep -pb Video.exe Copy of Video.exe Video.exe matches Copy of Video.exe (99) Copy of Video.exe matches Video.exe (99)

FIGURE 5.6–ssdeep “pretty matching mode”

FILE VISUALIZATION

R Visualize file data in an effort to identify potential anomalies and to quickly correlate like files. Visualizing file data, particularly through byte-usage-histograms, provides the digital investigator with a quick reference about the data distribution in a file. • Inspect suspect files with bytehist, a GUI-based tool for generating byte-usage-histograms.8 • Bytehist makes histograms for all file types, but is geared toward PE files, in that it makes separate sub-histograms for each section of the executable file. • Histogram visualization of executables can assist in identifying file obfuscation techniques such as packers and cryptors (discussed in the “File Obfuscation: Packing and Encryption Identification” section later in this chapter). • Byte distribution in files concealed with additional obfuscation code or with encrypted content will typically manifest visually distinguishable from unobfuscated versions of the same file, as shown in Figure 5.7, below, which displays histogram visualization of the same file in both a packed and unpacked condition with bytehist. • Comparing histogram patterns of multiple suspect files can also be used as a quick triage method to identify potential like files based upon visualization of data distribution. • To further examine a suspicious binary file through multiple visualization schemes, probe the file with BinVis, a framework for visualizing binary file structures.9 BinVis is discussed in greater detail in Chapter 6. @ u

FIGURE 5.7–Visualizing files with bytehist 8 For more information about bytehist, go to http://www.cert.at/downloads/software/ bytehist_en.html. 9 For more information about BinVis, go to http://code.google.com/p/binvis/.

Chapter | 5 File Identification and Profiling

247

File Signature Identification and Classification

R After gathering system details, acquiring a digital fingerprint, and conducting a file index similarity inquiry, additional profiling to identify and classify the suspect file will prove an important part of any preliminary static analysis. u This step in the file identification process often produces a clearer idea about the nature and purpose of the malware, and in turn, the type of damage the attack was intended to cause the victim system. • Identifying the file type is determining the nature of the file from its file format or signature based upon available data contained within the file. • File type analysis, coupled with file classification, or a determination of the native operating system and the architecture for which the code was intended, are fundamental aspects of malware analysis that often dictate how and the direction in which your analytical and investigative methodology will unfold.

File Types The suspect file’s extension cannot serve as the sole indicator of its contents; instead examination of the file’s signature is paramount. • A file signature is a unique sequence of identifying bytes written to a file’s header. On a Windows system, a file signature is normally contained within the first 20 bytes of the file. • Different file types have different file signatures; for example, a Windows Bitmap image file (.bmp extension) begins with the hexadecimal characters 42 4D in the first two bytes of the file, characters that translate to the letters “BM.” • Most Windows-based malware specimens are executable files, often ending in the extensions .exe, .dll, .com, .pif, .drv, .qtx, .qts, .ocx, or .sys. The file signature for these files is “MZ” or the hexadecimal characters 4D 5A, found in the first two bytes of the file. • Generally, there are two ways to identify a file’s signature. r First, query the file with a file identification tool. r Second, open and inspect the file in a hexadecimal viewer or editor. Hexidecimal (or hex, as it is commonly referred) is a numeral system with a base of 16, written with the letters A–F and numbers 0–9 to represent the decimal values 0–15. In computing, hexadecimal is used to represent a byte as 2 hexadecimal characters (one character for each 4-bit nibble), translating binary code into a more humanreadable format. • By viewing a file in a hex editor, every byte of the file is visible, assuming its contents are not obfuscated by packing, encryption, or compression. u

248

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• MiniDumper by Marco Pontello10 is a convenient tool for examining a file in hexadecimal format, as it displays a dump of the file header only, as illustrated in Figure 5.8.

FIGURE 5.8–Examining a file header in MiniDumper

• Other hexadecimal viewers for Windows provide additional functionality to achieve a more granular analysis of a file, including strings identification, hash value computation, multiple file comparison, and ­templates for parsing the structures of specific file types. @

 Other Tools to Consider Hex Editors

RevEnge—http://www.sandersonforensics.com/content.asp?page=325 010 Editor—http://www.sweetscape.com/010editor/ McAffee FileInsight—http://www.mcafee.com/us/downloads/free-tools/­fileinsight .aspx Hex Workshop Hex Editor—http://www.hexworkshop.com/ FlexHex—http://www.flexhex.com/ WinHex—http://www.x-ways.net/winhex/index-m.html HHD Hex Editor Neo—http://www.hhdsoftware.com/free-hex-editor Further discussion and comparison of hex editors can be found in the Tool Box section at the end of this chapter, and on the companion Web site, http://www .malwarefieldguide.com/Chapter5.html.

File Signature Identification and Classification Tools u Unlike distributions of the Linux operating system that come with the utility file preinstalled (which classifies a queried file specimen based on the data

contained in the file as compared against a comprehensive list—or, magic file of known file headers), Microsoft Windows operating systems have no ­inherent 10

  For more information about MiniDumper, go to http://mark0.net/soft-minidumper-e.html.

Chapter | 5 File Identification and Profiling

249

equivalent command. Despite this apparent void in this genre of analytical tools, there are a number of CLI and GUI tools that have been developed to address file identification and analysis for Windows systems.

CLI File Identification Tools • Perhaps the closest tool to the Linux version of file is File Identifier (version 0.6.1), developed by Optima SC.11 Similar to file, File Identifier compares a queried file against a magic-like database file.12 @ • In addition to conducting file identification through signature matching, File Identifier also extracts file metadata, as illustrated in Figure 5.9. C:Documents and SettingsMalware Lab>file c:MalwareVideo.exe File identify [Freeware] Version 0.6.2 Copyright (c) Optima SC Inc. 20022009 Video.exe

[exe] Windows NT portable executable file, w/Symbol info

1/1 files identified 100.00 % found. 0 seconds

FIGURE 5.9–Scanning a suspect file with File Identifier

• In addition to providing a variety of different file scanning modes, including

•

•

11

a recursive mode for applying the tool against directories and subdirectories of files, File Identifier also offers Hypertext Markup Language (HTML) and CVS report generation. As an alternative, TrID, a CLI file identifier written by Marco Pontello,13 does not limit the classification of an unknown file to one possible file type based on the file’s signature, unlike other tools. Rather, it compares the unknown file against a file signature database and provides a series of possible results, ranked by order or probability, as depicted in the analysis of the suspect file in Figure 5.10. The TrID file database consists of approximately 4,000 different file signatures,14 and is constantly expanding, due in part to Pontello’s distribution of TrIDScan, a TrID counterpart tool that offers the ability to easily create new file signatures that can be incorporated into the TrID file signature database.15

For more information about the File Identifier tool, go to http://www.optimasc.com/products/ fileid/index.html. 12 For more information about the Optima SC magic file, go to http://www.optimasc.com/products/ fileid/magic-format.pdf and www.magicdb.org. 13 For more information about TrID, go to http://mark0.net/soft-trid-e.html. 14 For a list of the file signatures and definitions, go to http://mark0.net/soft-trid-deflist.html. 15 For more information about TrIdScan, go to http://mark0.net/soft-tridscan-e.html.

250

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

C:Documents and SettingsMalware Lab>trid c:MalwareVideo.exe TrID/32 — File Identifier v2.02 — (C) 2003-06 By M.Pontello Definitions found:

4063

Analyzing… Collecting data from file: c:MalwareVideo.exe 90.1% 5.7% 1.3% 1.3% 1.3%

(.EXE) (.EXE) (.EXE) (.EXE) (.EXE)

ASPack compressed Win32 Executable (generic) (133819/79/30) Win32 Executable Generic (8527/13/3) Win16/32 Executable Delphi generic (2072/23) Generic Win/DOS Executable (2002/3) DOS Executable Generic (2000/1)

FIGURE 5.10–Scanning a suspect file with TrID

GUI File Identification Tools • There are a number of GUI-based file identification and classification programs for use in the Windows environment; many are intuitive to use and convenient for an initial static analysis of any suspect file. @ • TrIDNet,16 a GUI version of TrID, provides for quick and convenient drag-and-drop functionality and an intuitive interface, as shown in Figure 5.11.

FIGURE 5.11–A suspect file classified with TrIDNet

16

For more information about TrIDNet, go to http://mark0.net/soft-tridnet-e.html.

Chapter | 5 File Identification and Profiling

251

• Like the CLI version, TrIDNet compares the suspect file against a file database of nearly 4,000 file signatures, scores the queried file based upon its characteristics, and reveals a probability-based identification of the file.

 Other Tools to Consider CLI File Identification Tools

Exetype—http://www.microsoft.com/resources/documentation/windowsnt/4/ server/reskit/en-us/reskt4u4/rku4list.mspx?mfr=true FileType—http://gnuwin32.sourceforge.net/packages/filetype.htm Infoexe v. 1.32—http://www.exetools.com/file-analyzers.htm Peace v. 1.00—http://www.exetools.com/file-analyzers.htm Fileinfo v. 2.43—http://www.exetools.com/file-analyzers.htm GUI File Identification Tools

Digital Record Object Identifier (DROID)—http://droid.sourceforge.net/ FileAlyzer—http://www.safer-networking.org/en/filealyzer/index.html WhatFile—http://www.sinnercomputing.com/dl.php?prog=WhatFile Further tool discussion and comparison can be found in the Tool Box section at the end of this chapter and on the companion Web site, http://www.malwarefieldguide .com/Chapter5.html.

Anti-virus Signatures After identifying and classifying a suspect file, the next step in the file profiling process is to query the file against anti-virus engines to see if it is detected as malicious code. • Approach this phase of the analysis in two separate steps: r First, manually scan the file with a number of anti-virus programs locally installed on the malware analysis test system to determine whether any alerts are generated for the file. This manual step affords control over the configuration of each program, ensures that the signature database is up to date, and allows access to the additional features of locally installed anti-virus tools (like links to the vendor Web site), which may provide more complete technical details about a detected specimen. r Second, submit the specimen to a number of free online malware scanning services for a more comprehensive view of any signatures associated with the file.

u

Local Malware Scanning u To scan malware locally, implement anti-virus software that can be configured to scan on demand, as opposed to every time a file is placed on the test system.

252

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• Make sure that the AV program affords choice in resolving malicious •

code detected by the anti-virus program; many automatically delete, “repair,” or quarantine the malware upon detection. Some examples of freeware anti-virus software for installation on your local examiner system include: r Avast17 r AVG18 r Avira AntiVir Personal19 r ClamWin20 r F-Prot21 r BitDefender22 r Panda23

Investigative Considerations • The fact that installed anti-virus software does not identify the suspect file as malicious code is not dispositive. Rather, it may mean simply that a signature for the suspect file has not been generated by the vendor of the antivirus product, or that the attacker is “armoring” or otherwise implanting a file protecting mechanism to thwart detection. • Although an anti-virus signature does not necessarily dictate the nature and capability of identified malicious code, it does shed potential insight into the purpose of the program. • Given that when a malicious code specimen is obtained and when a signature is developed for it may vary between anti-virus companies, scanning a suspect file with multiple anti-virus engines is recommended. Implementing this redundant approach helps ensure that a malware specimen is identified by an existing virus signature and provides a broader, more thorough inspection of the file.

Web-based Malware Scanning Services After running a suspect file through local anti-virus program engines, consider submitting the malware specimen to an online malware scanning service. • Unlike vendor-specific malware specimen submission Web sites, online malware scanning services will scan submitted specimens against

u

17

  For more information about Avast, go to http://www.avast.com/free-antivirus-download.   For more information about AGV, go to http://free.avg.com/us-en/company-profile. 19   For more information Avira AntiVir Personal, go to http://www.free-av.com/. 20   For more information about ClamWin, go to http://www.clamwin.com. 21   For more information about F-Prot, go to http://www.f-prot.com/products/home_use/linux/. 22   For more information about BitDefender, go to http://www.bitdefender.com/PRODUCT14-en—BitDefender-Free-Edition.html. 23   For more information about Panda, go to http://research.pandasecurity.com/free-commandlinescanner/. 18

Chapter | 5 File Identification and Profiling

253

numerous anti-virus engines to identify whether the submitted specimen is detected as hostile code. Web Service

Features

VirusTotal: http://www.virustotal.com

•

Scans submitted file against 43 different anti-virus engines

•

“First seen” and “last seen” submission dates provided for each specimen

•

File size, MD5, SHA1, SHA256, and ssdeep values generated for each submitted file

•

File type identified with file and TrID

•

PE file structure parsed

•

Relevant Prevx, ThreatExpert, and Symantec reports cross-referenced and hyperlinked

•

URL link scanning

•

Robust search function, allowing the digital investigator to search the VirusTotal (VT) database

•

VT Community discussion function

•

Python submission scripts available for batch ­submission: http://jon.oberheide.org/blog/2008/11/20/virustotalpython-submission-script/ http://www.bryceboe.com/2010/09/01/submitting-­ binaries-to-virustotal/

VirScan: http://virscan.org/

•

Scans submitted file against 36 different anti-virus engines

•

File size, MD5, and SHA1 values generated for each ­submitted file

Jotti Online Malware Scanner: http://virusscan.jotti.org/en

•

Scans submitted file against 19 different anti-virus engines

•

File size, MD5, and SHA1 values generated for each ­submitted file

•

File type identified with file magic file

•

Packing identification

•

Scans submitted file with 19 different anti-virus engines

•

File size, MD5, and SHA1 values generated for each ­submitted file

•

File type identification

•

Packing identification

•

“Last scanned” dates

Metascan Online www.metascan-online.com

• During the course of inspecting the file, the scan results for the respective anti-virus engines are presented in real time on the Web page.

• These Web sites are distinct from online malware analysis sandboxes that execute and process the malware in an emulated Internet, or

254

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

•

•

• •

“­ sandboxed,” network. The use of online malware analysis sandboxes will be discussed in Chapter 6. Remember that submission of any specimen containing personal, sensitive, proprietary, or otherwise confidential information may violate the victim company’s corporate policies or otherwise offend the ownership, privacy, or other corporate or individual rights associated with that information. Be careful to seek the appropriate legal guidance in this regard, before releasing any such specimen for third-party examination. Do not submit a suspicious file that is the crux of a sensitive investigation (i.e., circumstances in which disclosure of an investigation could cause irreparable harm to a case) to online analysis resources, such as anti-virus scanning services, in an effort not to alert the attacker. The results relating to a submitted file to an online malware analysis service are publicly available and easily discoverable—many portals even have a search function. Thus, as a result of submitting a suspect file, the attacker may discover that his malware and nefarious actions have been discovered, resulting in the destruction of evidence, and potentially damaging your investigation. Assuming you have determined it is appropriate to do so, submit the suspect file by uploading the file through the Web site submission portal. Upon submission, the anti-virus engines will run against the suspect file. As each engine passes over the submitted specimen, the file may be identified, as manifested by a signature identification alert similar to that depicted in Figure 5.12.

FIGURE 5.12–A suspect file submitted and scanned on VirusTotal

Chapter | 5 File Identification and Profiling

255

• If the file is not identified by any anti-virus engine, the field next to the

•

•

•

respective anti-virus software company will either remain blank (in the case of VirusTotal and VirScan), or state that no malicious code was detected (in the case of Jotti Online Malware Scanner and Metascan Online). The signature names attributed to the file provide an excellent way to gain additional information about what the file is and what it is capable of. By visiting the respective anti-virus vendor Web sites and searching for the signature or the offending file name, more often than not a technical summary of the malware specimen can be located. Alternatively, through search engine queries of the anti-virus signature, hash value, or file name, information security-related Web site descriptions or blogs describing a researcher’s analysis of the hostile program also may be encountered. Such information may contribute to the discovery of additional investigative leads and potentially reduce time spent analyzing the specimen. Conversely, there is no better way to get a sense of your malicious code specimen than thoroughly analyzing it yourself; relying entirely on thirdparty analysis to resolve a malicious code incident often has practical and real-world limitations.

Embedded Artifact Extraction: Strings, Symbolic Information, and File Metadata

R In addition to identifying the file type and scanning the file with anti-virus scanners to ascertain known hostile code signatures, many other potentially important facts can be gathered from the file itself. u Information about the expected behavior and function of the file can be gleaned from entities within the file, like strings, symbolic information, and file metadata. • Although symbolic references and metadata may be identified while parsing the strings of a file, these items are treated separately and distinctly from one another during the examination of a suspect file. • Embedded artifacts—evidence contained within the code or data of the suspect program—are best inspected separately to promote organization and clearer file context. Each inspection may shape or otherwise frame the future course of investigation.

Strings Some of the most valuable clues about the identifiers, functionality, and commands associated with a suspect file can be found within the embedded strings of the file. Strings are plain-text ACSII and Unicode (contiguous) characters embedded within a file. Although strings do not typically provide a complete picture of the purpose and capability of a file, they can help identify program functionality, file names, nicknames, Uniform Resource Locators (URLs), e-mail addresses, and error messages, among u

256

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

other things. Sifting through embedded strings may yield the following information: • Program Functionality: Often, the strings in a program will reveal calls made by the program to a particular .dll or function call. To help evaluate the significance of such strings, the Windows API Reference Web site24 and the Microsoft Advanced Search engine25 are solid references. • File Names: The strings in a malicious executable often reference the file name the malicious file will manifest as on a victim system, or perhaps more interestingly, the name the hacker bestowed on the malware. Further, many malicious executables will reference or make calls for additional files that are pulled down through a network connection to a remote server. • Moniker Identification (“greetz” and “shoutz”): Although not as prevalent recently, some malicious programs actually contain the attacker’s moniker hard-coded within it. Similarly, attackers occasionally reference, or give credit to, another hacker or hacking crew in this way—references known as “greetz” or “shoutz.” Like self-recognition references inside code, however, greetz and shoutz are less frequent.26 • URL and Domain Name References: A malicious program may require or call on additional files to update. Alternatively, the program may use remote servers as drop sites for tools or stolen victim data. As a result, the malware may contain strings referencing the URLs or domain names utilized by the code. • Registry Information: Some malware specimens reference registry keys or values that will be added or modified upon installation. Often, as discussed in other chapters, hostile programs create a persistence mechanism through a registry autorun subkey, causing the program to start up each time the system is rebooted. • IP Addresses: Similar to URLs and domain names, Internet Protocol (IP) addresses often are hard-coded into malicious programs and serve as “phone home” instructions, or in other instances, the direction of the attack. • E-mail Addresses: Some specimens of malicious code e-mail the attacker information extracted from the victim machine. For example, many of the Trojan horse variants install a keylogger on the victim ­computers to collect usernames and passwords and other sensitive information, then transmit the information to a drop-site e-mail address that serves as a central receptacle for the stolen data. An attacker’s e-mail address is obviously a significant evidentiary clue that can develop further investigative leads. 24

  http://msdn.microsoft.com/microsoft.com/en-us/library/aa383749.aspx.   http://search.microsoft.com/AdvancedSearch.aspx?mkt=en-US&qsc0=0&FORM=BAFF. 26   One example of a greetz can be found inside the Zotob worm code, in the phrase “Greetz to good friend Coder” (http://www.f-secure.com/weblog/archives/archive-082005.html). 25

Chapter | 5 File Identification and Profiling

257

• IRC Channels: Often the channel server and name of the Internet Relay

•

•

Chat (IRC) command and control server used to herd armies of compromised computers or botnets are hard-coded into the malware that infects the zombie machines. Indeed, suspect files may even reference multiple IRC channels for redundancy purposes should one channel be lost or closed and another channel comes online. Program Commands or Options: More often than not, an attacker needs to interact with the malware he or she is spreading, usually to ­promote the efficacy of the spreading method. Some older bot variants use instant messenger (IM) programs as an attack vector, and as such, the command to invoke IM spreading can be located within the program’s strings. Similarly, command-line options and/or embedded help/usage menu information can potentially reveal capabilities of a target specimen. Error and Confirmation Messages: Confirmation and error messages found in malware specimens (such as “Exploit FTPD is running on port: %i, at thread number: %i, total sends: %i”) often become significant investigative leads and provide good insight into the malware specimen’s capabilities.

 Analysis Tip

False Leads: “Planted” Strings

Despite the potential value embedded strings may have in the analysis of a suspect program, be aware that hackers and malware authors often “plant” strings in their code to throw digital investigators off track. Instances of false nicknames, e-mail addresses, and domain names are fairly common. When examining any given ­malware specimen and evaluating the meaningfulness of its embedded strings, remember to consider the entire context of the file and the digital crime scene.

Tools for Analyzing Embedded Strings u Unlike Linux and UNIX distributions, which typically come preloaded with the strings utility, Windows operating systems do not have a native tool to analyze strings. Thankfully, there are a number of strings extracting utilities, both CLI and GUI, available for use on Windows systems. • A version of strings, named “strings.exe” has been ported to Windows by Mark Russinovich of Microsoft (formerly of Sysinternals).27 • Like the UNIX/Linux version of strings, Russinovich’s ported version can query for both ASCII and Unicode strings and by default searches for three or more printable characters. Strings.exe can also recursively scan subdirectories. 27

  For more information about strings.exe, go to http://technet.microsoft.com/en-us/­ sysinternals/bb897439.

258

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• BinText28 is an intuitive and powerful GUI-based strings extraction program that displays ASCII, Unicode, and resource strings, each identified by a distinct letter and color on the left-hand side of the GUI (ASCII strings are identified by a green “A,” Unicode Strings by a Red “U,” and resource strings by a blue “R”), as displayed in Figure 5.13. @

FIGURE 5.13–Examining a suspect file in BinText

• BinText identifies the file offset and memory address of the discoverable strings in unique fields in the GUI. Further, the tool provides drag-anddrop functionality and a useful search feature, allowing the digital investigator to query for particular strings within the output.

 Other Tools to Consider GUI Strings Analysis Tools

AnalogX TextScan—http://www.analogx.com/contents/download/Programming/ textscan/Freeware.htm TextExtract—previously hosted on http://www.ultima-thule.co.uk/downloads/ textextract.zip String Extractor (Strex)—http://www.zexersoft.com/products.html iDefense Malcode Analyst Pack (MAP) Strings Shell Extension—http://labs.­idefense .com/software/malcode.php#more_malcode+analysis+pack Further tool discussion and comparison can be found in the Tool Box section at the end of this chapter, and on the companion Web site, http://www.malwarefieldguide .com/Chapter5.html.

28

  For more information about BinText, go to http://www.mcafee.com/us/downloads/free-tools/ bintext.aspx.

Chapter | 5 File Identification and Profiling

259

Inspecting File Dependencies: Dynamic or Static Linking During initial analysis of a suspect program, simply identifying whether the file is a static or dynamically linked executable will provide early guidance about the program’s functionality and what to anticipate during later dynamic analysis of library and system calls made during its execution. • A number of tools can help quickly assess whether a suspect binary is statically or dynamically linked. @ • DUMPBIN,29 a command-line utility provided with Microsoft Visual C++ in Microsoft Visual Studio,30 combines the functionality of the Microsoft development tools LINK, LIB, and EXEHDR. Thus, DUMPBIN can parse a suspect binary to provide valuable information about the file format and structure, embedded symbolic information, as well as the library files required by the program. • To identify an unknown binary file’s dependencies, query the target file with DUMPBIN, using the /DEPENDENTS argument, as shown in Figure 5.14.

u

C:Documents and SettingsMalware Lab>Dumpbin /DEPENDENTS Video.exe Microsoft (R) COFF/PE Dumper Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file Video.exe File Type: EXECUTABLE IMAGEImage has the following dependencies: kernel32.dll user32.dll advapi32.dll oleaut32.dll advapi32.dll version.dll gdi32.dll user32.dll ole32.dll oleaut32.dll ole32.dll oleaut32.dll comctl32.dll shell32.dll wininet.dll urlmon.dll shell32.dll comdlg32.dll shlwapi.dll user32.dllSummary 1000.adata 8000.aspack 3000.idata 1000.rdata F000.reloc BA8000.rsrc 1000.tls 2000 BSS DC000 CODE 3000 DATA

FIGURE 5.14–DUMPBIN query of a suspect file

• To obtain a better picture of the suspect file’s capabilities based upon the dependencies it requires, research each dependency separately, eliminating those that appear benign or commonplace, and focus more on those that seem more anomalous. Some of the better Web sites on which to perform such research are listed in the textbox Online Resources: Reference Pages. 29

For more information about DUMPBIN, go to http://support.microsoft.com/kb/177429. For more information about Visual Studio, go to http://www.microsoft.com/express/ Downloads/# http://www.microsoft.com/express/Downloads/# (Visual Studio Express version) and http://www.microsoft.com/visualstudio/en-us/products/2010-editions/professional/overview (Visual Studio Professional). 30

260

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

¿

Online Resources

Reference Pages

It is handy during the inspection of embedded entities like strings, dependencies, and API function call references to have reference Web sites available for quick perusal. Consider adding these Web sites to your browser toolbar for quick and easy reference. Windows API Reference—http://msdn.microsoft.com/en-us/library/aa383749% 28v=vs.85%29.aspx Process and Thread Functions Reference—http://msdn.microsoft.com/en-us/library/ ms684847.aspx Microsoft DLL Help Database—Retired by Microsoft in February 2010, but archived on http://web.archive.org/web/20090615190853/http://support.microsoft.com/dllhelp/ Microsoft Advanced Search Engine—http://search.microsoft.com/advancedsearch .aspx?mkt=en-US&setlang=en-US Microsoft TechNet—http://technet.microsoft.com/en-us/ Microsoft Standard .Exe Files and Associated .DLLs—http://technet.microsoft .com/ en-us/library/cc768380.aspx

• If the feel of a GUI tool to inspect file dependencies is preferred, Tim

•

Zabor has developed dumpbinGUI,31 a sleek front-end for DUMPBIN, which includes dumpbinCHM, a shell context menu that allows for a right-click on the target file and a selection of the DUMPBIN argument to be applied against a target file. @ To gain a more granular perspective of a target file’s dependencies, a useful command-line and GUI utility is Dependency Walker,32 which builds a hierarchical tree diagram of all dependent modules in the binary executable—allowing drill-down identification of the files that the dependencies require and invoke, as shown in Figure 5.15.

FIGURE 5.15–Examining a suspect file with Dependency Walker 31

For more information about dumpbinGUI, go to http://www.cheztabor.com/dumpbinGUI/ index.htm. 32 For more information about Dependency Walker, go to http://www.dependencywalker.com/.

Chapter | 5 File Identification and Profiling

261

Symbolic and Debug Information

R The way in which an executable file is compiled and linked by an attacker often leaves significant clues about the nature and capabilities of a suspect program. u If an attacker does not strip an executable file of program variable and function names known as symbols, which reside in a structure within Windows executable files called the symbol table, the program’s capabilities may be readily detected. • To check for symbols in a binary, turn to the utility nm, which is preinstalled in most distributions of the Linux operating system. The nm command identifies symbolic and debug information embedded in executable/object files specimen. • Although Windows systems do not have an inherent equivalent of this utility, there are several other tools that nicely extract the same symbol information. • As with file dependencies, DUMPBIN can be used with the /SYMBOLS ­argument to display the symbols present in a Windows executable file’s symbol table. • As previously discussed, there is a GUI alternative to the DUMPBIN console program called dumpbinGUI, which also can be used to query target files for symbolic information. DumpbinGUI is particularly helpful in that it offers a shell context menu, allowing for a file to be right-clicked and run through the program.

Embedded File Metadata

R In addition to embedded strings and symbolic information, an executable file may contain valuable clues within its file metadata. u The term metadata refers to information about data. In a forensic context, discussions pertaining to metadata typically center on information that can be extracted from document files, like those created with Microsoft Office applications. Metadata may reveal the author of a document, the number of revisions, and other private information about a file that normally would not be displayed. • Metadata also resides in executable files, and often these data can provide valuable insight as to the compilation date/time, origin, purpose, or functionality of the file. • Metadata in the context of an executable file does not reveal technical information related to file content, but rather contains information about the origin, ownership, and history of the file. In executable files, metadata can be identified in a number of ways. r To create a binary executable file, a high-level programming language must be compiled into an object file, and in turn, be linked with any required libraries and additional object code.

262

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

From this process alone, numerous potential metadata footprints are left in the binary, including the high-level language in which the program was written, the type and version of the compiler and linker used to compile the code, and the date and time of compilation. In addition to these pieces of information, other file metadata may be present in a suspect program, including information relating to the following: r

•

Metadata Artifacts Program author

Publisher

Warnings

Program version

Author/Creator

Location

Operating system or platform in which the executable was compiled

Created by software

Format

Intended operating system and processor of the program

Modified by software

Resource Identifier

Console or GUI program

Contributor information

Character Set

Company or organization

Copyright information

Spoken or Written Language

Disclaimers

License

Subject

Comments

Previous File Name

Hash Values

Creation Date

Modified Date

Access Date

• These metadata artifacts are references from various parts of the exe-

•

•

•

33

cutable file structure. The goal of the metadata harvesting process is to extract historical and identifying clues before examining the actual executable file structure. Later in this chapter (in the “Windows Portable Executable Format” ­section), as well as in Chapter 6, we will be taking a detailed look at the format and structure of the PE file, and specifically where metadata artifacts reside within it. Most of the metadata artifacts listed in the previous table manifest in the strings embedded in the program; thus, the strings parsing tools discussed earlier in this chapter certainly can be used to discover them. However, for a more methodical and concise exploration of an unknown, suspect program, the tasks of examining the strings of the file and harvesting file metadata are better separated. To gather an overview of file metadata as a contextual baseline, scan a suspect file with exiftool.33 A number of GUI front-ends have been

  For more information about exiftool, go to http://www.sno.phy.queensu.ca/~phil/exiftool/.

Chapter | 5 File Identification and Profiling

•

263

developed for exiftool that provide for drag-and-drop functionality and recursive scanning. @ Exiftool will provide the digital investigator with temporal context, operating system, and target environment identifiers, along with other helpful clues such as linker version, as displayed in Figure 5.16. However, further probing is often required to gather additional metadata artifacts of value from a suspect executable file.

C:Malware Lab>exiftool c:Malwareavupdater.exe ExifTool Version Number : 8.40 File Name : avupdater.exe Directory : c:/Malware File Size : 288 kB File Modification Date/Time : 2010:12:17 17:41:19-08:00 File Permissions : rw-rw-rwFile Type : Win32 EXE MIME Type : application/octet-stream Machine Type : Intel 386 or later, and compatibles Time Stamp : 2010:06:08 04:31:24-07:00 PE Type : PE32 Linker Version : 6.0 Code Size : 169984 Initialized Data Size : 123904 Uninitialized Data Size : 0 Entry Point : 0x26fda OS Version : 4.0 Image Version : 0.0 Subsystem Version : 4.0 Subsystem : Windows GUI File Version Number : 3.0.0.1 Product Version Number : 3.0.0.1 File Flags Mask : 0x0017 File Flags : (none) File OS : Win32 Object File Type : Executable application File Subtype : 0 Language Code : Russian Character Set : Windows, Cyrillic File Description : AVUpdateHelper File Version : 3, 0, 0, 1 Internal Name : AVUpdateHelper Legal Copyright : Btnt AV Copyright (C) 2010 Original Filename : avupdater.exe Product Name : AV2010 Application Product Version : 3, 0, 0, 1

FIGURE 5.16–Gathering metadata from a PE file with exiftool

• After gaining an overview of the file metadata, review or “peel” the file for specific metadata artifacts in chronological order of the compilation process—from high-level source code to compiled executable. Initial clues to look for include: r Identify the high-level language used to create the suspect program r Determine the compiler (and linker version) used to create the program

264

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Ascertain the file compilation time and date Identify the Regional Settings (Language Code and Character Set) embedded within the binary during the time of compilation r File version information Often, metadata items of interest are obfuscated by the attacker through packing or encrypting the file (discussed in the “File Obfuscation: Packing and Encryption Identification” section, later in this chapter). If the file is not obfuscated, the high-level programming language can be quickly identified by GT2, a file format detection utility with a shell context menu that allows for a right-click on the target file.34 @ Although GT2 can identify and parse many file formats, it is particularly geared toward extracting data from PE files. Figure 5.17 displays the output of GT2 extracting file version information and identifying the highlevel programming language of a target file (Visual C++ 6.0). r r

•

•

— C:Malwareavupdater.exe (295168 bytes) — binary Is a Win32 executable Size of header File size in header Entrypoint Overlay size No relocation entries

00000040h 00000490h 00000040h 00047C70h

/ / / /

64 1168 64 294000

… Version Info: ID: 00000001h / 1 RVA: 000B8058h; Offset: 00047C58h; Size: 704 bytes VersionInfo resource: FileVersion: 3.0.0.1 ProductVersion: 3.0.0.1 Target OS: 32 bit Windows Language ‘041904E3’ FileDescription: ‘AVUpdateHelper’ FileVersion: ‘3, 0, 0, 1’ InternalName: ‘AVUpdateHelper’ LegalCopyright: ‘Btnt AV Copyright (C) 2010’ OriginalFilename: ‘avupdater.exe’ ProductName: ‘AV2010 Application’ ProductVersion: ‘3, 0, 0, 1’ Processed/created with:

±

Found compiler ‘Visual C++ 6.0 (EXE) (nodebug)’

FIGURE 5.17–PE metadata extracted with GT2

• There are a number of other utilities that may be useful for identifying

the compiler used to create a binary executable. Among them is PEid,35 a power utility for examining PE files, including compiler and packing identification. Another is Babak Farrokhi’s Language 2000 tool,36 an

34 35 36

For more information about GT2, go to http://philip.helger.com/gt/index.php. For more information about PEiD, go to http://www.peid.info. For more information about Language 2000, go to http://farrokhi.net/language/language.zip.

Chapter | 5 File Identification and Profiling

•

•

265

older compiler detection utility, which identifies the compiler used to create a program and extracts the program version information embedded in the file. @ PE file metadata can also provide temporal context surrounding an incident and contribute toward building an investigative time line in conjunction with live response and post-mortem forensic artifacts acquired from a victim system. In particular, the date and time stamp when the executable was compiled can be extracted from the IMAGE_FILE_HEADER structure of a PE file. A detailed discussion of the IMAGE_FILE_HEADER and other PE file structures can be found in the section “Windows Portable Executable File Format,” later in this chapter. r The compilation date and time can be quickly extracted using Nick Harbour’s pestat command line utility.37 r For digital investigators who prefer a graphical utility, as depicted in Figure 5.18, MiTeC’s EXE Explorer38 intuitively extracts and displays the time stamp data (in GMT).

FIGURE 5.18–PE compilation date and time extracted with EXE Explorer

• Looking back at the output in Figure 5.17, extensive file version

•

37

information was extracted, most likely obtained from the executables Resource section (a topic covered in depth in Chapter 6). Although this ­information is not dispositive, these are substantial leads that can be further pursued through online research. To gain further insight about the attacker, examine the Language Code and Character Set identifiers embedded within the IMAGE_ RESOURCE_DIRECTORY structure of the binary during the time of compilation. These settings provide information about the native

  For more information about pestat, go to http://www.rnicrosoft.net/.   For more information about EXE Explorer, go to http://www.mitec.cz/exe.html.

38

266

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

attacker system environment or settings selected by the attacker during compilation. r For example, looking at the data extracted in Figures 5.16 and 5.17, we learn that the regional settings in the suspect executable include a Language Identifier Code 041904E3 (Russian)39 and a Character Set (Cyrillic).40 r A granular examination of the Language and Character codes can be conducted by parsing the Resource section of a target file with a PE Analysis tool such as HeavenTools’ PE Explorer,41 as depicted below in Figure 5.19.

FIGURE 5.19–Examining language and character codes with PE Explorer

¿ Online Resources Locale Identifiers

Consider adding these Web sites to your browser toolbar for quick and easy reference of Locale Identifiers. Locale IDs Assigned by Microsoft—http://msdn.microsoft.com/en-us/goglobal/ bb964664 Locale IDs, Inout Locales, and Language Collections for Windows XP and Windows Server 2003—http://msdn.microsoft.com/en-us/goglobal/bb895996

39   For a list of Language Identifier Codes, go to http://msdn.microsoft.com/en-us/library/ aa912040.aspx. 40   For a list of Character Codes, go to http://msdn.microsoft.com/en-us/library/cc195051.aspx. 41   For more information about PE Explorer, go to http://www.heaventools.com/overview.htm.

Chapter | 5 File Identification and Profiling

267

Investigative Consideration: • A word of caution: As with embedded strings, file metadata can be modified by an attacker. Time and date stamps, file version information, and other seemingly helpful metadata are often the target of alteration by attackers who are looking to thwart the efforts of researchers and investigators from tracking their attack. File metadata must be reviewed and considered in context with all of the digital and network-based evidence collected from the incident scene.

FILE OBFUSCATION: PACKING AND ENCRYPTION ­IDENTIFICATION

R Thus far this chapter has focused on methods of reviewing and analyzing data in and about a suspect file. All too often, malware “in the wild” presents itself as armored or obfuscated, primarily to circumvent network security protection mechanisms like anti-virus software and intrusion detection systems. u Obfuscation is also used to protect the executable’s innards from the prying eyes of virus researchers, malware analysts, and other information security professionals interested in reverse-engineering and studying the code. • Moreover, in today’s underground hacker economy, file obfuscation is no longer used to just block the “good guys,” but also to prevent other attackers from examining the code. Savvy and opportunistic cyber criminals can analyze the code, determine where the attacker is controlling his infected computers or storing valuable harvested information (like keylogger contents or credit card information), and then “hijack” those resources away to build their own botnet armies or enhance their own illicit profits from phishing, spamming, click fraud, or other forms of fraudulent online conduct. • Given these “pitfalls,” attackers use a variety of utilities to obscure and protect their file contents; it is not uncommon to see more than one layer, or a combination, of file obfuscation applied to hostile code to ensure it remains undetectable. • Some of the more predominant file obfuscation mechanisms used by attackers to disguise their malware include packers, encryption programs (known in hacker circles as cryptors), and binders, joiners, and wrappers, as graphically portrayed in Figure 5.20. Let’s take a look at how these utilities work and how to spot them.

Packers u The terms packer, compressor, and packing are used in the information security and hacker communities alike to refer generally to file obfuscation programs. • Packers are programs that allow the user to compress, and in some instances encrypt, the contents of an executable file.

268

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Packers

Cryptors

on code

Obfuscati

oiners / Binders /J Wrappers

FIGURE 5.20–Obfuscating code

• Packing programs work by compressing an original executable binary,

• •

and in turn, obfuscating its contents within the structure of a “new” executable file. The packing program writes a decompression algorithm stub, often at the end of the file, and modifies the executable file’s entry point to the location of the stub.42 As illustrated in Figure 5.21, upon execution of the packed program, the decompression routine extracts the original binary executable into memory during runtime and then triggers its execution. In addition to unpacking programs that were created to foil specific packers, there are numerous generic unpackers and file dumping utilities that can be implemented during runtime analysis of a packed executable malware specimen. These tools will be discussed in greater detail in Chapter 6.

ble Executa program

Compression / Obfuscation

ble Executa in program memory

FIGURE 5.21–Execution of a packed malware specimen

42

  For a good discussion on file packing programs and obfuscation code analysis, see Lenny Zeltser’s SANS Forensics 610, Reverse-Engineering Malware: Malware Analysis Tools and Techniques, 2010.

269

Chapter | 5 File Identification and Profiling

Cryptors u Executable file encryption programs or encryptors, better known by their colloquial “underground” names cryptors (or crypters) or protectors, serve the same purpose for attackers as packing programs. They are designed to conceal the contents of the executable program, render it undetectable by anti-virus and IDS, and resist any reverse engineering or hijacking efforts. • Unlike packing programs, cryptors accomplish this goal by applying an encryption algorithm upon an executable file, causing the target file’s contents to be scrambled and undecipherable. • Like file packers, cryptors write a stub containing a decryption routine to the encrypted target executable, thus causing the entry point in the original binary to be altered. Upon execution, the cryptor program runs the decryption routine and extracts the original executable dynamically at runtime, as shown in Figure 5.22.

ble Executa program

Cryptor

ble Executa in program memory

FIGURE 5.22–Execution of a cryptor protected executable file

Packer and Cryptor Detection Tools u PEiD43 is the packer and cryptor freeware detection tool most predominantly used by digital investigators, both because of its high detection rates (more than 600 different signatures) and its easy-to-use GUI interface that allows multiple file and directory scanning with heuristic scanning options. • PEiD allows drag-and-drop functionality to quickly identify obfuscation signatures, as demonstrated in Figure 5.23. • PEiD contains a plug-in interface44 and a myriad of plug-ins that afford additional detection functionality. Plug-ins are listed and described in the Tool Box section at the end of this chapter. @ 43

  For more information about PEiD, go to http://peid.info/.   For more information on PEiD plug-ins, go to http://www.peid.info/plugins/.

44

270

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

FIGURE 5.23–Analyzing a suspect file with PEiD

• Entropy calculation—or the measurement of disorder in a block of

•

data45—and PE Entry Point (EP) anomaly detection in a suspect file can be calculated with PEiD using the “Extra Information” feature invoked by clicking the double append button located at the bottom right corner of the PEiD GUI. High entropy levels are typically indicia that an obfuscation scheme has been applied to a suspect file. In addition to PEiD, there are a number of other GUI-based obfuscation detection tools that offer slightly different features and plug-ins, including Mandiant’s Red Curtain,46 NTCore’s PE Detective,47 and RDG.48 Refer to the Tool Box section at the end of this chapter and on the companion Web site, http://www.malwarefieldguide.com/Chapter5.html, for additional tool options. @

CLI Packing and Cryptor Detection Tools • In addition to these GUI-based tools, there are a few handy python-based tools, making them extensible and command-line operated. • Pefile,49 developed by Ero Carrera, is a robust PE file parsing utility as well as a packing identification tool. In particular, some of its functionality includes the ability to inspect the PE header and sections, obtain warnings for suspicious and malformed values in the PE image, detect file obfuscation with PEiD’s signatures, and generate new PEiD signatures. • Jim Clausing, a SANS Internet Storm Center Incident Handler, wrote a ­similar python script for PE packer identification based upon pefile, called 45

  Lyda, R., and Hamrock, J. (2007). Using entropy analysis to find encrypted and packed malware, IEEE Security and Privacy (S&P). 46   For more information about Mandiant Red Curtain, go to http://www.mandiant.com/products/ free_software/red_curtain/. 47   For more information about PE Detective, go to http://www.ntcore.com/pedetective.php. 48   For more information about RDG, go to http://www.rdgsoft.8k.com/. 49   For more information about pefile, go to http://code.google.com/p/pefile/.

Chapter | 5 File Identification and Profiling

271

packerid.py.50 Like pefile, packerid.py is extensible and can be run in both the Windows and Linux environments, convenient for many Linux purists who prefer to conduct malware analysis in a Linux environment. Further, like pefile, packerid.py can be configured to compare queried files against various PE obfuscation signature databases, including those used by PEiD51 and others created by Panda Security.52 The output of packerid.py as applied against a suspect binary can be seen in Figure 5.24.

[email protected]:~/Malware Lab/Windows Malware$ python packerid.py Video.exe [‘ASPack v2.12’]

FIGURE 5.24–Inspecting a suspect file with packer.py on a Linux system

• Another very helpful CLI-based packer detection utility is SigBuster, written by Toni Koivunen of teamfurry.com. SigBuster has a myriad of different scan options and capabilities, and is written in Java, making it useful on Linux and UNIX systems (Figure 5.25). Currently, SigBuster is not publicly available, but is available to anti-virus researchers and law enforcement. However, SigBuster is implemented in the Anubis online malware analysis sandbox where the public can submit specimens for analysis.53

[email protected]:~/Malware Lab/Windows Malware$ java -jar SigBuster.jar –f Video.exe SigBuster version 1.1.0 starting up. Happy hunting! Initializing databases… Loaded 466 EPO signatures into ScanEngine. Scanning -> Video.exe Signature found: [ASPack v2.12 SN:750] Signature found: [ASPack vna SN:1633] Scan took 2741ms Directory scan took 2788ms Scanned total 1, of which 1 were valid PE files. Of the valid 1 files 1 got stamped with a signature. Detection rate is 100.0%

FIGURE 5.25–Inspecting a suspect file with SigBuster on a Linux system

50 51 52 53

To obtain a copy of packerid.py, go to http://handlers.dshield.org/jclausing/packerid.py. http://www.peid.info/BobSoft/Downloads.html. http://research.pandasecurity.com/blogs/images/userdb.txt. For more information about Anubis, go to http://anubis.iseclab.org/.

272

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Binders, Joiners, and Wrappers Binders (also known as joiners or wrappers) in the Windows environment simply take Windows PE files and roll them into a single executable. • The binder author can determine which file will execute and whether the state will be normal or hidden. The copy location of the file can be specified in the Windows, system, or temp directories, and the action can be specified to either open/execute or copy only. • From the underground perspective, binders allow attackers to combine their malicious code executable together with a benign one, with the latter serving as an effective delivery vehicle for the malicious code’s distribution. • There are many different binders available on the Internet; a simple and most fully featured one is known as YAB or “Yet Another Binder.”54

u

Embedded Artifact Extraction Revisited

R After de-obfuscating a target specimen, conduct a file profile of the unobscured file. u After successfully pulling malicious code from its armor through the static and behavioral analysis techniques discussed in Chapter 6, re-examine the unobscured program for strings, symbolic information, file metadata, and PE structural details. In this way, a comparison of the “before” and “after” file will reveal more clearly the most important thing about the structure, contents, and capabilities of the program.

Windows Portable Executable File Format

R A robust understanding of the file format of a suspect executable program that has targeted a Windows system will best facilitate effective evaluation of the nature and purpose of the file. u This section will cover the basic structure and contents of the Windows PE file format. In Chapter 6 deeper analysis of PE files will be conducted. • The PE file format is derivative of the older Common Object File Format (COFF) and shares with it some structural commonalities. • The PE file format not only applies to executable image files, but also to DLLs and kernel-mode drivers. Microsoft dubbed the newer executable format “Portable Executable” with aspirations of making it universal for all Windows platforms, an endeavor that has proven successful. • The PE file format is defined in the winnt.h header file in the Microsoft Platform Software Development Kit (SDK). Microsoft has documented 54

  For more information about Yet Another Binder, go to http://gsa.ca.com/pest/pest .aspx?ID=453073945.

Chapter | 5 File Identification and Profiling

•

273

the PE file specification,55 and researchers have written whitepapers focusing on its intricacies.56 Despite these resources, PE file analysis is often tricky and cumbersome.57 The difficultly lies in the fact that a PE file is not a single, large continuous structure, but rather a series of different structures and subcomponents that describe, point to, and contain data or code, as illustrated graphically in Figure 5.26. er S Head MS-DO ADER) DOS_HE (IMAGE_

MS-DOS

Stub

er PE Head DERS) NT_HEA (IMAGE_ LE_HEADER) FI R) (IMAGE_ ONAL_HEADE OPTI (IMAGE_

ctory Data Dire ECTORY) IR DATA_D

(IMAGE_

Table Section ER) N_HEAD SECTIO

(IMAGE_

FIGURE 5.26–The Portable Executable (PE) file format

• To gain a clear and intuitive perspective of the entire PE file format, run the suspect binary through a CLI tool, like Matt Pietrek’s pedump utility,58 or pefile.py, so that each structure and sub-component can be studied and analyzed in a comprehensive view. Alternatively, for a general graphical overview of the PE structure, load the suspect file into a GUI-based PE analysis tool, such as PEView,59 AnyWherePEViewer,60 and CFF Explorer61 (see Figure 5.27), among others. @ 55

  http://msdn.microsoft.com/en-us/windows/hardware/gg463119.aspx.   Some of the foundational whitepapers on the subject are authored by Matt Pietrek, including: Peering Inside the PE: A Tour of the Win32 Portable Executable File Format (http://msdn.microsoft .com/en-us/library/ms809762.aspx) and An In-Depth Look into the Win32 Portable Executable File Format (http://technet.microsoft.com/en-us/library/bb985992.aspx). 57   http://www.openrce.org/reference_library/files/reference/PE%20Format.pdf. 58   http://www.wheaty.net/pedump.zip. 59   For more information about PEView, go to http://www.magma.ca/~wjr/. 60   For more information about Anywhere PE Viewer, go to http://www.ucware.com/apev/index .htm. 61   For more information about CFF Explorer, go to http://www.ntcore.com/exsuite.php. 56

274

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

FIGURE 5.27–Parsing a suspect PE file with CFF Explorer

• After reviewing the entirety of the PE file output, which can often be rather extensive, consider “peeling” the data slowly by reviewing each structure and sub-component individually; that is, begin your analysis at the start of the PE module and work your way through all of the structures and sections, taking careful note of the data that are present, and perhaps just as important, the data that are not.

MS-DOS Header u The IMAGE_DOS_HEADER structure, or MS-DOS header, is the file structure that every PE file begins with. For investigative purposes, the MS-DOS header contains two important pieces of information. • First, the e_magic field contains the DOS executable file signature, previously identified as “MZ” or the hexadecimal characters 4D 5A, found in the first two bytes of the file. Similarly, Borland Delphi executables have a “P” in the file signature, following the MZ. • Second, as shown in Figure 5.28, the e_lfanew field points to the offset in the file where the PE header begins, known as the IMAGE_NT_ HEADERS structure. MS-DOS Stub u The IMAGE_DOS_HEADER is followed by the MS-DOS stub program, which serves primarily as a compatibility notification method. • In particular, when the PE file format was first introduced, many users operated in DOS and not within the Windows GUI environment. If a PE file is mistakenly executed in DOS, the MS-DOS stub prints out the message “This program cannot be run in DOS mode.”

275

Chapter | 5 File Identification and Profiling

re “MZ”

Signatu

er S Head MS-DO DER) A E H _ _DOS (IMAGE

w

e_Ifane

S Stub

MS-DO

der PE Hea DERS) HEA _ T N _ ) (IMAGE ILE_HEADER ) ER _F E D A G E A H M _ (I L PTIONA O _ E G (IMA

ectory Y) Data Dir ECTOR TA_DIR A D _ E G (IMA

Table Section _HEADER) N IO T C E _S (IMAGE

FIGURE 5.28–The e_magic and e_lfanew fields in IMAGE_DOS_HEADER

• The stub program is not essential for the successful execution of a PE file, and many times attackers will modify, delete, or otherwise obfuscate it (see Figure 5.29).

PE Header u Below the MS-DOS stub, at the offset address designated by the e_lfanew field, resides the IMAGE_NT_HEADERS structure, also known simply as the PE Header.62 • As depicted in Figure 5.30, the PE Header is actually comprised of the PE signature and two other data structures: the IMAGE_FILE _HEADER structure and the IMAGE_OPTIONAL_HEADER structure, which contains its own substructure, the Data Directory. • A PE file is identified by the 4-byte (or DWORD) signature “PE” followed by two null values (ASCII characters “PE” with the hexadecimal 62

  For more information about the IMAGE_NT_HEADERS structure, go to http://msdn .­microsoft.com/en-us/library/ms680336%28v=vs.85%29.aspx.

276

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

er S Head MS-DO _HEADER) S O D E_ (IMAG

t be canno e.» rogram “This p in DOS mod run S Stub

MS-DO

ader PE He ADERS) T_HE DER) N _ E G (IMA _HEA DER) A E_FILE (IMAG TIONAL_HE E_OP (IMAG

irectory Data D IRECTORY) TA_D A D _ E (IMAG

Table Section _HEADER) N ECTIO S _ E G (IMA

FIGURE 5.29–The MS-DOS Stub Program

• •

translation of 50 45 00 00). The signature appears in the file after the MS-DOS stub, but need not be located at a particular offset. The first sub-structure in the IMAGE_NT_HEADERS structure is the IMAGE_FILE_HEADER, also known as the COFF File header.63 From an investigative perspective, this structure is potentially comprised of informative data about the target file, including, among other things (Figure 5.31)64:

63   For more information about the IMAGE_FILE_HEADER structure, go http://msdn.microsoft .com/en-us/library/ms680313%28v=vs.85%29.aspx. 64   Microsoft Portable Executable and Common Object File Format Specification, Section 2.3, Revision 8.2—September 21, 2010.

277

Chapter | 5 File Identification and Profiling

IMAGE_NT_HEADERS typedef struct _IMAGE_NT_HEADERS { DWORD Signature; IMAGE_FILE_HEADER FileHeader; IMAGE_OPTIONAL_HEADER OptionalHeader; } IMAGE_NT_HEADERS, *PIMAGE_NT_HEADERS;

er S Head ER) MS-DO S_HEAD E_DO (IMAG

S Stub

MS-DO

EADER

FILE_H

IMAGE_ e

gnatur

PE Si

ader RS) PE He EADE E_NT_H

(IMAG

DER

AL_HEA

OPTION

IMAGE_

rectory Data Di IRECTORY) DATA_D

(IMAGE_

Table Section N_HEADER) IO E_SECT

(IMAG

FIGURE 5.30–The PE Header and its contents

HEADER R IMAGE_FILE_ ILE_HEADE ct _IMAGE_F typedef stru {

EAD ER

LE_H IMAGE_FI PE Header S) _HEAD ER

PE Signature

_HEAD _OPTIONAL

ER

IMAGE

(IMAGE_NT

e. WORD Machin erOfSections; WORD Numb ; eDateStamp Tim D OR DW Table; nterTosymbol ; DWORD Poi mbols fSy erO mb DWORD Nu er; ead alH tion fOp WORD SizeO cteristics;} WORD Chara ADER HE LE_ _FI IMAGE DER; _FILE_HEA *PIMAGE

ry Data Directo Y) _DIRECTOR (IMAGE_DATA

FIGURE 5.31–The IMAGE_FILE_HEADER structure

Time and date the file was compiled/created Target platform/processor Number of sections in the Section Table File characteristics, such as whether the file is executable Whether symbols have been stripped from the file Whether debugging information has been stripped from the file To parse the IMAGE_FILE_HEADER for these details, query the suspect file in PEView, a GUI-based tool that provides an intuitive interface for navigating headers, descriptors, and values for each field in the PE structure, as shown in Figure 5.32. r r r r r r

•

278

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

FIGURE 5.32–Examining the Image_File_Header with PEView

ADER

FILE_HE

IMAGE_

PE er PE Head DERS) NT_HEA

e Signatur

DER

AL_HEA

OPTION

IMAGE_

(IMAGE_

tory ) Data Direc ECTORY DATA_DIR

(IMAGE_

HEADER ER 1 TIONAL_ NAL_HEAD IMAGE_OP E_OPTIO uct _IMAG typedef str gic Ma RD WO rsion: jorLinkerVe BYTE Ma ion: rLinkerVers BYTE Mino fCode: eO Sit D DWOR lizedData itia fIn eO Sit : DWORD itializedData siteofunin DWORD e Baseofcod DWORD ata ofd Base DWORD e ImageBas DWORD ment Sectionalign DWORD nt on Filealignme DWORD ystemVersi operatings jor Ma rsion WORD gsystemVe noroperatin WORD Mi ion ers jorimageV WORD Ma ersion norimageV WORD Mi rVersion jorsubaste WORD Ma rVersion norsubaste Mi RD WO ionvalue ers 2v n3 Wi DWORD e: ag Sizeofim DWORD ers: Sizeofread DWORD Checksum: DWORD bsystem: Su RD WO stem charactersy WORD All kmeasure: Sizeofstac it: DWORD fheapcomm eo siz D DWOR preserve Sizeofheap it: DWORD mm co ap Sizeofhe DWORD s: Loaderflag DWORD eandSizes fAv ero Numb DWORD CTORY TA_DIRE IMAGE_DA EADER, TICAL_R . IMAGE_OP READER L_ NA OPTIO *PIMAGE_

FIGURE 5.33–The IMAGE-OPTIONAL_HEADER structure

• Following the IMAGE_FILE_HEADER structure is the IMAGE_ OPTIONAL_HEADER, better known simply as the Optional Header, which is ironically not optional as the executable will fail to load without it.65 (See Figure 5.33.)

65   For more information about the IMAGE_OPTIONAL_HEADER structure, go to http://msdn .microsoft.com/en-us/library/ms680339%28v=vs.85%29.aspx.

279

Chapter | 5 File Identification and Profiling

• The Optional Header is dense with a number of fields containing items of interest to digital investigators that can be extracted from this structure, including66: r Linker version used to compile the executable file r DLL characteristics r Pointer to address of entry point r Operating system version

Data Directory u In addition, the Optional Header also contains the IMAGE_DATA_ DIRECTORY structures, commonly referred to as Data Directories. The IMAGE_DATA_DIRECTORY, shown in Figure 5.34, contains 16 directories

r S Heade MS-DO _HEADER) _DOS (IMAGE

Export

Table

Import

Table

le rce Tab

Resou

ble

tion Ta

Excep Stub MS-DOS

der PE Hea ADERS) E _NT_H R) (IMAGE ILE_HEADE R) _F DE (IMAGE IONAL_HEA T P MAGE_O

(I

ctory Data Dire ECTORY) _DIR E_DATA

(IMAG

ble

cate Ta

Certifi

le on Tab

elocati

Base R

ging Debug

ation Inform

Data

ecture

Archit

egister

R Pointer

Global Thread

LS) torage(T Local S ble

ation Ta

onfigur

Load C

Table Section _HEADER) ON _SECTI (IMAGE

Bound

Import

dress

Table ad

Address

Import

Table tor

escrip

port D

DelayIm

ress

er add

Rhead

The CL

ed

Reserv

FIGURE 5.34–The IMAGE_DATA_DIRECTORY structure 66

  Microsoft Portable Executable and Common Object File Format Specification, Section 2.4, Revision 8.2—September 21, 2010.

280

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

that identify values and map the locations of other structures and sections within the PE file.

• Not all PE files have entries in all 16 Data Directories, so when assessing a suspect executable, make note of which directories are present.

Section Table u The last structure in the PE file is the IMAGE_SECTION_HEADER, or Section Table, which follows immediately after the IMAGE_DATA_DIRECTORY. • The Section Table consists of individual entries, or section headers, each 40 bytes in size and containing the name, size, and description of the respective section. • The IMAGE_FILE_HEADER (COFF header) structure contains a “NumberOfSections” field, which identifies the number of entries in the Section Table. The Section Table entries are arranged in ascending order, starting from the number one (see Figure 5.35).

er S Head MS-DO _HEADER) OS D _ E G (IMA

S Stub

MS-DO

ader PE He ADERS) _HE T N _ R) E (IMAG FILE_HEADE ER) AD E_ (IMAG TIONAL_HE E_OP (IMAG

irectory Data D IRECTORY) DATA_D

_ (IMAGE

.text .data

(IMAG

Table Section N_HEADER IO T C E S E_

.rsrc

.reloc

FIGURE 5.35–Section Table

Chapter | 5 File Identification and Profiling

281

¿ Online Resources Exe Dump Utility

To get a feel for how pefile works, submit an executable file to the Exe Dump Utility portal at http://utilitymill.com/utility/Exe_Dump_Utility and receive a text or HTML report containing the results of the file being processed through pefile.

PROFILING SUSPECT DOCUMENT FILES During the course of profiling a suspect file, the digital investigator may determine that a file specimen is not an executable file, but rather a document file, requiring distinct examination tools and techniques. R Malicious document files have become a burgeoning threat and increasingly popular vector of attack by malicious code adversaries. u Malicious documents crafted by attackers to exploit vulnerabilities in document processing and rendering software such as Adobe (Reader/Acrobat) and Microsoft Office (Word, PowerPoint, Excel) are becoming increasingly more common. • As document files are commonly exchanged in both business and personal contexts, attackers frequently use social engineering techniques to infect victims through this vector—such as attaching a malicious document to an e-mail seemingly sent from a recognizable or trusted party. • Typically, malicious documents contain a malicious scripting “trigger mechanism” that exploits an application vulnerability and invokes embedded shellcode; in some instances, an embedded executable file is invoked or a network request is made to a remote resource for additional malicious files. • Malicious document analysis proposes the additional challenges of navigating and understanding numerous file formats and structures, as well as obfuscation techniques to stymie the digital investigator’s efforts. u In this section we will examine the overall methodology for examining malicious documents. As the facts and context of each malicious code incident dictates the manner and means in which the digital investigator will proceed with his investigation, the techniques outlined in this section are not intended to be comprehensive or exhaustive, but rather to provide a solid foundation relating to malicious document analysis. • Malicious Document Analysis Methodology r Identify the suspicious file as a document file through file identification tools r Scan the file to identify indicators of malice r Examine the file to discover relevant metadata

282

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

r r r r r r

Examine the file structure to locate suspect embedded artifacts, such as scripts, shellcode, or executable files Extract suspect scripts/code/files If required, decompress or de-obfuscate the suspect scripts/code/files Examine the suspect scripts/code/files Identify correlative malicious code, file system, or network artifacts previously discovered during live response and post-mortem forensics Determine relational context within the totality of the infection process

Profiling Adobe Portable Document Format (PDF) Files

R A solid understanding of the PDF file structure is helpful to effectively analyze a malicious PDF file.

PDF File Format A PDF document is a data structure comprised of a series of elements Figure 5.37)67: • File Header: The first line of a PDF file contains a header, which contains 5 characters; the first three characters are always “PDF,” and the remaining two characters define the version number, for example, “%PDF-1.6” (PDF versions range from 1.0 to 1.7). • Body: The PDF file body contains a series of objects that represent the contents of the document. • Objects: The objects in the PDF file body represent contents such as fonts, text, pages, and images. r Objects may reference other objects. These indirect objects are labeled with two unique identifiers collectively known as the object identifier: (1) an object number and (2) a generation number. r After the object identifier is the definition (Figure 5.36) of the indirect object, which is contained in between the keywords “obj” and “endobj.” For example:

u

5

0

obj

> endobj

FIGURE 5.36–Object definition 67

For detailed information about the Portable Document Format, see the Adobe Portable Document File Specification (International Standard ISO 32000-1:2008), http://www.adobe.com/ devnet/pdf/pdf_reference.html.

283

Chapter | 5 File Identification and Profiling

Header Object Object

Body

…. Object XREF Trailer FIGURE 5.37–The Portable Document File format

Indirect objects may be referred to from other locations in the file by an indirect reference, or “references,” which contains the object identifier and the keyword “R,” for example: 11 0 R. r Objects that contain a large amount of data (such as images, audio, fonts, movies, page descriptions, and JavaScript) are represented as stream objects or “streams.”68 Streams are identified by the keywords stream and endstream, with any data contained in between the words manifesting as the stream. Although a stream may be of unlimited length, streams are typically compressed to save space, making analysis challenging. Careful attention should be paid to streams during analysis, as attackers frequently take advantage of their large data capacity and embed malicious scripting within a stream inside of an object. Cross Reference (XREF) Table: The XREF table serves as a file index and contains an entry for each object. The entry contains the byte offset of the respective object within the body of the file. The XREF Table is the only element within a PDF file with a fixed format, enabling entries within the table to be accessed randomly.69 Trailer: The end of a PDF file contains a trailer, which identifies the offset location of the XREF table and certain special objects within the file body.70 r

•

•

68

  Portable Document Format Specification (International Standard ISO 32000-1:2008), Section 7.3.8.1. 69   Portable Document Format Specification (International Standard ISO 32000-1:2008), Section 7.5.4, Note 1. 70   Portable Document Format Specification (International Standard ISO 32000-1:2008), Section 7.5.5.

284

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

In addition to the structural elements of a PDF, there are embedded entities for investigative consideration, such as dictionaries, action type keywords, and identifiable compression schemes as described in the next chart.71 u

Keyword

Relevance

/AA

Indicia of an additional-actions dictionary that defined actions that will occur in response to various trigger events affecting the document as a whole.

/Acroform

Interactive form dictionary; indicia that an automated action will occur upon the opening of the document.

/OpenAction

A value specifying a destination that will be displayed, or an action that will occur when the document is opened.

/URI

Indicia that a URI (uniform resource identifier) will be resolved, such as a remote resource containing additional malicious files.

/Encrypt

Indicia that encryption has been applied to the contents of strings and streams in the document to protect its contents.

/Named

Indicia that a predefined action will be executed.

/JavaScript

Indicia that the PDF contains JavaScript.

FlateDecode

Indicia of a compression scheme encoded with the zlib/deflate compression method.

/JBIG2Decode

Indicia of a compression scheme encoded with the JBIG2 compression method.

/JS

Indicia that the PDF contains JavaScript.

/EmbeddedFiles

Indicia of embedded file streams.

/Launch

Indicia that an application will be launched or a file will be opened.

/Objstm

Indicia of an object stream inside the body of the PDF document.

/Pages

An indicator that interactive forms will be invoked.

/RichMedia

Indicia that the PDF contains JavaScript.

71

  Further detail can be found in the PDF specification documentation: Portable Document Format Specification (International Standard ISO 32000-1:2008); International Organization for Standardization (ISO) 2008; Adobe Extensions to ISO 32000-1:2008, Level 5; Adobe Supplement to the ISO 32000-1:2008, Exension Level 3.

Chapter | 5 File Identification and Profiling

285

PDF Profiling Process: CLI Tools u

The following steps can be taken to examine a suspect PDF document: Triage: Scan for Indicators of Malice • Inspect the suspect file for indicators of malice—clues within the file that suggest the file has nefarious functionality—using Didier Stevens’ python utility, pdfid.py. • Pdfid.py scans the document for keywords and provides the digital investigator with a tally of identified keywords that are potentially indicative of a threat, such as those previously described (Figure 5.38). C:Python26>pdfid.py «c:MalwareBeneficial medical programs.pdf» PDFiD 0.0.11 c:MalwareBeneficial medical programs.pdf PDF Header: %PDF-1.5 obj 15 endobj 15 stream 5 endstream 5 xref 1 trailer 1 startxref 1 /Page 1(1) /Encrypt 0 /ObjStm 0 /JS 1 /JavaScript 1(1) /AA 0 /OpenAction 1(1) /AcroForm 1(1) /JBIG2Decode 0 /RichMedia 0 /Launch 0 /Colors > 2^24 0

FIGURE 5.38–Scanning a suspect PDF file with pdfid.py

• An alternative to pdfid.py for triaging a suspect PDF is the pdfscan.rb •

script in Origami, a Ruby framework for parsing and analyzing PDF documents.72 Further, the python utility pdf-parser.py (discussed in greater detail later), when used with the —stats switch, can be used to collect statistics about the objects present in a target PDF file specimen. @

Discover relevant metadata • Meaningful metadata can provide temporal context, authorship, and original document creation details about a suspect file. • Temporal metadata from the suspect file can be gathered with pdfid.py using the —extra switch (Figure 5.39). 72

For more information about Origami, go to http://code.google.com/p/origami-pdf/.

286

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• Deeper metadata extraction, such as author, original document name, and original document creation application, among other details, can be acquired by querying the suspect file with the Origami framework printmetadata.rb script. @ %%EOF

4

——————————-

After last %%EOF

0

Document information dictionary

D:20091217022545+08’00

/CreationDate

——————————-

D:20091217022545+08’00

/ModDate

Author: cj

D:20091217031438+08’00

/CreationDate

CreationDate: D:20091217031438+08’00’

D:20091217031438+08’00

/ModDate

ModDate: D:20091217090825+08’00’

D:20091217031438+08’00

/CreationDate

Title: Microsoft Word — kk.doc

D:20091217031438+08’00

/CreationDate

Creator: PScript5.dll Version 5.2

D:20091217031534+08’00

/ModDate

Producer: Acrobat Distiller 7.0.5 (Windows)

D:20091217090825+08’00

/ModDate

Total entropy:

7.974883 (1226811 bytes)

—————

Entropy inside streams: 7.975323 (1221897 bytes)

Metadata stream

Entropy outside streams: 5.278630 (4914 bytes)

—————DocumentID: uuid:2b22379d-4af0-4711-bf4006edc7f79e3a MetadataDate: 2009-12-17T09:08:25+08:00 Producer: Acrobat Distiller 7.0.5 (Windows) format: application/pdf CreateDate: 2009-12-17T03:14:38+08:00 ModifyDate: 2009-12-17T09:08:25+08:00 title: Microsoft Word — kk.doc creator: cj CreatorTool: PScript5.dll Version 5.2 InstanceID: uuid:2c16cb46-0cbe-41f5-8aca7baf5ae29025

FIGURE 5.39–Metadata gathered from a suspect PDF with the pdfid.py —extra command switch (left) and the Origami framework printmetadata.rb script (right).

Examine the file structure and contents • After conducting an initial assessment of the file, use Didier Stevens’ pdf-parser.py tool to examine the specimen’s file structure and contents to locate suspect embedded artifacts, such as anomalous objects and streams, as well as hostile scripting or shellcode. The following ­commands are useful in probing the PDF file specimen: Command Switch

Purpose

—stats

Displays statistics for the target PDF file

—search

String to search in indirect objects (except streams)

—filter

Pass stream object through filters (FlateDecode ASCIIHex Decode and ASCII85Decode only)

—object=

ID of indirect object to select (version independent)

—reference=

ID of indirect object being referenced (version ­independent) (Continued)

Chapter | 5 File Identification and Profiling

Command Switch

Purpose

—elements=

Type of elements to select (cxtsi)

—raw

Raw output for data and filters

—type=

Type of indirect object to select

—verbose

Displays malformed PDF elements

—extract= —hash

Displays hash of objects

—dump

Dump unfiltered content of a stream

—disarm

Disarms the target PDF file

• An alternative to

pdf-parser.py is the pdfscan.rb script from the Origami framework. @ • Use the information collected with pdfid.py as a guide for examining the suspect file with pdf-parser.py. For instance, the pdfid.py results in Figure 5.38 revealed the presence of JavaScript in the suspect file. Pdf-parser.py can be used to dig deeper into the specimen, such as locating and extracting this script. Locating suspect scripts and shellcode • To locate instances of JavaScript keywords in the suspect file, use the —search switch and the string javascript, as shown in Figure 5.40. The results of the query will identify the relevant objects and references in the file. • The relevant object can be further examined using the —object= switch. In this instance, the output reveals that the object contains a stream that is compressed (Figure 5.41). Decompress suspect stream objects and reveal scripts • Use the —filter and —raw switches to decompress the contents of the stream object and reveal the scripting as shown in Figure 5.42.

C:Python26>pdf-parser.py —search javascript “c:MalwareBeneficial medical programs.pdf” obj 11 0 Type: /Action Referencing: 12 0 R [(1, ‘ n’), (2, »), (1, ‘n’)] >

FIGURE 5.40–Searching the suspect file for embedded JavaScript with pdf-parser.py

288

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

C:Python26>pdf-parser.py —object=12 “c:MalwareBeneficial medical programs.pdf” obj 12 0 Type: Referencing: Contains stream [(2, »)] > >>

FIGURE 5.41–Parsing a specific object with pdf-parser.py

C:Python26>pdf-parser.py —object=12 —raw —filter «c:MalwareBeneficial medical programs.pdf» obj 12 0 Type: Referencing: Contains stream

> //afjp;ajf’klaf

var nXzaRHPbywqAbGpGxOtozGkvQWhu; for(i=0;iofficecat.exe c:MalwareDiscussions.doc Sourcefire OFFICE CAT v2 * Microsoft Office File Checker * Processing c:MalwareDiscussions.doc VULNERABLE OCID: 49 CVE-2008-2244 MS08-042 Type: Word Invalid smarttags structure size

FIGURE 5.48–Scanning a suspect Word document file with officecat 100

For more information about officecat, go to http://www.snort.org/vrt/vrt-resources/officecat.

Chapter | 5 File Identification and Profiling

299

•

Officecat scans the suspect file and compares it against a predefined set of signatures and reports whether the suspect file is vulnerable. A list of the vulnerabilities checked by officecat can be obtained by using the –list switch. • In addition, officecat output: r Identifies the suspect file type r Lists the applicable Microsoft Security Bulletin (MSB) number r Lists the CVE identifier r Provides the unique officecat identification number (OCID) • You can further examine the suspect file for indicators of malice with the Microsoft Office Visualization Tool (OffVis).101 • OffVis is a GUI-based tool that parses binary formatted MS Office files, allowing the digital investigator to traverse the structure and contents of a target file through a triple-paned graphical viewer, which displays: r A view of the raw file contents in a hexadecimal format r A hierarchical content tree view of the parsing results r A Parsing Notes section, which identifies anomalies in the file • When loading a target file into OffVis, select the corresponding applicationspecific parser from the parser drop-down menu, as shown in Figure 5.49. OffVis uses unique binary format detection logic in each application-specific parser to identify 16 different CVE enumerated vulnerabilities; if a vulnerability is discovered in the target file, the Parsing Notes identify the file as Definitely Malicious, as shown in Figure 5.49, below. • By double-clicking on the Definitely Malicious Parsing Note, the raw content of the target file containing the vulnerability is populated in the hexadecimal viewing pane. Discover Relevant Metadata • Meaningful metadata can provide temporal context, authorship, and original document creation details about a suspect file. Insight into this information may provide clues as to the origin and purpose of the attack. • To extract metadata details from the file specimen, query the file with exiftool,102 as shown in Figure 5.50. Examining the metadata ­contents, a number of valuable contextual details are quickly elucidated, such as the Windows code page language (Windows Simplified Chinese), the purported company name in which the license of Word was registered to that it generated the document (VRHEIKER), as well as the file creation, access, and modification dates. • There are a number of others tools that can effectively probe an MS Office document for metadata. However, be mindful that some of these

101

  For more information about OffVis, go to http://blogs.technet.com/b/srd/archive/2009/09/14/ offvis-updated-office-file-format-training-video-created.aspx; http://go.microsoft.com/ fwlink/?LinkId=158791. 102   For more information about exiftool, go to http://www.sno.phy.queensu.ca/~phil/exiftool/.

300

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

FIGURE 5.49–Selecting a parser and examining a suspect MS PowerPoint document with OffVis

C:Malware Labexiftool>exiftool.exe c:MalwareDiscussions.doc ExifTool Version Number : 8.40 File Name : Discussions.doc Directory : c:/Malware File Size : 114 kB File Modification Date/Time : 2010:05:16 01:20:06-07:00 File Permissions : rw-rw-rwFile Type : DOC MIME Type : application/msword Title : Subject : Author : Keywords : Template : Normal.dot Last Modified By : Revision Number : 2 Software : Microsoft Word 11.0 Total Edit Time : 1.0 minutes Create Date : 2007:09:18 04:34:00 Modify Date : 2007:09:18 04:35:00 Pages : 1 Words : 0 Characters : 0 Security : None Code Page : Windows Simplified Chinese (PRC, Singapore) Company : VRHEIKER

FIGURE 5.50–Querying a suspect MS Word file with exiftool (Cont’d)

Chapter | 5 File Identification and Profiling

Lines Paragraphs Char Count With Spaces App Version Scale Crop Links Up To Date Shared Doc Hyperlinks Changed Title Of Parts Heading Pairs Comp Obj User Type Len Comp Obj User Type

: : : : : : : : : : : :

301

1 1 0 9.2812 No No No No ╧∞┬O, 1 20 Microsoft Word ╬─╡╡

FIGURE 5.50­–(Continued)

tools cause the target file to open during the course of being processed, potentially executing embedded malicious code. Be certain to understand how your metadata extraction tool works prior to implementing it during an examination.

Deeper Profiling with OfficeMalScanner OfficeMalScanner is a malicious document forensic analysis suite developed by Frank Boldewin that allows the digital investigator to probe the structures and contents of a binary format MS Office file for malicious artifacts—allowing for a more complete profile of a suspect file.103 • The OfficeMalScanner suite of tools includes: r OfficeMalScanner (malicious MS Office file analysis tool); r DisView (a lightweight disassembler); r MalHost-Setup (extracts shellcode and embeds it into a host Portable Executable file); and r ScanDir (python script to scan an entire directory of malicious ­documents) Each tool will be examined in greater detail in this section. • OfficeMalScanner has five different scanning options that can be used to extract specific data from a suspect file104: u

Scanning Option

Purpose

Info

Parses and displays the OLE structures in the file and saves located VB macrocode to disk.

Scan

Scans the a target file for generic shellcode patterns using the ­following methods: (Continued)

103

  For more information about OfficeMalScanner, go to http://www.reconstructer.org/code.html.   Boldewin, F. (2009). Analyzing MS Office Malware with OfficeMalScanner, http://www .reconstructer.org/papers/Analyzing%20MSOffice%20malware%20with%20OfficeMalScanner .zip and Boldewin, F. (2009). New Advances in MS Office Malware Analysis, http://www .­reconstructer.org/papers/New%20advances%20in%20Ms%20Office%20malware%20analysis.pdf. 104

302

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Scanning Option

Purpose GetEIP

(Four methods) Scans for instances of instructions to locate the EIP (instruction pointer register, or program counter), ­indicating the presence of embedded ­shellcode.

Find Kernel32 base

(Three methods) Scans for the presence of instructions to identify the base address of where the kernel32.dll image is located in memory, a technique used by shellcode to resolve addresses of dependencies.

API Hashing

Scans for the presence of instructions to locate hash values of API function names in memory, indicative of executable code.

Indirect Function calls

Searches for instructions that generate calls to functions that are defined in other files.

Suspicious Strings

Scans for Windows function name strings that are commonly found in malware.

Decryption sequences

Scan searches for indicia of decryption routines.

Embedded OLE Data

Scans for unencrypted OLE compound file signature. Identified OLE data is dumped to disk (OfficeMalScanner directory).

Function prolog

Searches for code instructions relating to the beginning of a function.

PE-File Signature

Scans for unencrypted PE file signature. Identified PE files are dumped to disk (OfficeMalScanner directory).

brute

Scans for files encrypted with XOR and ADD with one-byte key values of 0x00 through 0xFF. Each time a buffer is decrypted, the scanner tries to identify PE files or OLE data; if identified it is dumped to disk (OfficeMalScanner directory).

debug

Scan in which located shellcode is disassembled and displayed in textual disassembly view; located embedded strings, OLE data, and PE files are displayed in a textual hexadecimal viewer.

inflate

Decompresses and extracts the contents of Office Open XML formatted MS Office files (Office 2007–Present) and places them into the examination system’s /Temp directory.

Chapter | 5 File Identification and Profiling

303

• In addition to the information collected with the scanning options, OfficeMalScanner rates scanned files on a malicious index, scoring files based on four variables and associated weighted values; the higher the malware index score, the greater the number of malicious attributes discovered in the file. As a result, the index rating can be used as a triage mechanism for identifying files with certain threshold values.105 Index

Scoring

Executables

20

Code

10

Strings

2

OLE

1

Examine the file structure • The structure of the suspect file can be quickly parsed with OfficeMalScanner using the info switch (Figure 5.51). In addition to displaying the storages and streams, the info switch will extract any VB macro code discovered in the file. C:Malware LabOfficeMalScanner>OfficeMalScanner.exe c:MalwareDiscussions.doc info +——————————————+ | OfficeMalScanner v0.53 | | Frank Boldewin / www.reconstructer.org | +——————————————+ [*] [*] [*] [*]

INFO mode selected Opening file c:MalwareDiscussions.doc Filesize is 117086 (0x1c95e) Bytes Ms Office OLE2 Compound Format document detected

——————————-[OLE Struct of: DISCUSSIONS.DOC] ——————————-1Table [TYPE: Stream — OFFSET: 0x1200 — LEN: 4096] CompObj [TYPE: Stream — OFFSET: 0x4a00 — LEN: 102] ObjectPool [TYPE: Storage] WordDocument [TYPE: Stream — OFFSET: 0x200 — LEN: 4096] SummaryInformation [TYPE: Stream — OFFSET: 0x2200 — LEN: 4096] DocumentSummaryInformation [TYPE: Stream — OFFSET: 0x2200 — LEN: 4096] ———————-No VB-Macro code found!

FIGURE 5.51–Parsing the structure of a suspect Word document file with OfficeMalScanner 105

Boldewin, F., 2009, Analyzing MS Office Malware with OfficeMalScanner, p. 8.

304

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Locating and Extracting Embedded Executables • After gaining an understanding of the suspect file’s structure, examine the suspect file specimen for indicia of shellcode and/or embedded executable files using the scan command. • If unencrypted shellcode, OLE or embedded executable artifacts are discovered in the file, the contents are automatically extracted and saved to disk. In the example shown in Figure 5.52, an embedded OLE artifact is discovered, extracted, and saved to disk.

C:Malware LabOfficeMalScanner>OfficeMalScanner.exe c:MalwareDiscussions.doc scan +——————————————+ | OfficeMalScanner v0.53 | | Frank Boldewin / www.reconstructer.org | +——————————————+ [*] [*] [*] [*] [*]

SCAN mode selected Opening file c:MalwareDiscussions.doc Filesize is 117086 (0x1c95e) Bytes Ms Office OLE2 Compound Format document detected Scanning now…

FS:[00h] signature found at offset: 0x6137 FS:[00h] signature found at offset: 0x64cf API-Hashing signature found at offset: 0x33d4 API-Name GetTempPath string found at offset: 0x7046 API-Name WinExec string found at offset: 0x703c API-Name ShellExecute string found at offset: 0x70d4 API-Name CloseHandle string found at offset: 0x6f2a Embedded OLE signature found at offset: 0x14f5e Dumping Memory to disk as filename: Discussions__EMBEDDED_OLE__OFFSET=0x14f5e.bin Analysis finished! ———————————————————-Discussions.doc seems to be malicious! Malicious Index = 39 ————————————————————

FIGURE 5.52–Using the OfficeMalScanner scan command

• Scan the newly extracted file with the scan and info commands in an effort to gather any further information about the file.

• Many times, shellcode, OLE data, and PE files embedded in malicious

•

MS Office files are encrypted. In an effort to locate these artifacts and defeat this technique, use the OfficeMalScanner scan brute command to scan the suspect file specimen with common decryption algorithms. If files are detected with this method, they are automatically extracted and saved to disk, as shown in Figure 5.53. Examine the extracted executable files through the file profiling process and additional malware forensic techniques discussed in Chapter 6 to gain further insight about the nature, purpose, and functionality of the program.

Chapter | 5 File Identification and Profiling

305

C:Malware LabOfficeMalScanner>OfficeMalScanner.exe c:MalwareDiscussions.doc scan brute +——————————————+ | OfficeMalScanner v0.53 | | Frank Boldewin / www.reconstructer.org | +——————————————+ [*] [*] [*] [*] [*]

SCAN mode selected Opening file c:MalwareDiscussions.doc Filesize is 117086 (0x1c95e) Bytes Ms Office OLE2 Compound Format document detected Scanning now…

FS:[00h] signature found at offset: 0x6137 FS:[00h] signature found at offset: 0x64cf API-Hashing signature found at offset: 0x33d4 API-Name GetTempPath string found at offset: 0x7046 API-Name WinExec string found at offset: 0x703c API-Name ShellExecute string found at offset: 0x70d4 API-Name CloseHandle string found at offset: 0x6f2a Embedded OLE signature found at offset: 0x14f5e

Dumping Memory to disk as filename: Discussions__EMBEDDED_OLE__OFFSET=0x14f5e.bin Brute-forcing for encrypted PE- and embedded OLE-files now… XOR encrypted MZ/PE signature found at offset: 0x9c04 — encryption KEY: 0xce Dumping Memory to disk as filename: Discussions__PEFILE__OFFSET=0x9c04__XORKEY=0xce.bin Bruting XOR Key: 0xff Bruting ADD Key: 0xff

Analysis finished! ————————————————————Discussions.doc seems to be malicious! Malicious Index = 59 ————————————————————

FIGURE 5.53–OfficeMalScanner scan brute mode detecting and extracting a PE embedded file

Examine Extracted Code • To confirm your findings use the scan brute debug command combination to display a textual hexadecimal view output of the discovered and decrypted portable executable file, as shown in Figure 5.54, below. • The scan debug command can be used to examine discovered (unencrypted) shellcode, PE, and OLE files in greater detail. r Identified shellcode artifacts can be cursorily disassembled and displayed in a textual disassembly view. r Identified PE and OLE file artifacts are displayed in a textual hexadecimal view. • Debug mode is helpful for identifying the offset of embedded shellcode in a suspect MS Office file and gaining further insight into the functionality of the code, as depicted in Figure 5.55.

306

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Brute-forcing for encrypted PE- and embedded OLE-files now… XOR encrypted MZ/PE signature found at offset: 0x9c04 — encryption KEY: 0xce Dumping Memory to disk as filename: Discussions__PEFILE__OFFSET=0x9c04__XORKEY=0xce.bin

[ PE-File (after decryption) 4d 5a 90 00 03 00 00 00 04 00 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0e 1f ba 0e 00 b4 09 cd 21 b8 69 73 20 70 72 6f 67 72 61 6d 74 20 62 65 20 72 75 6e 20 69 6d 6f 64 65 2e 0d 0d 0a 24 00

256 bytes ] 00 00 ff ff 00 00 00 00 00 00 00 00 00 00 e0 00 01 4c cd 21 20 63 61 6e 6e 20 44 4f 00 00 00 00

00 00 00 00 54 6e 53 00

00 00 00 00 68 6f 20 00

| | | | | | | |

MZ………….. [email protected] ……………. ……………. ……..!..L.!Th is program canno t be run in DOS mode….$…….

FIGURE 5.54–Examining an embedded PE file using OfficeMalScanner

C:Malware LabOfficeMalScanner>OfficeMalScanner.exe c:MalwareDiscussions.doc scan debug +——————————————+ | OfficeMalScanner v0.53 | | Frank Boldewin / www.reconstructer.org | +——————————————+ [*] [*] [*] [*] [*]

SCAN mode selected Opening file c:MalwareDiscussions.doc Filesize is 117086 (0x1c95e) Bytes Ms Office OLE2 Compound Format document detected Scanning now…

FS:[00h] signature found at offset: 0x6137 64A100000000 mov eax, fs:[00h] 50 push eax 64892500000000 mov fs:[00000000h], esp 81EC34080000 sub esp, 00000834h 53 push ebx 55 push ebp 56 push esi 57 push edi 33DB xor ebx, ebx B9FF000000 mov ecx, 000000FFh 33C0 xor eax, eax 8DBC2445040000 lea edi, [esp+00000445h] 889C2444040000 mov [esp+00000444h], bl 885C2444 mov [esp+44h], bl F3AB rep stosd 66AB stosw ———————————————————-FS:[00h] signature found at offset: 0x64cf 64A100000000

mov eax, fs:[00h]

FIGURE 5.55–Examining a malicious Word document file using OfficeMalScanner in debug mode (Cont’d)

307

Chapter | 5 File Identification and Profiling

50 push eax 64892500000000 mov fs:[00000000h], esp 83EC20 sub esp, 00000020h 53 push ebx 56 push esi 57 push edi 8965E8 mov [ebp-18h], esp 8365FC00 and [ebp-04h], 00000000h 6A01 push 00000001h FF15E8204000 call [004020E8h] 59 pop ecx 830DC0314000FF or [004031C0h], FFFFFFFFh 830DC4314000FF or [004031C4h], FFFFFFFFh FF15E4204000 call [004020E4h] 8B0DB8314000 mov ecx, [004031B8h] ———————————————————-

FIGURE 5.55–(Continued)

Locating and Extracting Shellcode with DisView and MalHost-Setup • If deeper probing of the shellcode is necessary, the DisView (DisView.exe) utility—a lightweight disassembler included with the OfficeMalScanner suite—can further disassemble the target code. • To use DisView, invoke the command against the target file name and relevant memory offset. In Figure 5.56, the offset 0x64cf was selected as it was previously identified by the scan debug command as an offset with a shellcode pattern (“Find kernel32 base” pattern). Identifying the correct memory offset may require some exploratory probing of different offsets.

C:Malware LabOfficeMalScanner>DisView.exe C:MalwareDiscussions.doc Filesize is 117086 (0x1c95e) Bytes 000064CF: 64A100000000 000064D5: 50 000064D6: 64892500000000 000064DD: 83EC20 000064E0: 53 000064E1: 56 000064E2: 57 000064E3: 8965E8 000064E6: 8365FC00 000064EA: 6A01 000064EC: FF15E8204000 000064F2: 59 000064F3: 830DC0314000FF 000064FA: 830DC4314000FF 00006501: FF15E4204000

mov eax, fs:[00h] push eax mov fs:[00000000h], esp sub esp, 00000020h push ebx push esi push edi mov [ebp-18h], esp and [ebp-04h], 00000000h push 00000001h call [004020E8h] pop ecx or [004031C0h], FFFFFFFFh or [004031C4h], FFFFFFFFh call [004020E4h]

FIGURE 5.56–Examining a suspect file with DisView

0x64cf

308

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• Once the relevant offset is located, the shellcode can be extracted and •

embedded into a host executable file generated by MalHost-Setup (MalHost-Setup.exe). To use MalHost-Setup, invoke the command against the target file, provide the name of the newly generated executable file, and identify the relevant memory offset as shown in Figure 5.57.

C:Malware LabOfficeMalScanner>MalHost-Setup.exe C:MalwareDiscussions.doc out. exe 0x64cf +——————————————+ | MalHost-Setup v0.12 | | Frank Boldewin / www.reconstructer.org | +——————————————+ [*] [*] [*] [*] [*]

Opening file C:MalwareDiscussions.doc Filesize is 117086 (0x1c95e) Bytes Creating Malhost file now… Writing 172382 bytes Done!

FIGURE 5.57–MalHost-Setup

• After the executable has been generated, it can be further examined with using static and dynamic analysis tools and techniques.

Profiling Microsoft Compiled HTML Help Files (CHM)

R Although not as prevalent as PDF or Microsoft Office document malware, Microsoft Compiled HTML Help Files (CHM) can be used as a vector of attack, particularly as a vehicle for Trojan Horse malware. u CHM files have a proprietary Microsoft file format. The files typically consist of a series of HTML pages and associated hyperlinks, compressed with LZX file compression. • Attackers use malicious scripting to automatically invoke a malicious file upon rendering of the help file contents. • The malicious scripting often invokes a malicious binary, such as a Windows executable or ActiveX control file, that is surreptitiously embedded into the CHM file by the attacker. • In many instances the malicious scripting will be hexadecimal encoded cipher text, adding an additional layer of analysis. • In addition to invoking a locally embedded binary, scripting can also query an encoded URL to retrieve additional malicious files.

CHM Profiling Process u

The following steps can be taken to examine a suspect CHM document: Triage: Identify Indicators of Malice.

Chapter | 5 File Identification and Profiling

309

• Query the suspect CHM file for anomalous strings, such as references to Windows Portable Executable files, ActiveX control files, or other executable file types. Often, these embedded artifacts are discoverable in plaintext strings. Discover Relevant Metadata • Unlike other document types, the CHM file structure does not store a vast amount of metadata. However, meaningful metadata providing temporal and situational context about the suspect CHM file can be acquired. • Metadata can be extracted with exiftool,106 NLNZ Metadata Extractor,107 and other utilities (Figure 5.58). C:Malware Labexiftool>exiftool.exe C:Malware LabUserGuide.chm ExifTool Version Number : 8.40 File Name : UserGuide.chm Directory : C:/Malware File Size : 145 kB File Modification Date/Time : 2007:11:08 08:17:02-08:00 File Permissions : rw-rw-rw-

FIGURE 5.58–Querying a suspicious CHM file with exiftool

Examine the File Structure and Contents • Decompile a suspect CHM file to look deeper into its file structure and contents. • CHM Decoder,108 a GUI-based utility, can be used to decompile a suspect file—resulting in the extraction and separation of file elements into individual files for closer examination. @ • To use CHM Decoder, select a target file, identify the location where the output should be saved, and process the file, as shown in Figure 5.59. • Closer inspection of the extracted file content reveals a suspicious executable file, “winhelp.exe,” which was embedded within the CHM file specimen. File identification and profiling can be conducted on this executable file to gain further insight into its nature and purpose. Further, if the file is indeed malicious, deeper dynamic and static analysis should be conducted to determine the scope of its functionality. Locating Suspect Scripts • Malicious executables concealed inside of CHM files are typically triggered as a linked or an embedded resource through HTML scripting. Be sure to examine HTML files extracted as a result of decompiling a CHM file. 106

For more information about exiftool, go to http://www.sno.phy.queensu.ca/~phil/exiftool/. For more information about the National Library of New Zealand (NLNZ) Metadata Extractor, go to http://meta-extractor.sourceforge.net/. 108 For more information about CHM Decoder, go to http://www.gridinsoft.com/chm.php. 107

310

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS 1

3

2

4

FIGURE 5.59–Decompiling a suspicious CHM file with CHM Decoder

• In examining the extracted file, AOC2007.html, depicted in Figure 5.60, the triggering mechanism of the winhelp.exe file is discovered:

colSpan=3>

FIGURE 5.60–Executable file triggering mechanism within HTML

Identifying and Decoding Obfuscated Scripts • It is not uncommon for attackers to conceal the triggering method by obfuscating the HTML scripting responsible for invoking the embedded executable file. Often, in malicious CHM files, the obfuscation method is hexadecimal cipher text encoded in JavaScript unescape or escape functions. • This obfuscation method is also used to conceal malicious VBScript embedded within HTML, which invokes requests for malicious files hosted on remote URLs.

Chapter | 5 File Identification and Profiling

311

• In Figure 5.61, the contents of a decompiled suspect CHM file reveal a suspicious ActiveX control file, “xpreload.ocx,” and the triggering mechanism (in clear text) within the page.html file. The decrypted hexadecimal cipher text reveals a call for the download of additional malware from a remote URL.

FIGURE 5.61–Obfuscated scripting within HTML

CONCLUSION

• Preliminary static analysis in a Windows environment of a suspect file can •

•

yield a wealth of valuable information that will shape the direction of future dynamic and more complete static analysis of the file. Through a logical, step-by-step file identification and profiling process, and using a variety of different tools and approaches, a meaningful file profile can be ascertained. There are a wide variety of tools for conducting a file profile, many of which were demonstrated in this chapter. Independent of the tools used and the specific suspect file examined, there is a need for a file profiling methodology to ensure that data are acquired in as consistent and repeatable a manner as possible. For forensic purposes, it is also necessary to maintain detailed documentation of the steps taken on a suspect file. Refer to the Field Notes at the end of this chapter for documentation guidance.

312

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

• The methodology in this chapter provides a robust foundation for the forensic identification and profiling of a target file. This methodology is not intended as a checklist and may need to be altered for certain situations, but it does increase the chances that much of the relevant data will be obtained to build a file profile. Furthermore, this methodology and the supporting documentation will strengthen malware forensics as a source of evidence, enabling an objective observer to evaluate the reliability and accuracy of the file profiling process and acquired data.

Chapter | 5 File Identification and Profiling

313

M Pitfalls to Avoid Submitting sensitive files to online anti-virus scanning services or analysis sandboxes  Do not submit a suspicious file that is the crux of a sensitive investigation (i.e., circumstances in which disclosure of an investigation could cause irreparable harm to a case) to online analysis resources such as anti-virus scanning services or sandboxes in an effort not to alert the attacker. R By submitting a file to a third-party Web site, you are no longer in control of that file or the data associated with that file. Savvy attackers often conduct extensive open source research and search engine queries to determine if their malware has been detected.

R The results relating to a submitted file to an online malware analysis service are publicly available and easily discoverable—many portals even have a search function. Thus, as a result of submitting a suspect file, the attacker may discover that his malware and nefarious actions have been discovered, resulting in the destruction of evidence and potentially damaging your investigation. Conducting an incomplete file profile

 An investigative course of action should not be based upon an incomplete file profile. R Fully examine a suspect file in an effort to render an informed and intelligent decision about what the file is, how it should be categorized or analyzed, and in turn, how to proceed with the larger investigation.

R Take detailed notes during the process, not only about the suspicious file but also about each investigative step taken. Consult the Field Notes located in the Appendices in this chapter for additional guidance and a structured note taking format. Relying upon file icons and extensions without further context or deeper examination  Neither the file icon nor file extension associated with a suspect file should be presumed to be accurate. R In conducting digital investigations, never presume that a file extension is an accurate representation. File camouflaging, or a technique that obfuscates the true nature of a file by changing and hiding file extensions in locations with similar real file types, is a trick commonly

314

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

used by hackers and bot herders to avoid detection of malicious code distribution.

R Similarly, the file icon associated with a file can easily be modified by an attacker to appear like a contextually appropriate or innocuous file. The file icon associated with a Windows Portable Executable file can be inserted or modified in the file Resources section. Solely relying upon anti-virus signatures or third-party analysis of a “similar” file specimen

 Although anti-virus signatures can provide insight into the nature of identified malicious code, they should not be solely relied upon to reveal the purpose and functionality of a suspect program. Conversely, the fact that a suspect file is not identified by anti-virus programs does not mean that it is innocuous.  Third-party analysis of a “similar” file specimen can be helpful guidance; it should not be considered dispositive in all circumstances. R Anti-virus signatures are typically generated based upon specific data contents or patterns identified in malicious code. Signatures differ from heuristics—identifiable malicious behavior or attributes that are non-specific to a particular specimen (commonly used to detect zeroday threats that have yet to be formally identified with a signature).

R Anti-virus signatures for a particular identified threat vary between

anti-virus vendors,109 but many times, certain nomenclature, such as a malware classification descriptor, is common across the signatures (e.g., the words “Trojan,” “Dropper,” and “Backdoor” may be used in many of the vendor signatures). These classification descriptors may be a good starting point or corroborate your findings, but should not be considered dispositive; rather, they should be taken into consideration toward the totality of the file profile.

R Conversely, if there are no anti-virus signatures associated with a suspect file, it may mean simply that a signature for the file has not been generated by the vendor of the anti-virus product, or that the attacker has successfully (albeit likely temporarily) obfuscated the malware to thwart detection.

R Third-party analysis of a similar malware specimen by a reliable source can be an incredibly valuable resource, and may even provide predictors of what will be discovered in your particular specimen. 109

  The wide variety of anti-virus signature names for certain threats caused the Mitre Corporation to create the Common Malware Enumeration project “[t]o provide single, common identifiers to new virus threats and to the most prevalent virus threats in the wild to reduce public confusion during malware incidents.” See http://cme.mitre.org/index.html.

Chapter | 5 File Identification and Profiling

315

Although this correlative information should be considered in the totality of your investigation, it should not replace thorough independent analysis. Examining a suspect file in a forensically unsound laboratory ­environment  Suspect files should never be examined in a production environment or on a system that has not been forensically baselined to ensure that it is free of misleading artifacts. R Forensic analysis of potentially damaging code requires a safe and secure lab environment. After extracting a suspicious file from a victim system, place the file on an isolated or “sandboxed” system or network, to ensure that the code is contained and unable to connect to or otherwise affect any production system.

R Even though only a cursory static analysis of the code is contemplated at this point of the investigation, executable files nonetheless can be accidentally executed fairly easily, potentially resulting in the contamination of or damage to production systems.

R It is strongly encouraged to examine malicious code specimens in a predesigned and designated malicious code laboratory, which can even be a field deployable laptop computer. The lab system should be revertible, that is, using a virtualization or host-based software solution that allows the digital investigator to restore the state of the system to a designated baseline configuration.

R The baseline configuration in which specimens are examined should be thoroughly documented and free from artifacts associated with other specimens, resulting in forensic unsoundness, false positives, and mistaken analytical conclusions. Basing conclusions upon a file profile without additional context or correlation  Do not make investigative conclusions without considering the totality of the evidence. R A file profile must be reviewed and considered in context with all of the digital and network-based evidence collected from the incident scene. Navigating to malicious URLS and IP addresses  Exercise caution and discretion in visiting URLs and IP addresses embedded in, or associated with, a target malware specimen.

316

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

R These resources might be an early warning and indicator capability employed by the attacker to notify him/her that the malware is being examined.

R Logs from the servers hosting these resources are of great investigative value (i.e., other compromised sites, visits from the attacker[s], etc.) to law enforcement, Computer Emergency Response Teams (CERTs), and other professionals seeking to remediate the malicious activity and identify the attacker(s). Visits by those independently researching the malware will leave network impression evidence in the logs.

Chapter | 5 File Identification and Profiling

317

SELECTED READINGS Papers Blonce, A., and Filiol, E., (2008). Portable Document File (PDF) Security Analysis and Malware Threats. In the Proceedings of Black Hat Europe 2008, http://www.blackhat.com/presentations/ bh-europe-08/Filiol/Presentation/bh-eu-08-filiol.pdf. Boldewin, F. (2009). Analyzing MS Office Malware with OfficeMalScanner, http://www.reconstructer .org/papers/Analyzing%20MSOffice%20malware%20with%20OfficeMalScanner.zip. Boldewin, F. (2008). New Advances in MS Office Malware Analysis, http://www.reconstructer.org/ papers/New%20advances%20in%20Ms%20Office%20malware%20analysis.pdf. Dan, B. (2008). Methods for Understanding and Analyzing Targeted Attacks with Office ­Documents. In the Proceedings of Black Hat Japan, 2008, http://www.blackhat.com/presentations/bh-jp-08/ bh-jp-08-Dang/BlackHat-Japan-08-Dang-Office-Attacks.pdf. Raynal, F., Delugré, G., and Aumaitre, D. (2010). Malicious PDF Origamis Strike Back. In the Proceedings of HACK.LU, 2009, www.security-labs.org/fred/docs/hack.lu09-origamis-strike -back.pdf. Raynal, F., and Delugré, G. (2008). Malicious Origami in PDF. In the Proceedings of the PacSec Conference, 2008, www.security-labs.org/fred/docs/pacsec08/pacsec08-fr-gd-full.pdf. Stevens, D. (2011). Malicious PDF Documents Explained, IEEE Security & Privacy Magazine, Vol. 9, No. 1. Stevens, D. (2010). Malicious PDF Analysis E-book. In the Proceedings of BruCON, 2010, http:// didierstevens.com/files/data/malicious-pdf-analysis-ebook.zip. Stevens, D. (2010). Malicious PDF Documents, ISSA Journal, Issue 7/2010, https://www.issa.org/ Library/Journals/2010/July/Stevens-Malicious%20PDF%20Documents.pdf. Stevens, D. (2010). Stepping Through a Malicious PDF Document, HITB Magazine, Issue 4, http:// magazine.hitb.org/issues/HITB-Ezine-Issue-004.pdf. Stevens, D. (2009). Anatomy of Malicious PDF Documents, HAKIN9 IT Security Magazine, Issue 6/2009. Tzermias, Z. et al. (2011). Combining Static and Dynamic Analysis for the Detection of Malicious Documents. In Proceedings of the 4th European Workshop on System Security (EuroSec), April 2011.

Online Resources Holz, T. (2009). Analyzing Malicious PDF Files, http://honeyblog.org/archives/12-Analyzing -Malicious-PDF-Files.html. Selvaraj, K., and Gutierres, N. F. (2010). The Rise of PDF Malware, http://www.symantec.com/connect/ blogs/rise-pdf-malware; http://www.symantec.com/content/en/us/enterprise/media/security_ response/whitepapers/the_rise_of_pdf_malware.pdf. Zdrnja, B. (2010). Sophisticated, Targeted Malicious PDF Documents Exploiting CVE-2009-4324, http://isc.sans.edu/diary.html?storyid=7867. Zeltser, L. (2010). Analyzing Malicious Documents Cheat Sheet, http://zeltser.com/reverse-malware/ analyzing-malicious-documents.html; http://zeltser.com/reverse-malware/analyzing-maliciousdocument-files.pdf.

318

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

TECHNICAL SPECIFICATIONS Microsoft Office File Formats: http://msdn.microsoft.com/en-us/library/cc313118.aspx Microsoft Office File Format Documents: http://msdn.microsoft.com/en-us/library/cc313105.aspx Microsoft Office Binary (doc, xls, ppt) File Formats: http://www.microsoft.com/interop/docs/officebinaryformats.mspx Microsoft Compound Binary File Format: http://msdn.microsoft.com/en-us/library/dd942138%28PROT.13%29.aspx http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf -a657e5900cd3/%5BMS-CFB%5D.pdf Microsoft Word (.doc) Binary File Format: http://msdn.microsoft.com/en-us/library/cc313153.aspx http://download.microsoft.com/download/2/4/8/24862317-78F0-4C4B -B355-C7B2C1D997DB/%5BMS-DOC%5D.pdf http://download.microsoft.com/download/5/0/1/501ED102-E53F -4CE0-AA6B-B0F93629DDC6/Word97-2007BinaryFileFormat(doc) Specification.pdf Microsoft PowerPoint (.ppt) Binary File Format: http://msdn.microsoft.com/en-us/library/cc313106.aspx http://download.microsoft.com/download/2/4/8/24862317-78F0-4C4B -B355-C7B2C1D997DB/%5BMS-PPT%5D.pdf http://download.microsoft.com/download/5/0/1/501ED102-E53F-4CE0 -AA6B-B0F93629DDC6/PowerPoint97-2007BinaryFileFormat(ppt) Specification.pdf Microsoft Excel (.xls) Binary File Format: http://msdn.microsoft.com/en-us/library/cc313154.aspx http://download.microsoft.com/download/2/4/8/24862317-78F0-4C4B -B355-C7B2C1D997DB/%5BMS-XLS%5D.pdf http://download.microsoft.com/download/5/0/1/501ED102-E53F -4CE0-AA6B-B0F93629DDC6/Excel97-2007BinaryFileFormat(xls) Specification.pdf Portable Document Format (PDF): http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/ devnet/pdf/pdfs/PDF32000_2008.pdf

Chapter | 5 File Identification and Profiling

319

320

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Strings Domain Name(s)

IP Addresses

E-mail Addresses

Nickname(s)/ Identifier(s)

Program Command(s)

Registry Reference(s)

Other:

File Dependencies Statically linked Dynamically linked

Dependencies identified:

Yes

No

Dynamic Link Library (.dll) Name

Purpose

Associated API Reference

Symbolic References Symbols have been stripped Symbols are present Symbols identified: Symbol Name

Yes

No Purpose

Associated API Reference

321

Chapter | 5 File Identification and Profiling

Metadata Author/Creator: Creation Date: Modification Date: File Type: MIME Type: Machine Type: Compilation Time Stamp: Programming Language: Compiler: Linker Version: Entry Point: Target OS Type:

File Version Number: Product Version Number: Language Code: Character Set: File Description: File Version: Internal Name: Legal Copyright: Original Filename: Product Name: Product Version: Other:

Notes:

File Obfuscation File examined for obfuscation

Yes

No

File obfuscation detected

Yes

No

Obfuscation Type: Packing Signature:___________________________________ Signature:___________________________________ Cryptor Signature:___________________________________ Signature:___________________________________ Binder Signature:___________________________________ Signature:___________________________________

File Submitted to File Unpacking Service(s)

Notes:

Ether

Successfully Extracted

Yes

No

Renovo (in BitBlaze)

Successfully Extracted

Yes

No

Jsunpack

Successfully Extracted

Yes

No

322

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

PE File Structure and Contents Export

Table

Import

Table

File Signature: Signature

r S Heade ER) MS-DO AD DOS_HE (IMAGE_

Table

e Resourc

on Table

Excepti

MS-DOS

te Table

Certifica

ation se Reloc

er PE Head DERS) NT_HEA ) (IMAGE_ E_HEADER ) FIL ER (IMAGE_ L_HEAD TIONA OP E_ (IMAG

on

Debugg

reData

ctu Archite

Thread

ectory Data Dir ORY) _DIRECT E_DATA

)

rage(TLS

(IMAG

le ration Tab

nfigu

Load Co Bound

Import

dress Table ad

Table Address

Import

Target platform/processor: Number of sections in the Section Table: ER LE_HEAD

re

gnatu

PE Si

HEADER

AL_ _OPTION

IMAGE

ctory Data Dire TORY) ATA_DIREC (IMAGE_D

Register

Local Sto

Time and date the file was compiled/created:

nnot be gram ca .» “This pro in DOS mode run IMAGE_FI

ormati ing Inf

Pointer

Entry Point Address:

e_Ifanew

Table

Ba

Global

Stub

“MZ”

File characteristics: Linker version: Target Operating System: PE Resources: Version Information:

.text

Other items of interest:

.data

Table Section _HEADER) SECTION

(IMAGE_

.rsrc

.reloc

scriptor

port De

DelayIm

ss

r addre

Rheade

The CL

d

Reserve

Additional Notes:

Full file profile performed on PE file specimen after extraction from obfuscation code [on separate File Profiling Notes: Suspicious File form]: Yes No

323

Chapter | 5 File Identification and Profiling

File Profiling Notes: Suspicious PDF File Case Number:

Date/Time:

Investigator: File Identifiers Source from which file was acquired: File Name:

Date acquired:

Size:

MD5: SHA1: File Similarity Index (FSI) matches: File Identified in Online Hash Repository(s): _____________________________________ _____________________________________

Metadata of Value: Subject: Author: Create Date: Modify Date Keywords: Original Document Title:

File Appearance:

File Content Visualization:

Creator Tool: Producer: Instance ID: Words: Characters: Pages: Security: Other: _______________

Anti-virus Signatures: Signature: Vendor: _________________________ ________________ _________________________ ________________ _________________________ ________________ _________________________ ________________ _________________________ ________________ _________________________ ________________ File Submitted to Online Virus Scanning Engines: Identified as Malicious? VirusTotal Yes No VirScan

Identified as Malicious?

Yes

No

Jotti

Identified as Malicious?

Yes

No

Metascan

Identified as Malicious?

Yes

No

File Submitted to Sandboxes: Norman BitBlaze JoeSecurity MalOffice Wepawet Vi.Check.ca

Yes Yes Yes Yes Yes Yes

File Submitted via Online URL Scanners: Identified as Malicious? JSunpack Yes Wepawet Identified as Malicious? Yes Identified as Malicious? AVG Yes URLVoid Yes Identified as Malicious? VirusTotal Identified as Malicious? Yes Identified as Malicious? Pareto Yes

No No No No No No

No No No No No No

Common Vulnerabilities and Exposures (CVE) identified: 1) 2) 3) 4) 5) 6) 7)

CVECVECVECVECVECVECVE-

—

: : : : : : :

Description:_____________________________________________________ Description:_____________________________________________________ Description:_____________________________________________________ Description:_____________________________________________________ Description:_____________________________________________________ Description:_____________________________________________________ Description:_____________________________________________________

324

MALWARE FORENSICS FIELD GUIDE FOR WINDOWS SYSTEMS

Strings Domain Name(s)

IP Addresses

E-mail Addresses

Nickname(s)/ Identifier(s)

Program Registry Command(s) Reference(s)

Other:

Triage File scanned to identify indicators of malice: Tool used: Indicator(s) of malice identified: Yes: No: ______________________________ ______________________________ ______________________________ ______________________________

Indicator /AA /Acroform /EmbeddedFile /Encrypt /FlateDecode /JavaScript /JS /JBIG2Decode /Launch /Names /Objstm /OpenAction /Page /RichMedia /URI

Number of Instances

Object Number

File Structure and Contents Anomalous Object(s) Identified: Yes: Object #:_______________________________________________________ Object #:_______________________________________________________ Object #:_______________________________________________________ Object #:_______________________________________________________ No

Chapter | 5 File Identification and Profiling

Anomalous Stream(s) Identified: Yes: Object #:_______________________________________________________ Object #:_______________________________________________________ Object #:_______________________________________________________ Object #:_______________________________________________________ No Suspect/Malicious Script(s) Identified: Yes Object #:_______________________________________________________ Object #:_______________________________________________________ Object #:_______________________________________________________ Object #:_______________________________________________________ No Embedded Shellcode Discovered: Yes Object #:_______________________________________________________ Object #:_______________________________________________________ Object #:_______________________________________________________ Object #:_______________________________________________________ No

Malicious Scripts 0DOLFLRXV6FULSW,GHQWLILHG

6FULSW7SH 6FULSW([WUDFWHGDQG6DYHG 6DYHG6FULSW1DPH 6L]H 0′ 6+$ )LOH6LPLODULW,QGH[)6, 0DWFKHV 6FULSWLVREIXVFDWHG BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 6FULSWLQYRNHVHPEHGGHGVKHOOFRGH BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 6FULSWLQYRNHVQHWZRUNUHTXHVWIRUDGGLWLRQDOILOHV BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB

pdftk.exe c:MalwarePDFsCMSIconf.pdf dump_data InfoKey: ModDate InfoValue: D:20100629103444+08’00’ InfoKey: CreationDate InfoValue: D:20100629103353+08’00’ PdfID0: c86a7444fab1b41a530d5d29cc77d7a PdfID1: 897f9215590643a9a3d611ffe01aa0 NumberOfPages: 1

Name: Jsunpack-n

Page Reference: 290 Author/Distributor: Blake Hartstein Available From: https://code.google.com/p/jsunpack-n/; Jsunpack: http://jsunpack.jeek.org/dec/go Description: Jsunpack-n, “a generic JavaScript unpacker,” is a suite of tools written in python designed to emulate browser functionality when navigating to URLs. Although a powerful tool for researchers to idenfity client-side browser vulnerabilities and exploits, Jsunpack-n is also a favorite tool of digital investigators to examine suspect PDF files and extract embedded Javascript. In the figure below, the pdf.py script is used to extract JavaScript from a suspect PDF file specimen and write it to a separate file for further analysis.

[email protected]:~/Tools/Linux/jsunpack-n$ ./pdf.py /home/malwarelab/Desktop/merry_christmas UNZIPPED.pdf processing /home/malwarelab/Desktop/merry_christmas UNZIPPED.pdf!!! parsing /home/malwarelab/Desktop/merry_christmas UNZIPPED.pdf failed to decompress object 26 0 Found JavaScript in 31 0 (3106 bytes) children [] tags [[‘Filter’, »], [‘FlateDecode’, »], [‘Length’, ‘1213’]] indata = streamHVmOG8Yd)}$PpEZ)io^y=Ytp5a~=

Eoghan Casey is a professor of Digital Forensic Science and Investigation in the School of Criminal Sciences at the University of Lausanne. For nearly two decades, he has dedicated himself to advancing the practices of digital forensics and intrusion investigation. He has extensive experience working in digital forensic laboratories in the public and private sectors, and he has analyzed many types of digital evidence to support complex cases. He has consulted with many attorneys, agencies, and police departments in the United States, South America, and Europe on a wide range of digital investigations, including fraud, violent crimes, identity theft, and on-line criminal activity. He has delivered expert testimony in civil and criminal matters, and has submitted expert reports and prepared trial exhibits for computer forensic and cyber-crime cases. He has helped organizations investigate and recover from security breaches, including network intrusions with international scope. He has helped develop new capabilities for extracting and analyzing digital evidence, including smartphones and networks.

In his former role as Chief Scientist of the Defense Cyber Crime Center (DC3), which houses one of the largest accredited digital forensic laboratories in the world, Dr. Casey prioritized research and development across multiple organizational units, and provided strategic and technical guidance to navigate evolving challenges in digital forensics and intrusion investigation. Dr. Casey also contributed directly to DC3 operations, performing advanced technical analysis of multi-faceted problems in order to determine the root cause and provide rational explanations supported by digital evidence.

Dr. Casey wrote the foundational book Digital Evidence and Computer Crime, now in its third edition, and he created advanced smartphone forensics courses taught worldwide. He has also coauthored several advanced technical books including Malware Forensics, and the Handbook of Digital Forensics and Investigation. Since 2004, he has been Editor-in-Chief of Digital Investigation: The International Journal of Digital Forensics & Incident Response, publishing cutting edge work by and for practitioners and researchers. He serves on the Digital Forensic Research Workshop (DFRWS) Board of Directors and helps organize biannual digital forensic research conferences. He also contributes to forensic science definitions, guidelines, and standards as Executive Secretary of the Digital/Multimedia Scientific Area Committee (DMSAC) of the Organization for Scientific Area Committees (OSAC).​