How do attackers use Siloscape?

How Siloscape works in a Kubernetes environment

Siloscape is used as a post-compromise toolchain for Kubernetes environments. The attacker goal is not just initial access, but control of containerised workloads, continued access over time and freedom to run code in places defenders may not be watching closely. That makes the cluster, rather than a single host, the real operating surface.

In practice, the malware abuses workload permissions, cluster trust relationships and exposed management paths to stay active after entry. Once inside, it can blend into ordinary container activity unless defenders are validating which workloads should exist, which images should run and which identities are allowed to talk to the API.

What attackers gain from cluster compromise

The value of Siloscape is that it helps an intruder turn one foothold into broader cluster control. That can include malicious code execution inside containers, persistence through surviving workloads or deployment paths, and movement toward other resources that are reachable from the same cluster trust boundary.

Malware Guide is useful here because Siloscape behaves like modern malware: it relies on stealth, execution inside a legitimate environment and abuse of the controls defenders assume are already in place. The defensive question is not only whether a container was compromised, but whether the cluster still contains a pathway the attacker can reuse.

That is why suspicious images, unexpected API calls and privilege gaps matter. A weakly governed Kubernetes estate can let an attacker move from one compromised workload to scheduling, secrets access or other resource use without needing noisy exploit steps.

What defenders should look for first

When Siloscape is suspected, the first checks should focus on workload provenance and control-plane activity. Look for containers that were not approved, images that do not match release records, commands executed from inside workloads that should be immutable, and API activity that does not match the normal pattern for the namespace or service account involved.

Defenders should also verify whether cluster permissions are broader than they need to be. The malware becomes more useful when service accounts, secrets access or namespace boundaries are loose enough to let an attacker pivot after the first compromise. A clean image alone is not enough if the workload still has excess rights.

Risk and Threat Considerations

Siloscape is dangerous because Kubernetes often concentrates many workloads, credentials and control paths into one trust domain. If one container is abused, the attacker may not need to “break out” in the classic sense, they may only need to find a misconfiguration or overprivileged path that the cluster already exposes.

Failure mechanism: An attacker abuses container execution and weak cluster boundaries to persist, reuse permissions and reach additional resources through the Kubernetes control plane or adjacent workloads.

Impact: The result can be broader cluster compromise, unauthorized code execution, workload tampering and a much larger blast radius than the initial container suggests.

Practitioner Guidance

What to verify: Confirm whether every running image, service account and namespace permission has a documented owner and approved purpose. If the answer is unclear, treat the environment as exposed even before you have a confirmed malicious artifact.

Decision rule: If the suspected container can reach the API, secrets or other workloads, prioritise containment and privilege review before deeper forensic tuning. If it cannot, focus first on image integrity, pod drift and signs of repeat deployment from the same source.

Practitioner takeaway: With Siloscape, the important judgement is whether a single container has become a reusable cluster access path. Once that happens, incident response must shift from endpoint-style cleanup to control-plane containment and privilege reduction.

Related resources from NHI Mgmt Group

• 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?