Difference between pages "Anti-forensic techniques" and "Memory analysis"

From ForensicsWiki
(Difference between pages)
Jump to: navigation, search
(Externals Links)
 
(External Links)
 
Line 1: Line 1:
'''Anti-forensic techniques''' try to frustrate [[forensic investigator]]s and their [[techniques]].
+
'''Memory Analysis''' is the science of using a [[Memory Imaging|memory image]] to determine information about running programs, the [[operating system]], and the overall state of a computer. Because the analysis is highly dependent on the operating system, it has been divded into the following pages:
  
This can include refusing to run when [[debugging]] mode is enabled, refusing to run when running inside of a [[virtual machine]], or deliberately overwriting data. Although some anti-forensic tools have legitimate purposes, such as overwriting sensitive data that shouldn't fall into the wrong hands, like any [[Tools|tool]] they can be abused.
+
* [[Windows Memory Analysis]]
 +
* [[Linux Memory Analysis]]
  
=Traditional anti-forensics=
+
== OS-Independent Analysis ==
==Overwriting Data and Metadata==
+
=== Secure Data Deletion ===
+
  
[[Secure data deletion|Securely deleting]] data, so that it cannot be restored with forensic methods.  
+
At the IEEE Security and Privacy conference in May 2011, Brendan Dolan-Gavitt presented a novel system, [http://www.cc.gatech.edu/~brendan/Virtuoso_Oakland.pdf Virtuoso], that was able to perform operating-system independent memory analysis. Using virtual machine introspection accompanied by a number of formal program analysis techniques, his system was able to monitor the machine-level instructions and behavior of application actions (listing processes, network connections, etc) and then automatically generate Volatility plugins that replicated this analysis.
  
Overwriting programs typically operate in one of three modes:
+
== Encryption Keys ==
# The program can overwrite the entire media.
+
# The program can attempt to overwrite individual files. This task is complicated by journaling file systems: the file itself may be overwritten, but portions may be left in the journal.
+
# The program can attempt to overwrite files that were previously “deleted” but left on the drive. Programs typically do this by creating one or more files on the media and then writing to these files until no free space remains, taking special measures to erase small files — for example, files that exist entirely within the Windows Master File Table of an NTFS partition (Garfinkel and Malan, 2005).
+
  
Programs employ a variety of techniques to overwrite data. Apple’s Disk Utility allows data to be overwritten with a single pass of NULL bytes, with 7 passes of random data, or with 35 passes of data. Microsoft’s cipher.exe, writes a pass of zeros, a pass of FFs, and a pass of random data, in compliance with DoD standard 5220.22-M. (US DoD, 1995). In 1996 Gutmann asserted that it might be possible to recover overwritten data and proposed a 35-pass approach for assured sanitization (Gutmann 1996). However, a single overwriting pass is now viewed as sufficient for [[Sanitizing Tools|sanitizing]] data from ATA drives with capacities over 15 GB that were manufactured after 2001 (NIST 2006).
+
Various types of encryption keys can be extracted during memory analysis.
 +
* [[AESKeyFinder]] extracts 128-bit and 256-bit [[AES]] keys and [[RSAKeyFinder]] and private and public [[RSA]] keys from a memory dump [http://citp.princeton.edu/memory/code/].
 +
* [http://jessekornblum.com/tools/volatility/cryptoscan.py cryptoscan.py], which is a [[List of Volatility Plugins|plugin for the Volatility framework]], scans a memory image for [[TrueCrypt]] passphrases
  
Be aware that software 'data destroyers' may not necessarily do what they state on the burb site.  In particular a common mistake is the oversight of how the underlying file system actually stores files, for instance a 'wipe drive' application that will write a series of random values across unallocated space on the hard disk may not take into account the slack space at the end of allocated data blocks.  Thus allowing a large portion of old data to still be recoverable.  This is a very handy for a forensic analyst, but not so handy for IT Managers.
+
== See Also ==
  
===Overwriting Metadata===
+
* [[Memory Imaging]]
If the examiner knows when an attacker had access to a Windows, Mac or Unix system, it is frequently possible to determine which files the attacker accessed, by examining file “access” times for every file on the system. Some CFTs can prepare a “timeline” of the attacker’s actions by sorting all of the computer’s timestamps in chronological order. Although an attacker could wipe the contents of the media, this action itself might attract attention. Instead, the attacker might hide their tracks by overwriting the access times themselves so that the timeline could not be reliably constructed.
+
* [[:Tools:Memory Imaging|Memory Imaging Tools]]
 +
* [[:Tools:Memory Analysis|Memory Analysis Tools]]
  
For example, [[Timestomp]] will overwrite [[NTFS]] “create,” “modify,” “access,” and “change” timestamps ([[Metasploi]]t 2006). [[The Defiler’s Toolkit]] can overwrite inode timestamps and deleted directory entries on many Unix systems; timestamps on allocated files can also be modified using the Unix touch command ([[The Grugq]] 2003).
+
== External Links ==
 +
* [http://wiki.yobi.be/wiki/RAM_analysis YobiWiki: RAM analysis]
 +
* [http://cryptome.org/0003/RAMisKey.pdf RAM is Key - Extracting Disk Encryption Keys From Volatile Memory], by [[Brian Kaplan]], May 2007
 +
* [https://docs.google.com/presentation/d/1KsZGF6cQ-N8ngABFGCZf8pTQQ5CZ19VoAHq5cO5ZPdE/edit Memory Forensics With Volatility (Technology Preview)], by [[Michael Cohen]], October 2012
 +
* [http://belkasoft.com/download/info/Live_RAM_Analysis_in_Digital_Forensics.pdf Discovering ephemeral evidence with Live RAM analysis] by Oleg Afonin and Yuri Gubanov, 2013
 +
* [http://www.dfrws.org/2013/proceedings/DFRWS2013-11.pdf An Evaluation Platform for Forensic Memory Acquisition Software] by Stefan Voemel and Johannes Stuettgen, DFRWS 2013
  
=== Preventing Data Creation ===
+
=== Anti-forensics ===
Prevent the creation of certain data in the first place. Data which was never there, obviously cannot be restored with forensic methods.
+
* [http://blog.handlerdiaries.com/?p=363 Forensic Analysis of Anti-Forensic Activities], by [[Jack Crook]], January 29, 2014
 +
* [http://volatility-labs.blogspot.ch/2014/02/add-next-big-threat-to-memory.html ADD: The Next Big Threat To Memory Forensics....Or Not], by [[Michael Hale Ligh]], February 3, 2014
 +
* [http://scudette.blogspot.ch/2014/02/anti-forensics-and-memory-analysis.html Anti-forensics and memory analysis], by [[Michael Cohen]], February 7, 2014
  
For example, a partition can be mounted read-only or accessed through the raw device to prevent the file access times from being updated. The Windows registry key HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate can be set to “1” to disable updating of the last-accessed timestamp; this setting is default under Windows Vista (Microsoft 2006).
+
=== Computer architecture ===
 +
* [http://en.wikipedia.org/wiki/64-bit_computing Wikipedia: 64-bit computing]
 +
* [http://www.unix.org/version2/whatsnew/lp64_wp.html 64-Bit Programming Models: Why LP64?], The Open Group, 1997
  
==Cryptography, Steganography, and other Data Hiding Approaches==
+
=== [http://volatility-labs.blogspot.com/ Volatility Labs] ===
=== Encrypted Data ===
+
* [http://volatility-labs.blogspot.com/2012/09/movp-11-logon-sessions-processes-and.html MoVP 1.1 Logon Sessions, Processes, and Images]
Cryptographic file systems transparently encrypt data when it is written to the disk and decrypt data when it is read back, making the data opaque to any attacker (or CFT) that does not have the key. These file systems are now readily available for Windows, Mac OS, and Linux. The key can be protected with a passphrase or stored on an auxiliary device such as a USB token. If there is no copy of the key, intentionally destroying the key makes the data stored on the media inaccessible (Boneh and Lipton, 1996). Even if the cryptographic system lacks an intentional sanitization command or “self-destruct,” cryptography can still be a potent barrier to forensic analysis if the cryptographic key is unknown to the examiner.  
+
* [http://volatility-labs.blogspot.com/2012/09/movp-12-window-stations-and-clipboard.html MoVP 1.2 Window Stations and Clipboard Malware]
 +
* [http://volatility-labs.blogspot.com/2012/09/movp-13-desktops-heaps-and-ransomware.html MoVP 1.3 Desktops, Heaps, and Ransomware]
 +
* [http://volatility-labs.blogspot.com/2012/09/movp-14-average-coder-rootkit-bash.html MoVP 1.4 Average Coder Rootkit, Bash History, and Elevated Processes]
 +
* [http://volatility-labs.blogspot.com/2012/09/movp-15-kbeast-rootkit-detecting-hidden.html MoVP 1.5 KBeast Rootkit, Detecting Hidden Modules, and sysfs]
 +
* [http://volatility-labs.blogspot.com/2012/09/movp-21-atoms-new-mutex-classes-and-dll.html MoVP 2.1 Atoms (The New Mutex), Classes and DLL Injection]
 +
* [http://volatility-labs.blogspot.com/2012/09/movp-22-malware-in-your-windows.html MoVP 2.2 Malware In Your Windows]
 +
* [http://volatility-labs.blogspot.com/2012/09/movp-23-event-logs-and-service-sids.html MoVP 2.3 Event Logs and Service SIDs]
 +
* [http://volatility-labs.blogspot.com/2012/09/movp-24-analyzing-jynx-rootkit-and.html MoVP 2.4 Analyzing the Jynx rootkit and LD_PRELOAD]
 +
* [http://volatility-labs.blogspot.com/2012/09/movp-25-investigating-in-memory-network.html MoVP 2.5: Investigating In-Memory Network Data with Volatility]
 +
* [http://volatility-labs.blogspot.com/2012/09/movp-31-detecting-malware-hooks-in.html MoVP 3.1 Detecting Malware Hooks in the Windows GUI Subsystem]
 +
* [http://volatility-labs.blogspot.com/2012/09/howto-scan-for-internet-cachehistory.html HowTo: Scan for Internet Cache/History and URLs]
 +
* [http://volatility-labs.blogspot.com/2012/09/movp-32-shellbags-in-memory-setregtime.html MoVP 3.2 Shellbags in Memory, SetRegTime, and TrueCrypt Volumes]
 +
* [http://volatility-labs.blogspot.com/2012/09/movp-33-analyzing-user-handles-and.html MoVP 3.3 Analyzing USER Handles and the Win32k.sys Gahti]
 +
* [http://volatility-labs.blogspot.com/2012/09/movp-34-recovering-tagclipdata-whats-in.html MoVP 3.4: Recovering tagCLIPDATA: What's In Your Clipboard?]
 +
* [http://volatility-labs.blogspot.com/2012/09/movp-35-analyzing-2008-dfrws-challenge.html MoVP 3.5: Analyzing the 2008 DFRWS Challenge with Volatility]
 +
* [http://volatility-labs.blogspot.com/2012/10/movp-41-detecting-malware-with-gdi.html MoVP 4.1 Detecting Malware with GDI Timers and Callbacks]
 +
* [http://volatility-labs.blogspot.com/2012/10/movp-43-taking-screenshots-from-memory.html MoVP 4.2 Taking Screenshots from Memory Dumps]
 +
* [http://volatility-labs.blogspot.com/2012/10/movp-43-recovering-master-boot-records.html MoVP 4.3 Recovering Master Boot Records (MBRs) from Memory]
 +
* [http://volatility-labs.blogspot.com/2012/10/movp-44-cache-rules-everything-around.html MoVP 4.4 Cache Rules Everything Around Me(mory)]
 +
* [http://volatility-labs.blogspot.com/2012/10/omfw-2012-malware-in-windows-gui.html OMFW 2012: Malware In the Windows GUI Subsystem]
 +
* [http://volatility-labs.blogspot.com/2012/10/omfw-2012-reconstructing-mbr-and-mft.html OMFW 2012: Reconstructing the MBR and MFT from Memory]
 +
* [http://volatility-labs.blogspot.com/2012/10/phalanx-2-revealed-using-volatility-to.html Phalanx 2 Revealed: Using Volatility to Analyze an Advanced Linux Rootkit]
 +
* [http://volatility-labs.blogspot.com/2012/10/solving-grrcon-network-forensics.html Solving the GrrCon Network Forensics Challenge with Volatility]
 +
* [http://volatility-labs.blogspot.com/2012/10/omfw-2012-analyzing-linux-kernel.html OMFW 2012: Analyzing Linux Kernel Rootkits with Volatility]
 +
* [http://volatility-labs.blogspot.com/2012/10/omfw-2012-datalore-android-memory.html OMFW 2012: Datalore: Android Memory Analysis]
 +
* [http://volatility-labs.blogspot.com/2012/10/movp-for-volatility-22-and-omfw-2012.html MoVP for Volatility 2.2 and OMFW 2012 Wrap-Up]
 +
* [http://volatility-labs.blogspot.com/2012/10/reverse-engineering-poison-ivys.html Reverse Engineering Poison Ivy's Injected Code Fragments]
 +
* [http://volatility-labs.blogspot.com/2012/10/omfw-2012-analysis-of-process-token.html OMFW 2012: The Analysis of Process Token Privileges]
 +
* [http://volatility-labs.blogspot.com/2012/10/omfw-2012-mining-pfn-database-for.html OMFW 2012: Mining the PFN Database for Malware Artifacts]
 +
* [http://volatility-labs.blogspot.com/2014/01/truecrypt-master-key-extraction-and.html TrueCrypt Master Key Extraction And Volume Identification], by [[Michael Hale Ligh]], January 14, 2014
  
Cryptography can also be used at the application level. For example, Microsoft Word can be configured to encrypt the contents of a document by specifying that the document has a “password to open.” Although older versions of Microsoft Word encrypted documents with a 40-bit key that can be cracked with commercial tools, modern versions can optionally use a 128-bit encryption that is uncrackable if a secure passphrase is used.
+
=== Volatility Videos ===
=== Encrypted Network Protocols===
+
* [http://sketchymoose.blogspot.com/2011/10/set-up-to-more-memory-forensics.html Set Up to More Memory Forensics!], October 2011
Network traffic can likewise be encrypted to protect its content from forensic analysis. Cryptographic encapsulation protocols such as [[SSL forensics|SSL]] and SSH only protect the content of the traffic. Protecting against traffic analysis requires the use of intermediaries. Onion Routing (Goldschlag, Reed and Syverson, 1999) combines both approaches with multiple layers of encryption, so that no intermediary knows both ends of the communication and the plaintext content.
+
* [http://www.youtube.com/watch?v=8HsZLge0wWc Using Volatility: Suspicious Process (1/2)]
 +
* [http://www.youtube.com/watch?v=XTZPNk-Esok Using Volatility: Suspicious Process (2/2)]
  
''More information: [[Tor]] and [[VPN]].''
+
=== WinDBG ===
 +
* [http://blog.opensecurityresearch.com/2013/12/getting-started-with-windbg-part-1.html Getting Started with WinDBG - Part 1], by [[Brad Antoniewicz]], December 17, 2013
 +
* [http://blog.opensecurityresearch.com/2013/12/getting-started-with-windbg-part-2.html Getting Started with WinDBG - Part 2], by [[Brad Antoniewicz]], December 24, 2013
 +
* [http://blog.opensecurityresearch.com/2013/12/getting-started-with-windbg-part-3.html Getting Started with WinDBG - Part 3], by [[Brad Antoniewicz]], December 31, 2013
 +
* [http://www.msuiche.net/2014/01/12/extengcpp-part-1/ Developing WinDbg ExtEngCpp Extension in C++ – Introduction – Part 1], by [[Matt Suiche]], January 12, 2014
 +
* [http://www.msuiche.net/2014/01/15/developing-windbg-extengcpp-extension-in-c-com-interface/ Developing WinDbg ExtEngCpp Extension in C++ – COM Interface – Part 2], by [[Matt Suiche]], January 15, 2014
 +
* [http://www.msuiche.net/2014/01/20/developing-windbg-extengcpp-extension-in-c-memory-debugger-markup-language-dml-part-3/ Developing WinDbg ExtEngCpp Extension in C++ – Memory & Debugger Markup Language (DML) – Part 3], by [[Matt Suiche]], January 20, 2014
  
===Program Packers===
+
[[Category:Memory Analysis]]
Packers are commonly used by attackers so that attack tools will not be subject to reverse engineering or detection by scanning. Packers such as PECompact (Bitsum 2006) and Burneye (Vrba 2004) will take a second program, compress and/or encrypt it, and wrap it with a suitable extractor. Packers can also incorporate active protection against debugging or reverse engineering techniques. For example, Shiva will exit if its process is being traced; if the process is not being traced, it will create a second process, and the two processes will then trace each other, since each process on a Unix system may only be traced by one other process. (Mehta and Clowes, 2003)
+
 
+
Packed programs that require a password in order to be run can be as strong as their encryption and password. However, the programs are vulnerable at runtime. Burndump is a loadable kernel module (LKM) that automatically detects when a Burneye-protected file is run, waits for the program to be decrypted, and then writes the raw, unprotected binary to another location (ByteRage 2002). Packed programs are also vulnerable to static analysis if no password is required (Eagle 2003).
+
=== Steganography ===
+
Steganography can be used to embed encrypted data in a cover text to avoid detection. Steghide embeds text in JPEG, MBP, MP3, WAV and AU files (Hetzl 2002). Hydan exploits redundancy in the x86 instruction set; it can encode roughly 1 byte per 110 (El-Khalil 2004). Stegdetect (Provos 2004) can detect some forms of steganography.
+
 
+
StegFS hides encrypted data in the unused blocks of a Linux ext2 file system, making the data “look like a partition in which unused blocks have recently been overwritten with random bytes using some disk wiping tool” (McDonald and Kuhn, 2003).
+
 
+
[[FreeOTFE]] and [[TrueCrypt]] allow a second encrypted file system to be hidden within another encrypted file system. The goal of this filesystem-within-a-filesystem is to allow the users to have a “decoy” file system with data that is interesting but not overtly sensitive. A person who is arrested or captured with a laptop encrypted using this software could then give up the first file system’s password, with the hope that the decoy would be sufficient to satisfy the person’s interrogators.
+
 
+
=== Generic Data Hiding===
+
Data can also be hidden in unallocated or otherwise unreachable locations that are ignored by the current generation of forensic tools.
+
 
+
Metasploit’s Slacker will hide data within the slack space of FAT or NTFS file system. FragFS hides data within the NTFS Master File Table. RuneFS (Grugq 2003) stores data in bad blocks. (Thompson and Monroe, 2006). Waffen FS stores data in the ext3 journal file (Eckstein and Jahnke 2005). KY FS stores data in directories (Grugq 2003). Data Mule FS stores data in inode reserved space (Grugq 2003). It is also possible to store information in the unallocated pages of Microsoft Office files.
+
 
+
Information can be stored in the [[DCO and HPA|Host Protected Area]] (HPA) and the [[DCO and HPA|Device Configuration Overlay]] (DCO) areas of modern ATA hard drives. Data in the HPA and DCO is not visible to the BIOS or operating system, although it can be extracted with special tools.
+
 
+
== Detecting Forensic Analysis ==
+
 
+
There are methods to detect whether an [[investigator]] tries to perform a (live) forensic analysis on the system. A malicious user or program could react to that by destroying evidence, for example.
+
 
+
=Other Anti Forensics=
+
==Targeting forensic tool blind spots==
+
==Targeting forensic tool vulnerabilities==
+
 
+
=== Casper ===
+
 
+
[[Image:Grml.png|thumb|right|[[grml]] mounted root file system on the [[hard drive]]]]
+
[http://bromavilleherald.com/index.php/Casper_boot_process Casper] is a set of scripts used to enable Linux-based distributions to boot from removable media. Casper scripts will search for the root file system (typically [[SquashFS]]) on the local data storage media during the boot, mount it, and execute ''/sbin/init'' program on mounted root. Most forensic Linux distributions based on [[Ubuntu]] and [[Debian]] lack of integrity checks of selected SquashFS images and will boot specially crafted images found on the hard drive (not on the CD).
+
 
+
==Targeting generic tool/lib vulnerabilities==
+
=References=
+
Garfinkel, S.,  Anti-Forensics: Techniques, Detection and Countermeasures, The 2nd International Conference on i-Warfare and Security (ICIW), Naval Postgraduate School, Monterey, CA, March 8-9, 2007. [http://www.simson.net/clips/academic/2007.ICIW.AntiForensics.pdf]
+
 
+
Henrique, G. Wendel, Anti Forensics: Making computer forensics hard, Code Breakers III, São Paulo, Brazil, Setember 2006.
+
[http://ws.hackaholic.org/slides/AntiForensics-CodeBreakers2006-Translation-To-English.pdf]
+
== See also ==
+
 
+
* [[:Category:Anti-forensics tools|Anti-forensics tools category]]
+
 
+
== Externals Links ==
+
* [http://www.safehack.com/Textware/forensic/Anti_Forensic_Break_Encase.pdf Breaking Encase with FILE0 and Winhex]
+
* [http://ws.hackaholic.org/slides/AntiForensics-CodeBreakers2006-Translation-To-English.pdf Anti Forensics: making computer forensics hard]
+
* [http://seclists.org/bugtraq/2008/Nov/0038.html PTK Forensic Local Command Execution Vulnerability (fixed in 1.0.1, see CHANGELOG)]
+
* [http://www.irongeek.com/i.php?page=videos/anti-forensics-occult-computing Anti-Forensics Class] Little over 3hr of video on the subject of anti-forensic techniques
+
* [http://www.computer-forensics-lab.org/pdf/Linux_for_computer_forensic_investigators_2.pdf Linux for computer forensic investigators: problems of booting trusted operating system]
+
* [http://www.blackhat.com/presentations/bh-jp-06/BH-JP-06-Bilby-up.pdf Low Down and Dirty: Anti-forensic Rootkits], by [[Darren Bilby]], Blackhat Japan 2006
+
 
+
[[Category:Anti-Forensics]]
+

Revision as of 02:59, 14 February 2014

Memory Analysis is the science of using a memory image to determine information about running programs, the operating system, and the overall state of a computer. Because the analysis is highly dependent on the operating system, it has been divded into the following pages:

OS-Independent Analysis

At the IEEE Security and Privacy conference in May 2011, Brendan Dolan-Gavitt presented a novel system, Virtuoso, that was able to perform operating-system independent memory analysis. Using virtual machine introspection accompanied by a number of formal program analysis techniques, his system was able to monitor the machine-level instructions and behavior of application actions (listing processes, network connections, etc) and then automatically generate Volatility plugins that replicated this analysis.

Encryption Keys

Various types of encryption keys can be extracted during memory analysis.

See Also

External Links

Anti-forensics

Computer architecture

Volatility Labs

Volatility Videos

WinDBG