BlackByte combines proven techniques with recently disclosed vulnerabilities to support its ongoing attacks

• The BlackByte ransomware group continues to exploit tactics, techniques and procedures (TTPs) that have formed the basis of its methods since its inception, continually adapting its use of vulnerable drivers to bypass security protections and deploying ransomware capable of spreading autonomously, similar to a worm.
  
• BlackByte uses techniques that depart from its established methods, such as exploiting the vulnerability CVE-2024-37085 – an authentication bypass flaw in VMware ESXi – shortly after its disclosure, and using a victim’s authorized remote access mechanism rather than deploying a commercial remote administration tool like AnyDesk.
  
• A new iteration of the BlackByte encryptor that adds the file extension “blackbytent_h” to encrypted files, drops four vulnerable driver files compared to the three previously observed, and uses the victim’s Active Directory credentials to spread.
  
• The BlackByte group is more active than its data leak site might suggest, where only 20 to 30% of successful attacks result in an extortion post.

BlackByte is a ransomware-as-a-service (RaaS) group believed to be an offshoot of the infamous Conti ransomware group. First observed between mid and late 2021, their modus operandi includes the use of vulnerable drivers to bypass security controls, the deployment of ransomware capable of spreading autonomously with worm-like capabilities, and the use of known system binaries (LoLBins) as well as other legitimate commercial tools in their attack chain.

BlackByte has rewritten its ransomware binary over time, with versions programmed in Go, .NET, C++, or a combination of these languages. The group’s apparent efforts to continually improve its tools, its operations and even its data leak site are well documented.

Initial access

During a recent BlackByte ransomware attack, the threat actor gained initial access by using valid credentials to access the victim organization’s VPN. Telemetry limitations and the loss of evidence after the ransomware encryption event prevented the IR Team from determining whether the credentials had been obtained by brute-forcing the VPN interface or were already known to the adversary before the attack. However, the IR teams have moderate confidence that brute-force authentication facilitated by internet scanning was the initial access vector, based on the following observations:

• The account initially compromised by the adversary had a basic naming convention and, according to the information, a weak password.
• The VPN interface may have allowed a domain account to authenticate without multi-factor authentication (MFA) if the target account had a specific configuration in Active Directory.
• BlackByte has a history of seeking out and exploiting publicly accessible vulnerabilities, such as the ProxyShell vulnerability in Microsoft Exchange Server.

Given BlackByte’s history of exploiting publicly accessible vulnerabilities for initial access, the use of the VPN for remote access may represent a slight change of technique or could be opportunistic. Using the victim’s VPN for remote access also offers the adversary other advantages, including reduced visibility from the organization’s EDR (endpoint detection and response)

Reconnaissance and enumeration

After gaining initial access to the environment, the adversary succeeded in escalating its privileges by compromising two Domain Admin-level accounts. One of these accounts was used to access the organization’s VMware vCenter server and, shortly after, to create Active Directory domain objects for individual VMware ESXi hypervisors, thereby joining them to the domain.

The same account was then used to create and add several other accounts to an Active Directory group called “ESX Admins”. The IR teams estimate that this user group was created to exploit the vulnerability CVE-2024-37085 , an authentication bypass in VMware ESXi known to be used by several ransomware groups. Successful exploitation of this vulnerability grants members of a specific Active Directory group elevated privileges on an ESXi host, allowing control of virtual machines (VMs), modification of the host server configuration, and access to system logs, diagnostic tools and performance monitoring.

The IR teams observed the threat actor exploiting this vulnerability, which initially received limited attention from the cybersecurity community, within days of its publication. This highlights how quickly ransomware groups like BlackByte can adapt their TTPs to incorporate newly disclosed vulnerabilities, as well as the time and effort invested in identifying potential leads to advance an attack

The threat actor accessed other systems, directories and files within each victim environment using protocols such as Server Message Block (SMB) and Remote Desktop Protocol (RDP). Analysis of system event logs and authentication logs revealed a consistent pattern where the threat actor primarily used NT LAN Manager (NTLM) for authentication, while the organization’s users primarily used Kerberos. This early NTLM-related activity could reflect authentication attacks such as “pass the hash” for lateral movement. Dynamic analysis of the ransomware binary subsequently revealed consistent use of NTLM for authentication by this file as well

Talos IR also observed the execution of a file named “atieclxx.exe“ from the directory “C:\temp\sys\“ on one of the file servers. The legitimate version of “atieclxx.exe” is normally found in the directory “C:\Windows\System32“ , where it supports system processes associated with AMD graphics cards. However, during the investigation of a BlackByte attack, “atieclxx.exe” was executed from the directory “C:\temp\sys“ with the command atieclxx.exe P@$$w0rd123!!!. Given that BlackByte actors are known to favor the string “P@$$w0rd“ when setting account passwords and as input parameters for custom tools, this syntax could indicate attempts to disguise malware – such as their custom data exfiltration tool, ExByte – as a known or legitimate file. The IR teams were unable to obtain a copy of the file for analysis.

