Tuesday, July 31, 2012

EnCase EnScript to list and resolve all the file permissions on a drive

I recently had a need to create a list of users who had data on a disk. One of the solutions I came up with was to go through every file on the disk and look at the owner permission. Once I had the owner's SID, I wanted to get the corresponding username so I used the PsGetSid utility from Sysinternals.

To automate this, I created an EnScript wrapper to recurse through all the files on a disk, get a list of unique SIDs, then pass the SID to the PsGetSid utility, then create a Excel spreadsheet with the SID, username, total number of files that user has and the total number of bytes those files occupy.


The first time you run the EnScript it will ask where the PsGetSid executable is and then remember that for the future. The command line options are in case you are running this EnScript on a non-domain machine, but want to resolve domain SIDs. You can then specify a domain machine to query against by specifying a \\computername -u username -p password option as articulated in the psgetsid syntax help:


Usage: psgetsid [\\computer[,computer2[,...] | @file] [-u Username [-p Password]]] [account | SID]
     -u         Specifies optional user name for login to
                remote computer.
     -p         Specifies optional password for user name. If you omit this
                you will be prompted to enter a hidden password.
     account    PsGetSid will report the SID for the specified user account
                rather than the computer.
     SID        PsGetSid will report the account for the specified SID.
     computer   Direct PsGetSid to perform the command on the remote
                computer or computers specified. If you omit the computer
                name PsGetSid runs the command on the local system,
                and if you specify a wildcard (\\*), PsGetSid runs the
                command on all computers in the current domain.
     @file      PsGetSid will execute the command on each of the computers listed
                in the file.

To run:
Select (blue check) the files you want to process, then run. Once completed, the output will be in the console tab and it can then be selected and pasted into Excel (it's tab delimited). It will look similar to this:



Monday, July 23, 2012

Updated F-Response + EnCase EnScript = Powerful tool!

A little over two years ago, I was lucky enough to work with Matthew Shannon when he was beginning to develop the scripting object within the F-Response tool. At that time, I posted a proof-of-concept EnScript that used the scripting API of the F-Response tool.

Fast forward two years and the F-Response tool has only become better. Matthew has also enhanced the scripting capability of the F-Response client. These past two years have allowed people to realize the extreme power of the F-response tool when controlled through a scripting language. The COM object of the F-response tool can be controlled by almost any programming language that can "talk" COM. In my previous POC, I wrote a simple EnScript to show how to control the F-response client by installing it, starting it, connecting to it, then doing something with the target disk inside EnCase, then disconnect, stop and remove the client.

A recently updated version of my initial EnScript is provided below to demonstrate the F-Response scripting capability within EnScript and the amazing power of combining the two together. The example EnScript will connect to the specified remote host and simply search for the file named "pagefile.sys" and display some basic metadata in the console if it is found. While this example is a powerful example, your imagination is really the only limit of how you can leverage the scripting capability of the F-Response client within a scripting language, such as EnScript.



The previous version was compiled into an EnPack. This version is uncompiled and easily readable with a text editor. You can easily modify this base source code to perform additional functions.


Download here (EnCase v6) 



Monday, July 9, 2012

Safely and efficiently imaging a MacBook Air

I was reviewing some training material I put together today related to imaging MacBook Pro and MacBook Air laptops. I wanted to create a simple decision tree for the common scenarios when encountering Mac laptops. The basic breakdown was this:

  1. Remote imaging (really only used in corporate environment)
    1. Using SSH/SCP to load and start agent
  2. Locally imaging
    1. Target Disk Mode (easiest)
    2. Booting to external OS (CDROM or external hard drive) Used when device does not support TDM.
One of the discussion points was how to quickly and efficiently image the internal drive of a MacBook Air. While newer models have two USB ports (allowing an external CDROM and external HD), older models only have one. No ethernet, CDROM or firewire (TDM), so the common simple solutions are not available.

The simplest solution seems to be a large external drive that has a bootable OS on a small partition, but then a large second partition (FAT32 or NTFS) that can be used to hold the image.

Boot the MacBook Air by holding down the "option" key and selecting the listed bootable external drive. Once booted, you could use an imaging tool for that OS (OSX or linux) to image the internal drive to the external drive. 

This solution only requires a single USB port and seems to be the simplest method. Although I would recommend using a powered external drive, this should work with a bus powered USB external laptop drive as well.

Aside from pulling out the internal drive, I would be interested in hearing what other people are doing or have found to be the quickest/safest/most efficient way?


Computer Forensics, Malware Analysis & Digital Investigations

Random Articles