Digital Forensics & Incident Response Notes (cleanup in progress)

DFIR.md

#DFIR These are my notes from BlackHat 2016 Digital Forensics & Incident Response Training

##Windows Drive Forensics NTFS: host default <---- Course focus ReFS: eventually the host default (not yet) <---- basically nothing FAT: external drives <--- a little focus ExFat: high-cap external drives <--- basically nothing

Our tools will mostly deal with NTFS and FAT.

###NTFS Forensics Used by all modern versions of Windows.

How are files/directories stored?

What metadata is available?

What happens when a file is:

• created?
• touched?
• deleted?
• accessed?

EVERYTHING is a file

• and each file is in the MFT.

####MFT anatomy

(entries 0-15 are system, typically hidden)

0. $MFT - location and size of MFT
1. $MFTMirr - keeps up to date with changes to 0

• for disaster recovery

2. $LogFile - journal. a file write buffer to keep writes atomic. On reboot

• this contains any outstanding FS changes at time of shutdown.

5. . - root directory

• equivalent to /

####MFT Entry Anatomy Attribute Type

• Size
• Name Attribute contents can be either a 1024-byte (128B) value or a pointer to other storage
• when file size >700B or so it becomes a pointer.

Attributes: $DATA (anything) $FILE_NAME filename and a pointer to MFT entry of the parent dir MAC (mod/access/change) times $STANDARD_INFO ($SI) (MAC times of all files&folders

• plus mtime of MFT entry)

If dir is small (where $IR < 1024b): $INDEX_ROOT contains info on the files and child dirs of current dir If dir is large: we also use $INDEX_ALLOCATION and $BITMAP

• helpers because $INDEX_ROOT is now a pointer

Changes to $SI can be compared to $FN because the way entries change differs between the two for each access type.

Directories stored in a B-tree

On delete

• directory B-tree is resorted
• BUT the file's clusters are dealloced NOT overwritten
• so we need to do some digging to find the original mem locs. Occasionally this gets rewritten by resort.

To find deleted files