Finally, the threat actor was observed tampering with security tool configurations via system registry modifications, manually uninstalling the EDR from several key systems, and, during one investigation, changing the root password of the organization’s ESXi hosts. Immediately before the first sign of file encryption, increased volumes of NTLM authentication attempts and SMB connections were observed between dozens of systems in the environment. This activity was later understood to be characteristic of the ransomware’s self-propagation mechanism.

Data exfiltration

The limitations of the available telemetry, the effect of the ransomware’s encryption process and the adversary’s off-network staging location during the IR teams’ investigation prevented a high-confidence assessment of the data exfiltration methods and of whether exfiltration took place. As mentioned in the previous sections, the possible use of BlackByte’s custom data exfiltration tool, ExByte, was observed, but could not be confirmed.

Ransomware execution

Similarities with previous reports

In recent cases, the BlackByte ransomware binary, “host.exe” , was executed from the same directory – “C:\Windows“ – on all victims investigated by the IR teams. The command syntax used by the adversary during each attack – C:\Windows\host.exe -s [8-digit numeric string] svc – and the behavior of the ransomware binary are consistent with previous analyses of the BlackByteNT binary by Microsoft, DuskRise, Acronis and others. The similarities observed include:

• The ransomware binary will not run without the correct eight-digit numeric string passed to the “-s” parameter. This eight-digit numeric string was the only element of the command syntax that varied between victims. During one attack, the adversary used two different encryptors sequentially, each with its own “-s” parameter value, although it is not clear why multiple encryptors were employed

• The “svc” parameter causes the ransomware to be installed as a service, which appeared to turn an infected system into an additional propagator as part of the ransomware’s worm-like propagation behavior. SMB and NTLM authentications were observed against accessible hosts after the ransomware service was created, resulting in several waves of encryption hours after the initial event

• The ransomware binary creates and operates mainly from the “C:\SystemData” directory. Several common files are created in this directory on all BlackByte victims, including a text file called “MsExchangeLog1.log”, which appears to be a process-tracking log in which execution steps are recorded as comma-separated values “q”, “w” and “b”, as shown in the following screenshot.

• After successful execution, the ransomware binary ran the command: 

‘/c ping 1.1.1[.]1 -n 10 > Nul & fsutil file setZeroData offset=0 length=503808 c:\windows\host.exe & Del c:\windows\host.exe /F /Q ‘  , which, after a delay, zeroes out the file’s contents and deletes itself. This general command structure has been observed in various BlackByte tools since 2022.

Novel observations

The IR teams observed some differences in recent BlackByte attacks. Most notably, the encrypted files on all victims were rewritten with the file extension “blackbytent_h” , which has not yet appeared in public reports.

This newer version of the encryptor also drops four vulnerable drivers as part of BlackByte’s usual technique called Bring Your Own Vulnerable Driver (BYOVD).

The four drivers were dropped by the encryptor binary in all BlackByte attacks examined by the IR teams, each with a similar naming convention – eight random alphanumeric characters followed by an underscore and an iterative numeric value. Using “AM35W2PH“ as a fictional example, the vulnerable drivers would appear in the same order as:

• “AM35W2PH” – RtCore64.sys, a driver originally used by MSI Afterburner, a system overclocking utility.
• “AM35W2PH_1” – DBUtil_2_3.sys, a driver that is part of the Dell Client firmware update utility.
•  “AM35W2PH_2” – zamguard64.sys, a driver that is part of the Zemana Anti-Malware (ZAM) application.
• “AM35W2PH_3” – gdrv.sys, a driver that is part of the GIGABYTE Tools software package for GIGABYTE motherboards.

The inclusion of the file “zamguard64.sys” , also known as “Terminator” , is particularly interesting because of recent reports from other security researchers on its prevalence, and also because the ransomware binary created two service-related registry keys associated with this file during execution, then deleted them later in the execution process. Using the same fictional string above, these registry keys would be:   

• HKLM\SYSTEM\CONTROLSET001\SERVICES\AM35W2PH_2
• HKLM\SYSTEM\CONTROLSET001\SERVICES\AM35W2PH_2\SECURITY

During dynamic analysis of several BlackByte ransomware binaries, the IR Teams discovered that the file attempted a network share enumeration via the NetShareEnumAll function of the named pipe ‘SRVSVC‘ using specific user accounts associated with the victim. Given that this analysis was performed in a controlled, sandboxed environment, these accounts could only have appeared in network traffic if they were embedded in the ransomware binary itself. This finding gives the IR teams high confidence that the per-victim customization of BlackByte’s ransomware encryptor includes embedding some form of stolen credentials in the binary to support its worm-like propagation capability.

Other behaviors of interest observed

Other interesting behaviors observed during dynamic analysis of this version of the ransomware binary include:

