Helpful Navigation Toolbar

Wednesday, March 4, 2015

And you get a POS malware name...and you get a POS malware name....and you get a POS malware name....

This morning I woke up to find Trend Micro/Trend Labs had a new post on an "old undetected PoS malware" which they have called "PwnPOS". I was interested at first, but this looks like just another case of randomly assigning names to malware and/or threat actors. Unfortunately for the folks at Trend, who usually put out pretty good work, the scraper in question (which is an executable file that I have personally seen with many names, but we will refer to it as "wnhelp.exe") is old. Very, very old. In fact, the date/time stamp embedded into the file itself is from 2010.

wnhelp as seen in PEStudio 8.46

The scraper is very basic, it looks through memory looking for Track data, and when it finds matching data, it saves it to a file "perfb419.dat" which is under the Windows/System32 folder. There are sometimes legitimate files with similar names under this path, no doubt it was an effort for the attackers to try to make the data blend in. 

Example of "track" data collected in perfb419.dat. 

The scraper itself does not have an active exfiltration mechanism, so either an additional file(s) is needed to exfil the collected data or the attacker(s) can remotely access the system and send the file out (email, ftp, file sharing site, etc). wnhelp uses a "service" persistence mechanism in order to stay running on the machine, so looking at just CurrentVersion/Run in the Registry will not allow you to detect the file. The service is named "Windows Media Help", and the information that is collected from the Live Response Collection using SysInternals autorunsc is listed below:

wnhelp embedded under the "Windows Media Help" service

The exfiltration methods listed in the Trend article "might" be new, but I cannot be certain as I personally do not have access to those files (yet, I am working on that). I am leery of how new these files may be though, simply based on the liberties that Trend appears to have taken with the original wnhelp file. Additionally, of all the files listed in the Trend post, the most recent compile time is listed as 2012, with most of the compile times dating back to 2010. None of these files appear to be "new" at all. 

Not "new" or "under the radar"

Back in 2013, the wnhelp sample was uploaded to malwr, among other sites, to use their automated malware analysis tool

malwr results from 2013

Additionally, a Google search for the md5 hash (c86327222d873fb4e12900a5cadcb849) shows that, at the very least, a user of the domain "" posed a question about wnhelp back in 2012. I did not dig through all of the results, but 83 search results, with several entries on the first page relating to "malware" in one form or another, is hardly flying "under the radar". query of wnhelp from 2012

In the Trend post, the author stated "PwnPOS is one of those perfect examples of malware that’s able to fly under the radar all these years". As you can see from just the examples that are listed above, that statement is simply not true. It does highlight the importance of understanding "what" is running within your POS environment. It also highlights the fact of regularly checking systems within your POS environment to make sure that they are running properly and there is nothing "else" (malicious or otherwise) running on those systems.

Several month ago I came across a domain that was hosting this (and other) samples of POS malware. I collected all of the samples and files on the domain. The owners of the domain let the registration lapse a few months ago, at which time I purchased it and re-directed it to "" (my own way of "getting back" at bad actors). If you are interested please feel free to contact me, I will share some of the files with you (I cannot share them all, as some of the files contained information that I legally cannot share).

Thursday, February 26, 2015

Gone Phishing

Hello again readers! Today's blog post deals with a phishing email that was sent to my Yahoo! email address that I received two days ago, allegedly from DHL. Interestingly enough the Symantec web filtering that Yahoo! uses did not block the attachment. As you can see, it is purposefully misnamed a few times. I cannot speak to the implementation of Symantec that Yahoo! uses, but I would love to know more about how it works if anyone has a contact at Yahoo!

The email came from the Display Name "sales company", and was titled "from DHL customer service". The file contained an attachment "[DHL Express tracking] (1)" (md5: 86915fae2dd82e039aab70c64ff1f5ef) (SHA256: 109f10822f89acf1a70665d7628173bc9c58c6f4d327bdbd0ca368e675f965c9). Maybe you were expecting a shipment from DHL, so maybe this email would not seem out of the ordinary to you. Hopefully the fact that the file has both a .PDF and .ZIP file extension raised a flag of caution and you recognized this as phishing, but let's proceed as if nothing odd was noticed. 

