Detect Siloscape by looking for anomalous activity inside Kubernetes containers and hosts, especially processes that spawn shells, discover cluster resources, or attempt persistence from within container contexts. Review container and node telemetry for unusual command execution, credential access, outbound connections, and lateral movement from workloads that should be constrained. Focus on tightly scoped permissions and unexpected privilege escalation.
What Siloscape detection should focus on in Kubernetes
Security teams should treat Siloscape as a Kubernetes workload compromise problem first, not just a generic malware event. Detection works best when you correlate container behaviour with node-level telemetry, because the signal is usually abnormal execution inside a container that should be narrowly constrained. Look for processes that behave like an operator, not an application.
A practical baseline is to compare each workload against its normal runtime pattern. A container that suddenly launches a shell, enumerates cluster objects, touches service account material, or reaches out to unfamiliar destinations is acting outside the profile you expect. If you already use workload hardening and least privilege, those controls make these deviations much easier to spot because legitimate container activity should be comparatively sparse.
For broader malware detection context, use the Malware Guide to anchor what anomalous execution, persistence, and evasion look like in practice. That helps teams separate ordinary container noise from behaviour that suggests an active payload or post-compromise tooling.
Telemetry and behaviours that are most useful
Prioritise container runtime logs, Kubernetes audit events, node process telemetry, and egress monitoring. The most useful clues are not just a single suspicious command, but a chain of actions that should rarely occur together: command execution in a container, discovery of cluster resources, access to credentials or tokens, then outbound connections or lateral movement. That sequence is more informative than any one alert in isolation.
Also watch for privilege changes that do not fit the workload’s purpose. If a pod that should only serve traffic begins interacting with the filesystem, host namespaces, sensitive mounts, or orchestration APIs, the question is not whether it is malware yet, but whether its runtime authority has already been abused. Container escape is not required for serious impact if the workload can still reach enough cluster metadata or secrets to expand access.
Use the MITRE ATT&CK Enterprise Matrix to map those behaviours to credential access, discovery, privilege escalation, and lateral movement patterns. That mapping helps analysts move from “odd container activity” to a defensible detection hypothesis and a repeatable hunt query.
How to confirm and investigate suspected Siloscape activity
Start with the workload identity and its normal permissions. Confirm which pod, service account, image, and node were involved, then ask whether the observed action was even possible under intended policy. If the workload accessed cluster resources it should not need, the investigation should expand from containment to blast-radius assessment, because the issue may be overpermissive access rather than a one-off malicious process.
Next, inspect surrounding evidence for persistence and propagation. Check whether the same pod or node shows repeated shell spawning, scheduled tasks, unexpected binaries, or new processes surviving restarts. Review whether the activity aligns with known cluster-admin style discovery, token theft, or attempts to stage follow-on access. A single suspicious command can be accidental; repeated privilege-seeking behaviour from a container usually is not.
For incident handling structure, FIRST is useful as a coordination reference when you need to preserve evidence, assign roles, and move quickly from triage to containment without losing chain-of-custody discipline.
Risk and Threat Considerations
Siloscape-style activity matters because containers often run with more cluster reach than defenders assume, especially when service credentials, node access, or overly broad permissions are involved. The main risk is not only malware execution, but the attacker using a compromised workload to move from a single container into the wider Kubernetes environment.
Failure mechanism: A malicious process inside a container abuses discovery, token access, and reachable APIs to enumerate the cluster, persist, or pivot into adjacent workloads before defenders notice the behaviour.
Impact: The result can be expanded access, secret exposure, workload takeover, and unreliable trust in the affected node or namespace, which often forces broader containment than teams expect.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Container shells and scripted execution are core to detecting post-compromise workload activity. |
| T1087 — Account Discovery | Cluster and account discovery behavior is central to spotting Siloscape-style reconnaissance. | |
| T1021 — Remote Services | Outbound pivoting and lateral movement from containers align with remote access abuse patterns. | |
| Recommendation — Hunt for unexpected shell spawning and scripted execution from Kubernetes containers. Correlate discovery activity with the originating pod and service context. Alert on unusual remote connections and lateral movement originating from workloads. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Container and node telemetry are the main evidence sources for detecting the activity. |
| Recommendation — Centralise and review container, node, and Kubernetes audit logs for anomalous execution. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Detection depends on analysing telemetry for unusual command execution and access patterns. |
| Recommendation — Review audit records for anomalous container actions and escalation attempts. | ||
Practitioner Guidance
What to verify: Validate that your detections distinguish ordinary orchestration noise from behaviour that indicates operator-like action inside a container. The best hunting signals are shell spawning, resource discovery, token or credential access, and outbound connections from workloads that should not initiate them.
Decision rule: If a container can reach cluster resources beyond its job function, treat the event as a permission and containment problem immediately, even before you prove malware lineage. If the workload has no legitimate reason to inspect the cluster, the investigative priority should be to reduce its access and scope the blast radius.
Practitioner takeaway: Detecting Siloscape is mostly about recognising when a constrained workload starts behaving like an intruder, and then proving whether that behaviour is isolated or already a pathway into the cluster.