• Communication with msdl.microsoft[.]com via the IP address 204.79.197[.]219 at the start of the execution process. This site is associated with the Microsoft Public Symbol Server. BlackByte’s tools have long been observed downloading and saving debugging symbols directly from Microsoft.
  
• Disabling antivirus and anti-spyware protections via the registry key HKLM\SOFTWARE\MICROSOFT\WINDOWS DEFENDER and adding the value “*.exe” to the registry key HKLM\SOFTWARE\MICROSOFT\WINDOWS DEFENDER\EXCLUSIONS\EXTENSIONS.
  
• Deleting system binaries from the directory “C:\Windows\System32″, including “taskmgr.exe”, “perfmon.exe”, “shutdown.exe” and “resmon.exe“

Overview of BYOVD use and BlackByte’s victimology

BlackByte’s victimology is consistent with this assessment, with more than 32% of known victims coming from the industrial sector (manufacturing).

These figures are likely conservative, given the difference between the number of victims posted on BlackByte’s data leak site over the past six to nine months and the number of victims identified through telemetry and disclosed in public reports. It is not clear why only a limited subset – estimated at between 20 and 30% – of BlackByte’s victims is ultimately published.

Implications for defenders

BlackByte’s progression through programming languages, moving from C# to Go, then more recently to C/C++ in the latest version of its encryptor – BlackByteNT – reflects a deliberate effort to strengthen the malware’s resilience against detection and analysis. Complex languages like C/C++ allow the incorporation of advanced anti-analysis and anti-debugging techniques, observed in BlackByte’s tools during detailed analyses carried out by other security researchers.

The self-propagating nature of the BlackByte encryptor presents additional challenges for defenders. The use of the BYOVD (Bring Your Own Vulnerable Driver) technique accentuates these difficulties, as it can limit the effectiveness of security controls during containment and eradication efforts. However, given that this current version of the encryptor appears to rely on embedded credentials stolen from the victim’s environment, an enterprise-wide reset of user credentials and Kerberos tickets would be very effective for containment. A review of the SMB traffic emanating from the encryptor during execution will also reveal the specific accounts used to spread the infection across the network.

From a broader perspective on the ransomware modus operandi, the inherent flexibility of the RaaS (Ransomware-as-a-Service) model allows threat actors to quickly counter new defensive strategies developed by cybersecurity experts, by adapting and updating their tools. This creates a perpetual race between cybercriminals and defenders. As BlackByte and other ransomware groups continue to evolve, organizations will need to invest in adaptive and resilient security controls, as well as develop measures capable of keeping pace with a dynamic and diverse threat landscape

Recommendations for defenders

• Implement multi-factor authentication (MFA) for all remote access and cloud connections. Prioritize the “verified push” method as the MFA method over less secure options such as SMS or phone calls.
  
• Audit the VPN configuration. Confirm that outdated VPN policies are removed and that authentication attempts not matching a current VPN policy are rejected by default. Restrict VPN access to only the necessary network segments and services, thus limiting the exposure of critical assets such as domain controllers.
  
• Set up alerts for any change in privileged groups, such as the creation of new user groups or the addition of accounts to domain administrators. Ensure that administrative privileges are granted only when necessary and regularly audited afterwards. A Privileged Access Management (PAM) solution can be used to streamline the control and monitoring of privileged accounts.
  
• Limit or disable the use of NTLM where possible and enforce more secure authentication methods such as Kerberos instead. Limit the rate of authentication attempts and failures on publicly exposed and internal interfaces to prevent automated authentication scans.
  
• Disable SMBv1 and enforce SMB signing and encryption to protect against lateral movement and malware propagation.
  
• Deploy EDR clients on all systems in the environment. Configure an administrator password on EDR clients to prevent unauthorized tampering with or removal of the client.
  
• Disable vendor accounts and remote access capabilities when they are not actively in use.
  
• Create detections for unauthorized configuration changes that could be made on various systems in the environment, including changes to Windows Defender policies, unauthorized modifications to Group Policy Objects, and the creation of unusual scheduled tasks and installed services.
  
• Develop and document the company’s password reset procedures to ensure that all user credentials can be reset quickly and completely. Include procedures for renewing critical Kerberos tickets in this documentation.
  
• Harden and patch ESX hosts to reduce the attack surface of these critical servers as much as possible and ensure that newly discovered vulnerabilities are patched as quickly as possible.

MITRE ATT&CK mapping of the new TTPs

IOCs

NOTE: Some IOCs have been withheld to avoid potential identification of victims.

RtCore64.sys – 01aa278b07b58dc46c84bd0b1b5c8e9ee4e62ea0bf7a695862444af32e87f1fd
DBUtil_2_3.sys – 0296e2ce999e67c76352613a718e11516fe1b0efc3ffdb8918fc999dd76a73a5
zamguard64.sys – 543991ca8d1c65113dff039b85ae3f9a87f503daec30f46929fd454bc57e5a91
gdrv.sys – 31f4cfb4c71da44120752721103a16512444c13c2ac2d857a7e6f13cb679b427