Original email, purportedly from "DHL". I believe the Norton/Symantec logo means the attachment was checked and passed a test, but not exactly sure what that test entails

Looking at the full header, we see that the email was sent from the email address "". I am pretty sure that an organization such as DHL would not use a Hotmail account to send tracking information, but once again, let us continue down the analysis path.

Email header of the DHL email

When we download the file, we can see that it is indeed not a PDF, but it is actually a .zip file. It also looks like it will create an .html file when we unzip it, which is exactly what happens.

Hex Workshop view of [DHL Express tracking] (1)

Unzipped file, now named "[DHL Express tracking] (1).pdf.html"

When opening the web page, we are presented with yet another classic sign of attempted phishing, a "DHL" webpage that requests your email address and password. Hopefully this is alarming enough and you do not put in any information.

This is the web page that is displayed when you open the html file 

Now that we have a web page, let's explore the formatting of it a bit. The icons for various email providers at the bottom are odd (why is "eBay" there?), especially on what is supposed to be a legitimate DHL page. Additionally, does any legitimate web page use Comic Sans MS font? 

When we look at the file in a text editor, we can see that the email address and password are required. We can also see that the page has an ironic meta tag, and the actual domain where your email address and password will be sent to.

Viewing "[DHL Express tracking] (1).pdf.html" in Notepad++

Just for fun, I entered the email address and the password "password" into the text box. 

Fake email address and password

Unfortunately after entering my "email address" and "password", I was redirected to the DHL home page. I had hoped the creators of this phishing email would have at least displayed a message stating "We are sorry, we cannot find your package in our database" or something similar, but all that happened was a basic redirect to the real, legitimate DHL home page. 

After all that, a simple redirect to DHL. Darn!

The moral of this blog post is to be wary of phishing email attempts. Most companies will never ask for your email address or password with regards to looking up information, especially in an unsolicited like this. Be sure to watch out for things like misspellings, odd looking icons, mismatched file extensions, and files with multiple extensions (""). If you feel that you are unsure about an email, ask a member of your IT or information security staff. Also do not hesitate to reach out to the "sender" of the email directly with a phone call, to make sure that it is legitimate. 

If you would like to look at the file, I just uploaded it to (might take a little while to process) as well as submitting it to VirusTotal (5/57 detections).

Wednesday, February 11, 2015

A (new) way to consider getting data from mobile phones

Hello again readers! Today's post is possible as the result of a joint collaboration with Berla ( in an effort not only to give some exposure to the very interesting and exciting world of vehicle forensics, but also to show how data stored on a vehicle can be an additional medium from which you can recover information, especially when you encounter devices for which no method exists. In fact, you can recover mobile phone data from vehicles that the device has synced to in the past, even if the device is not currently synced with the car! This post covers only a very, very small subset of the amount of data that can be recovered using the tools and techniques employed by Berla.

The subject of this post is a typical user, who employs pretty good overall security practices and owns a Samsung Galaxy Note II. This particular device is password protected, the encryption option for both the phone and the SD card are turned on, and USB debugging mode is turned off. Using a standard mobile device forensic solution, such as Cellebrite UFED, and trying a variety of different methods of extraction yields no results. This means that the data that is stored on this phone is not accessible through traditional methods. 

Galaxy Note II - Physical Extraction Attempt

Downloading... (or at least that is what it says!)

Extraction in progress...(or at least that is what it says)

First Extraction Error

Logical extraction attempt

Extraction in progress. Part II

Another extraction error. Foiled again!!

I verified that USB debugging is not on

It is passcode protected too. Curses!!

