{
	"id": "1f068bd5-ab06-4144-bad1-470c19b032cb",
	"created_at": "2026-04-06T00:20:08.472592Z",
	"updated_at": "2026-04-10T03:20:19.526766Z",
	"deleted_at": null,
	"sha1_hash": "4438749d2712b599429b10322dbccc9df9475ce2",
	"title": "Inside the SYSTEMBC Command-and-Control Server",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3114628,
	"plain_text": "Inside the SYSTEMBC Command-and-Control Server\r\nBy Dave Truman\r\nPublished: 2024-01-19 · Archived: 2026-04-02 10:43:51 UTC\r\nThroughout Q2 and Q3 2023, Kroll has observed an increased use of the malicious “SYSTEMBC” tool to\r\nmaintain access in a compromised network. SYSTEMBC was first observed in the wild in 2018 with its core\r\nfunctionality revolving around its ability to act as SOCKS5 proxy. This provides a useful capability for threat\r\nactors as a persistent access mechanism or for purposes of leaving behind a backdoor in case of discovery of their\r\ninitial access method. The SOCKS protocol allows for a threat actor to access a victim network almost as if their\r\nworkstation was directly connected. The tool has been leveraged by a number of threat actors across several\r\ncampaigns as well as used alongside many malware families, including RHYSIDIA, BLACKBASTA, CUBA,\r\nGOOTLOADER, COBALTSTRIKE and EMOTET.\r\nSYSTEMBC can be purchased on underground marketplaces and is supplied in an archive containing the implant,\r\na command-and-control (C2) server, and a web administration portal written in PHP.\r\nThe Kroll Cyber Threat Intelligence (CTI) team conducted research into SYSTEMBC, focusing on its C2 server.\r\nWatching the initial walkthrough of the SYSTEMBC C2 server from our threat intelligence expert, Dave Truman\r\nSYSTEMBC Server Installation\r\nSYSTEMBC comes as an installation package with several software components:\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 1 of 17\n\nSYSTEMBC implant in standalone preinstallation environment (PE) Windows executable (.EXE) file\r\nformat\r\nSYSTEMBC implant as PE dynamic link library (DLL) file (32-bit and 64-bit versions)\r\nServer executable in Windows .EXE format\r\nServer executable in Linux executable and linkable format (ELF) format\r\nPHP file for rendering the C2 panel interface\r\nGeoIP2 data\r\nAlongside the software components, the developers of the malware provide a text file containing both English and\r\nRussian language installation steps for the server.\r\nFigure 1 - Installation Instructions Provided in Both Russian and English\r\nInstallation instructions are provided for both Windows and Linux, containing detailed steps on packages to install\r\nand execution commands to run. While the Windows instructions are much more succinct, Linux instructions are\r\nmore in-depth. They can be found below:\r\nFigure 2 – Linux Installation\r\nFinally, the installation document details how to set up fast flux for use with SYSTEMBC, although it states that\r\nfast flux is not recommended to be used with the tool.\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 2 of 17\n\nFigure 3 – Fast Flux Warning and Instructions\r\nWithin the fast-flux instructions are details on setting kernel-level parameters for network “keep alive” behaviors\r\nas a mechanism to avoid the SOCKS connections from disconnecting.\r\nSYSTEMBC Server Configuration\r\nAt the heart of the C2 side of the application is the “server” binary for Windows. This is called “server.exe”; for\r\nLinux, it is called “server.out”. Our research focused on the Linux server due to its common use.\r\nThe server opens two or more Transmission Control Protocol (TCP) ports:\r\nOne port for inter-process communication (IPC) between itself and the PHP-based panel interface, usually\r\nport 4000 and bound to localhost.\r\nOne port for C2 traffic. We have seen many different port numbers for C2 across the different servers that\r\nthe Kroll CTI team found in the wild; however, 443 is likely the default.\r\nFor each active implant, the server opens a port. These range in number from 4001 to 49151.\r\nThe configuration for the C2 and IPC ports are represented as plain text string within the binary itself. Both port\r\nnumber strings are prepended with a label acting as an identifying string “PORT0:” for IPC and “PORT1:” for C2.\r\nEach is also padded with null characters so the space allocated for each would total six characters, allowing for a\r\nfive-printable and one null-terminating character representation of all valid TCP port numbers (1–65535).\r\nFigure 4 – Port Settings Within Binary with Visible Padding\r\nThe way the data is stored within the binary indicates that it is likely to be configurable, potentially with a tool\r\nthat reads the binary and updates the values by searching for the labels and updating the strings. Testing modifying\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 3 of 17\n\nthe values with a hex editor allowed for configuration of the ports.\r\nThere are core three data files that the server uses:\r\nFigure 5 – Table of Server Executable’s Configuration Files\r\nThese files get created when the server needs them, so if no comments have been made for any implants/victims,\r\nthere will not be a .comments file.\r\nThe use of the value 49151 for the maximum port number hints that the developer might be used to lower-level\r\nprogramming such as C or Assembly. While 49151 in its decimal notation doesn’t appear relevant, in hex it is\r\n0xBFFF, which is one lower than a round number (0xC000). This indicates an awareness of the memory allocation\r\nof integers.\r\nFigure 6 – Source Filename Contained Within the Linux Server Binary\r\nWhile it is generally reported that SYSTEMBC is written in C, there is reference to a source file within the Linux\r\nServer binary that could indicate that part of SYSTEMBC was coded directly in Assembly language.\r\nSYSTEMBC Control Panel\r\nThe SYSTEMBC panel is written as a single monolithic PHP script. The code itself appears mainly written as a\r\nseries of “if” statements, with little use of functions. At the beginning of the code, we can see the setup of the TCP\r\nconnection to the server binary with the port number of 4000 hardcoded. This indicates that while this port is\r\nconfigurable in the binary, it is likely intended to be left at 4000. Rather than utilizing PHP’s built-in ability to act\r\nas code nested within an HTML document, instead most of the HTML elements of the page are printed out with\r\nthe echo function. While both are valid approaches, the choice might provide insights into the developer’s\r\nprevious development experience.\r\nFigure 7 – Control Panel PHP code with Hardcoded Connection String to Server IPC Port\r\nOne of the few separated-out functions, which solves an arguable non-complex problem, is a function called\r\n“secondsToTime”, which appears to be copied and modified from a stack overflow post with the original\r\ncomments left in.\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 4 of 17\n\nFigure 8 – Side-by-Side Comparison of Function Within PHP Panel and Stack Overflow Post\r\nAlong with the previously mentioned maximum port, there are indicators that might also point to the possibility of\r\nthe developer having more experience (or interest) in lower-level programming, with the PHP being a means to an\r\nend. For example, the developer would seek a faster way to get a working web interface rather than one of their\r\ngo-to technologies. Some of these indicators are:\r\nThe minimalist and monolithic nature of the PHP code\r\nPrinting the HTML elements rather than nesting of the PHP within an HTML document\r\nChoice to do most of the business logic within the server executable\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 5 of 17\n\nBinary configuration files\r\nUtilization of externally sourced functions for relatively easy-to-write PHP code\r\nThe control panel is the attacker’s view of the machines they have infected. It is dominated by a table with a row\r\nfor the key details of each machine, most important of which is the port on which the C2 server is listening for\r\nSOCKS traffic to tunnel into victim networks.\r\nFigure 9 – SYSTEMBC C2 Panel Showing Active Implant with its SOCKS Access Port Highlighted\r\nCore Functionalities of SYSTEMBC\r\nSYSTEMBC has a small set of core functionalities; however, it is entirely based upon enabling other\r\nfunctionalities. The functionality of SYSTEMBC can be broken down into 3 components.\r\nSOCKS5 proxying onto a compromised host\r\nLoader functionality for running separate scripts and executables\r\nModule loading for on-the-fly expanding of SYSTEMBC implants core functionality\r\nSOCKS5\r\nUpon check-in, the implant establishes an outbound network connection from the victim machine to the C2 server;\r\nthat connection is kept open while the implant is running. On the C2, a listening TCP socket is created and\r\nassigned a port number, which in turn is associated with the specific implant. This relationship is maintained via\r\nthe user of the .settings file. The server implements the SOCKS5 protocol on the port associated with the implant\r\nand accepts any SOCKS5 connections for which it will then send the network data to be proxied along with the\r\nnetwork connection established from the victim machine. Once received, the implant will forward traffic on this\r\nnetwork to the intended destination as if the victim machine had made the request.\r\nA threat actor can use this SOCKS connection as a beachhead within the target network forwarding on any tool\r\nwith SOCKS support, including vulnerability scanners, password sprayers and remote connections. Often\r\noverlooked, it also provides the actor with a means for attacking other networks from the victim network. This can\r\nbe useful in abusing trusted relationships between companies and for attacking from IP addresses that belong to\r\nlegitimate entities with a low-risk profile, rather than from anonymized IPs via VPNs or Tor that might trigger\r\nsecurity events on well-defended networks.\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 6 of 17\n\nFigure 10 – SOCKS Communication Across a Victim Network\r\nThe server-side configuration of the SOCKS access allows for two optional settings for the SOCKS proxy. Both\r\nare geared toward securing the connection on behalf of the actor.\r\nThe first is the option to enable authentication individually for each connection. This is done by switching a toggle\r\nfor the specific implant on the main page. When toggled, the page changes to show a username and password that\r\ncan be used to authenticate via SOCK5 protocol as defined in RFC 1929 for that specific implant. The username\r\nand password are randomly generated and not set by the control panel user. Turning the authentication toggle off\r\nand on again will cause the username and password to rotate. The configuration for this is stored in the .settings\r\nfile.\r\nFigure 11 – Authentication Toggle and Auto-Generated SOCKS Credentials\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 7 of 17\n\nFigure 12 – Packet Capture Showing Server Requiring SOCKS5 (05) Credential Authentication (02) as per RFC\r\n1929\r\nThe second configuration option that affects the behavior of the SOCKS proxy functionality is the configuration\r\nthat is accessed via the link labeled “Firewall”.\r\nFigure 13 – Link to Host-based Access Control Configuration\r\nBy entering one or more IP addresses in the text area, the server will accept SOCKS connections from that list of\r\nIP addresses. This is a global setting, and all implants will now only be SOCKSaccessible via these IP specific\r\naddresses.\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 8 of 17\n\nFigure 14 – Host-based Access Control Configuration\r\nThe access control mechanism is not a firewall as it does not block access to the port and the application behind it.\r\nInstead, the server process will immediately close the connection, instigating a graceful shutdown upon first use.\r\nFigure 15 – Graceful Shutdown Initiated by Server on First Use After TCP Handshake\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 9 of 17\n\nThe TCP port will still show up as open via a port scan from an IP address not in the allowed list; however,\r\nindications of it handling SOCKS5 protocol are no longer present in the packet data of that connection.\r\nLoader\r\nIn order to run a file on a victim machine, a direct URL needs to be submitted to the file in the “LOAD URL”\r\ntextbox within the “LOADER” page. This will trigger the implant to execute a GET request for file download.\r\nThe implant can download via both HTTP and HTTPS.\r\nFigure 16 – C2 Panel LOADER Page with Example URL\r\nThe loader contains functionality for multiple file extensions. Viewing the code in a decompiler, we can see that\r\nthe downloaded file will be treated as an .EXE by default and changed if one of the other extensions is used.\r\nFigure 17 – File Extensions Executable by SYSTEMBC\r\nThis means that any file being sent without one of the extensions listed will be treated as an .EXE file, allowing a\r\nfilename to appear in network logs that might blend in more easily.\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 10 of 17\n\nFigure 18 – Network Traffic Capture of Implant Downloading a Remote File\r\n \r\nOnce the file has been downloaded, the implant saves the file to the %TEMP% directory with a filename\r\nconsisting of random lowercase characters and the file extension. The implant will set up a scheduled task to run\r\nthe downloaded file. The task list is made up of 19 lowercase characters. Since this scheduled task is set up to only\r\nrun once, it will no longer be visible after it is triggered.\r\nFigure 19 – Example Scheduled Task Created for Loading Other Malware on Compromised System\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 11 of 17\n\nFigure 20 – Downloaded Executable Running with Parent Process svchost.exe\r\nThe launch of the downloaded file via a scheduled task cannot easily be traced back to the implant by antivirus\r\nsolutions at runtime, as the parent process of that file will be svchost.exe and not the implant. This means that if\r\nthe new file gets blocked or quarantined, the implant might be able to continue unnoticed.\r\nShellcode\r\nThe shellcode functionality, which is also accessible via the “LOADER” page, allows for a different approach in\r\nexecuting malicious code. Instead of downloading and executing a file, the shellcode in backslash, escaped,\r\nhexadecimal format can be sent to the implant directly via a text area on the page.\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 12 of 17\n\nFigure 21 – Example Shellcode for a Reverse TCP Shell Being Entered into C2 Panel\r\nFigure 22 – Reverse TCP Shell Running\r\nThe PHP control panel creates a text file contain the shellcode string utilizing the uniqid function seeded with the\r\ncurrent time for filename purpose. This gives the file a somewhat predictable filename as highlighted in figure 23,\r\nthe first part of the filename will be the 10-character UNIX timestamp, followed by 13 hexadecimal characters and\r\na “.txt” extension.\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 13 of 17\n\nFigure 23 – PHP Code Used to Generate Distinctive Shellcode Filename on Server\r\nThe implant will download this file directly into memory. It then sets the area of memory via the VirtualProtect\r\nWindows API call to executable by passing in 0x40, and then executes it via the CreateThread call.\r\nFigure 24 – Code Within the Implant for Directly Executing Shellcode from Server\r\nUnlike the loader, the implant does not write the downloaded shellcode file to disk before execution. This can be\r\nseen when tracing the implant execution with the procmon utility. As such, the implant can avoid detection based\r\non filesystem-scanning AV tools, which will hinder obtaining malicious samples from disk forensics.\r\nFigure 25 – Procmon Output Showing No File-Writes Around Time of Shellcode Execution\r\nHowever, because the shellcode runs inside the implant itself, malicious activity might be able to be linked back to\r\nthe implant if detected at runtime. For example, with our reverse shell, we can see cmd.exe has spawned from our\r\nimplant process. An attacker will have to choose when to use the loader functionality and when to use code\r\ninjected directly into the implant itself to avoid detection, along with understanding what activities might draw\r\nattention to the implant itself while utilizing the direct-code injection.\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 14 of 17\n\nFigure 26 – Reverse Shell Spawning as Child of Implant When Running as Shellcode\r\nThe shellcode functionality is not only limited to a reverse shell, but also has full remote capabilities that can be\r\ninjected into the implant at runtime, while being less obvious than spawning cmd.exe for a reverse shell. For\r\nexample, figure 27 shows a Meterpreter instance running inside the implant, which provides a full remote toolset\r\nfor performing a variety of post-exploitation activity. Because the remote functionality in Meterpreter is contained\r\nwithin the code loaded directly into memory, the implant no longer has a suspicious cmd.exe.\r\nFigure 27 – Meterpreter Running After Being Injected via Shellcode Functionality\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 15 of 17\n\nFigure 28 – Process Listing Showing No Obvious Sign Meterpreter is Running Within Implant\r\nThe loader, shellcode and ability to turn on SOCKS authentication functionality are duplicated in the settings page\r\nof the control panel. The difference is that on the settings page, any submissions will be sent to all active implants,\r\nwith an option of setting a “repeat” timer.\r\nFigure 29 – Loader, Shellcode and SOCKS Functionality Duplicated for Global Deployment, with Repeat\r\nScheduling\r\nConclusion\r\nSYSTEMBC represents a real and significant threat to organizations, as cybercriminals typically deploy it as a\r\nmethod of maintaining access to an environment after initial compromise. Kroll has identified that SYSTEMBC is\r\nfavored by RHYSIDA ransomware operators. In one such case impacting a large health care organization, threat\r\nactors accessed the system using compromised credentials coupled with a vulnerability in the client’s Citrix\r\nNetScaler environment. Shortly after access, the threat actors deployed SYSTEMBC, which established their\r\nbeachhead into the victim environment, and allowed the actors to begin deploying additional tooling to further the\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 16 of 17\n\nattack. The actors used multiple tools during the incident, including Advanced Port Scanner for network discovery,\r\nAnyDesk for remote access and MegaSync for exfiltration. After files were successfully encrypted, the actors\r\nchanged passwords to the system so that IT employees could not access the network.\r\nWhen looking at a compromised device from the threat-actor point of view, the Kroll CTI team was able to\r\nsimulate the workflow of an attacker to recreate the launch of an attack using the SYSTEMBC toolset. Our\r\nexperts were able to leverage the tool as a backdoor into a victim’s network, demonstrating the tool’s utility and\r\nease of use. The program is commonly used for persistent access to a victim network or left behind as a secondary\r\ningress point in case the primary is discovered and remediated.\r\nSource: https://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nhttps://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server"
	],
	"report_names": [
		"inside-the-systembc-malware-server"
	],
	"threat_actors": [],
	"ts_created_at": 1775434808,
	"ts_updated_at": 1775791219,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4438749d2712b599429b10322dbccc9df9475ce2.pdf",
		"text": "https://archive.orkl.eu/4438749d2712b599429b10322dbccc9df9475ce2.txt",
		"img": "https://archive.orkl.eu/4438749d2712b599429b10322dbccc9df9475ce2.jpg"
	}
}