On the Viability of Memory Forensics in Compromised Environments

Total Page:16

File Type:pdf, Size:1020Kb

On the Viability of Memory Forensics in Compromised Environments On the Viability of Memory Forensics in Compromised Environments Zur Praktikabilit¨atvon Hauptspeicherforensik in kompromittierten Umgebungen Der Technischen Fakult¨atder Friedrich-Alexander-Universit¨at Erlangen-N¨urnberg zur Erlangung des Grades DOKTOR-INGENIEUR vorgelegt von Johannes Stuettgen aus Herdecke Als Dissertation genehmigt von der Technischen Fakult¨atder Friedrich-Alexander-Universit¨at Erlangen-N¨urnberg Tag der m¨undlichen Pr¨ufung: 28.05.2015 Vorsitzende des Promotionsorgans: Prof. Dr.-Ing. habil. Marion Merklein Gutachter: Prof. Dr.-Ing. Felix Freiling Prof. Dr. Michael Meier Abstract Memory forensics has become a powerful tool for the detection and analysis of ma- licious software. It provides investigators with an impartial view of a system, expos- ing hidden processes, threads, and network connections, by acquiring and analyzing physical memory. Because malicious software must be at least partially resident in memory in order to execute, it cannot remove all its traces from RAM. However, the memory acquisition process is vulnerable to subversion in compromised envi- ronments. Malicious software can employ anti-forensic techniques to intercept the acquisition and filter memory contents while they are copied. In this thesis, we analyze 12 popular memory acquisition tools for Windows, Linux, and Mac OS X, and study their implementation in regard to how they enumerate and map memory. We find that all of the analyzed programs use the operating system to perform these tasks, and further illustrate this by implementing an open source memory acquisition framework for Mac OS X. In a survey of kernel rootkit techniques, that prevent or filter physical memory access, we show that all 12 tested programs are vulnerable to anti-forensics, because they rely on the operating system for critical functions. To elliminate this vulnerability, we develop an operating system independent ap- proach that directly utilizes the hardware to enumerate and map memory. By inter- acting with the PCI controller, we are able to safely avoid memory mapped device buffers while acquiring the entire physical address space. We program the page tables directly to map memory, forcing the MMU to facilitate arbitrary physical memory access from our driver’s data segment. We implement our techniques into the open source memory acquisition frameworks Winpmem, Pmem, and OSXPmem, further- ing the capabilities of memory acquisition software on the Windows, Linux, and Mac OS X platforms. Finally, we apply our novel technique to related problems in memory forensics. Memory acquisition software for Linux can only be run on a system with the exact same kernel version and configuration as the system it was compiled on, dueto dependencies on kernel data structures. We are able to create a minimal, kernel independent version of our module, which we inject into a compatible host module on the target. By hijacking the hosts data structures, we are able to load the infected module, redirect control flow, and communicate with it using a character device. A second innovative property of our acquisition approach is that, because we can enumerate the location of memory mapped device buffers, we are able to safely access memory regions unknown to the operating system. This allows us to acquire malicious firmware during of the memory acquisition process. We present asurvey on firmware code and data in the physical address space, and show how wecan capture the BIOS, PCI option ROMs, and the ACPI tables using our approach. We implement plugins for the open source memory analysis framework Volatility, which are able to extract the ACPI tables from memory and analyze them for malicious behavior. Zusammenfassung Hauptspeicherforensik hat sich zu einem m¨achtigen Werkzeug fur¨ die Erkennung und Analyse von Schadsoftware entwickelt. Sie stellt Ermittlern eine objektive Sicht auf Computersysteme bereit, mit der versteckte Artefakte, wie Prozesse und Netzwerk- verbindungen, durch Analyse des Hauptspeicherinhalts enttarnt werden k¨onnen. Da Schadsoftware zumindest in Teilen des Hauptspeichers vorhanden sein muss um aus- gefuhrt¨ werden zu k¨onnen, ist es unm¨oglich alle Spuren einer Infektion zur Laufzeit aus dem Speicher zu beseitigen. In kompromittierten Umgebungen besteht allerdings die Gefahr, dass der Zugriff auf den Hauptspeicher durch anti-forensische Methoden unterwandert wird. In dieser Arbeit analysieren wir die Implementierung von 12 weit verbreitete Werk- zeuge zur Erstellung von Hauptspeicherabbildern unter Windows, Linux, und Mac OS X. Unsere Untersuchungen zeigen, dass alle Programme das Betriebssystem zur Umsetzung kritischer Aufgaben verwenden, was wir durch die Implementierung des Programms OSXPmem illustrieren. In einer Studie geben wir dann einen Uberblick¨ uber¨ die verschiedenen anti-forensischen Techniken auf Betriebssystemebene, und zeigen mit einem Experiment das alle 12 untersuchten Programme anf¨allig fur¨ Anti- Forensik sind. Wir schließen diese Lucke¨ durch die Entwicklung von betriebssystemunabh¨angige Techniken zur Hauptspeichersicherung. Durch direkte Interaktion mit dem PCI Con- troller identifizieren wir in den physischen Adressraum eingeblendete¨ Gerate, was uns den sicheren Zugriff auf den restlichen Speicher¨ ermoglicht. Wir blenden diesen in den Adressraum unserer Anwendung ein, indem wir die Datenstrukturen der MMU manipulieren. Wir implementieren unsere Techniken in die quelloffenen Programme Winpmem, Pmem, und OSXPmem, was Ermittlern den Einsatz unter Windows, Linux, und Mac OS X erm¨oglicht. Schließlich nutzen wir unsere Techniken, um zwei weitere Probleme der Hauptspei- cherforensik zu l¨osen. Programme zur Speichersicherung unter Linux sind nur auf Systemen mit der exakt gleichen Kernel Version und Konfiguration lauff¨ahig mit der sie kompiliert wurden, da sie ein Kernel Module laden was von den Datenstrukturen des Kernels abh¨angig ist. Wir l¨osen dieses Problem indem wir eine minimale Version unseres Moduls in ein kompatibles Opfer“-Modul auf dem Zielsystem injizieren. Zur ” Kommunikation mit dem Kernel zweckentfremden wir die Datenstrukturen des Op- fers, was uns erlaubt unser Programm auf einer großen Menge verschiedener Linux Systeme zu verwenden, ohne es neu kompilieren zu mussen.¨ Die zweite innovative Eigenschaft unseres Ansatzes ist, dass wir gefahrlos auf Speicherbereiche zugreifen k¨onnen die dem Betriebssystem nicht bekannt sind, da uns die Position der in den Adressraum eingeblendeten Ger¨ate bekannt ist. Dies erlaubt uns den Zugriff auf die Firmware im Zuge der Hauptspeicheruntersuchung. Wir geben einen Uberblick¨ uber¨ die Lage von BIOS, PCI option ROMs und den ACPI Tabellen im physischen Adress- raum, und implementieren Techniken zur Sicherung und Analyse von Firmware fur¨ die quelloffene Speicheranalyse-Software Volatility. Acknowledgments This thesis would not have been possible without the support of others. First and foremost, I would like to thank my supervisor Felix Freiling for his continuous advice and support during my time at the Security Research Group of the Department of Computer Science in Erlangen. Many thanks also go to Michael Meier, from the University of Bonn, for agreeing to be my second supervisor. I also thank my colleagues at the Security Research Group, for a cheerful and friendly working atmosphere. I would also like to extend my thanks to the Google Incident Response Team, for many interesting discussions and an exciting working environment. A special thank you goes to Michael Cohen, who, with his guidance and inspiration facilitated two of the three papers this thesis is built upon. In addition, I want to thank the following list of people (in alphabetical order) for helping me proofread this thesis and forge it into something legible: Michael Gruhn, Tilo M¨uller,Ben Stock, Heiner St¨uttgenand Stefan V¨omel. Finally, I want to thank Mathieu Suiche, for his commitment to forensic tool testing, providing me with an evaluation version of Moonsols Windows Memory Toolkit, that allowed me to also test a commercial tool for anti-forensic resilience. Contents 1 Introduction ................................................... 1 1.1 Contributions................................................2 1.2 Related Work................................................4 1.3 Publications.................................................7 1.4 Outline.....................................................8 2 Technical Background ......................................... 9 2.1 x86 Architecture............................................. 10 2.1.1 The Physical Address Space............................. 12 2.1.2 Memory Protection.................................... 15 2.1.3 The PCI Express Bus.................................. 19 2.2 Linux Kernel Modules........................................ 25 2.2.1 Module Binary Organization............................ 26 2.2.2 Linking and Loading................................... 27 2.3 System Firmware............................................. 29 2.3.1 Basic Input Output System............................. 29 2.3.2 (Unified) Extensible Firmware Interface................... 30 2.3.3 PCI Option ROMs..................................... 30 2.3.4 Advanced Configuration and Power Interface.............. 31 2.4 Summary.................................................... 33 3 Memory Acquisition .......................................... 35 3.1 Principles of Memory Acquisition............................... 36 3.1.1 Criteria for Sound Memory Acquisition................... 36 3.1.2
Recommended publications
  • Beyond BIOS Developing with the Unified Extensible Firmware Interface
    Digital Edition Digital Editions of selected Intel Press books are in addition to and complement the printed books. Click the icon to access information on other essential books for Developers and IT Professionals Visit our website at www.intel.com/intelpress Beyond BIOS Developing with the Unified Extensible Firmware Interface Second Edition Vincent Zimmer Michael Rothman Suresh Marisetty Copyright © 2010 Intel Corporation. All rights reserved. ISBN 13 978-1-934053-29-4 This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold with the understanding that the publisher is not engaged in professional services. If professional advice or other expert assistance is required, the services of a competent professional person should be sought. Intel Corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights that relate to the presented subject matter. The furnishing of documents and other materials and information does not provide any license, express or implied, by estoppel or otherwise, to any such patents, trademarks, copyrights, or other intellectual property rights. Intel may make changes to specifications, product descriptions, and plans at any time, without notice. Fictitious names of companies, products, people, characters, and/or data mentioned herein are not intended to represent any real individual, company, product, or event. Intel products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility applications. Intel, the Intel logo, Celeron, Intel Centrino, Intel NetBurst, Intel Xeon, Itanium, Pentium, MMX, and VTune are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
    [Show full text]
  • Boot Mode Considerations: BIOS Vs UEFI
    Boot Mode Considerations: BIOS vs. UEFI An overview of differences between UEFI Boot Mode and traditional BIOS Boot Mode Dell Engineering June 2018 Revisions Date Description October 2017 Initial release June 2018 Added DHCP Server PXE configuration details. The information in this publication is provided “as is.” Dell Inc. makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any software described in this publication requires an applicable software license. Copyright © 2017 Dell Inc. or its subsidiaries. All Rights Reserved. Dell, EMC, and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be the property of their respective owners. Published in the USA [1/15/2020] [Deployment and Configuration Guide] [Document ID] Dell believes the information in this document is accurate as of its publication date. The information is subject to change without notice. 2 : BIOS vs. UEFI | Doc ID 20444677 | June 2018 Table of contents Revisions............................................................................................................................................................................. 2 Executive Summary ............................................................................................................................................................ 4 1 Introduction ..................................................................................................................................................................
    [Show full text]
  • Designing PCI Cards and Drivers for Power Macintosh Computers
    Designing PCI Cards and Drivers for Power Macintosh Computers Revised Edition Revised 3/26/99 Technical Publications © Apple Computer, Inc. 1999 Apple Computer, Inc. Adobe, Acrobat, and PostScript are Even though Apple has reviewed this © 1995, 1996 , 1999 Apple Computer, trademarks of Adobe Systems manual, APPLE MAKES NO Inc. All rights reserved. Incorporated or its subsidiaries and WARRANTY OR REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH No part of this publication may be may be registered in certain RESPECT TO THIS MANUAL, ITS reproduced, stored in a retrieval jurisdictions. QUALITY, ACCURACY, system, or transmitted, in any form America Online is a service mark of MERCHANTABILITY, OR FITNESS or by any means, mechanical, Quantum Computer Services, Inc. FOR A PARTICULAR PURPOSE. AS A electronic, photocopying, recording, Code Warrior is a trademark of RESULT, THIS MANUAL IS SOLD “AS or otherwise, without prior written Metrowerks. IS,” AND YOU, THE PURCHASER, ARE permission of Apple Computer, Inc., CompuServe is a registered ASSUMING THE ENTIRE RISK AS TO except to make a backup copy of any trademark of CompuServe, Inc. ITS QUALITY AND ACCURACY. documentation provided on Ethernet is a registered trademark of CD-ROM. IN NO EVENT WILL APPLE BE LIABLE Xerox Corporation. The Apple logo is a trademark of FOR DIRECT, INDIRECT, SPECIAL, FrameMaker is a registered Apple Computer, Inc. INCIDENTAL, OR CONSEQUENTIAL trademark of Frame Technology Use of the “keyboard” Apple logo DAMAGES RESULTING FROM ANY Corporation. (Option-Shift-K) for commercial DEFECT OR INACCURACY IN THIS purposes without the prior written Helvetica and Palatino are registered MANUAL, even if advised of the consent of Apple may constitute trademarks of Linotype-Hell AG possibility of such damages.
    [Show full text]
  • Chapter 1. Origins of Mac OS X
    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
    [Show full text]
  • University of Cape Town Declaration
    The copyright of this thesis vests in the author. No quotation from it or information derived from it is to be published without full acknowledgementTown of the source. The thesis is to be used for private study or non- commercial research purposes only. Cape Published by the University ofof Cape Town (UCT) in terms of the non-exclusive license granted to UCT by the author. University Automated Gateware Discovery Using Open Firmware Shanly Rajan Supervisor: Prof. M.R. Inggs Co-supervisor: Dr M. Welz University of Cape Town Declaration I understand the meaning of plagiarism and declare that all work in the dissertation, save for that which is properly acknowledged, is my own. It is being submitted for the degree of Master of Science in Engineering in the University of Cape Town. It has not been submitted before for any degree or examination in any other university. Signature of Author . Cape Town South Africa May 12, 2013 University of Cape Town i Abstract This dissertation describes the design and implementation of a mechanism that automates gateware1 device detection for reconfigurable hardware. The research facilitates the pro- cess of identifying and operating on gateware images by extending the existing infrastruc- ture of probing devices in traditional software by using the chosen technology. An automated gateware detection mechanism was devised in an effort to build a software system with the goal to improve performance and reduce software development time spent on operating gateware pieces by reusing existing device drivers in the framework of the chosen technology. This dissertation first investigates the system design to see how each of the user specifica- tions set for the KAT (Karoo Array Telescope) project in [28] could be achieved in terms of design decisions, toolchain selection and software modifications.
    [Show full text]
  • UEFI PXE and Ipxe Alternative Approaches to PXE Booting
    Installing ESXi Using PXE n gPXELINUX is a hybrid configuration that includes both PXELINUX and gPXE and supports booting from a Web server. gPXELINUX is part of the SYSLINUX package. If you use gPXELINUX to boot the ESXi installer, only the gpxelinux.0 binary file, mboot.c32, and the configuration file are transferred via TFTP. The remaining files are transferred via HTTP. HTTP is typically faster and more reliable than TFTP, especially for transferring large amounts of data on a heavily loaded network. NOTE VMware currently builds the mboot.c32 plugin to work with SYSLINUX version 3.86 and tests PXE booting only with that version. Other versions are likely to be incompatible. This is not a statement of limited support. For support of third-party agents that you use to set up your PXE booting infrastructure, contact the vendor. UEFI PXE and iPXE Most UEFI firmware natively includes PXE support that allows booting from a TFTP server. The firmware can directly load the ESXi boot loader for UEFI systems, mboot.efi. Additional software such as PXELINUX is not required. iPXE can also be useful for UEFI systems that do not include PXE in firmware and for older UEFI systems with bugs in their PXE support. For such cases you can try installing iPXE on a USB flash drive and booting from there. NOTE Apple Macintosh products do not include PXE boot support. They include support for network booting via an Apple-specific protocol instead. Alternative Approaches to PXE Booting Alternative approaches to PXE booting different software on different hosts are also possible, for example: n Configuring the DHCP server to provide different initial boot loader filenames to different hosts depending on MAC address or other criteria.
    [Show full text]
  • Powerpc™ Open Firmware Quick Start Guide Release
    PowerPC™ Open Firmware Quick Start Guide Release 2.0 PPCOFWQSA/UG2 Notice While reasonable efforts have been made to assure the accuracy of this document, Motorola, Inc. assumes no liability resulting from any omissions in this document, or from the use of the information obtained therein. Motorola reserves the right to revise this document and to make changes from time to time in the content hereof without obligation of Motorola to notify any person of such revision or changes. No part of this material may be reproduced or copied in any tangible medium, or stored in a retrieval system, or transmitted in any form, or by any means, radio, electronic, mechanical, photocopying, recording or facsimile, or otherwise, without the prior written permission of Motorola, Inc. It is possible that this publication may contain reference to, or information about Motorola products (machines and programs), programming, or services that are not announced in your country. Such references or information must not be construed to mean that Motorola intends to announce such Motorola products, programming, or services in your country. Restricted Rights Legend If the documentation contained herein is supplied, directly or indirectly, to the U.S. Government, the following notice shall apply unless otherwise agreed to in writing by Motorola, Inc. Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013. Motorola, Inc. Computer Group 2900 South Diablo Way Tempe, Arizona 85282 Preface The PowerPC Open Firmware Quick Start Guide provides the general information and procedures required to test and initialize the system hardware, determine the hardware conÞguration, and to boot the operating system.
    [Show full text]
  • Bundling Spatially Correlated Prefetches for Improved Main Memory Row Buffer Locality
    Bundling Spatially Correlated Prefetches for Improved Main Memory Row Buffer Locality by Patrick Judd A thesis submitted in conformity with the requirements for the degree of Master of Applied Science Graduate Department of Electrical and Computer Engineering University of Toronto © Copyright by Patrick Judd 2014 Bundling Spatially Correlated Prefetches for Improved Main Memory Row Buffer Locality Patrick Judd Masters of Applied Science Graduate Department of Electrical and Computer Engineering University of Toronto 2014 Abstract Row buffer locality is a consequence of programs ’ inherent spatial locality that the memory system can easily exploit for significant performance gains and power savings. However, as the number of cores on a chip increases, request streams become interleaved more frequently and row buffer locality is lost. Prefetching can help mitigate this effect, but more spatial locality remains to be recovered. In this thesis we propose Prefetch Bundling, a scheme which tags spatially correlated prefetches with information to allow the memory controller to prevent prefetches from becoming interleaved. We evaluate this scheme with a simple scheduling policy and show that it improves the row hit rate by 11%. Unfortunately, the simplicity of the scheduling policy does not translate these row hits to improved performance or power savings. However, future work may build on this framework and develop more balanced policies that leverage the row locality of Prefetch Bundling. ii Acknowledgments There are many people to thank as I reflect back on my Master’s degree. First and foremost I must thank my supervisor, Andreas Moshovos, for his support, confidence in my abilities, and most of all for his ability to keep me grounded during stressful and trying times.
    [Show full text]
  • User Space Memory Analysis
    User Space Memory Analysis Master's Thesis University of Twente Author: Committee: Edwin Smulders dr. J.Y. Petit prof. dr. P.H. Hartel R.B. van Baar, MSc (NFI) November 13, 2013 Contents 1 Introduction 5 1.1 Digital Forensics . .5 1.2 Memory Forensics . .5 1.3 Organisation of this document . .6 2 Problem Statement and Research Questions 7 2.1 Problem Statement . .7 2.2 Research Questions . .8 3 Related Work 11 3.1 Acquisition . 11 3.2 Platforms . 12 3.3 Multi-platform . 15 3.4 Userland . 15 3.5 Virtual Machines . 16 3.6 Other . 16 3.7 Conlusion . 17 4 Methodology 19 4.1 Introduction . 19 4.2 Methods . 19 4.3 Summary . 25 5 Data Acquisition 27 5.1 Virtualbox . 27 5.2 Operating Systems . 27 5.3 Applications . 28 6 Core Implementation 29 6.1 Registers . 29 6.2 System Calls . 30 6.3 Reverse engineering the PLT . 31 6.4 Stacks and Calling Conventions . 33 6.5 Optimizations . 35 3 6.6 Finding Main . 37 6.7 Limitations . 39 7 Considerations 41 7.1 Compile Options . 41 7.2 Static compilation . 43 7.3 Stripped executables . 43 8 Case Examples 45 8.1 Python networking test case . 45 8.2 Analysis of the steam locomotive . 47 9 Results and evaluation 51 9.1 Test data - Ubuntu 13.04 . 51 9.2 Tests and evaluation of swap use . 52 9.3 Registers . 53 9.4 System call analysis . 55 9.5 Stack analysis . 55 9.6 Register call analysis . 56 9.7 Method weaknesses .
    [Show full text]
  • PXE Network Boot Methods
    PXE network boot methods Luc Sarzyniec <[email protected]> 2013-02-21 Contents 1 Introduction to PXE boot 2 1.1 Boot over the network procedure . 2 1.2 The PXE specifications . 2 1.3 Network Bootstrap Programs . 2 1.4 Configure a specific NBP on DHCP server . 2 1.4.1 ISC DHCP server . 2 1.4.2 dhcpcd . 2 1.4.3 dnsmasq . 2 2 Network Bootstrap Programs 3 2.1 PXElinux . 3 2.2 GPXElinux . 3 2.3 iPXE . 4 2.4 GRUB2 disk . 5 2.5 Comparison of NBPs . 6 3 Install and configure NBPs 6 3.1 PXElinux/GPXElinux . 6 3.2 iPXE . 6 3.2.1 Boot a iPXE NBP from DHCP . 6 3.2.2 Create an iPXE ROM to be burned on a NIC's PROM 7 3.2.3 Load iPXE from GNU/GRUB . 7 3.3 GRUB2 disk . 9 4 Boot nodes following a node-specific profile 10 4.1 PXElinux/GPXElinux (core feature) . 10 4.2 iPXE (custom feature) . 11 4.3 GRUB2 disk (custom feature) . 12 1 5 Download and boot Operating System kernel 13 5.1 PXElinux . 13 5.2 GPXElinux . 14 5.3 iPXE . 14 5.4 GRUB2 disk . 15 6 Boot local Operating System (from hard disk) 16 6.1 chain.c32 COMBOOT . 16 6.1.1 PXElinux/GPXElinux . 16 6.1.2 iPXE . 16 6.2 GRUB2 disk . 17 7 Chaining NBPs 17 7.1 From PXElinux to GRUB2 disk . 18 7.2 From PXElinux to iPXE . 18 7.3 From iPXE to PXElinux .
    [Show full text]
  • The Acquisition and Analysis of Random Access Memory
    Currently “In Submission” to JDFP (some content may change before publication) THE ACQUISITION AND ANALYSIS OF RANDOM ACCESS MEMORY Timothy Vidas Naval Postgraduate School Monterey, CA ABSTRACT Mainstream operating systems (and the hardware they run on) fail to purge the contents of portions of volatile memory when that portion is no longer required for operation. Similar to how many file systems simply mark a file as deleted instead of actually purging the space that the file occupies on disk, Random Access Memory (RAM) is commonly littered with old information in unallocated space waiting to be reused. Additionally, RAM contains constructs and caching regions that include a wealth of state related information. The availability of this information along with techniques to recover it, provide new methods for investigation. This article discusses the benefits and drawbacks of traditional incident response methods compared to an augmented model that includes the capture and subsequent analysis of a suspect system’s memory, provides a foundation for analyzing captured memory, and provides suggestions for related work in an effort to encourage forward progress in this relatively new area of digital forensics. KEYWORDS: memory, random access memory, memory analysis, digital forensics, Windows forensics, incident response, best practices Tim Vidas is a Research Associate at the Naval Postgraduate School. He has been focusing research in the field of digital forensics for a few years and is now primarily working on in the area of trusted operating systems and kernels. In addition to research, he likes to teach and has a wide set of IT related interests. He maintains several affiliations like ACM, CERT, and Infragard and holds several certifications such as CISSP, Sec+ and EnCE.
    [Show full text]
  • Netbooting Microsoft Windows 7 and XP
    Netbooting Microsoft Windows 7 and XP Chris Holman∗ Centre for Advanced Internet Architectures, Technical Report 130226A Swinburne University of Technology Melbourne, Australia [email protected] Abstract—This tutorial shows how to set up Microsoft and testing the Windows PE are detailed in Section VI. Windows 7 and XP to be booted using network attached Installing to the iSCSI drive is covered in Section VII. storage. iSCSI support is built in to a Windows 7 installer The report concludes with Section IX and an appendix. using the Windows 7 Automated Installation Kit. DHCP, an iSCSI server and a TFTP server are configured on the II. BACKGROUND server to provide a PXE client and an iSCSI target. Once A. DHCP set up, a client PC will be able to operate entirely without a local disk. Dynamic Host Configuration Protocol’s (DHCP) [2] Index Terms—Windows 7, Windows XP, PXE, netboot- primary purpose is to assign IP addresses and other ing network configuration details to hosts. It is used in this tutorial for the purposes of providing network and PXE I. INTRODUCTION booting configuration details, including TFTP server PXE (“Preboot eXecution Environment”) [1] booting, settings and configuration filenames. or net booting, can be used to load an operating system B. TFTP over the network without using the local hard drive. While FreeBSD and Linux Operating Systems (OSes) Trivial File Transfer Protocol (TFTP) [3] is a simple support a number of different PXE boot methods (includ- protocol to transfer files. It is commonly used in PXE ing NFS, TFTP, HTTP, iSCSI and more), Windows only scenarios because of its simplicity.
    [Show full text]