Helpful Navigation Toolbar

Wednesday, August 26, 2015

Publicly announcing buatapa!!

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

Running buatapa

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 "" 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 usage

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. - download here 

MD5: 8c2f9dc33094b3c5635bd0d61dbeb979
SHA-256: c1f67387484d7187a8c40171d0c819d4c520cb8c4f7173fc1bba304400846162
Version 0.0.7
Updated: January 30, 2018

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 long last, updates to the Live Response Collection!!

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. - download here 

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