Attackers use SystemBC as a proxy and backdoor to hide traffic and maintain access on compromised hosts. It can support command and control as well as relay connections to other tools, so defenders should look for unusual outbound proxying, persistent service artefacts, and traffic that obscures the true source. Network egress controls and host isolation help contain it.
How SystemBC is used in an intrusion chain
SystemBC is valuable to attackers because it helps them separate the compromised host from the tools they want to run next. That makes it easier to keep a foothold alive while reducing the chance that defenders immediately see the real operator, the real destination, or the full shape of the traffic path.
At a practical level, this means the malware is less about a single payload action and more about enabling later stages. It can carry command traffic, relay connections, and help other malware or operator tooling reach the infected system without exposing the attacker’s origin as clearly.
What defenders should expect to observe
When SystemBC is active, the visible signs are often indirect. You may see persistent outbound connections that do not fit the host’s normal role, proxy-like behaviour on a workstation or server that should not be brokering traffic, or service artefacts that restart the malware after reboot.
Defenders should also treat concealment as part of the threat model. If traffic is being relayed through the host, the source of the session may look misleading unless you correlate endpoint telemetry, network egress logs, and process lineage. That is why unusual proxying deserves the same attention as a traditional backdoor.
Containment and response priorities
The first containment question is whether the host is simply relaying traffic or also acting as an access point for additional tooling. If it is still connected, isolate it quickly enough to stop further relay activity, but preserve evidence before wiping artefacts that explain how the operator maintained access.
Because the malware can support continued remote access, response should focus on both the host and the broader access path. Reset any credentials, tokens, or sessions that could have been used after the initial compromise, and review nearby systems for signs that the relay was used to pivot or stage other tools.
Risk and Threat Considerations
SystemBC matters because proxy and backdoor functions can turn one compromised endpoint into a stealthy transit point for later intrusion activity. That raises the likelihood of missed dwell time, hidden command and control, and incomplete incident scope if teams focus only on the first infected host.
Failure mechanism: The malware relays traffic and maintains remote reachability while blending the operator’s activity into the compromised system’s normal outbound paths, which weakens source attribution and can obscure follow-on tooling.
Impact: Attackers may preserve access longer, move traffic through a trusted internal host, and use the relay to support additional intrusion stages without immediately exposing the true origin of the session.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1090 — Proxy | SystemBC is used to relay attacker traffic through a compromised host. |
| T1105 — Ingress Tool Transfer | SystemBC often supports delivery of follow-on tools through the compromised host. | |
| T1572 — Protocol Tunneling | SystemBC can obscure the origin of command traffic by tunneling it through relays. | |
| Recommendation — Map proxy-like traffic to T1090 and hunt for relay patterns in network telemetry. Trace suspicious post-compromise downloads and block staged tool transfer paths. Correlate tunneled sessions with endpoint evidence to expose hidden command and control. | ||
Practitioner Guidance
What to verify: Check whether the host is making outbound connections that act like a proxy, whether the process tree matches any approved software, and whether the persistence mechanism survives reboot or service restart. If those three conditions line up, treat the host as an active relay rather than a simple infected endpoint.
Decision rule: If the host is already handling suspicious relay traffic, prioritise containment and credential review before spending time on payload reconstruction. If the machine is business-critical, preserve disk and memory evidence first, then move it out of the network path as fast as possible.
Practitioner takeaway: The main mistake is to investigate SystemBC as only malware on one box, because its real operational value is often the hidden access path it creates for everything that follows.
Related resources from NHI Mgmt Group
- Guide: Malware Guide
- How do attackers turn a supply-chain incident into wider NHI compromise?
- How do attackers operationalise stolen OAuth tokens at scale?
- Why do attackers often check model availability before trying to generate content?
- How do attackers turn stolen npm secrets into broader compromise?