The steps that this user took to protect their device are fairly standard and easy to accomplish, especially if the user follows some basic mobile device security best practices. However, this particular user also has a lot of music stored on their device (for long commutes, subway rides, and general time passing) and, on a regular basis, syncs the device to their automobile (in this case, a uConnect system from a 2014 Fiat 500L). This is where Berla and the iVe Vehicle System Forensics can come into play and, quite honestly, may be the only source of mobile device data that you can collect.

The folks at Berla were nice enough to set up the uConnect as well as give me a quick run through of the iVe program. If you've had any experience dealing with mobile devices, the steps are going to be kind of similar, with helpful techniques and procedures (and even videos!) built-in to the iVe program to help make your vehicle data extraction go as smoothly as possible. For ease of convenience, in this case we used a uConnect 6.5/RA3 and I connected my phone over Bluetooth. (NOTE: There will be a future post about the data pulled after a USB connection, as well as posts regarding different vehicle systems and the amount of data that can be extracted from them). The Chrysler brand uses various versions of the uConnect in their family of vehicles.

First we powered on the uConnect and turned on Bluetooth on the Galaxy Note II and started the sync processes.


Bluetooth syncing with uConnect

Successful sync!

uConnect prompt requesting access to contacts and call history

Not only can you now see my contacts and call history, you can also see up to the last 16 text messages visible on the device that were received prior to syncing with the uConnect (it is a feature, not a bug!) plus all additional messages that are received while the device is synced and connected via Bluetooth. I included a couple of screenshots from the uConnect showing this data (personal contact information removed, with the exception of a telemarketer call)

uConnect recent calls

SMS (not MMS, and only the last 16)

All contacts
(NOTE: I would like to stress again that it may very well be possible to get more data from a USB sync. Since it requires some more setup that is planned for a future post)

Once that was done, it was time to fire up iVe and extract the data from the uConnect. I cannot stress how easy Berla has made this process. It's very simple, just point, click, fill in the fields, and run the tool.

iVe Forensics GUI

Choosing the vehicle and target systems. Guides and videos are included to help you through this process if needed.

I always want as much data as possible, but partial (user data only) is also an option and is much faster.

Everything looks good, ready to rock!

Case information entered just before acquisition, just in case something in the setup process goes wrong!

And it begins!

One of the many great things about iVe is, on top of extracting data from a vehicle, is it also presents the data in a nice, simple format. Thus far it seems like a majority of the files have been SQLite databases. iVe goes a step farther and does some parsing of the data and puts it in a nice, easy to read format so even if your SQLite skills are not up to the challenge, the program can show you data such as Address Book entries, SMS, and Call History. 

Overview of data gathered by iVe (look at all of the synced devices!)

iVe parsed SMS (including panda emoticons!)

Call logs from device

Address book from device

You can export the data, if you so desire!

