Hello again readers! First off, I want to start the post by announcing that the latest update to the Live Response collection of tools is up; you can download it here:
LiveResponseCollection-Cedarpelta.zip - download here
Updated: September 5, 2019
The main highlight of this update is the inclusion of a Linux script that gathers data from a live system. I still want to add quite a bit of features and functionality to the script but I wanted to get a version out that automates most of the items listed in the Malware Forensics Field Guide to Linux Systems. Some of the items that the script collects are:
• Copy contents of “log” folders
• Determine date on the system
• Determine hostname of the system
• Determine logged in users on the system
• Determine running processes on the system
• Determine process tree (and arguments)
• Determine mounted disks/items
• Review output of disk utility
• Determine loaded kernel extensions
• Determine system uptime
• Determine system environment
• Determine (more detailed) system environment
• Determine OS kernel version
• Determine running process memory usage
• Determine running services
• Determine all loaded modules
• Determine “who” logged in user is
• Review .bash_history for each user
• Determine current network connections
• Determine socket statistics
• Determine list of open files and network connections
• Determine routing table
• Determine ARP table
• Determine network interface information
• Review allowed hosts
• Review denied hosts
This version includes a "Triage" version of the Windows script, but it does not collect a memory dump and it does not run WinAudit, to save some time (creating memory dumps and running WinAudit can take a long time). I still recommend running the full script whenever possible, but sometimes you don't need a memory dump or have the ability to create one with a different tool. I don't want to force you into using something else, so I took those two specific items out.
I also included checklists for each of the operating systems covered by the collection (Windows, OSX, and Linux) and updated a couple of items in the Windows collection like PEStudio and the latest version of FTK Imager. I kept the old version of FTK Imager as well which is why the size is roughly double what the previous size of the zip file was. I will phase out the older version in the next release but I wanted to keep it in case there is an imaging issue with the latest version. Please do not hesitate to provide any feedback (positive or negative) regarding the use of these freely available tools!
SUPER AWESOME BONUS FEATURE!!
I also try to ensure that the data from the tools can be use by other, already existing tools, and last week I encountered a prime example of using the output with a tool to get data that I was looking for.
As you may know, the Windows Live Response script attempts to identify executable files and hash those files which are located in the %WINDIR%\system32 folder, the %SYSTEMDRIVE%\Temp" folder, and ALL files in the %TEMP% folder. The script uses the program md5deep to perform these activities. My goal for this output was to search for the hashes on VirusTotal (or your malware repository of choice) and try to identify possibly malicious files that were on the system(s).
Fortunately for all of us in the community, Didier Stevens already wrote "virustotal-search.py", a small Python script to perform queries using your own VirusTotal API key, with the added bonus of writing the script so that it can process data that kind of follows a specific format! So rather than having to re-parse the output data, if take the output from md5deep and you run his script with the "-c" flag (for "Comment"), it will look up the hashes and save them to a nice CSV formatted file for you. Then you just have to import the file into Excel, choosing the semi-colon (";") as your delimiter, and you have a nice view of what files have already been scanned to VirusTotal. It even takes into account the API query limits for the standard (free) API keys. Pretty cool!!
|Contents of "Hashes_md5_User_TEMP_WindowsPE_and_Dates.txt" file created by the Windows Live Response script using md5deep|
|Formatted results of the script. How awesome is that?!?!|
Thanks for this awesome collection!ReplyDelete
You are quite welcome! Please don't hesitate to reach out if you encounter any issues or have any ideas for enhancements or new features!Delete
I'm sad, I had really high hopes. In the spirit of the internet I will offer no help but will criticize
Strike 1) You giving people a script that uses system binaries that could themselves be compromised :-(
2) You don't test that binary is there you just attempt to run it.
3) You don't reset your path change the IFS or do anything related to securing shell scripts
HERE! This link doesn't suck: https://developer.apple.com/library/mac/documentation/OpenSource/Conceptual/ShellScripting/ShellScriptSecurity/ShellScriptSecurity.html
Well the last one was help.
Please don't give people bad data to work with. If they don't read your script then they are users but as an "EXPERT" you have to take heed
YOU SHOULD NOT KNOWINGLY COMMIT HARM!!!!! If you didn't know SHAME, SHAME, SHAME
Thank you for taking the time to comment. I am sorry you are sad, so let me try to help some of your sadness!
1) I fully admit, and have admitted on many occasions in the past, that it uses internal binaries on the system that could be compromised. I don't have a good way around that yet, but perhaps you could take some time from your busy schedule to ensure the necessary files, folders, and dlls are included to work on every version on Windows to alleviate that problem!
2) I did indeed change the scripts to test for the presence of executables that are included with the LRC when I changed to the modules approach. Have you downloaded and tried the latest version? In fact, the screenshots in the Writing Your Own Module Post http://www.brimorlabsblog.com/2015/09/introducing-windows-live-response.html show that the line to test for the binary is there. (if exist %TOOLSCRIPTPATH%[Tool path] and the you substitute your own binaries and commands accordingly). I don't believe I missed any brought along binary in the new code, but if I did please let me know where and I will fix it!
3) I know that I can improve on some of the coding practices of batch and shell. Let's be honest, no matter what you write or code, there are always "other" ways to do it, so getting help and input like yours is very valuable to try to make the best possible community driven open source tool! I fully intend to work on cleaning up the code when I have time. And once again, if you would like to help I appreciate it!
With you sharing your thoughts on the LRC in such detail I would imagine that your insight is based off of an older version, so please look at the new one and please do not hesitate to reach out to help to make it a better open source tool!
My comments were around
nix_Live_Response.sh --> # RELEASE DATE: 20160112
$sha256sum.exe nix_Live_Response.sh -->
The scope of my assessment was for the nix tool only. I have not looked at the Windows tool as of this writing.
Since you're project is not on github or anything like that. I can't fork it or do any of the things that someone might do that would ultimately improve the state of affairs while promoting my own brand. As such it would not be strategic for me to contribute to your efforts through the means you've provided thus far.