Ransomware operators use SystemBC RAT as off-the-shelf Tor backdoor

In our investigations into a number of recent ransomware attacks, we’ve observed sets of tools associated with multiple types of ransomware deployed in much the same way, suggesting their use by one or more ransomware-as-a-service affiliates.  One of those tools is SystemBC, a backdoor that provides attackers with a persistent connection to their victims’ systems.

First seen in 2019, SystemBC is a proxy and remote administrative tool, named by researchers after the string in the URI its control panel used.  It acts both as a network proxy for  concealed communications and as a remote administration tool (RAT)—capable of executing Windows commands, and delivering and executing scripts, malicious executables and dynamic link libraries (DLLs).  After being dropped by other malware, it provides attackers with a persistent backdoor.

While SystemBC has been around for over a year, we’ve seen both its use and its features continue to evolve. The most recent samples of SystemBC carry code that, instead of acting essentially as a virtual private network via a SOCKS5 proxy, uses the Tor anonymizing network to encrypt and conceal the destination of command and control traffic.

Over the past few months, we have continued to detect hundreds of attempted SystemBC deployments worldwide. SystemBC was used in recent Ryuk and Egregor attacks investigated by Sophos MTR’s Rapid Response team, often used in combination with post-exploitation tools such as Cobalt Strike. In some cases, the SystemBC RAT was deployed to servers after the attackers have gained administrative credentials and moved deep into the targeted network.


When dropped and executed, SystemBC performs a check to see whether it was launched with a command line “start”—indicating it was executed as a scheduled service.  SystemBC then  looks for a running process called a2guard.exe—Emsisoft’s anti-malware software. If it finds, it terminates itself. This behavior dates back to the earliest versions of the malware detected in May of 2019.  If not, it copies itself to a randomly-named directory and file name within the ProgramData directory, and then schedules that copy as a task (launched with the “start” command)  to achieve persistence.

Decompiled code from SystemBC showing the installation logic.

Once SystemBC is launched from its scheduled task, it starts its command and control connections.

BC phone home

There are two elements of the CnC: a beacon connection to a remote server at one of two domains hard-coded into the the malware, and a lightweight Tor client.

The non-Tor communications are raw TCP, connecting to port 4044 (typically used by the Location Tracking Protocol) on the remote server. The domains varied from sample to sample—likely configured for a specific campaign at build-time. We observed two domains in use in our primary sample: advertrex20[.]xyz and gentexman37[.]xyz. The first domain no longer resolved at the time of analysis; during analysis, the second domain also became unreachable.

The malware selects one of the hardcoded domains, and sends an initial block of data (100 bytes in this instance), then maintains an open socket, with the connection occasionally being reset.

Part of a packet capture of SystemBC’s initial CnC communications
The packet block sending the initial data from SystemBC to the command and control domain.

Most of the CnC communications with the SystemBC RAT are over a Tor connection. The Tor communications element of SystemBC appears to be based on mini-Tor, an open-source library for lightweight Tor connectivity to .onion hidden services. The code of mini-Tor isn’t duplicated in SystemBC (since mini-Tor is written in C++ and SystemBC is compiled from C). But the bot’s implementation of the Tor client closely resembles the implementation used in the open-source program, including its extensive use of the Windows Crypto Next Gen (CNG) API’s Base Crypto (BCrypt) functions.

Some of the Tor client code from the SystemBC executable dumped from memory and disassembled. The IP addresses shown are known Tor gateway hosts, including dannenberg[.]torauth[.]de and tor[.]noreply[.]org

When the bot is executed from scheduled task, it  collects the following information and store it in a buffer and sends it to CnC through the Tor connection:

  • The active Windows user name
  • The Windows build number for the infected system
  • A WOW process check (whether the OS on the infected system is 32-bit or 64-bit)
  • The volume serial number.

The collected data is rc4 encrypted with a hard-coded key before it is sent it to CnC, using a socket connection handled by the malware’s mini-tor library and socket APIs.

A snippet of decompiled code from SystemBC showing data sent about the targeted system back to the Tor CnC.

Remote control

The operators of the bot can use the CnC server to send a number of payloads back to the infected system for execution. SystemBC can parse and execute EXE or DLL data blobs passed over the Tor connection, shell code, VBS scripts, Windows commands and batch scripts, and PowerShell scripts.

A chunk of the decompiled code from SystemBC showing types of data it expects from the CnC.

For VBS, BAT and CMD commands, the bot creates a randomly named file in the  %TEMP% directory and create a scheduled task for the script. For Powershell commands, it creates a scheduled task for the script and adds the following command line to make it hidden:

'-WindowStyle Hidden -ep bypass -file "'

If the data received is not parsed as a script, it checks for an MZ header in the data to check if it is a Windows executable. If it is, SystemBC loads it directly for execution without writing a file. If the data received from the CnC doesn’t have any MZ signature, the bot assumes it is shellcode and spawns a thread to execute it. And If it is determined to be DLL binary data, SystemBC will load the dll using execute_pe_from_mem_thread and call its export function using call_dll_export_function_thread.

From spray and pray to sniping

Collectively, these capabilities give attackers a point-and-shoot capability to perform discovery, exfiltration and lateral movement with packaged scripts and executables—without having to have hands on keyboard.  These capabilities were originally intended for mass exploitation, but they have now been folded into the toolkit for targeted attacks—including ransomware.

In a September Ryuk attack, SystemBC was deployed on the target network’s domain controller—apparently deployed by CobaltStrike. And in November, we saw SystemBC in association with an Egregor attack—again associated with Cobalt Strike (though it is not clear which dropped which).

In these cases, SystemBC was deployed as one of several commodity tools to establish persistence across the targeted network. In the Ryuk attacks we saw with SystemBC, initial compromise came from phishing messages that delivered the Buer Loader malware; other attacks in the same campaign used Bazar or Zloader. The Egregor attacks we saw used another loader dropped by malicious emails—Qbot.

All of these attacks appear to have been launched by affiliates of the ransomware operators, or by the ransomware gangs themselves through multiple malware-as-a-service providers. They involved days or weeks of time on the targets’ networks and data exfiltration. SystemBC is an attractive tool in these types of operations because it allows for multiple targets to be worked at the same time with automated tasks, allowing for hands-off deployment of ransomware using Windows built-in tools if the attackers gain the proper credentials.

Fortunately, SystemBC is detected by many anti-malware tools, including Sophos (via both signature and machine learning). Attackers continue to use SystemBC situationally with success because they leverage inconsistent malware protection across organizations or leverage legitimate credentials to disable some malware protection.

A list of IOCs for SystemBC is posted on SophosLabs’ GitHub page.

Sophos would like to acknowledge the contributions of Anand Aijan and Syraj Mundalik of SophosLabs, and of Peter Mackenzie,Elida Leite, Syed Shahram and Bill Kearney of the Sophos MTR Rapid Response team to this report.

Latest Posts