I also included a screenshot showing the SQLite database file "pm7000033.dbf" which, in this case, contains the SMS messages. I believe the name of the file and the path that it is under may vary, depending on the vehicle (more testing is needed for that, I didn't think to ask the question today during our extractions)

Hex Workshop and Windows Explorer view of "pm7000033.dbf", which is a SQLite database containing the SMS data from the uConnect

(NOTE: The uConnect seems to have a built-in feature that automatically powers off if running from a battery alone for more than 15 minutes. This should only happen if the uConnect has been removed from a vehicle and is set up in a lab/workbench environment. This may come into play if the vehicle has been in an accident and you must remove the uConnect from the vehicle in order to extract data from it. It took four tries (thus the name Try4) to get the full acquisition, as it took about 23 minutes. Fortunately on the last attempt I was able to hit the power button in time and keep it on before it powered off. If you are doing performing a uConnect data extraction from inside a vehicle, you should not encounter this because the uConnect will be in auxiliary mode.)

If it were not for iVe, we would have not gotten any data associated with this particular mobile device. Thanks to iVe, we managed to get a total of 1521 Address Book entries, 18 SMS, 86 call events that were associated with the device. It is definitely something to keep in mind if you are faced with a mobile device that you cannot extract data from!

There is one more key area that I would like to address, which is the protection of data that is important to you and your company. Let's imagine a scenario where you are a C-level executive working for Galactic Empire, Inc. and you fly from New York to Los Angeles in order to meet with some business representatives regarding very sensitive plans for a new Death Star you are building. There have been many text messages between you and other senior level executives with details on your secretive project. Since you have been with Galactic Empire, Inc. for many years, you have a lot of music (like the Imperial March) on your company-owned mobile device that you want to play during your drive from LAX to your hotel, so you sync your device with your rental vehicle for easier playback. Simply playing music seems innocuous, and despite prompts saying the device wants to access your information, you choose to anyway because it is "just a car". However, there is a very good probability that you also just synced your address book, call history, and (at least some) SMS messages with the vehicle. All a competitor (or security researcher, hacker, or other malicious actor) has to do is gain access to the data stored within the vehicle and they will be able to potentially gain access to much more information than just the music that you thought you synced, even if your mobile device is no longer present in the vehicle. Mobile device syncing with vehicles is yet another factor that businesses should consider in their risk analysis assessments of cyber security.

Friday, January 30, 2015

GUI, Logging, Compression, and Encryption -- Updates to the Live Response Collection!

Hello again readers! Over the past few weeks, in between cases, I have been hard at work trying to get a couple of new features implemented into the Windows Live Response Collection. Today I am very happy to announce those changes are ready to be publicly released!

Change 1: A GUI

The first change that you may notice is in the Windows folder, there is now an executable file named "Windows Live Response Collection.exe". When you run this executable (which asks to run Administrative privileges), you are presented with *gasp* a GUI that allows you to choose between a total of six options: Secure-Complete, Secure-Memory Dump, Secure-Triage, Complete, Memory Dump, and Triage. There are two main reasons for the GUI, the first being that if you need to collect data from a system with a touchscreen (like a POS system) you no longer need a keyboard and/or mouse to do so. The second is, quite honestly, most people are more comfortable with a GUI.

The Windows Live Response Collection now has a GUI!!

Change 2: "Secure" options

There is a brief description of each option next to your choice, but the most notable change in this release are the "Secure" options. If you choose one of these options, upon completion of the data gathering, the output is compressed and encrypted using 7-zip with a one-time, randomly generated 16-character password. Once this occurs, the original data is deleted using SDelete (this runs up to 10 times). In my testing I was able to recover a couple of file names, but none of the actual data. Choosing one of the "secure" options allows you to collect data from various systems. This way if the drive ends up in the wrong hands, you can feel fairly confident that the collected data cannot be opened. This additional layer of security will be useful in cases where drives have to be transported or mailed.

You are prompted a few times to ensure that you copy the password, because if you do not, short of brute-forcing the password, there is no way to open the 7zip file. So, I cannot stress this enough, if you use one of the "Secure" options, please make sure that you copy the password and never save them on the same drive as the data.

Change 3: Logging options

The Windows Live Response Collection now has automatic command error/processing logging, which is cleverly stored in the "Processing_Details" text file. For ease of looking through the files, "File_Hashes" is now stored separately as well. 

File_Hashes and Processing_Details in the folder

Example of data contained in Processing_Details file

All six of the options have their very own batch script, so you can still choose to run the batch script if you would like. Also, for your convenience and customization options, the GUI is simply an .hta (html application) that essentially acts as a wrapper around the batch scripts. So as long as you do not rename the batch scripts themselves, you can still edit the batch scripts and the GUI will still run them. However, please note that if you customize it I cannot guarantee that the script will run properly, so please ensure you have an understanding of the batch scripting language and the changes/functionality that you want to add prior to running it through the GUI. - download here

md5: ee39cbb201b46346b6a136701caf1088
SHA256: 7bc8114536b47845b89aee9df96abb6cd0896209c414ee2e5ee3685a29b27037

Upload Date: 30 January 2015

Other Live Response options worth noting

The fine folks over at Yelp put together (and more importantly, publicly released) an OSX collection script that is built primarily for their environment, but it performs a few functions, such as LSQuarantine parsing, that my OSX collection script does not. I highly encourage you to check it out, if you have not done so already!

Blog post

OSXCollector on GitHub

CrowdStrike also announced an update to their Crowd Response tool, which delves into some Superfetch data. I have not had a chance to test it out that much, but please be aware their tool requires PowerShell, which (in my experience) is not installed on many POS terminals, which is one of the primary platforms that I built the Live Response collection for. 

Crowd Response blog post 

Beside these options, there are many other tools that you can use for gathering volatile data from systems, (Corey Harrell's Tr3secure script is one that I highly recommend checking out if you have not already). I compiled the Live Response Collection primarily to gather data from systems that I primarily deal with, which will end up saving my clients costs associated with travel and on-site analysis, but please remember that different tools are written with different functions and different end users in mind. 

Monday, December 8, 2014

Even More Live Response Collection Updates!!

Hello again readers! The last update to the Live Response collection was about two months ago, and I have been working on adding more open-source tools and data collection processes to the collection. I also tried to enhance the way that the Windows Live Response collection operates, including building in some file/location existence checking in an effort to ensure compatibility with newer version of Windows, including some initial attempts at gathering data from Windows 10, with many thanks going to Brad Garnett for doing testing on these newer versions.

While a majority of the changes are going to be transparent to the end user, the processing of some items, like Sysinternals, has greatly changed. It also leverages a couple of really powerful tools to copy files, such as Registry Hives, $MFT, $LogFile, $UsnJrnl, and Event Logs from Windows systems. In a blog post in about a month ago Corey Harrell pointed out an awesome tool from Joakim Schicht  that allows the extraction of the $UsnJrnl that not only copies it from a system, it also only extracts "used" data, which usually results in a very great reduction in size. To quote Joakim: 

"This may be a significant portion of the total data, and most tools will extract this data stream to its full size (which is annoying and a huge waste of disk space). This is where this tools comes in, as it only extract the actual data for the change journal. That way extraction obviously also goes faster. Why extract 20 GB when you might only need 200 MB?" 

The script also now leverages another great data extraction tool, forecopy_handy. By using this tool, it also allows copying of in-use files such as Registry Hives, Event Logs, and browser related files from a live system. If you create a disk image using the "Complete" version of the script it is likely that you will get access to these files, but this method allows you to take the files prior to (or instead of!) creating a disk image if you would like.

There are also many changes to the overall processing performed by the script, for example, before the script would delete the entire Registry folder related to Sysinternals, but Luca Pugliese pointed out that in some investigations you may very well be looking for when Sysinternals was installed on the system, and that method could very well wipe out evidence (which could potentially be a bad thing). The script now checks for evidence of Registry Keys related to the Sysinternals programs that the script requires. If it finds them, it updates the value to "1" (to ensure the tool will run without user interaction) and that is the only change that is made. If the key is not found, it will populate the required Registry keys, but it will still clean up after itself. 

Extracting the $MFT, $LogFile, and $UsnJrnl had always been in my plans (especially if you use the TriForce tool) but I just hadn't had the time to work on the updates until the past week or so.

Please do not hesitate to reach out if there are any items that you commonly use during the course of an investigation that the script does not currently extract, and hopefully it can be included in the next release. For example, some of the requests for data collection from Windows are:

  • Automatically encrypting the output of the script (volatile data collection, memory, and disk image)
  • More browser history related file extraction
  • Log file collection (IIS logs, AV logs, application logs, etc.)
  • Data collection/file hashing for all users (not just current)

I am hopeful that the next release will cover most, if not all, of the requests. I am also hopeful that automated Mac memory collection and drive imaging will be included in the next update (fingers crossed!) - download here

md5: ee39cbb201b46346b6a136701caf1088
SHA256: 7bc8114536b47845b89aee9df96abb6cd0896209c414ee2e5ee3685a29b27037

Upload Date: 30 January 2015

Wednesday, December 3, 2014

Part of an Afternoon with TrustPipe...

Today an article that sounded interesting was pointed out to me, regarding a company named TrustPipe that is claiming to catch 100% of network attacks. A direct quote from their website:

"Our patented technology understands the DNA 
of the Internet — what’s good and what’s bad.
It can detect virtually every attack — even the 
brand new "zero-day" ones — and protect you."

Naturally I was intrigued by this, although the cost of the tool (five dollars for five years) seemed to be awfully cheap, and I was a little surprised that the two options at the bottom of the screen are "Rest of World" and "Mainland China". 

My location options are "Rest of World" and "Mainland China". That seems a little odd.

When I did a Google search for the company, I came across their Twitter account which, since joining in 2011, as a total of one tweet. That also seems odd, especially for a company that does as much business at the article states.

Since February 2011, the company Twitter account has tweeted one time. Again, that seems odd to me.

At this point I was a little concerned, and I decided to use a very low limit credit card that I seldom use, just in case I had any more bad vibes after making the purchase. I paid the five dollar cost and received an email to download the tool. The instructions seem fairly straight-forward, and I downloaded the tool.

The download instructions after paying five dollars for TrustPipe

I transferred the file to my Malware Box of Evil and I ensured that I had .NET 3.5 installed prior to the installation, just like the instructions stated.

When I tried to install the program, I got an error message 1721 stating that there was a problem with the installation.

Error trying to install TrustPipe

I tried to install the application a few times before giving up. If there is an installation problem I would very much like to be told what the program that is needed would be, rather than a general error. I did a little bit of digging into the program with PEStudio and didn't see anything that jumped out at me as a warning flag, but then again, it is difficult to say without spending some time reverse engineering it, which I am not inclined to do at this point. The bottom line for me is that this product, which is supposed to be lightweight, easy to use, easy to install, etc. will not even install properly on the Malware Box of Evil, which is running Windows XP SP3. I don't see how a product geared towards specifically working on Windows XP cannot run/install properly on the box, but at least I am only out five dollars.

Their website is not very helpful and it does not have very much information, and browsing the LinkedIn profiles of their "Team" page on the website, it is hard to determine exactly who is employed by TrustPipe and who is not. I would love to hear from anyone who has actually used the product and am curious on their results with it. I was looking forward to testing some POS malware with TrustPipe running to see how it would fare, but due to the installation problems I don't even recommend getting the application for testing purposes. I also immediately called up my credit card company and cancelled the card that I made the purchase with. With the bad vibes that I felt going through the initial checkout process, I felt that it was best to cancel the card and request a new one, just in case.

Thursday, October 16, 2014

Automated Windows disk imaging? Sure, it can do that!

Hello again readers! After a busy couple of weeks, I had some time to work on adding a new feature to the Windows Live Response collection, automated disk imaging! This means that when you run the "Complete_Windows_Live_Response" batch file (with administrative privileges) that, on top of creating a memory dump and gathering volatile data from a system, it also attempts to identify all mounted drives on a system (excluding network shares) and if your destination drive has enough storage space, a forensic image of the drive will be created. It also will not allow you to create a disk image of a device when the destination is that device itself (in other words, you cannot run the script from a folder on your desktop and create a disk image. The memory dump will still occur, but disk imaging will not). And best of all, after each image is created, if you have more than one drive, the free space calculation runs again to try to ensure that the destination drive has enough free space available. Because of this new functionality, the Windows Collection also has three different scripts available:

"Complete_Windows_Live_Response.bat" must be run with Administrative privileges to work to the fullest extent possible. This script creates everything in the "Memory_Dump_Windows_Live_Response.bat" script, as well as creates full disk images of logical drives (except for network drives) on a device. This script must be run from an external device (or internally on a non-system partition) in order to create the physical disk image. The external device also must have more free space available than the size of the drive(s) that it is imaging (it checks prior to each image being created for free space). This is the ultimate "plug it in, run it, pick it up" option. The script can run without administrative privileges, however running the script with non-administrative privileges will not create the disk image or the memory dumps.

"Memory_Dump_Windows_Live_Response.bat" is the traditional Windows Live Response collection.  The script will automatically collect a memory dump and copy files of interest (such as Prefetch files) to the %computername% folder. It will also leverage hashdeep to compute the md5 and SHA256 hashes of Windows PE files located in the %WINDIR%\system32 folder and the %SystemDrive%/Temp folder (if it exists). It will also compute the md5 and SHA256 hash of every file, recursively, in the %TEMP% folder. It will also run netstat -anb, to provide results of services with open connections and it will also install winpcap, in order to run an nmap scan in an attempt to detect evidence of ARP poisoning. It needs elevated privileges to perform these functions, but it can be run without administrative privileges as well.  However, it will not return as in-depth of results as it would have if it were run with administrative privileges

"Triage_Live_Response.bat" is the "lite" version of the Windows Live Response collection. This gets rid of time consuming elements like the Memory Dump and WinAudit. It is still best to run this with administrative privileges, but it should work much faster and give an examiner quicker results than the other scripts.

In order to run the script, you should complete the following steps:

  • Step 1 - Download the Live Response collection
  • Step 2 - Unzip the Live Response collection to an external drive (I prefer USB3 hard drives larger than 1TB in size)
  • Step 3 - Navigate to the Windows Live Response folder on your external drive
  • Step 4 - Run "Complete_Windows_Live_Response"
  • Step 5 - Check back in a few hours, the image should be complete!

I made a short video using Snagit showing the above steps as well, which is embedded below:

I tried my best to make it as easy as possible to run as well as putting in as many checks as possible, within the batch script, to ensure that something bad would not happen. The update allows an incident responder, system administrator, help desk associate, non-IT savvy employee, etc. to be able to do an initial collection from a Windows system, as long as they have (at least) local administrative privileges. I built-in checks so that a disk image will not be created on the device that you are trying to image (you can do a memory dump still on a local machine, but disk imaging will not occur). It will also ignore the drive where you are running the script from, but if that drive has other partitions that are recognized, those will be imaged (please be aware of that and try to use drives with only one mounted partition as your destination).

I also had to debate whether to image the entire physical drive or just the logical drive. After going back and forth, I decided on the logical drive, for a couple of reasons. The first reason is that if we image the logical drive, we may indeed be missing some data, but if you utilize full disk encryption and we image the entire physical drive, more than likely we will have to decrypt that image at some point. This could add steps to the analysis process, so I tried my best to keep it as straight-forward as possible. The second reason is that with the physical drives, it will take into account multiple partitions on the internal drive. While this may be a catch-22 if you have multiple partitions on the destination drive, I decided to go that route to ensure if you have another volume mounted on your system (like TrueCrypt) that will get imaged as well.

You may also note that I added the GPL to this instance of the Live Response Collection. All of the tools included in the collection are available to use at no-cost, but I want to ensure that the work that went into making the scripts work and perform the automated memory dumps and disk imaging remains available to anyone who wants to use it. While I certainly hope that a company would not take the Live Response collection and attempt to monetize it, I felt that putting the GPL in there would be another step that I could take to try to ensure that monetization of the collection will not happen. - download here

md5: ee39cbb201b46346b6a136701caf1088
SHA256: 7bc8114536b47845b89aee9df96abb6cd0896209c414ee2e5ee3685a29b27037

Upload Date: 30 January 2015

As always, any feedback is very welcome and if there are any features that you would like to see in a future update to the collection, please let me know! Happy automated disk imaging everyone!!