INTRODUCTION
Recently, Quadrant Security was able to aid a client during a targeted organization-wide compromise executed by the Black Basta ransomware group. The following is an illustration of the techniques and timeline as the attack progressed from delivery and detonation, to detection and response. Our intention is to better educate the security community regarding these types of events. Below are other resources related to this specific event.
RELATED TO THIS STORY
- TECHNICAL ANALYSIS: BLACK BASTA MALWARE OVERVIEW
- EXPERT INSIGHTS: BLACK BASTA BACKEND OPERATIONS
- PODCAST: BREAKING BADNESS – QUADRANT SECURITY | BLACK BASTA SPECIAL REPORT
THE PLAYERS
-
QUADRANT SECURITY. Managed Detection and Response provider offering 24/7/365 threat detection and response, curated by dedicated Security Analysts.
-
OUR CLIENT. A large, regional energy outfit based in the southeastern United States.
-
THE THREAT ACTORS. Black Basta, a Ransomware-as-a-Service organization known to target infrastructure companies. Detections of Black Basta in the wild remain relatively low, often credited to the recency of the group’s rise, though their successful and documented attacks are high-impact to the victim organizations.
DISCLAIMER
The names of all clients, accounts, and some files have been modified for client confidentiality. Indicators of compromise, including malicious domain names, have not been modified. Although some details of the threat actor’s actions are still unknown, the evidence gathered has allowed for inferences that paint a nearly definitive picture.
THE ATTACK
As is often the case with successful network intrusion, the compromise began with a rather basic phishing attack – with one wrinkle – the target was a third-party vendor (TPV).
Although little is known to Quadrant about the compromise of the TPV, the access allowed for use of an "info@" account, allowing the Threat Actor to pose as the compromised user without creating extra "junk" in the inbox that would raise suspicion. Following initial phishing emails, the Threat Actor continued to submit additional phishing emails to the client via similar account names from different domains. Both of these samples reached their victims shortly after noon on the first day.
The phishing emails contained what was later determined to be "Qakbot," a sophisticated and familiar trojan. Following the infection, these hosts began to beacon out to 100+ IP's using various ports, eventually finding an active C2 server. It took roughly half an hour between initial infection and the first successful communication between a compromised host and the C2 domain.
The second-stage payload, which was later determined to likely be the pen-testing framework "Brute Ratel," was then downloaded via a connection to an IP from Russia.
ATTACK ESCALATION
Following the initial compromise and gaining foothold, our Threat Actor began lateral movement through the client's infrastructure, consisting of three domains: Construction, Commerce, and a Subsidiary. Both of the initial compromised hosts were in the Construction environment. These domains had shared trust and were connected via VPN tunnels which allowed the threat actor to move freely between both.
Initial lateral movement and lay-of-the-land was likely conducted through the use of Brute Ratel. This was determined through a review of files found on one of the initially compromised hosts, matching the hash of previously submitted Brute Ratel samples. The IP’s used for C2 and the level of interaction changed over time as the compromise grew.
Multiple administrative and system accounts were compromised during this escalation. One possible explanation comes from Kerberoasting, a technique observed in the Commerce environment through a sharp increase in Kerberos requests using RC4 encryption. We do not believe that this was successful in this environment, due in part to the lack of additional signs of compromise specific to this Domain.
However, this technique was likely performed on the other two client domains where visibility gaps existed. This is further supported by the fact that the source and destination of these requests were cross-domain. The source of the Kerberoasting was based in the Subsidiary environment and the Domain Controller that was attacked was located in the Commerce environment.
Once administrative access had been achieved, the threat actor also added new administrative accounts to the environment.
PROPAGATION AND EXFILTRATION
Unknown to everyone but the Threat Actor, multiple files were now being transmitted throughout the environment, including EXE and BAT files seemingly designed to turn off antivirus and anti-malware software.
These files continued to replicate throughout the organization through the use of SMB, eventually spreading to almost every endpoint and server in two of the three domains; Construction and Subsidiary. The majority of hosts in the Commerce environment have more restrictions placed on their operating system by default, likely contributing to the lack of success by the Threat Actors in that environment.
Once a file server was identified, an FTP connection was established to an external site for receiving the exfiltrated data. Our Suricata logs show that RClone was downloaded on the file servers in order to facilitate exfiltration of the logs. RClone is designed to transfer large volumes of data from one host to the cloud with ease. This legitimate program was abused by the attacker to steal client data.
THE RESPONSE
The most critical asset in our Security Operations Center is the human SOC Analyst. A human can look at the totality of a situation and make a judgement call that no AI, software, or automated process can.
From the Analyst's perspective, the only alert that was generated and brought to the SOC was a Suricata FTP rule looking for CVE 1999-0911, related to an overflow using the MKD command. This FTP command is defined as:
"...causes the directory specified in the pathname to be created on the server. If the specified directory is a relative directory, it is created in the client's current working directory."
Although many old signatures are decommissioned or otherwise suppressed, Quadrant leaves some rules in place as "Hunting" rules. These are more focused on the overall techniques, or "odd" traffic that could be an Indicator of Compromise. In this case, the Analyst investigating the alert observed that this was technically a False Positive, as the command was not used in an abnormal fashion.
However, looking at the destination, which had not been previously observed in the environment, the varied file names, and the volume of the outbound files, the Analyst decided to alert the client and err on the side of caution. Had the Analyst not conducted their due diligence or had this archaic signature been suppressed, it is highly likely that this compromise would not have been detected until after the encryption process had begun.
This alert was submitted just over 30 hours after the initial infection.
Our client confirmed that this activity was out-of-the-ordinary but was unaware of the full extent of the compromise. During the course of the evening, it became apparent that something was greatly amiss with this activity. The following morning, the client’s CISO contacted Quadrant management to report that there was, in fact, an active compromise within their environment.
The client provided malware samples from the phishing emails and the deeper analysis was initiated. Threat hunting was conducted within the logs and a dedicated communication channel between Quadrant and the client was established. As more evidence was uncovered, the full threat began to be realized.
“LOOKING FOR ANYTHING SUSPICIOUS”
One of the first actions taken by the Incident Response (IR) team was a live Log review. The term "look for anything suspicious" is often a nightmare of a request, eye-roll-worthy, even – how does one truly define “suspicious” without a baseline?
Armed with considerable knowledge of the situation and years of experience,, a member of the IR team decided to review the raw logs in real-time to see if anything stood out. A majority of logging of the clipboard is conducted through the use of the NXLogging agent on Windows devices. This is not always stored on the local host in the form of a log, but is always immediately submitted to the Sagan Log Analysis Engine for analysis and retention. Because of this review, Quadrant became aware of the use of RDP by the Threat Actor through the observation of RDPClip.exe logging that looked, by definition, suspicious.
Among the many clipboard logs observed, "client.exe -bomb," stood out. Although the full extent of the command was not realized at the time, the implied malice of such a line was enough to attempt a purge of the Threat Actor. The Client’s response team locked out the accounts that were known to be compromised, while remaining unaware of the extent of control the Threat Actor had over the environment.
Following the initial lock-out attempt, the Threat Actor retaliated, scorched-earth-style, resulting in catastrophic lockout of the client's staff and admins.
All significant accounts were locked out and the total loss of their environment seemed imminent. After a quick conference between Quadrant and the client, all parties agreed to an aggressive response: only 56 hours after the initial phishing email had been opened, the physical cables between the domains, as well as their connection to the Internet, were severed.
Because of the observation, hunting, and cooperative teamwork between the Quadrant team and the client, only a handful of ESXi servers were encrypted. Had the team not taken action to sever the internet and domain connections, the encryption command would likely have replicated throughout the Construction and Subsidiary environments.
With the assistance of a third-party Incident Response firm and constant on-going contact with the Quadrant team, the client was able to slowly, systematically, and safely bring their servers on-line while purging any remains of the Threat Actor over the subsequent days.
While many lessons were learned, this event was considered a striking success in defense of the client. Through the later review of the logging and after-action analysis of the event, additional detection rules have been created to better alert on what visibility does exist in this, and many other, client environments.
For more information regarding this story, interested parties should contact [email protected]
EXPLORE THIS STORY FURTHER
