Windows Live Response collection vs. JackPOS

The primary reason on why I took the time to put together the Windows Live Response tool collection is that I got to the point where I was experiencing the same things over and over again and I wanted an easy way for either myself or anyone else to be able to collect this data in an easy fashion. While combing through the output of the script itself may not solve your case completely, it does have the potential to help point you in the right direction very quickly and can greatly reduce the size of the haystack in which you are trying to find a needle.

As long-time readers of my blog know, I have a second-hand system that I like to do a lot of my malware and tool testing on that I affectionately call my "Malware Box of Evil". For this example, I installed a malicious file onto the system and ran the Windows Live Response tools.

One of the first things that I like to look for on a system are persistence mechanisms. This could be slew of different items, such as a registry entry, scheduled task, installing as a service, etc. For this case, I opened up the "PersistenceMechanisms" folder and took a look at "autorunsc.txt"

Data contained in "PersistenceMechanisms" folder in Windows Live Response collection

The batch script is written so that autorunsc.exe runs with the "* -a -v -m -f" options:

* - prints data for all users

-a - shows all entries

-v - attempts to verify digital signatures

-m - hides signed Microsoft entries (NOTE: I include this to try to limit the sheer amount of data that is shown as Windows runs a LOT automatically. Even if malware is a signed Microsoft entry it "should" show up in other output from the Live Response tools. I haven't encountered that yet, but I am well aware it could be an issue)

-f - prints hashes of files

After opening our autoruns file, there is one entry of particular interest here, namely one for a "Java SE Platform Updater". The two main reasons that it jumps out of interest to me are that the version is apparently 1.0.0.0 and the company name is "K-Software". While we all know Java has its short-comings (and there are many) I would be very surprised if "K-Software" was a legitimate name associated with Java.

Autorunsc output 

One of the nice features of autorunsc is that it can also give the hashes of files that have been identified by the tool. A quick search on just the hash reveals quite a bit of interesting items on the first page alone.

Searching for the md5 of the file

Of course, of particular interest is a VirusTotal entry, which tells us that 28/48 engines identified the file as malicious.

VirusTotal results on file (captured on 19 March 2014)

But what if I didn't have internet access from wherever I gathered this data? Fortunately, there are some other items in the collection that can help you highlight "abnormal". One of my favorites is the "Installed Software" output from running WMIC. 

Installed software from WMIC

One of the items that I want to highlight here is that out of all of the applications installed on my machine (admittedly, there are not many as it is a stand-alone system), Java is not one of them. This is not a 100% sure-fire method to highlight potential evil, however, it can once again help lead you in the right direction (for example, DeepFreeze is installed on the system and it does not show up here.)

What if the malware was a little more advanced and purposely disabled some tools, like anything from sysinternals,  and ended up preventing them from running on a system? Well, that is part of the reason that I try to pull the data using a couple of different mechanisms. If a certain tool or process fails, hopefully one of the other ones will pull out the data. In this case, we turn to the output from WinAudit. The output shows us the same autorun entry, as well as the running service again with the "K-Software" name and "1.0.0.0" version.

WinAudit startup programs

WinAudit running programs

So hopefully this brief example helps highlight just how beneficial having something like the Windows Live Response collection can be. We didn't even look at the executable file itself; we simply are able to highlight some items of interest and do our best to try to identify "abnormal" as quickly as possible. I tried to make the script's data output as basic as possible so that anyone can open them and view the data with ease. 

LiveResponseCollection-Cedarpelta.zip - download here 

MD5: 7bc32091c1e7d773162fbdc9455f6432
SHA256: 2c32984adf2b5b584761f61bd58b61dfc0c62b27b117be40617fa260596d9c63
Updated: September 5, 2019

Announcing OSX Live Response bash script (and updates to Windows Live Response too!)

Good news everyone!! After having some time the past couple of weeks to work on my Live Response automation project, I am happy to announce that a bash script, for running on OSX machines, is available in the latest download! The script focuses on gathering data from the following areas:

BasicInfo

• date
• hostname 
• who 
• ps auxwww (List of running processes)
• mount  (Mounted_items)
• diskutil list 
• kextstat -l (Loaded kernel extensions)

UserInfo

• /etc/passwd
• /etc/group
• .bash_history
• .sh_history
• AddressBookMe.plist

NetworkInfo

• netstat -an
• lsof -i 
• scutil --dns 
• netstat -rn
• arp -an
• ifconfig -a 
• ifconfig -L
• /etc/hosts.allow
• Wifi connections
• Firewall Configuration
• NAT Configuration
• SMB Configuration

PersistenceMechanisms

• LaunchedLogInItems.plist
• loginwindow.plist
• User Launch Agents
• System Startup Items
• Library Startup Items
• System Launch Agents
• System Launch Daemons
• Library Launch Agents
• Library Launch Daemons
• Application LogIn Items

Logs

• copying all log files from /var/log/
• copying all log files from /private/var/log/

The following steps is the methodology that I recommend to run ths script:

1. Place the script on an external drive
2. Insert drive to your OSX device
3. Open Terminal
4. cd to the device (for example, cd /Volumes/MORANHD01/LiveResponse/OSX_Live_Response)
5. Run the bash script ("./OSX_Live_Response.sh")
6. Profit!!

When the script is complete, it will hash the output of all of files (MD5 and SHA256) and store that in a separate text file for your viewing/parsing convenience. The script has not had the extensive testing that the Windows Live Response script (simply because I do not have access to a wide range of OSX systems) but in the testing that has occurred I (and others) have not encountered any issues. If you do, please let me know and I will try to update the script accordingly. If you also have suggestions and/or improvements to the script, please let me know that as well!!

Windows Live Response Update!!

I am also very happy to announce that I have modified the Windows Live Response script as well, it includes the latest version of PEStudio (8.12 as of 19 March 2014). In addition, the output of the script is also stored in a folder structure that makes going through the output a little easier and the collected data is also automatically hashed. I also changed the autorunsc command syntax to produce better results...more on that in my next blog post!

LiveResponseCollection-Cedarpelta.zip - download here 

MD5: 7bc32091c1e7d773162fbdc9455f6432
SHA256: 2c32984adf2b5b584761f61bd58b61dfc0c62b27b117be40617fa260596d9c63
Updated: September 5, 2019

(NOTE: The original upload of the OSX script, version 1.3, had a pathing issue that was pointed out to me by Cristina Roura. The download link has changed, as the script has been updated to version 1.4 to fix this issue. It was an oversight on my part as I made the folder output the same for the Windows collection and the OSX collection, but forgot to update the pathing accordingly in the script itself. Also please notice, the hashes of the file have also changed. I am truly sorry for any inconvenience that this may have caused!) 

For the keen observers, you will note there is a "nix" folder in the Live Response zip file. My goal is to get a *nix version of the script working in the very near future so that way you can download the LiveResponse.zip file and have something to deal with any system you may encounter. I have several items on my "To Do" list regarding the script(s) but if you have any ideas or feedback please do not hesitate to let me know!

Some quick "lessons learned"

My little corner of the Internet has been quiet for a few weeks as I have been involved with some case work. One of the things that I try to do on every single case that I work is not only learn from it, but also to share what I have learned so hopefully if someone encounters the same issue(s), there is at least one resource that they can go to (hopefully more, but sometimes that is unfortunately not the case).

Two tidbits of information that I want to highlight from this care are:

1) Ensure that your tool(s) recognize the data they are trying to parse 

