8Base Ransomware Investigation Uncovers Surprising Insights

Almost every engagement of the Eye Security Incident Response team provides new learnings. We share these to inform cyber security and IT professionals. After all, acquiring knowledge of a threat actor’s tactics, techniques and procedures (TTPs) can be of help to fellow incident responders. Once you have successfully attributed an attack, knowing the threat actor’s modus operandi provides you with a significant advantage.     

During a recent incident that we attributed to the 8Base ransomware group, we observed several new and interesting TTPs which we have shared below. 

Background to the Ransomware Investigation 

We were contacted by an organisation as soon as they learned they had suffered a successful ransomware attack. For this blog, we will refer to this organisation as “the target”. We partnered with their leadership and IT team to quickly investigate and remediate the incident, and we provided a successful outcome, rapidly restoring their infrastructure without the expense of paying the ransom.  

To maintain customer confidentiality and anonymity, we cannot go into a certain level of detail. But this does not preclude us from sharing the information below to provide interesting insights.  

Attack Discovery  

The target discovered a ransomware note left on one of their impacted hosts. This immediately led to our first surprising discovery—the ransomware note linked to an unused and offline .onion site. This is likely because an outdated version of an encryptor was used. The upshot is that, even if the target had wished to pay the ransom, they had no mechanism for getting in touch with the threat actor.  

This appeared to be a mistake, which led us to suspect that, regardless of the threat actor claiming to be the 8Base ransomware group, maybe they were not responsible. However, we kept an open mind as maintaining an understanding of your adversary and their TTPs provides a significant advantage during incident response. Later, once the 8Base group leak site was updated to include information stolen from the target, we confirmed we were dealing with 8Base. 

During the investigation, we discovered that the attack was timed to take place over the weekend when the target would likely be most vulnerable. The timeline and actions are discussed below.           

Attack Day 1 

1. Initial access was traced to the target’s SSL VPN. The threat actor used a service account with a high level of privileges. We didn’t observe any unsuccessful login attempts. So the credentials were already in the threat actor’s possession. As this was a service account, they could not have been compromised during an earlier phishing attack. We suspect they had been obtained from an initial access broker. Log searches didn’t uncover any further related information, so we assume they had been compromised some time ago.  
   
2. The threat actor moved laterally to another host in the network immediately after establishing the SSL VPN connection. This was detected by that host’s Endpoint Detection and Response (EDR).  However, the resulting alert went unnoticed. The threat actor proceeded to dump the registry hives and continued their discovery process. After a few hours, activity on the VPN ceased. 

Attack Day 2 

1. The threat actor returned during the early part of the night. Firewall logs show that the entire /24 subnet was scanned for sixteen distinct TCP ports (TCP ports: 22, 80, 135, 139, 443, 445, 1556, 3389, 4119, 4343, 5800, 5900, 8000, 8080, 9392, 9443, UDP ports: 137, 161, 5353). At least one of these ports is used by backup solutions such as Veeam (i.e. tcp/9392). As expected, the threat actors were actively seeking out and sabotaging backups, which is standard preparation for a ransomware attack. 
2. The threat actor then gained access to the domain controller. It is unclear how they obtained the credentials. We suspect it may be from the registry hive dump on day 1 as there had been no alerts related to credential misuse, such as a LSASS dump, on any of the hosts in the attack path. If they were already in possession of them prior to the attack commencing, they would likely have used them for initial access. 8Base is not known for subtle approaches, preferring speed over stealth. Using these credentials initially would certainly have speeded up their progress.  
3. Progress was speeded up further by a second threat actor going “hands-on”. We detected a second IP address on the SSL VPN and now we knew there were two threat actors involved, both using Windows virtual machines (VM).  
4. Next, the threat actors were observed accessing fileshares. They continued all their activities via the SSL VPN and at this stage, made no attempts to deploy malware to compromise an on-site host or pivot to a bastion host for stealth. They likely realised they were free to use the SSL VPN so why over-complicate the attack.  
5. The threat actors then made several “mistakes” when connecting to the targets’ Windows hosts over RDP. We observed a new Windows host name accessing the VPN that we can now associate with the group for future reference. They then attempted to login to the targets’ hosts as UserName and kali. These are the default logins that the tools they were using use to access the target hosts. Not replacing these with the correct, compromised credentials demonstrates their somewhat aggressive approach and preference for speed.

Attack Day 3 

