Basic analysis performed on a sample from the Black Basta Malware group
Executive Summary
mary of each sample is presented in the table in the following section.
Many organizations are under current attack by the black basta group. per 🏴☠️ Groups profiles (ransomware.live) that number could be well over 460 organizations at the time of this writing. The groups typical targeted industries are usually financial organizations, healthcare, and education.
Below I have broken down a sample obtained from Malwarebazare. https://bazaar[.]abuse.ch/download/723d1cf3d74fb3ce95a77ed9dff257a78c8af8e67a82963230dd073781074224/
**High-Level Sample Summary
**
Sample Name: 723d1cf3d74fb3ce95a77ed9dff257a78c8af8e67a82963230dd073781074224.exe / Minipath.exe
SHA 256: 723d1cf3d74fb3ce95a77ed9dff257a78c8af8e67a82963230dd073781074224
Malware type:Ransomware
The Attack path for this sample of the Black Basta ransomware is relatively simple a user needs to unzip and open the .exe file. Or for a bad actor to open it on a users computer with stolen credentials. There are no mechanisms within the sample to spread or propagate this malware further once in a network, this likely means that . Meaning that it will rely on other means of distributing this sample widely within an organization.
Once opened the sample will utilize various .DLL and access to begin encrypting all files on the machine. It will take additional precautions utilizing the VSSadmin account to also delete any of Window’s Shadow Copies. This gives an important element for detection criteria and alerting organizations can easily utilize.
**Basic Facts:
**
After initial Unzip of the file the name is kept in its hash form from Malwarebazare 723d1cf3d74fb3ce95a77ed9dff257a78c8af8e67a82963230dd073781074224.exe
Basic Static Analysis:
Basic static analysis with strings gave us some information as seen below but it is usually a challenge to find and understand the inner workings without more analysis.
From the Floss Strings output we can start to see some interesting pieces of the file and what they are doing interesting pieces include various libraries and different things that may be taking place in the code. But more analysis will be required before we draw any hard conclusion (Floss output should be included).
We can utilize a few other static tools such as PEdetective which may give us what language the malware is likely written in
Utilize PEStudio we can start seeing some of the calls this software is making to libraries.
From PE studio we can start seeing some of the potential abilities of this malware it is making calls to multiple
We can also see some of the potentially malicious imports
Basic Static Analysis Summary: We have some pretty good ideas of what this malware is going to do from some of the imports it is requesting as well as some of the functions we have examined so far but the next step is to start letting it run and see what happens.
Advanced Static Analysis
For advanced Static Analysis I utilized the tools Cutter and Cappa. Using Cappa very verbose mode is a great way to find spots to investigate in the assembly of cutter.
We can see some of the basic facts about the sample from cutter such as hashes and any available info.
I feel like putting a disclaimer here as im not a master of assembly but I do think it is pretty great that using Capa’s very verbose mode on the malware you can get an output of where various mechanisms are in the assembly and get an idea of how they work.
Overview from Cutter
By following the @ location within Capa we can go into cutter and find each of the potentially dangerous strings and unravel each mechanism. If we need we can even break down the assembly language to understand how it is functioning and what it is doing. In this example we can see there is a delay function being called.
Shows the Delay execution
Geolocation information
Seeing the create directory function
Setting file attributes.
**Basic Dynamic Analysis ** To begin the dynamic Analysis I started it in the most simple way I could think of by opening the malware and seeing what happens. I will note that uppon the initial opening it did take a minute or two to notice the impact. But once made my files were encrypted, and a ransom note was placed
It is important to note that the ransom note does not change no matter how many times you detonate the .tor link remains the same as well as the login ID.
For this initial detonation I did not have any network simulation running. I only had my FlareVM running and was prepared to analyze the basic output. This also gives us an IOC with the address : https:[]//bastad5huzwkepdixedg2gekg7jk22ato24zyllp6lnjx7wdtyctgvyd[.]onion/ (Fascinatingly this address is only listed as 1 suspicious and one confirmed malicious on virustotal VirusTotal - URL)
Next I reset the VM and initiated inetsim to replicate a DNS server that way I would pick up any suspicious traffic. I utilized wireshark to see traffic but did not see anything of value. Double checking with Virus Total’s report there was some benign traffic such as grabbing certs. I do not believe this traffic is malicious nor was it mentioned as malicious in the Virus total summary either. VirusTotal - File - 723d1cf3d74fb3ce95a77ed9dff257a78c8af8e67a82963230dd073781074224 (This will become important as we unpack some of the other capabilities of the malware and files as it does raise some questions).
Another piece of analysis I enjoy performing just to get an idea of how big the malware is/how many changes the malware has made is a regshot before and after execution.
Regshot Pre Detonation
RegShot Post Detonation
Checking Reg shot we can see that 19 registry keys were added, and approximately 291 values were changed.
Next we roll back the Virtual machine for another piece of Dynamic analysis. the goal of this one is to check and see what processes this malware starts with Procmon.
We start with setting up the Filter with the file name
We can also utilize the network feature to see how much network activity is being made after execution and we see very little if any
This does not align with some other analysis from Virus total but those all being legitimate traffic it could indicate false positives. Or it could require the malware to run to completion to the very end.
Leveraging process monitor and process explorer helps us visualize the results in a more meaningful way. We can see from the file tree in process explorer that after the malware detonated it spawned a child process windows Command prompt which spawned another child process cohost.exe console window which then spawned another child Vssadmin.
We can also see that from some of the results from process monitor results that the malware begins changing registry settings, opening and reading files and encrypting them. It starts making its way through more and more critical files.
Utilizing tools like Dir watch we can also see more clearly what services the malware is calling
Final Summary:
Given the findings of this analysis I think it is fair to say that the Black Basta malware is likely a second stage payload relying on other malware to pave the way and get the environment ready this can be further confirmed from the Sentinel one Report (https://www.sentinelone.com/anthology/black-basta/). This would be confirmed as there is no mechanism of propagating itself once infected and would require either a C2 or user to open the file. There are also many attributes in the malware that make it recognizable and would be a wise idea for organizations to check any detection rules around the use of VSSadmin or any alerting around the attempted use of it this is also an excellent resource for learning more about it https://akshayj0111.medium.com/how-to-secure-yourself-from-malware-misusing-vssadmin-exe-fe9bb2a807cd