They often assume that no file on disk means no practical detection path. In reality, fileless malware still creates process, shell, and network behaviour that runtime tools can observe. The mistake is relying on static scanning alone when the threat is designed to operate in memory and evade disk-based signals.
Why This Matters for Security Teams
Fileless malware in containers is dangerous because it defeats the assumptions many teams still make about detection. If the alert strategy is centered on image scanning, file integrity monitoring, or “no executable on disk means no compromise,” the runtime layer becomes a blind spot. Containerised workloads are especially exposed because short-lived processes, inherited environment variables, mounted secrets, and network egress can all be abused without leaving a conventional forensic trail. The control problem is closer to runtime behaviour monitoring than to classic endpoint hygiene, which is why guidance in the NIST Cybersecurity Framework 2.0 matters here.
NHIMG research on The State of Non-Human Identity Security shows that inadequate monitoring and logging are among the top causes of NHI-related attacks, which maps directly to container runtime visibility gaps. The same pattern appears in supply-chain abuse, such as the Shai Hulud npm malware campaign, where attackers pivot through trusted tooling and exposed secrets rather than dropping obvious binaries. In practice, many security teams discover container malware only after egress, credential use, or lateral movement has already begun, rather than through intentional runtime detection.
How It Works in Practice
Fileless malware in containers usually executes through a legitimate process path, then pivots into memory, shell execution, or in-process scripting. That means the attacker may use a base image utility, an init container, a sidecar, or a compromised application process to run payloads without writing a durable artifact to disk. The practical defence is to watch what the workload does, not just what files it contains.
Current guidance suggests layering runtime telemetry with identity-aware controls. That includes process execution events, parent-child process chains, container start and exec activity, DNS and outbound HTTP patterns, and secret access events. Runtime policies should also cover permissions that enable the attack path, such as over-broad service accounts, writable mounts, host namespace exposure, and unnecessary package managers. Where possible, tie detections to workload identity so the alert is anchored to the specific container or service account, not only the node.
- Use CISA-style hardening principles to reduce the attack surface before runtime.
- Correlate container process creation with secret access and egress activity.
- Prefer ephemeral, scoped credentials over long-lived tokens inside the container.
- Alert on unexpected shell use, interpreter spawning, and child process chaining.
NHIMG’s DeepSeek breach coverage reinforces the broader point: when secrets and credentials are exposed, attackers move quickly and do not need disk-based malware to succeed. Mapping this to container operations means assuming the runtime is the primary evidence source. These controls tend to break down in highly ephemeral Kubernetes environments with noisy autoscaling because telemetry gaps and rapid pod churn can outpace collection.
Common Variations and Edge Cases
Tighter runtime monitoring often increases alert volume and operational overhead, so organisations have to balance faster detection against false positives and platform complexity. That tradeoff is real, especially when clusters run many short-lived jobs, service meshes, or language runtimes that legitimately spawn helper processes.
Best practice is evolving, but there is no universal standard for how much container runtime telemetry is enough. Some environments can rely on eBPF-based process and network visibility, while others need admission controls, syscall filtering, or workload-specific baselines to make detections usable. A common mistake is treating every shell invocation as malicious, when CI jobs, migrations, and troubleshooting workflows may legitimately use shells.
Security teams should also watch for cases where malware never needs persistence because the container itself is ephemeral and the attacker only needs minutes of access. That is especially true when credentials are mounted at start-up, tokens are long-lived, or the workload can reach sensitive APIs directly. The right question is not whether a file was written, but whether the workload performed actions outside its expected identity and network pattern.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Runtime abuse often starts with exposed workload secrets and over-privileged identities. |
| NIST CSF 2.0 | DE.CM-7 | Container malware requires continuous monitoring of runtime behaviour and anomalies. |
| NIST AI RMF | Autonomous detection and response should be governed by clear AI risk and monitoring practices. |
Collect process, network, and secret-access telemetry so abnormal container behaviour is detected fast.