• walk the MFT and look for not-in-use entries (entries with in-use flag off). <700B files recoverable (because it's right there in $DATA as soon as we find the entry)
• larger files depends on if cluster was overwritten.

####MFT ANALYSIS TOOLS:

#####FTK Imager:

• drive gets mounted w/o making changes
• can select whether to block writes to FS
• Red X means files are unallocated
• manually walk files; can create an image from a physical disk
• integration with "Chain of Custody" process

#####Sleuthkit Much more commonly used for FS analysis

• works on a lot of FSes. Scriptable in Python. Commonly used as a library Lots of analysis capabilities:
• Volume System (entire drive)
• Filesystem
• File name
• Metadata
• Data unit

Win7+ always has a recovery partition in addition to the typical C drive.

mmls

• mmcat
• mmstat
• fsstat demo

1. Use mmls to find the offset of the drive/section you want
2. then fsstat to examine a specific offset

• Sector is the smallest addressable block of continuous memory
• Cluster is N sectors where N is set for a whole FS

#####File name layer tools

Use "metadata address" - inode

• MFT entry number (these are analogous)

• fls

  • -r (recurse children)
  • -l (list metadata) d/d 237053-144-5 ^--address

• ffind

  • Determine which file's data includes a particular inode
  • A file data can contain multiple inodes because of arbitrary length so this is useful if we identify a specific chunk of data on disk to look for

#####Metadata layer tools

Info ABOUT a file

• nothing to do with its contents

• icat

• ifind

  • block number to metadata address (MFT #)
  • filename (must use posix / not windows \) to metadata address (MFT #)

• ils

  • list all inode metadata
  • can pipe this into scripts

• istat

  • list all metadata baout file or directory

• requires metadata address

icat ifind ils istat Demo:

Run fls to find MFT root at offset 2048. The first 16 files are indeed the system stuff. Can see a deleted file Config.Msi

Given offset

• we can now run fls on any individual MFT node (example of Program Files and we can list within Program Files)

Create a file

• then icat on it - we can list its contents. *If it's deleted and found
• still works :)* THen istat it:
• We get MAC times for both $SI and $FN
• in addition to size of $DATA
• $FILE_NAME Allocated Size and Actual Size are 0 when the whole file is stored in $DATA.
• Update Sequence Number corresponds to SCN in journal

#####Data Unit Layer Tools Analyze raw FS data.

• blkstat

  • If block is allocated or not - if we find a string or something

• can see if it's associatd with a file

• blkcat

  • Read arbitrary data from a block offset and write to stdout.
  • Useful when we don't have pointers to the data.

• blkls

  • Extracts unallocated blocks so we can search through deleted data.

Autopsy Demo

Autopsy is a GUI for these tools.

####Index Records Directories contain INDX records

• which are marked free when children are deleted So they still exist until overwritten
• which often isn't for a while. Recover them using INDXParse.

####NTFS Journaling MSFT calls journaling "logging"

Two files part of 0-15 MFT entries:

• $LogFile - FS transaction log (64MB by default)
  • contains timestamped info on file MAC and metadata modification
  • Where was a file before it was moved?
  • What was the metadata before it was modified?
  • Useful because MFT is only THE CURRENT STATE (mostly)
• $UsnJrnl
  • $J attribute contains FS journal entries
    • Name (full path can be found via MFT)
    • Reason for operation
    • Timestamp

These give us file deletion time and multiple sets of MAC

TOOLS:

• LogFileParser
  • parse $LogFile and $UsnJrnl
• Windows Journal Parser
  • Dumps UsnJrnl
• TriForce
  • Parses above two PLUS MFT to correlate current vs past state...
  • Paid version can do automated post-analysis

#####File System Tunneling

tl;dr: MAC is reused for files that are deleted/renamed

• then created w/ the same name w/in 15 sec This means that if you quickly delete & recreate a file you don't get new timestamps in the timeline Thus we need to go to the journal

DEMO:

Finding deleted files: delte out of dir

• istat the directory
• get the metadata address of the index allocation and append to MFT entry (MFT-metadataaddress) - we can use INDXParse to get the filenames by examining the dir
• along with MAC
• but NOT the actual contents

In the malware case

• it creates a bunch of files
• moves only some and deletes the rest (to obscure journal) - we can peel out deleted filenames given a known directory because we can recover the INDX records
• and see whether antiforesics was used

File Carving

Key Tool: Scalpel

Recovering files from unstructured input (aka cobbling shit together from bytes)

• Hard drives
• Network streams
• Memory captures

1. Recognize the file

• Header/footer searching

  • Ex: magic byte examination
  • Lots of false positives

• especially with short headers that are easy to find in any random sequence of bytes

  • Need to learn to filter out the noise if you want to use this method well

• Straight-up file parsing

• Tricks:

  • files are usually written on cluster boundaries (but sometimes

• in tricky cases

• are not)

2. Establish file boundaries

• Search for footer within reasonable bounds
• Maybe recognize another file so you know the first one has ended
  • This can produce noise

3. Extract (carve) files to output

• Ez

4. Filter noise

• use blkls to extract all unallocated space
• then run the file carver against it - now you're only viewing deleted files

5. View recovered files

• Make sure you mount the recovery drive read-only to avoid changing the filesystem
• which invalidates evidence

Lab notes:

1. Most of the zip files are corrupted. Some images are incomplete

• meaning Scalpel probably found a footer that wasn't really a footer.

2. Some are office files...

Lab 2 notes photorec: We were able to recover some files better/some only with Photorec (ppt which is really just a zip

• an exe) but some images are missing entirely.

Compare/contrast: Scalpel will chop files out of other files

• such as multimedia presentations. This is sometimes useful and sometimes not.

• Can be useful when files are embedded in other files - either to hide them or because of multimedia stuff

• archives

• etc

  • Can be useful when we need a summary of all data available in the image
  • Can be very UN-useful when we need to reconstruct the scenario that the user was in.

Recycle Bin Forensics

Recycle Bin works drastically differently in XP vs 7/Vista vs 8 vs 10...

C:\Recycler\
  -<USER SID>
    - INFO2
    - Deleted files (renamed at first d level

• same name deeper down the tree) INFO2: a file per-user containing metadata about the deletion

In 7/Vista

• deleted files create an $I and $R file in C:\$Recycle.Bin\<PER USER ID>

LNK File Forensics

Useful because they are basically references that get created and hang around by various activities on the system such as the "Recent" file feature

• MS office recent files
• probably most applications with a "recent" feature. They contain a wealth of forensic info that can be examined even across multiple devices - for example
• external drives get .lnk files created on other disks
• so a trace is left when you plug in a USB drive. Another example is mapping a network drive creates a .lnk file which contains network share information.

Tools: lnkinfo

Similar:

Jump Lists (first appeared in Win7)

Basically another way of creating shortcuts on the system to various files

• with similar forensic properties. Also have the advantage that they're more that pointers - they also include some preferences data
• etc

Key features - DestList (MRU files for app in question)

Sticks around after files are deleted.

Jump lists have App IDs which correspond uniquely to a single application

Tools:

• JumpLister
• JumpListExplorer

Event Logs

Registry contains logging configs

By default

• event log is a ring buffer
• so sometimes parsing can fail because of overwriting

Typically have a description which is partly defined by the configured message templating executable in registry

Like Jump List App IDs

• event log IDs are unique globally
• and there are repositories containing this data online

Vista+ event logs are XML

• and have a similar ID (with 4096 prepended)

When a file is executed it often creates a prefetch file on disk which is recorded in the MFT.

Therefore we can confirm execution by looking for a prefetch file in MFT mac analysis.

Log Types

• Application

  • Apps write here

• Security

  • Auditing - events called "audits"
  • Need to change registry key permissions to see these for admins
  • Often disabled by default (in XP

• totally disabled)

• HKLM\SECURITY\Policy\PolAdtEv - a binary blob containing security auditing configuration

• Can toggle success/failure/both along with different event types

• Therefore an audit is basically a pair (0|1

• TYPE)

• Highly granular set of event logs (log when user unlocks computer

• attempts to unlock computer

• can differentiate between login with local and networked credentials...)

• Also logs service logins so the typical malware pattern of installing a service leaves many tracks here

• System

  • Operational stuff
  • System services write here

• Setup

• Forwarded

####Tools

• evtparse.pl

• GrokEvt

• libevt

More artifacts

Prefetch Files

• Prefetch files (from before) are created on first execution of something

• to optimize performance

• Layout.ini is kept in the prefetch folder and contains some info about prefetch files that have been deleted

• Prefetching is configurable with various defaults on various versions of windows

  • for various types of prefetching (boot vs application)

• Prefetch file name includes a hash calculated from the full path of the executable

• When executables delete themselves

• or when someone deletes them

• prefetch doesn't go away

• In Win10

• prefetch on-disk format changed a lot

• so tools are still catching up

Windows Search Database

• Indexes a bunch of files

• and other stuff: IE history

• emails... even the contents of plaintext/human-readable files

• Only on by default in Vista/7+

• Stored in .edb format and readable using libesedb

Scheduled Tasks

• Often used by APT

• When a scheduled task is created

• job files are also created in C:\windows\Tasks

• Contain job metadata (runtime

• priority

• command)

• "at" utility creates Tasks/At1.job

• "Sceheduled Tasks Wizard" creates named Tasks/ files instead

Restore Points aka Volume Shadow Service

Tools:

• ShadowExplorer

  • Actually examines the image

• mklink

  • Basically mounting the copy as a read-only drive

• Hibernation file can sometimes be found and contains copies of RAM (nice!)

Anti-Forensics

• The A-bomb: FDE

  • However

• FDE is usually on a partition basis...

  • Check for recovery partition

• etc

• Also

• password managers

• memory captures

• config files

• stringsing the image can find the password

• But if you can't find the password

• you might be screwed ;)

• Basically techniques to remove forensic artifacts from a system.

• However

• this itself leaves traces on the machine - we can detect them with anti-anti-forensic tools.

• This can qualify as destruction of evidence

• Also covers your ass about why you found nothing

  • Cause otherwise you get fired :)