2) SQLite queries can be your friend. Or your enemy. But try to make them your friend

"Ensure that your tool(s) recognize the data they are trying to parse"

This issue came up when I had the joy of parsing several gigabytes of data from iOS backups, going back as far as 2007. Now, as you may or may not know, the iTunes MobileSync backup data structure has gone through several changes during the course of their existence. Originally the data was saved as ".mdbackup" files, which contained some header information at the very beginning of the file. Then iTunes moved on to a combination of .mddata and .mdinfo files, where the header information was contained in the .mdinfo file, and the actual data was contained in .mddata files. Then they did away with file extensions completely, which is where we still are today (The fine folks over at AppleExaminer have a nice post on the older backup structures, you can read it here if you wish.) 

Since the backup structure is very widely known and has been around for a long time, I figured that commercial tools available on the market today could handle the backups with no problem. What I was very surprised to find out is that, in fact, processing them is a VERY big problem! On this particular case I used AccessData's MPE+ to process the backups. It did a fine job on the "newer" files, however, the older data (I believe it was not only the .mdbackup files that it had an issued processing and that it was also the .mddata/.mdinfo files, but I didn't take the time to do additional research because once a tool was confirmed as not pulling out the data, I move on to something that can).

In the end, I ended up using MobileSyncBrowser (available for $20) and an old Perl script I wrote when initially performing iOS backup research to ensure the results were valid. MSB is, in my estimation, a very under-appreciated tool that everyone performing mobile forensics should have in their toolkit.

Tweeting about my experiences with MPE+

"SQLite queries can be your friend. Or your enemy. But try to make them your friend"

This statement partially falls in line with my aforementioned problems with the iOS backup parsing, but it also applies to SQLite data in general. You should be aware of how to pull at least some, if not all, of the data that your tools "extract" from SQLite databases to ensure they are working properly and not, for example, adding an additional seven days to a time stamp or anything like that. You do not need to know how to get the 100% same result (although, admittedly that can benefit you greatly if you do know how to get the same result) but at least having the capability to run "SELECT * FROM Messages" in a SQLite browser will go a long way in validating tools, techniques, and processes.

On an unrelated note to iOS backups, I also found the parsing the database file "Envelope Index" (and subsequent files) on OS X to with some SQLite to be incredibly helpful. While I am sure there are better ways to parse the data, this statement allowed me to quickly get an idea for email addresses/subjects/dates to be looking for with regards to potential items of interest. I couldn't find any SQLite queries online to extract this data, so if you know of a better way to parse it, please do share!! You can throw some LIKE statements in there toward the end as well, particularly in "addresses.address", to try to find email addresses of interest.

SELECT addresses.address as "Email Address", addresses.comment as "Display Name", DATETIME(messages.date_sent, 'unixepoch') as "Date Sent", DATETIME(messages.date_received, 'unixepoch')as "Date Received", DATETIME(messages.date_last_viewed, 'unixepoch')as "Date Last Viewed", messages.subject_prefix, subjects.subject, messages.snippet FROM recipients LEFT JOIN addresses ON recipients.address_id = addresses.ROWID LEFT JOIN messages ON recipients.message_id = messages.ROWID LEFT JOIN subjects ON subjects.ROWID = messages.subject ORDER BY messages.date_sent ASC 

Basic Envelople Index SQLite query

Always ensure that you know what your tools are doing behind the pretty GUI. "Trust but verify" is a term that it used a lot in our field and verifying the results can make a HUGE difference in the overall completeness of your forensic examination!!