The Gentlemen's Proxy: Dissecting SystemBC's 1,570-Victim Botnet
Just saw the new research from Check Point regarding the SystemBC C2 server linked to The Gentlemen RaaS operation. It’s wild that a single exposed server led to identifying over 1,570 victims. It really highlights how aggressive these initial access brokers and affiliates are right now.
For those who haven't dived deep into SystemBC, it acts as a bridge to establish SOCKS5 proxies on infected hosts. This lets the threat actors route traffic through the victim's infrastructure to hide their C2 communication or move laterally. It’s classic proxy malware, often used to stage the environment before the actual ransomware payload drops.
Detection can be tricky because it looks like legitimate traffic if you aren't inspecting closely, but the persistence mechanisms usually give it away. We’ve seen variants dropping executables that register as services or run via scheduled tasks.
Here’s a quick PowerShell snippet I’ve used to hunt for unusual processes with active network connections that might be acting as proxies. It’s a starting point for a wider hunt:
Get-NetTCPConnection -State Established |
Where-Object { $_.LocalPort -gt 1024 -and $_.RemoteAddress -notmatch "^(127\.|10\.|172\.1[6-9]\.|172\.2[0-9]\.|172\.3[0-1]\.|192\.168\.)" } |
ForEach-Object {
$proc = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
if ($proc) {
[PSCustomObject]@{
ProcessName = $proc.ProcessName
PID = $proc.Id
LocalPort = $_.LocalPort
RemoteAddress = $_.RemoteAddress
CommandLine = (Get-CimInstance Win32_Process -Filter "ProcessId = $($proc.Id)").CommandLine
}
}
}
Given the volume of victims here, it seems like OpSec failures are becoming the norm, or they just don't care about burning infrastructure anymore. How are you folks tracking proxy traffic in your environments? Are you relying on NetFlow/Zeek or going full EDR hunting?
Solid snippet. From a SOC perspective, we've had luck detecting SystemBC specifically by looking for the cmd.exe /c parent chains often used in their deployment scripts. Also, don't sleep on the JA3 signatures; SystemBC's SSL/TLS handshake has a fairly distinct fingerprint if you're decrypting SSL traffic at the perimeter.
The sheer scale of that C2 log dump is insane. It's a classic case of 'easy come, easy go' for the attackers. In my pentesting experience, SystemBC is a favorite because it's so lightweight, but that lack of sophistication often leads to these massive OpSec fails. We usually find it running under obscure service names, so random process names in services.msc should be a red flag.
We tackled a similar infection last month. The key for us was restricting outbound connections to non-standard ports at the firewall level. It breaks some legitimate business apps, but it effectively neutralized the proxy functionality until we could eradicate the malware.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access