Forensic Friday: Get-ForensicRunKey

[This article is a continuation of my Forensic Friday series.  Every Friday I will provide a short post on a forensic topic of interest or PowerForensics functionality (such as cmdlet descriptions, use cases, and details about lesser known features). Subscribe to Invoke-IR so you don’t miss a Forensic Friday!]

Vote for PowerForensics for the Forensic 4:cast Awards' Open Source Digital Forensic Software of the Year!

Now back to your regularly scheduled programming! Yesterday, Vijay (@vakasapu on Twitter) asked if we are taking feature requests (specifically regarding autoruns like features) for PowerForensics.

@jaredcatkinson @mattifestation are you taking requests for new features? If so, would be great to have an autoruns equivalent module.

— Vijay (@vakasapu) March 31, 2016

Let me start by saying that we are very interested in community involvement! If you have ideas to make PowerForensics better, please let me know via email (jared@invoke-ir.com) or github. While PowerForensics does not currently support the extensive list of Auto Start Extensibility Points (ASEP), we do currently support a few of the more common auto start locations. This week I want to introduce Get-ForensicRunKey which parses the registry for entries in the numerous system and user based "run" keys. This cmdlet is built on top of PowerForensics' MFT and Registry Parser, so all of this data is gathered from a live system without relying on the Window's API.

Common Use

By default, this cmdlet parses the system SOFTWARE hive and all NTUSER.DAT hives on the system’s C: volume, but can be pointed at any logical volume. Individual hives (including exported hives) can be parsed using the -HivePath parameter in order to perform offline analysis. I’ve listed a few examples below.

Parse system and user hives for Run Key Persistence:

Get-ForensicRunKey -VolumeName C: | Format-List

Parse the system SOFTWARE hive for Run Key persistence:

Get-ForensicRunKey -HivePath ‘C:\Windows\System32\config\SOFTWARE’ | Format-List

Forensic Friday: Get-ForensicChildItem

[This is a continuation of my Forensic Friday series.  Every Friday I provide a short post on a forensic topic of interest or PowerForensics functionality (such as cmdlet descriptions, use cases, and details about lesser known features). Subscribe to Invoke-IR so you don’t miss a Forensic Friday!]

Welcome to another edition of Forensic Friday. I've been incredibly busy this week, but I want to touch on a very useful cmdlet called Get-ForensicChildItem. Those with a PowerShell background can probably guess what Get-ForensicChildItem does. For those that are new to PowerShell Get-ChildItem is the cmdlet that is used for directory listings (among other things). Get-ForensicChildItem performs the same task, but without the Windows API. It parses the Master File Table (MFT) to find the entry for the target directory and outputs a list of files the directory contains.

To understand what is happening it’s important to know that NTFS treats directories just like any other file. This means that directories each have an entry in the MFT. All NTFS does to differentiate a directory file from a data file is flip a bit in a flag field and adds special $INDEX_ROOT and $INDEX_ALLOCATION attributes to the directory file’s MFT entry. Get-ForensicChildItem parses these attributes to return the contents of a directory (including System and Hidden files).

Common Use

List all children of a directory (example targets the root of the C: volume):

Get-ForensicChildItem -Path C:\

List the children of the current working directory (example uses the C:\temp directory):

Get-ForensicChildItem

Return an MFT entry for every file in a directory (example uses the root directory of the C: volume):

Get-ForensicChildItem -Path C:\ | Get-ForensicFileRecord

Forensic Friday: Invoke-ForensicDD

[This is a continuation of my Forensic Friday series.  Every Friday I provide a short post on a forensic topic of interest or PowerForensics functionality (such as cmdlet descriptions, use cases, and lesser known features). Subscribe to Invoke-IR so you don’t miss a Forensic Friday!]

Happy Forensic Friday! This week I am taking us back to the basics with Invoke-ForensicDD. Pretty much every Forensicator/Incident Responder has used the Unix dd utility during their day, but I figured it’d be pretty cool to have a PowerShell implementation. This cmdlet provides read only access to the physical disk or logical volume, and returns the requested data as a byte array.

For a practical example of Invoke-ForensicDD, check out my Copying Locked Files with PowerForensics post. Not only does this show leveraging Invoke-ForensicDD to copy a locked file, the post also shows how PowerForensics builds on this functionality to provide more user friendly APIs.

