In the past 24 months, many threat actors have begun to pivot from the saturation of Windows endpoints to a more focused targeting of Linux-based enterprise infrastructure. A recent example of this is the malware family SystemBC, which was originally discovered in 2019 as a Windows proxy bot. Recently, a new Linux variant of SystemBC has been discovered.

How It Works

SystemBC functions primarily as a SOCKS5 proxy, converting infected machines into relay nodes that allow attackers to tunnel malicious traffic into and out of compromised networks. The primary suspected users of this functionality are RaaS groups such as Akira, BlackBasta, and Qilin.

The ELF variant of SystemBC is a direct port of the original C/C++ codebase found in Windows samples, and recompiled for the Linux environment. This enables attackers to infect a wide range of architectures, including x86, x64, and potentially ARM-based IOT devices. The malware generally takes the following path:

1. In most campaigns, the infection starts with a compromise of a Linux server either through vulnerabilities or weak credentials. Once access is established, the SystemBC payload is delivered.
   • In many cases, the malware is not dropped directly but is instead retrieved by an intermediate shell script.
   • To evade detection, the ELF binary is frequently renamed to mimic legitimate system processes such as monitor, sysdr, rsyslogd, or kworker.
2. Upon execution, the ELF binary initializes by decrypting its embedded configuration block containing C2 domains and communication parameters.
   • The configuration data is obfuscated using a hardcoded 40-byte XOR key.
   • Once the C2 address has been resolved, an initial “beacon” packet is sent to register the victim machine within the botnet. This packet comprises of the 40-byte XOR key, followed by 10 bytes of patting, and finally an encrypted payload containing a marker (typically 0xffff), which is in turn followed by 48 bytes.
3. SystemBC then employs a multi-layered encryption scheme for its network traffic that is designed to bypass NIDS systems that rely on entropy analysis or protocol fingerprinting. The encryption routine is as follows:
   • First Pass (XOR): The raw payload is XORed with the session key.
   • Encryption (RC4): The result of this first pass is encrypted using the RC4 stream cipher, keyed with the same session key.
   • Final Pass (XOR): The cipertext is XORed again with the key.
4. For an attacker to utilize the back-connect architecture:
   • The infected Linux server initiates an outbound connection to the C2, either through port 80 or 443 (used for HTTP and HTTPS, respectively).
   • Once connected, the bot keeps the socket open and sends periodic keep-alive beacons.
   • When a threat actor wants to access the victim’s internal network, they connect to the C2 server, which bridges the attacker’s connection with the bot’s active session.
   • Malicious traffic, such as RDP login attempts, SMB file transfers, or shell commands- is encapsulated in the SystemBC protocol, sent to the bot, decapsulated, and forwarded to the internal target.
5. From here, SystemBC attempts to maintain persistence.
   • Since the malware is usually installed as a systemsd service. It creates unit files that define the malware as a critical service, generally with the Restart=always directive. This ensures that the server OS automatically restarts the malware if it crashes or is shut down.

You can view a sandbox detonation of the Linux variant of SystemBC here.

Why It Matters

Migration to Linux targets, which often hold lower levels of protection than Windows workstations running EDR solutions, demonstrates shifting interest from the malware developers and the RaaS organizations that employ their offerings. However, we think that this trend is more about following the pivot from Windows Domain Controllers to Linux-based instances hosted in the cloud.

IOCs