SystemBC Botnet Hacked 1,500 VPS Servers Daily to Hire for DDoS Attack

The emergence of the SystemBC botnet marks a significant evolution in proxy-based criminal infrastructure.

Rather than co-opt residential devices for proxying, SystemBC operators have shifted to compromising large commercial Virtual Private Servers (VPS), enabling high-volume proxy services with minimal disruption to end users.

In recent months, Lumen Technologies has observed an average of 1,500 newly compromised VPS systems daily, each enlisted to relay malicious traffic on behalf of criminal threat groups.

These compromised servers function as robust, high-bandwidth proxies, delivering an unprecedented level of throughput that traditional residential botnets cannot sustain.

Initially documented by Proofpoint in 2019, SystemBC functionality has expanded beyond simple proxy operations.

After successful infiltration, the loader decrypts a hard-coded configuration and establishes a connection to one of over 80 command-and-control (C2) servers.

The payload leverages a combination of XOR and RC4 encryption to secure its communication channel, ensuring that detection and analysis by defenders remains challenging.

Lumen analysts identified this encryption pipeline during dynamic analysis of a Linux variant sample, revealing a three-stage process for both outbound beaconing and C2 responses.

This constant cat-and-mouse game between evasion and detection has underscored the resilience of SystemBC over multiple years.

The impact of this botnet has been felt across the cybercrime ecosystem. In addition to supplying proxies for renting, SystemBC’s network has been integrated into larger offerings such as REM Proxy, a tiered commercial service catering to multiple criminal enterprises.

REM Proxy’s high-end “Mix-Speed” tier comprises numerous SystemBC-infected servers, prized for their volume and stability.

Meanwhile, lower-quality proxies are relegated to brute-force campaigns and credential harvesting. This dual-use of compromised VPS assets highlights how threat actors optimize distinct infection and exploitation stages under a single unified architecture.

Infection Mechanism and Decryption Workflow

The infection mechanism often begins with opportunistic scanning of internet-facing services on port 443. Once a vulnerable VPS is identified, the malware download is initiated via HTTP over port 80.

The retrieved shell script, annotated with Russian comments, automates the parallel download and execution of over 180 SystemBC samples.

Each sample shares a 40-byte XOR key embedded in its binary. Upon execution, the loader performs the following pseudocode to reconstruct its C2 configuration:-

# Pseudocode for SystemBC configuration decryption
key = read_bytes(offset=0x100, length=40)
encrypted_config = read_bytes(offset=0x200, length=config_length)
config = xor(rc4(xor(encrypted_config, key), key), key)

Once decrypted, the configuration yields a list of C2 endpoints and operational parameters. The loader then crafts an initial beacon packet—composed of the key, padding bytes, and a 0xFFFF header—encrypted in the same pipeline before transmission.

The response from the C2 server contains a four-byte header indicating commands: new proxy creation, proxy data injection, or termination.

Lumen researchers noted that this symmetric encryption approach effectively evades signature-based detection while maintaining low computational overhead on compromised servers.

Through its blend of scalable infection tactics, robust encryption, and integration into commercial proxy services, SystemBC exemplifies a modern malware-as-a-service model.

Continuous monitoring and rapid sharing of indicators of compromise remain critical to mitigate its widespread threat.

Find this Story Interesting! Follow us on Google News, LinkedIn, and X to Get More Instant Updates.