Tuesday, January 12, 2016
Hello readers and welcome back! Today we are proud to announce the newest round of updates to the Live Response Collection, specifically with a focus on some new features on the OSX side!
Improved OSX features!
The biggest change is that the OSX version of the Live Response Collection now creates a memory dump using osxpmem, as long as you run the program with root privileges. The script does the internal math, just like on the Windows side, to make sure that you have enough free space on your destination, regardless of whether or not it is an internal or external drive. I have encountered where OSX provides differently formatted results for the sizes (sometimes throwing in things like an equal sign or a random letter) and I tried to account for that as much as possible. If you encounter a bug with the memory dump please let me know and I will try to figure it out, but as I have done more and more work on the OSX side I have come to realize just how terrible OSX is. For example, some Apple programs do not work properly if it was created on Yosemite and it was running on El Capitan...so much for "it just works"! If you encounter any issues I will try to get to the bottom of it as best as I can though!
The other main OSX feature is a topic that was briefly touched on during the Forensic Lunch on Friday. Dave, Nicole, and James talked about the FSEvents Parser that they wrote. If you run the script with root privileges the script will copy the fseventsd data to the correlating destination folder, and then you can run their tool to go through the data. (NOTE: It is best to transfer the data to a Windows machine to do this, otherwise the fseventsd data may be hidden from you, depending on how the access permissions on your machine are set)
A new naming scheme!
As you may have noticed, the title is "Live Response Collection - Allosaurus". I decided to go with the names of dinosaurs to differentiate between Live Response Collection versions, which will also ensure that you are using the latest build and also to help with any bugs that may pop up. Sometimes a bug that is reported has been fixed in a newer release, but because of the old naming scheme, it wasn't immediately clear if you were actually using the latest build.
As always, please do not hesitate to contact me if you have any questions or comments regarding the Live Response Collection
LiveResponseCollection-Allosaurus.zip - download here
Updated: January 12, 2016
Thursday, January 7, 2016
Hello again readers and welcome back! Today's blog post is going to cover an instance, which unfortunately occurs WAY to often in the cyber-security realm, especially on the topic of "threat intelligence" or "advanced analytics" or whatever other buzzwords the marketing folks are spinning since it is now 2016. I had originally planned to write this post toward the end of the month, but the more I thought about the whole incident the angrier I got, so I am posting it much earlier than I had anticipated.
The subject of today's post involves a very large company. I have redacted their name and information at the request of the company involved and will be referring to them as "Kelvarnsen Industries" and an external company that I will call "Mountebank Labs". (FULL DISCLOSURE: I have not had any dealings, personally, with any member of Mountebank Labs but I have since spoken with several individuals who have). Apparently a few days ago, the CEO of Mountebank Labs sent an email to the CIO of Kelvarnsen Industries informing them of "an early warning about an email they have received (or are about to receive) that contained malware [sic]". A friend of mine works at Kelvarnsen Industries and asked my opinion about the email, which was flagged internally by the CIO as a phishing attempt because his first name was wrong (not just spelled wrong, his name was actually wrong), the message contained a slew of grammatical errors and sentences that made no sense, and referenced something that really did not seem possible. Honestly the most disturbing piece of the email sent from Mountebank Labs is that it appears they are actually targeting Kelvarnsen Industries in their "threat intelligence" platform:
|"Alert" information sent from Mountebank Labs CEO to Kelvarnsen Industries CIO|
I took a look at the referenced data and was able to easily determine it was email that was sent ENTIRELY internally, as the policy for Kelvarnsen Industries is to upload suspected malicious emails with attachments directly to VirusTotal. Yes, you read that 100% correctly. The email appeared to come FROM a legitimate internal user, sent TO a legitimate internal user...because....wait for it....THAT IS EXACTLY WHAT HAPPENED!!!
To take a quote from their blog post, in which they wrote about this as a "win" (with my own comments added in BOLD):
|Excerpt from blog post, with my own comments added|
Now, we can argue the merits of uploading samples to VirusTotal or doing analysis on them internally first. In this case, I personally happen to support the former, because there is no need for the internal CIRT to respond to an email that contained an attachment which solely installs a toolbar for "Decent Looking Mail Order Brides", so depending on what the VirusTotal results determines the internal escalation of the email. If an actual advanced threat group is trying to infiltrate an organization and they have a piece of malware uploaded to VirusTotal and the whole world can see it, so what? It means that they have been discovered and will probably have to come up with something new in an effort to achieve their goal of infiltrating their target. VirusTotal is simply a tool that we can use, it is not the end all be all solution (see malware, polymorphic)
There are a limited number of individuals and companies that work in our profession, but that number is growing every single day. Unfortunately this growth also brings with it individuals who misrepresent capabilities and understanding of pertinent information, but are more than happy to sell you products and services that usually come with very expensive price tags. In this particular case, it looks like Mountebank Labs is loading domains into VirusTotal and, when a hit comes back, shooting off an email to the CISO or CIO of the company and "alerting" them. While there is nothing "wrong" with that aspect of it (although frankly, I don't know how you can have the time or resources to do that, as everyone that I know has plenty of work with our own clients and don't need to put out a blanket domain search in VirusTotal in an effort to drum up work), in my opinion it is not the right thing to do.
I do perform monitoring from several data sources for my clients, and in the event of discovering data from another company, I will inform them who I am, who I work for, of exactly what I was doing, how I found their data, where they can go to find that data, how to contact me, and leave it at that. I strive to be as 100% transparent as possible because the last thing that I want to have happen is a company to think that I was the source of their data being compromised. If they want to have additional conversations that is entirely up to them and I tell them so. I want to help people protect their networks and sensitive data, regardless of whether or not they hire me to help them. If you receive an email like this, the author of the email (who will usually NOT be a CEO or a member of the sales team, it will likely be a technical employee or a manager) should answer several questions in the original message without your or your CIRT team searching for answers to these questions:
- Who exactly are you?
- What company do you currently work for?
- What were you doing when you found this information?
- Where did you find this information?
- When did you find this information?
- What is your contact information (not in a signature block, you should clearly list your contact information)
If these questions are not answered with very specific details, it is more than likely going to be just another marketing email, trying to get you to spend your money to utilize their services. Granted, this may not always be the case, but usually, it will be. When in doubt, you can always get a second opinion, which is exactly what Kelvarnsen Industries did when they contacted me regarding this issue.
This case also highlights another area of importance that I cannot stress enough. It is bad enough that CIRT/Net Defenders/etc. teams are tasked on a daily basis with detecting and thwarting attacks by adversaries. When a company's C-Suite executives receive an email like this, the teams must stop everything that they are doing in order to manage their C-Suite executive's concern and ultimately determine if an email such as this is an actual phish or is nothing more than vaguely worded and misconstrued marketing attempt (ahem...scare tactics). This also shows that unknowledgeable individuals are targeting companies, in publicly available data sources, in an effort to find out more about them in an attempt to secure a business deal. Pretty ironic that these folks are doing the EXACT same thing that adversary groups are doing: attempting to gather information for their own financial or informational gain. The irony of that is not lost on anyone! The unfortunate truth about marketing emails like this is that, just like phishing, they must work occasionally or else these unknowledgeable individuals would not send them. These teams also have enough to do on a daily basis (plus after-hours and weekends, as was the case here) without having to deal with the Marketing Persistent Threat. Blatant marketing attempts such as the one detailed in this post hurt MUCH more than they could ever possibly help!
Thursday, November 12, 2015
Hello again readers and welcome back! Today we are pleased to announce the release of a new version of buatapa, updating from version 0.0.5 to 0.0.6. The changes are going to be mostly transparent for end users, but it does account for a change in the output of autoruns.csv files generated with the recently release Autoruns 13.5, which has an additional field in the output. The new version of buatapa attempts to identify if the autoruns.csv file was generated by Autoruns 13.5, or if it was generated by Autoruns 13.4 (or earlier). The parsing of the data and need for the VirusTotal API key to do the VirusTotal lookups is exactly the same.
And as a super awesome bonus feature, it also performs queries of ThreatCrowd and returns data if it is found. In order to not have to write an additional timer (the ThreatCrowd API is limited to one query every 10 seconds) I included the ThreatCrowd lookup with the VirusTotal lookup, so for the purposes of buatapa you are required to have the VirusTotal API in order to perform the ThreatCrowd look ups. You can modify the script to not require that if you wish, but if you do that be sure to allot for a 10 second sleep between each query.
|Output results of buatapa 0.0.6|
In this particular instance, we have two URLs, one is for the Virus Total results of the hash:
|VirusTotal results for the ZeroAccess malware sample|
and the other is for the Threat Crowd results of the hash:
|ThreatCrowd results for the ZeroAccess malware sample|
If it has been noted on ThreatCrowd you can go through the information listed to look for additional information on the malware, including domains and IP addresses, in an effort to help combat/detect other instances of the malware within your environment. Plus, the pictures are really nice!!
buatapa_0_0_6.zip - download here
Updated: November 11, 2015
Friday, October 30, 2015
Hello again readers and welcome back! For us, October consisted of a lot of traveling giving presentations about the Live Response Collection at BSides Raleigh, Anne Arundel Community College, WomenEtc. (Richmond, Virginia), and the Open Source Digital Forensics Conference (OSDFCON). I just posted the presentation that I gave at OSDFCon on slideshare, if you would like to view the slides!
NOTE: I made some slight variations on the presentation at each venue, so if you attended one (or more!) of my talks you will notice that the slides are similar, but may not be exactly what you saw.
All of the events that I spoke at were great, but I was most impressed with OSDFCon this year. There was an incredible lineup of speakers at the event and the venue and presentation was fantastic (And thanks again goes out to Ali for all of her hard work, mainly behind the scenes, to ensure the event went smoothly!). There were quite a few students and other new entrants into the DFIR community at this years event, which is always great to see. Hopefully that trend continues, as there is not a single person within the DFIR community who has gotten to where they are today without the help, collaboration, and communication of others!
Not to give away any spoilers, but I am working on some exciting updates for the Live Response Collection, primarily on the OSX side, that I hope to have out before the end of the year. I am always looking for anyone who can devote any time or resources for beta testing, so if you want to help please do not hesitate to reach out!
Monday, September 21, 2015
Hello again readers and welcome back. Today I am very happy to announce the public release of the latest round of updates to the Live Response Collection. This release focuses on the "modules" that I touched briefly on in the last update. The size of the six main scripts themselves has been greatly reduced and almost all of the code now resides in the folder "Scripts\Windows-Modules". This makes maintaining the code easier (since all six scripts share a large majority of the code, it only has to be edited once instead of six times) and allows even greater customization opportunities for end users.
There are some small changes to the way the LRC handles data, including a built in check to ensure the date stamp does not have weird characters, which was seen on some UK based systems. The script now attempts to decipher that data properly but, in the event that it cannot, it tries to ensure that backslashes are removed from the date field so that way the output of the tools and system calls are stored properly.
Writing your own module!!
The main focus of this update is demonstrating how easy it is to create your own module. I attempted to make this process as easy as possible, so if you want to write/add modules, you can do so very easily. Since it is written in batch, you can write your own module however you would like, but following this methodology should present the best results and ensure that the script will error out rather than possibly present bad data to you.
The first thing you have to do is choose an executable (or system call) that you would like to add. In this particular case, I decided that the "Wireless NetView" executable from nirsoft would be a good choice for the walk through. The first thing you have to do is to download the zip file from their website. Once that is done, navigate to the folder and unzip the file. Once that is done, you should see a folder like this.
|Contents of the folder "wirelessnetview"|
Copy that folder to the "Tools" directory under the Windows Live Response folder.
|wirelessnetview folder under "Tools"|
Once that is done, you are ready to begin writing your module!
Initial Steps of Module Creation
|Contents of Windows-Module-Template.bat|
Once you have it open, save it as the tool name that you would like to run. In this case, I would open the file "Windows-Module-Template.bat" and save it as "wirelessnetview.bat".
|Saving the template as our new module|
Now you can begin to edit the "wirelessnetview.bat" module and add more functionality to the LRC!
Writing the module
1) Have an understanding of what command line arguments you need to give your executable file (or system command), and
2) Be able to find and replace text within your new batch script
You should not have to change any of the environment and script variables, so I will not cover them in great detail, unless a specific request is made to do so. Here is a full listing of the items that you should replace (Ctrl + H in most cases):
YYYYMMDD - Four digit year, two digit month, and two digit day (19970829, 20150915)
DD - Date you wrote the module, with two digits (03, 11, 24, 31)
Month - Month you wrote the module (July, March, December)
YYYY - Year you wrote the module (2015, 2016, 4545)
[Your Name] - Your name, if you want to put it in there (Brian Moran, Leeroy Jenkins)
[you@emailaddress] - Your email address, if you want to put it in there (firstname.lastname@example.org, email@example.com)
[Twitter name] - Your Twitter name, if you want to put it in there (Captain America, Star Wars)
[@Twitterhandle] - Your Twitter handle, if you want to put it in there (@captainamerica, @starwars)
[MODULENAME] - What you want to call your module. I prefer to use the tool name, so in this case WIRELESSNETVIEW
[Tool path] - This is the path, within the tools folder, of the folder name and the exe. In this case, it would be wirelessnetview\WirelessNetView.exe
[command line arguments] - This is where you have to do some testing of running your tool from the command line before you create the module. In this particular case, I am going to use what is listed on the web page as the command I want to run. The full command is
WirelessNetView.exe /shtml "f:\temp\wireless.html", so our [command line arguments] in this case would be /shtml
[Output folder] - The folder that you want to output the data to. Since this is network related, saving it under "NetworkInfo" seems like a good idea.
[Output file name and file extension] - The filename that you want to save the file as. Generally I make this the name of the tool, so I would call this one "Wirelessnetview.html".
[Tool name] - The name of the tool. (Wirelessnetview)
[Executable name] - The name of the executable (WirelessNetView.exe)
[Executable download location, if applicable] - The URL where you downloaded the tool from (in this case, http://www.nirsoft.net/utils/wireless_network_view.html)
And that is it!
**Please note that you can choose between modifying saving output directly, or saving output from the executable/command itself. It is best to refer to the executable or system command when trying to determine "how" you should save the output.**
So when we modify the wirelessnetview.bat file, we replace the following items with their value:
YYYYMMDD - is replaced with 20150917
DD - is replaced with 17
Month - is replaced with September
YYYY - is replaced with 2015
[Your Name] - is replaced with Brian Moran
[you@emailaddress] - is replaced with firstname.lastname@example.org
[Twitter name] - is replaced with BriMor Labs
[@Twitterhandle] - is replaced with @BriMorLabs
[MODULENAME] - is replaced with WIRELESSNETVIEW
[Tool path] - is replaced with wirelessnetview\WirelessNetView.exe
[command line arguments] - is replaced with /shtml
[Output folder] - is replaced with NetworkInfo
[Output file name and file extension] - is replaced with Wirelessnetview.html
[Tool name] - is replaced with Wirelessnetview
[Executable name] - is replaced with WirelessNetView.exe
[Executable download location, if applicable] - is replaced with http://www.nirsoft.net/utils/wireless_network_view.html
|Screenshot of our new module, after replacing the text!|
Now that our module is written, we have to add the module to whichever batch scripts we would like. I usually like to keep the modules that perform similar functions near each other, so in this case I am going to choose to add it after the PRCVIEWMODULE. The easiest way to do this is simply copy the five lines of text associated with the PRCVIEWMODULE entry, and paste it below it.
|Selecting the code associated with PRCVIEWMODULE|
|Copying the code associated with PRCVIEWMODULE to create a new subroutine for our new module|
Once you have it copied, change the line GOTO ....MODULE in the original module to the name of your new module. In this case, we would change it to GOTO WIRELESSNETVIEWMODULE. Then change the name of the subroutine itself to the name of your module, in this case WIRELESSNETVIEWMODULE.
|Adding WIRELESSNETVIEWMODULE code|
Finally, change the name of the batch script that is being called to the name of your newly created script, then save it. That is it, you are all done!
|Our module is fully added!|
It is best to run your module(s) on a test system before deploying it widely, just to ensure that everything works properly. Also ensure that you add the code for your new module to each of the six batch scripts, if you so desire.
I hope that this tutorial has been helpful, please do not hesitate to contact me if you have any additional questions or comments as you create your own modules for the Live Response Collection!
LiveResponseCollection-Allosaurus.zip - download here
Updated: January 12, 2016
Wednesday, August 26, 2015
Hello again readers and welcome back! Today's blog post is going to cover a small script that I developed called "buatapa". This was meant to be released several months ago, but steady case work has kept me busy. I finally carved out some development time to finish up this blog post and push it out publicly at long last!
According to the magic of Google Translate, "bua tapa" is the Irish Gaelic translation of the phrase "quick win".
|The phrase "quick win" translated to Irish Gaelic, thanks to Google Translate!|
I decided to call my (GASP!) first publicly released Python script "buatapa" for a couple of reasons, with the main reasons being that it is very heavily based off of Brian Baskin's noriben personal malware sandbox, so I wanted to have a cool name for it as well. The results of this script have the potential to indeed give you a "quick win" with trying to find malware on a Windows system.
What buatapa does
The purpose of this script is to collect the data and then run the script against the collected data from a second machine (rather than performing the VirusTotal queries from the suspected compromised system itself) in case there is no network connectivity on the suspected compromised system (like a secured environment, POS environment, etc.) It simply works by parsing the results of autoruns.csv that is generated by Sysinternals autoruns on a Windows system. The script finds Unicode characters, anything that resembles a poweliks Registry entry, and anything that does not have a signed certificate. It then attempts to perform a VirusTotal hash lookup for any files with abnormal characters and unsigned entries and returns the results in an easy to read text file.
How to set up buatapa
The first thing that is required to get the fullest functionality is to get a VirusTotal API. You can get your public API by heading over to VirusTotal and signing up for an account, if you do not already have one.
Once you have your account, login to VirusTotal and choose the option under your username of "My API key"
|"My API key" option on VirusTotal|
When you choose that option, you will be presented with a page like this, which contains your API key.
|Page with your API key, settings, and rate limits|
Note that the public API has rate limit queries, which are built into the script automatically (rather than running four in a minute and then waiting for 60 seconds; I chose to do one query every 15 seconds. You can of course modify the script to change the sleep time and query rate if you would like).
Highlight your API key and input it into the script. (It is the exact same code as Noriben, so if you are familiar with that, you should be familiar with this.)
|Copy the API key to here (or here) in the script (buatapa and/or noriben)|
It is very important to also install the "requests" Python library to your Python distribution if you have not already. I once again defer to Brian Baskin's Python experience (which admittedly dwarfs my own) as he stated:
"Without Requests it cannot do VirusTotal queries. That's the only internet-based functionality. So you have to install requests ("pip install requests")...Requests is the HTTP library that I use. The built-in Python libs are horrible."
So, make sure that you type in run the command 'pip install requests' from a command prompt before you run buatapa or noriben, in order to get the internet functionality that is needed to run the scripts!!
|Type in 'pip install requests' from a command prompt to install Requests|
You will have to have Python either natively installed on your system or be running something like Active State Python in order to run buatapa. In order to run buatapa, simply open a command prompt and give the path of where the buatapa script resides. The script will automatically create the output text file in the directory the script was run from, so make sure you have read/write permissions to that directory. For example, don't run it from C:\Windows\System32 unless you open the command prompt with Administrative privileges. You must give the script the "-c" argument to open the autoruns.csv file.
|The results from running buatapa (NOTE: The script is name "personal_buatapa.py" because it has my API key in it)|
You do not have to use the Live Response Collection to create the autoruns.csv file (although I did include the output in the latest update, to make life easier for you if you do), however you do indeed have to have the output of autoruns saved as a csv for buatapa to process the file. The text output of autoruns, while easier for human reading, is more difficult to parse and correlate than the csv version.
Results from buatapa
The results are saved as a text file, named "$DATE_$TIME_buatapa_output.txt" (for example 20150825_181703_buatapa_output.txt), with all of the information that autoruns collects about the suspected entry presented in an easy to read text format. If a VirusTotal hit is found, the scan date, detection ration, and VirusTotal report URL will be presented at the very top of the entry.
|Screenshot of a snippet of the buatapa output|
buatapa (by default) only looks at unsigned entries, but it also attempts to identify abnormal Unicode characters (anything that is not Windows CP-1252) as well as trying to look for entries that are similar to poweliks. You can change the defaults by giving the script different arguments, which can be seen the -h or --help flag.
buatapa is by no means meant to replace in-depth analysis; it is meant to provide a faster and easier way to identify potentially compromised systems. buatapa will likely not be able to identify incredibly well-hidden rootkits, digitally-signed malware or never seen before malware, as it is not meant to do that. It is meant to rapidly provide an easy to read list of files that have been identified by VirusTotal as likely being malware that is set to automatically run in an area recognized by autoruns. It will provide you a "quick-win" in identifying the "low hanging fruit" malware.
As I have said many times in the past (and will continue to say many times in the future) the malware will only be as sophisticated as it needs to be in order to gain access to the data your adversaries are after. If a piece of malware originally written four years ago can steal every credit card transaction in your environment, the adversary will use it. They will not use their "next generation Cloud 2.0 automatic exfiltration memory-only kernel-level rootkit" malware in the event that it might actually get discovered in an environment where very basic malware would suffice. Remember the third party vendor used by Goodwill to process payments last year? The malware that was allegedly used in that compromise displayed every single transaction in a command prompt window and had no method of persistence. If the window had simply been closed by ANY individual, even by accident, or if the system was rebooted, the compromise would have stopped. Hardly "advanced" or "sophisticated", but the malware allegedly ran for 18 months and resulted in 868,000 compromised credit cards.
buatapa_0_0_6.zip - download here
Updated: November 11, 2015
If you encounter any bugs or any have suggestions or feedback on the tool, please do not hesitate to let me know!
Thursday, August 20, 2015
Hello again readers! I am happy to announce, after many long months in development (and due to a pretty busy six months, about six months later than I had originally planned) an updated version of the Live Response Collection is available!
The first item that you will probably note is the Windows folder looks very different. I wanted to provide a cleaner look for users, so when you run the LRC against a system it is easier to find the output folder. By having four main folders, instead of about 35, the results will be much easier to see. I moved all of the "tools" into the folder cleverly named "Tools", and all of the scripts into the similarly cleverly named folder "Scripts". While this does not change the function of the tools, it does slightly change file paths leveraged by the old scripts, so you will have to update any custom changes that you made for your environment.
|New Windows folder structure|
Within the "Scripts" folder I also began the process of what I am calling "Modules", which I started for several reasons. Since all six scripts share a lot of code and functionality, I wanted to reduce the overall size of each file by leveraging code that they share. It makes the maintenance and updates for the LRC easier. It also allows easier user customization, because instead of trying to figure out which large section of code they want to use (or not to use) you can just choose to skip a module completely if you don't want it by replacing the name within the code itself. I plan on writing a future post in the future detailing just how easy it is to write a customized module, complete with a breakout of the variables that the script(s) rely on, so users can add functionality and features easier than ever (<hint hint> and hopefully you share them for inclusion into a future LRC release!)
|The beginnings of LRC "modules". There will be more!|
As I stated, the overall functions of the LRC did not change terribly much, some Startup folder hashing was added as well as also saving autoruns output to csv, which will be touched on in my next blog post. The next post will also be the public release of a tool that is also several months in the making, but also several months later than I had originally anticipated to release it.
LiveResponseCollection-Allosaurus.zip - download here
Updated: January 12, 2016