• Execution leaves a trace

• so knowing the tools means you can identify prefetch

• event logs

• etc.

• CCleaner is a good example

• basically just deletes a ton of shit

• Some things can't be touched by anti-forensics:

  1. Restore points
  2. Volume Shadow Copies
  3. Registry Hives (deleted keys)

• RegDecoder can sometimes tell when a key was deleted

• Proving anti-forensics was used:

  • Often leave artifacts in memory
    • Especially in malware cases

• software goes from network to process memory w/o ever touching disk

• File deletion leaves leftovers in 'slack space' aka space between cluster boundary and EOF

  • BUT: In ext* FS

• this space is zeroed

• and some tools zero it too (like Eraser)

• Can run strings against memory to find remnants of stuff

  • OSX Strings sucks. get the GNU version for unicode support.

• Tough to erase SSDs

• because block re-mappings mean software may never overwrite the intended block (read more...)

  • But these blocks can be v hard to access by forensics

• Password cracking tips:

  • strings the image and build a cracking dict

  • Tools:

    1. Elcomsoft makes cracking stuff for ZIP/RAR/Office/PDF (GuaPDF)

• Encrypted files were usually unencrypted once

  • Can find em in temp files

• printing cache

• page file?

• etc

• Encrypted Containers

  • Allow for portable encrypted filesystems (implemented as a file)
  • TrueCrypt is one
  • Still have MAC times

