Keypoints
- SYSTEMBC is sold as a package containing implants (EXE/DLL), server binaries (Windows EXE, Linux ELF), a PHP C2 panel, and GeoIP2 data.
- The Linux server commonly opens an IPC port (typically 4000 bound to localhost), a C2 port (often 443 by default), and a dynamic per-implant port (range observed 4001–49151).
- Binary-stored configuration uses labeled, padded ASCII strings (e.g., “PORT0:”, “PORT1:”) that can be modified (even with a hex editor) to change ports.
- Three core server files are .settings (proxy interaction), _loader (loader/shellcode history), and .comments (ASCII notes for implants), created on demand.
- SOCKS5 proxying is the primary persistence/pivot mechanism, with optional per-implant SOCKS authentication and a host-based access-control list that closes unauthorized connections.
- The loader accepts a direct URL to fetch executables (HTTP/HTTPS), saves them to %TEMP% with randomized lowercase filenames, and launches them via one-time scheduled tasks to obscure parentage.
- Shellcode can be submitted via the panel (written to a uniqid-based .txt), downloaded directly into implant memory, made executable with VirtualProtect, and run with CreateThread—avoiding disk writes.
MITRE Techniques
- [T1090] Proxy – SYSTEMBC implements a SOCKS5 proxy on per-implant ports to forward actor traffic: [‘act as SOCKS5 proxy’ … ‘server implements the SOCKS5 protocol on the port associated with the implant’]
- [T1105] Ingress Tool Transfer – The loader downloads payloads via HTTP/HTTPS to the implant: [‘direct URL needs to be submitted to the file in the “LOAD URL” textbox … implant will execute a GET request for file download. The implant can download via both HTTP and HTTPS.’]
- [T1053] Scheduled Task/Job – Downloaded payloads are launched via one-time scheduled tasks with randomized 19-character names: [‘the implant saves the file to the %TEMP% directory … sets up a scheduled task to run the downloaded file. The task list is made up of 19 lowercase characters.’]
- [T1055] Process Injection – Shellcode is injected and executed in-memory using VirtualProtect and CreateThread: [‘implant will download this file directly into memory. It then sets the area of memory via the VirtualProtect Windows API call to executable … and then executes it via the CreateThread call.’]
- [T1190] Exploit Public-Facing Application – Operators have leveraged a Citrix NetScaler vulnerability to gain initial access in at least one incident: [‘accessed the system using compromised credentials coupled with a vulnerability in the client’s Citrix NetScaler environment.’]
- [T1078] Valid Accounts – Threat actors gained access using compromised credentials as part of initial access: [‘accessed the system using compromised credentials …’]
Indicators of Compromise
- [Filenames] server binaries and config files – server.exe (Windows), server.out (Linux), .settings, _loader, .comments
- [Ports] IPC and C2 ports – IPC commonly 4000 (localhost), C2 often 443, per-implant ports observed 4001–49151
<li[%TEMP% paths / task names] loader/scheduled task artifacts – downloaded files saved to %TEMP% as random lowercase names, scheduled task names of 19 lowercase characters
<li[Shellcode filenames] predictable uniqid naming – shellcode text files generated by PHP using uniqid (10-digit Unix timestamp + 13 hex chars + “.txt”)
SYSTEMBC is distributed as an installation archive that includes Windows EXE/DLL implants, server binaries for Windows and Linux, a monolithic PHP control panel, and GeoIP2 data. The Linux server commonly listens on a localhost IPC port (default 4000), a C2 port (often 443), and allocates a unique TCP port per active implant (observed 4001–49151). Port values are stored in the server binary as labeled, null-padded ASCII strings (e.g., “PORT0:” and “PORT1:”), allowing configuration by updating those strings; three primary server-side files—.settings (proxy/implant mappings), _loader (loader/shellcode history), and .comments (implant notes)—are created on demand to track implants.
The server implements SOCKS5 on the per-implant ports to proxy traffic through compromised hosts, with optional per-implant RFC 1929 authentication (auto-generated credentials) and a host-based access-control list that causes the server to gracefully close connections from unauthorized IPs. Loader functionality lets the operator submit a direct URL (HTTP/HTTPS) which the implant GETs, saving the payload to %TEMP% under a randomized lowercase filename and scheduling it to execute via a one-time scheduled task—this places the launched payload under benign parent processes (e.g., svchost.exe) and reduces attribution to the implant. The same loader and shellcode capabilities can be applied globally to all implants with an optional repeat schedule from the panel settings page.
For in-memory execution, the panel writes submitted shellcode to a uniqid-named .txt, the implant fetches it into memory (no disk write), marks the memory executable with VirtualProtect (0x40), and spawns a thread with CreateThread to run the code, enabling payloads (including Meterpreter) to operate without obvious new processes. These behaviors—SOCKS-based pivoting, URL-based loader with scheduled execution, and direct in-memory shellcode injection—are core to SYSTEMBC’s operational procedure and persistence model.
Read more: https://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server