Common Use
Like the unix dd utility, Invoke-ForensicDD has an -InFile parameter that should be used to point at the physical drive (\\.\PHYSICALDRIVE0) or logical volume (\\.\C:). An optional -OutFile parameter directs the output to a file instead of PowerShell’s output stream. The -Offset, -BlockSize, and -Count parameters provide instructions regarding what data to return (-Offset and -BlockSize must be divisible by the physical disk’s sector size, typically 512 bytes). Like Unix’s dd, -BlockSize represents the number of bytes to read at one time while -Count represents the number of BlockSize chunks to read. By default, -Offset has a value of 0 (the beginning of the file) and -BlockSize has a value of 512 (the smallest number of bytes that can be read at once).

This example reads 512 bytes from the beginning of the physical disk (\\.\PHYSICALDRIVE0) and passes the output to Format-Hex:

Invoke-ForensicDD -InFile \\.\PHYSICALDRIVE0 -Count 1 | Format-Hex

Read the first 512 bytes from the logical volume (\\.\C:) and write output to C:\evidence\VBR:

Invoke-ForensicDD -InFile \\.\C: -OutFile C:\evidence\VBR -Offset 0 -BlockSize 512 -Count 1

Forensic Friday: Get-ForensicUsnJrnl

[This article is a continuation of my Forensic Friday series.  Every Friday I will provide a short post on a forensic topic of interest or PowerForensics functionality (such as cmdlet descriptions, use cases, and details about lesser known features). Subscribe to Invoke-IR so you don’t miss a Forensic Friday!]

Welcome back to Forensic Friday! This week I want to highlight the Get-ForensicUsnJrnl cmdlet, which parses the $UsnJrnl file or NTFS change journal.The UsnJrnl is responsible for keeping track of file system operations such as file creation, deletion, and truncation. During an investigation I highly recommend inspecting the $UsnJrnl as it provides extremely detailed context about what has transpired on the file system. For example, this is especially helpful in providing details about a deleted and otherwise unrecoverable file.

Common Use

By default, this cmdlet parses the $UsnJrnl file (\$Extend\$UsnJrnl) on the system’s C: volume, but can be pointed at any logical volume. An exported $UsnJrnl file can be parsed using the -Path parameter in order to perform offline analysis. I’ve listed a few examples below. The -Usn parameter tells Get-ForensicUsnJrnl to parse and return a single entry.

Parse a volume’s UsnJrnl & store in $usn variable (Example using volume “C:”):

$usn = Get-ForensicUsnJrnl -VolumeName C:

Parse $UsnJrnl file based on path & store in $usn variable (Example path C:\$Extend\$UsnJrnl):

$usn = Get-ForensicUsnJrnl -Path ‘C:\$Extend\$UsnJrnl’

Parse $UsnJrnl entry based on Update Sequence Number (Example with Usn #1189553536):

Get-ForensicUsnJrnl -VolumeName C: -Usn 1189553536

Forensic Friday: Get-ForensicFileRecord

[This is the first article in my Forensic Friday series.  Every Friday I will provide a short post on a forensic topic of interest or PowerForensics functionality (such as cmdlet descriptions, use cases, and details about lesser known features). Subscribe to Invoke-IR so you don’t miss a Forensic Friday!]

Lets start with Get-ForensicFileRecord, the PowerForensics cmdlet I tend to use the most.  This cmdlet parses the Master File Table (MFT) of an NTFS formatted volume (more formats are in the works).  This function provides the base for all other NTFS based PowerForensics cmdlets and allows an analyst to perform a variety of different tasks (finding files, recovering deleted files, detecting timestomping, etc).  As always, please leave any questions or comments about this post below, maybe you’ll inspire the next Forensic Friday post!

Common Use

By default, this cmdlet parses the $MFT file on the system’s C: volume but can be pointed at any logical volume. The -Index and -Path parameters tell Get-ForensicFileRecord to parse and return a single MFT File Record. Lastly, an exported $MFT file can be parsed using the -MftPath parameter in order to perform offline analysis. I’ve listed a few examples below.

Parse a volume’s Master File Table and store in $mft variable (Example using volume “C:”):

$mft = Get-ForensicFileRecord -VolumeName C:

Parse MFT record based on Index/Record Number (Example with Index 0):

Get-ForensicFileRecord -Index 0

Parse MFT record based on file path (Example with C:\Windows\System32\config\SAM):

Get-ForensicFileRecord -Path C:\Windows\System32\config\SAM

Parse an exported Master File Table (Example for C:\evidence\MFT):

$mft = Get-ForensicFileRecord -MftPath C:\evidence\MFT