• still have lnk files

• jump list

• registry entries

Lab:

tcpxtract does it automatically.

Wireshark FTP data extraction:

• Follow TCP stream - results in a view of a "conversation" reconstructed
• See RAR header to notice filetype
• Click "Raw" to get raw format
• Save stream as raw
• and you have the file

Gmail forensics: Essentially

• use strings to search for things of interest. Because of memory locality

it's pretty common to be able to find things within visible distance.

IIS Forensics

• IIS is still a really common web server.

• MSSQL contains some pretty crazy key stuff:

  • xp_cmdshell

    • Get a cmd.exe shell from MSSQL

  • xp_reg

    • Edit the registry from MSSQL

  • xp_grantlogin

    • Grant MSSQL access to a Windows user

  • If you can RCE

• can run basically: nc -l 9999 | bash

Parsing IIS Logs

These were Win specific tools; I just chopped things up with the standard Unix toolkit for the same result.

---

Memory Forensics

Acquisition

• Before disconnecting from the network!

• Not during times of heavy activity involving lots of memory use

• Was done in usermode before Win2003 SP1

• Now done in kernel mode with a device driver

• Hibernation file (C:\hiberfil.sys) contains a full copy of RAM at time of hibernation

  • Not a substitute for live RAM because the process of hibernation closes network connections and releases DHCP leases

• Easier to get memory from a VM

• of course...

  • So if you plan to detonate

• nice to do it on a VM :)

F-Response

• Can selectively query memory - useful for sweeping for IOC

F-response demo

Analysis

• Strings/hex/grep/less + carving can be useful

• but limited in context and can't follow across pages/swapping

• Better: Volatility framework

  • Actually works on memory from all kinds of systems

• etc

• Figure out what sample you've got with kdbgscan (searches for a certain signature to find machine profile)

• Entry point: pslist lists processes by walking a linked list of processes

• Sometimes

• processes are hidden. kernelmode malware can directly overwrite pointers in kernel objects

• so we can't walk the linked list to find the process! D:

• you can do psscan to carve EPROCESS objects based on struct shape which doesn't rely on the linked list pointers

• Onec you identify a process can:

  • dump its executable (or memory with --memory)
  • check what DLLs it's got loaded (a DLL is basically a .so :))
  • ldrmodules even shows unlinked DLLs; which is to say DLLs which have been obscured by overwriting kernel pointers
  • dlldump to dump DLL for analysis - default dumps all

• can get more specific

Concept: the VAD

• A self-balancing AVL tree containing info about memory allocaed to a process
  • location of memory mapped files
  • what addresses are used
  • unlinked DLLs
  • injected code

Lab notes: everything works as expected, it's pretty cool.

Metasploit default port is 4444

Metasploit modules often use _ReflectiveLoad to load dlls directly into memory

Check out Sam* Win32 API calls that typically indicate credential dumping (as seen in MimiKatz)

Process Interactions

In memory we can find things like:

• Anything memory mapped including code and data

• Any pointers that are kept including files, reg keys, locks, IPC......

• Env vars

• The _FILE_OBJECT structure represents a file and we can find the physical offset using vol

  • vol can also dump any _FILE_OBJECT given a physical address

Kernel objects

• Modules/drivers live in LDR_DATA_TABLE_ENTRY linked list - can pool scan like others as well