Tr3Secure Data Collection Script Reloaded
Sunday, September 15, 2013
There are a few movies I saw in my childhood that had an impact on me. One of those movies was Back to the Future. To this day I still have vivid memories leaving the theater after watching it and being filled with wonder and excitement. The final scene in the movie is relevant to the discussion about triage scripts. In the scene, Doc reversed his time-traveling DeLorean onto the road. Marty sitting in the passenger seat says "hey Doc you better back up we don't have enough road to get up to 88". Marty's comment was based on his previous experience with the DeLorean. The car had to reach a speed of 88mph to time travel and to reach that speed required enough road to drive on. Doc said to Marty in response "Roads? Where we're going we don't need roads". Then the time-traveling DeLorean lifted off of the road and flew back at the screen. Whenever I think about triage scripts I paraphrase Doc to myself saying "Hard drives? Where we're going we don't need hard drives". My updated Tr3Secure collection script makes this statement a reality for triaging systems; it makes it possible to go in a direction where we "don't need hard drives".Re-introducing the Tr3Secure Volatile Data Collection Script
Sometime ago I released the Tr3Secure Volatile Data Collection Script and accompanied the release with the blog post Dual Purpose Volatile Data Collection Script describing it. The script's focus was on the collection of volatile data only and it served a dual purpose. "First and foremost it had to properly preserve and acquire data from live systems". "The second required function was the tool had to help with training people on examining volatile data". The script served its dual purpose but it had its limitations. As a result, I overhauled the script with a focus on improving its capability as a triage tool. In the process as it evolved its name change to properly reflect what the tool is; meet the Tr3Secure Data Collection Script.
Tr3Secure Data Collection Script
It's probably easier to say what in the script remained the same than it is to say what is new. For the practically usage the script retained its: flexibility, organized output, documentation in a collection log, and preservation according to RFC 3227. For the training usage, the script retained the ordered output reports and references pointing to the books Windows Forensic Analysis, 2nd edition and Malware Forensics: Investigating and Analyzing Malicious Code for the volatile data collection. Before going into the changes I have to give a shout out to Troy Larson. Some of the new functionality in this script where inspired by his ideas and the wicked cool For loop to grab the user profile registry hives is his. Now let's move on to the changes starting with the minor updates followed by the significant upgrade.
Minor Updates
The first noticeable modification is the way the script executes. I dropped the need to interact with the script to make it execute with command-line syntax for complete automation. Now you can enter one command to collect volatile data, non-volatile data, or image the memory. Speaking about imagining memory leads me to my next change. I dropped Memoryze and went with the winpmem program. The last minor update I wanted to highlight was an addition to the preservation activities. When the script runs it tries to preserve certain data to prevent evidence from being overwriting. I added the collection of two more items; one of which is the NTUSER.DAT registry hive of the user account running the script. For the other minor updates refer to the change_log.txt accompany the scripts.
Significant Upgrade
The original Tr3Secure Volatile Data Collection Script focused on collecting volatile data such as open files, network connections, and running processes. The one area that I felt was lacking was the script's ability to collect non-volatile data. When I approached upgrading the script I asked myself one simple question. What data would I want from the hard drive if I couldn't have the entire hard drive? The end result is very telling by my paraphrasing the Back to the Future quote: "Hard drives? Where we're going we don't need hard drives". Below is a highlight of the new data collected by the Tr3Secure Data Collection Script.
- Grabs the partition information
- Images the MBR (to help with MBR infectors)
- Images the hard drive from the MBR to the sector of the first partition (to help with MBR infectors)
- Collects all registry hives. By all I mean the ones in the config folder, Regback folder (for Windows 7), and the hives from every user loaded user profile
- Grabs select Windows event logs and in Windows 7 the entire log folder
- Grabs the scheduled tasks
- Grabs the NTFS artifacts $MFT and $LogFile. I opted to go with RawCopy from my post Tools to Grab Locked Files
- Grabs the group policies applied to the system
- Grabs the McAfee logs and quarantine folder (this is for demo purposes and should be customized for your environment)
Tr3Secure Data Collection Script Syntax
Viewing the script with a text editor shows the syntax on how to use the script and all of my detailed comments. Below is syntax to run the script:
tr3-collect.bat [case number] [drive letter for storing collected data] [menu selection #]
[case number] = the unique identifier for the case
[drive letter for storing collected data] = drive letter of where the collected data is to be stored
[menu selection] = optional field and can be used to collect the following:
1 = Acquire Memory Forensic Image
2 = Acquire Volatile Data
3 = Acquire Non-Volatile Data
4 = Acquire Volatile and Non-Volatile Data (default)
5 = Acquire Memory Forensic Image, Volatile, and Non-Volatile Data
i.e.
tr3-collect.bat 2012-09-14_1 F
tr3-collect.bat 2012-09-14_1 F 3
A cool thing to keep in mind. The drive letter to store the collected data can either be a removable media attached to the system or a mapped drive to a network share.
Tr3Secure Data Collection Script for User Account
In my talk Finding Malware Like Iron Man I walked through a mock scenario responding to a system and triaging it for malware. One of the comments I made was that it is faster and more efficient to collect data either by going over the wire or using collection script. Being an incident responder time is of the essence so taking the time to remove and image a hard drive takes too long. Some may see the new functionality in the Tr3Secure Data Collection Script and say to themselves. Wait a second, you aren't collecting certain data so the hard drive is still needed. Those who said this to themselves are correct and my response to them is to check out the new script that accompanies the Tr3Secure Data Collection Script. The Tr3Secure Data Collection Script for User Account collects data from a specified user profile on the system. Below is a highlight of the data collected.
- Grabs the Recent folder contents to including LNK files and jump lists
- Grabs the LNK files in the Office Recent folder
- Grabs the Network Recent folder contents
- Grabs the entire temp folder (great location to find attack vector artifacts)
- Grabs the entire Temporary Internet Files folder
- Grabs the PrivacIE folder (to see why check out my post Malware Root Cause Analysis)
- Grabs the Cookie folder
- Grabs the Java Cache folder contents (Java anyone)
One thing I wanted to be clear about why this second script was needed. In corporate environments and to a certain extent systems used by home users there are multiple loaded user profiles on a system. Pretty much on ever single examination I've done over the last five years my interest has only been on one or two user profiles. The other profiles were old and left on the system. Trying to collect the above data from every loaded user profile is not only inefficient but takes way too much time. Time that is better spent responding to the system as opposed to waiting for the collection script to finish. As such, I put the collection of the user profile data in a separate script so it can be run against the one or two user profiles of interest.
Tr3Secure Collection Script for User Account Syntax
Viewing the script with a text editor shows the syntax on how to use the script and all of my detailed comments. Below is syntax to run the script:
tr3-collect-user.bat [path to store collected data] [user profile name]
[path to store collected data] = the path to store the collected data without any quotes or spaces
[user profile name] = the user account's profile name to collect data from
i.e.
tr3-collect-user.bat F:\Data-demo2\computername-08.12.13-19.14 jsmith
Similar to the Tr3Secure Data Collection Script, the path to store the collected data can either be an attached removable media or a mapped network share.
Where Are We Going
When I made my comment in my Finding Malware Like Iron Man presentation it was because of the capability I have with these triage scripts. I first run the Tr3Secure Data Collection Script to grab the volatile and non-volatile data followed by running the Tr3Secure Data Collection Script for User Account to collect the user data. Both scripts are pretty fast and they provide me with all of the data I would need to triage a system. I can even leverage the triage technique I outlined in the presentation against the collected data to find malware and do root cause analysis in less than 20 minutes. Not bad and hopefully my Back to the Future reference now makes a little more sense: "Hard drives? Where we're going we don't need hard drives".
You can download the TR3Secure Data Collection Script from the following download site.
Posts
The user version of the script doesn't seem to collect AntiVirus logs.
Any thoughts on whether remoting this, perhaps with psexec?
The tr3-collect.bat script is the one that collects the AV logs. There is only code to collect McAfee logs so you need to change it for other AV products. Open the script in a text editor then search for McAfee to find what to edit. I didn't want to try to account for every AV product.
At this time this version is the only one I'm releasing publicly so anything relating to remote capability I won't discuss on my blog.
why did you go for winpmem and dropped memoryze ?
Thanks for the new scripts
It would be nice for script to collect some non-volatile data from volume shadow copies also (e.g. registry hives, event logs, $MFT, $LogFile, etc.).
Thanks
@tamer
I dropped Memoryze for two reasons. The first was to launch Memoryze in a script it opens a second command prompt. I wanted to avoid this. The second reason was because at times Memoryze wasn't consistent. Sometimes it would fail and the time to acquire memory varied too much. Winpmem was a little more consistent but I'm still on the lookout for other options
@anon
It wouldn't be too hard to modify the script to collect data from VSCs but would this extra data be worth it. Is the additional time sacrificed worth collecting all the same data from VSCs. I ask because I haven't had the need to parse VSCs for triaging since the data on the computer can answer my questions. For deep dives VSCs are helpful but I haven't used them for triaging
Have you tried Moonsols' Dump it utility for memory? It works
well on various Windows architectures.
Remote execution would be amazing. In disparate and complex corporate environments, it can take some time following the detection of an event before addressing the system responsible.
@Kevin
I did look at Dumpit and my issue with it is the inability to specify where the memory image goes. It drops it in the current directory and you can't pick where it gets stored (i.e. mapped drive). Win32dd won't work either since the free version isn't scriptable.
Agreed about the time lapse and this is something I'm currently working on.
Hello,
They are a lot of problem with your script :s why don"t acquire exe in tools directory ?
For exemple you
use netstat.exe: Located in Windows\System32 folder
If they are a Rootkit or just a malware nestat.exe can be corrupt. If you use your exe, with your MD5hash of this, it's better for your case
@sanguinarius
I took into consideration running tools on the target operating system. Trying to account for exes on the target system wasn't worth the effort. Some programs are os dependent (runs either on XP or 7). It was would have required accounting for 32 and 64 versions. All this effort isn't needed. If you suspect there is a Rootkit then just dump the memory. It doesn't matter what native tools the Rootkit is messing with since you can do memory forensics.
I'm trying to re-create this at a new company. It looks like TeamCTI is no more and I cannot seem to find a pv.exe for the tools directory. Any idea on where do find this?
Kevin,
I dropped pv.exe in future version since it was no longer available.
http://journeyintoir.blogspot.com/2014/08/autorip-tr3securecollection-dfs-updates.html
Corey,
I like adding ipconfig /displaydns
Your thoughts?
Question:
What information can be found in the java_cache?
Do you recommend specific tools to parse the cookies & Temp_Internet_Files?
Great product!!
@anon,
In regards to the java cache it contains a wealth of information about where those files came from. I pasted below a few links that illustrate what I mean:
(Almost) Cooked Up Some Java
http://journeyintoir.blogspot.com/2011/02/almost-cooked-up-some-java.html
Java Malware - Identification and Analysis
http://www.ghettoforensics.com/2013/04/java-malware-identification-and-analysis.html
BinMode: Parsing Java *.idx files, pt. deux
http://windowsir.blogspot.com/2013/01/binmode-parsing-java-idx-files-pt-deux.html
As for the tools you asked about, I use a few different ones. If you prefer GUIs and are still learning about these artifacts then try out the Nirsoft tools. The have various tools for web browsers.
Corey, awesome job man. Friend pointed me to your website, started with iron man slides and now this. I appreciate you sharing this.