1. The threat actors returned one final time in the middle of the night/early the following morning, still using the SSL VPN as a point of access into the target’s network. In this final phase, they compromised a Windows host and downloaded their tools to it. We discovered Netscan, their encryptor (named Fast.exe), and Anydesk, a remote monitoring and management (RMM) tool. This is another move that generated EDR alerts. If monitored, these would have resulted in the threat actors being discovered. By this time, they had likely become fairly confident their activities were not being monitored.  So they pushed on, generating significant numbers of alerts from the target’s EDR.
2. Next, the threat actors initiated an FTP session, directly over the internet, from a compromised host to their Windows VM. They used this to exfiltrate tens of gigabytes of data. This was all monitored and logged by the target’s firewall—another sign of an in-progress attack. 
3. The final act was to encrypt the target’s data across their VMWare estate. Surprisingly, rather than using an encryptor that runs directly on an ESXi hypervisor, the threat actors mounted the disks on a compromised Windows VM in the target's network and encrypted them from there. This is a new TTP and one that we have not seen across OSINT sources that we use. This would have taken longer than using an encryptor installed directly on the hypervisor. But as we have seen, these threat actors were now confident of success. Even if they were detected and failed to encrypt all the target’s data, they could extort them, as they could threaten to leak the data already exfiltrated. 

The Recovery Stage

After running the encryptor, the VMWare ESXi machines were left in an unbootable state. Several of them were rendered unusable and had to be reinstalled.  

When we discovered an  ESXi with the ransomware binary still running in a guest virtual machine, an Eye Security incident responder visited the target’s offices to investigate it in person. We observed new files on the disk of the ESXi being encrypted as soon as they were created. We collected logs and forensic artefacts in an attempt to recover the encryption keys in use. Then we decided to completely reinstall the ESXi machines. (See 8Base Ransomware – Key and File Recovery for more information).  

Part of 8base's modus operandi is to actively seek out and destroy local backups. Fortunately, the target had immutable backups off-site, from which the entire infrastructure could be recovered.  

Each restored system was brought online in a network-restricted environment, allowing our incident responders to deploy our preferred EDR agent. This enabled us to immediately check the restored systems for signs of suspicious behaviours, such as backdoors, and continue to monitor them and collect digital forensic evidence.  

This is a standard element of Eye Security’s incident response service. We automatically enroll customers’ endpoints onto our MDR service for one month. This approach allows for fast yet safe restoration of the environment. Threats are caught and neutralised early, greatly reducing the time it takes for customers to resume normal operations.  

Eye Security’s unique incident recovery approach enabled us to fully recover the customer’s environment in 12 days, with minimal impact on business operations. During the process, any risks were fully mitigated by Eye Security’s managed detection and response service.

Conclusion  

8base is currently one of the most prolific ransomware groups, and as you can see, their methods are sometimes blunt. This results in more damage than just encrypted files, as evidenced by the destroyed ESXi hosts. One might assume that if victims understand the extent of their recovery task even after paying for the keys to decrypt their data, they might think twice about doing so.    

There was one final piece of this story yet to unfold. Eye Security and the target’s teams didn’t contact 8Base throughout this process. Even if the target’s preference had been to pay the ransom, they couldn’t because the .onion site link on the ransomware note was unavailable. The target received a number for emails and then a phone call related to the attack. The caller claimed to be acting on behalf of 8Base and wanted to negotiate the ransom. But  they were far too late, even if the target had been interested.     

All things considered, this ransomware case was neither sophisticated nor cutting-edge. 8base had no issues in accessing and exploiting the target's network and was not countered at any point, even though the EDR solution that was already in place generated actionable alerts. If human intervention had taken place after one of those early warnings, the threat actor would have had a much harder time, and the entire incident would likely have been prevented.  

How to Get Ahead of Threat Actors 

There are a number of stages during this attack where an activity triggered an alert that should have been investigated. However, the timing of the attack played a major part in its success.  

This, however, is not unusual—threat actors realise that many organisations have neither the budget nor resources to monitor their EDR on a 24x7 basis. This is why many organisations turn to MDR providers. The majority would have responded during the first stage of this attack, when lateral movement was detected on the server from which data was exfiltrated.  

It is highly likely that, had the target been an Eye Security MDR customer, the attack would not even have reached this stage. A fundamental part of our onboarding process is to perform a number of scans of a customer’s attack surface to assess their security posture.  

We surface these as human-led insights. And in this case, the excessive privileges used by the service account would have been highlighted. Without these, the attack could have been over before it began.    

Worried about protecting your network against ransomware? Wondering how Eye Security can help? Book a meeting now: