Fileless cryptojacking in containers shows why runtime control matters

At a glance

What this is: Aqua Security describes a fileless cryptojacking campaign in containers that executed in memory, established persistence, and used outbound mining communication while avoiding scanner-first detection.

Why it matters: It matters because container security teams need enforcement at runtime, not only posture and image scanning, when attackers can operate entirely inside a running workload.

Context

Fileless attacks are a control gap problem as much as a malware problem. If execution never touches disk, controls designed around images, signatures, and pre-deployment checks lose their best inspection point before they can judge intent. In containerized environments, that gap widens because workloads are ephemeral, process trees are dense, and legitimate application traffic can resemble malicious activity at the network edge.

The article sits squarely in cloud and application security, but it has an identity angle because the attacker manipulated workload behaviour through runtime execution paths, persistence artefacts, and process-level actions. That is an NHI-adjacent control problem in the broader sense: the environment needs to govern what a running workload is allowed to do, not just what was present when it was built.

Key questions

Q: What fails when container security relies on scanning instead of runtime enforcement?

A: Scanner-first controls fail when the payload is loaded after deployment or executed directly in memory, because the malicious action happens after the inspection point. That leaves little more than post-alert evidence. Runtime enforcement changes the control point by stopping unauthorized execution, drift, or egress before the workload can complete the harmful action.

Q: Why do containerised workloads make cryptojacking harder to spot?

A: Containerised workloads make cryptojacking harder to spot because the malicious process can live inside a legitimate application context, use standard ports and disappear when the container is replaced. Without process lineage and workload-aware telemetry, the miner can blend into normal application traffic and normal runtime churn.

Q: What do teams get wrong about detecting cryptominers in cloud-native environments?

A: Teams often rely too heavily on periodic scans and signature-based tools, which miss miners that use rootkits, fileless techniques, renamed processes, or off-peak activation to blend in. They also miss miners that reduce their resource consumption to avoid obvious spikes. Effective detection needs continuous runtime monitoring, behavioral analysis, and automated response.

Q: Should teams prioritise runtime controls or Kubernetes posture controls first?

A: They should do both, but not as substitutes. Posture controls reduce the chance that a workload is launched with excessive privilege or weak isolation, while runtime controls detect abuse that still gets through. If workloads are already in production and internet-facing, runtime visibility usually deserves the first operational attention.

Technical breakdown

Why fileless container malware evades scanner-first controls

Fileless malware keeps its primary payload in memory, often loading via shell pipes, packed loaders, or memory-backed execution paths such as memfd. That bypasses static inspection because the image on disk may look clean while the live process is already malicious. In containers, this matters more because the container runtime creates a narrow window between deployment and execution, and conventional scanners usually inspect only the image or registry artifact. Once the process starts, a scanner that has no runtime context cannot reliably distinguish legitimate code paths from injected or unpacked payloads.

Practical implication: Treat image scanning as a precondition, not a containment control, for workloads that can execute downloaded or unpacked code.

How runtime enforcement changes the control point

Runtime visibility observes process, file, memory, and network activity after the workload starts, but visibility alone still allows the kernel to permit the action first. Enforcement changes that sequence by blocking the suspicious execution path before the payload completes, which is the difference between detection and prevention. In this article, that means stopping memfd-based execution, blocking binaries introduced after deployment, and interrupting persistence attempts before they become durable. The control objective is to reduce the attacker’s usable dwell time inside the live workload, not merely improve the quality of later alerts.

Practical implication: Place hard enforcement on execution, drift, and egress events inside the workload, not just on alerts sent to the SOC.

Why process context matters for cryptomining detection

Cryptomining traffic is difficult to spot at the perimeter because the miner can use ordinary ports and blend into otherwise normal outbound behaviour. Process lineage resolves that ambiguity by tying a connection back to the exact application or child process that created it. That matters in containers, where a compromised web process can spawn apparently legitimate-looking helpers and persist through cron jobs, init scripts, or shell profile edits. The security value is not just seeing that mining occurred, but proving which process chain created it and whether the behaviour was introduced after deployment.

Practical implication: Correlate outbound connections with parent-child process trees so mining, masquerading, and persistence can be blocked as one chain.

Threat narrative

Attacker objective: The objective was to convert compromised container capacity into persistent, concealed Monero mining infrastructure while avoiding conventional detection.

1. Entry occurred through a Next.js exploit that enabled in-memory execution inside a containerized Node.js workload.
2. The attacker used wget piping to shell and memory-backed loading to run a first-stage script without writing the initial payload to disk.
3. Persistence followed through cron jobs, rc.d scripts, shell profile changes, and an SSH key backdoor that made the compromise durable.
4. The miner then communicated with an external Monero pool over standard outbound traffic, turning the workload into a cryptomining resource.

Breaches seen in the wild

• Storm-1283 OAuth apps abuse 2023: Storm-1283 added secrets to new and existing OAuth apps in Entra ID and used them to run Azure cryptomining VMs, costing victims up to $1.5 million.
• Carbonato botnet 2026: A botnet puts a Hermes AI agent on exposed Docker hosts to steal AI API keys, SSH keys and tokens, powering the operators' own LLM gateway.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime enforcement is now the real boundary between exposure and compromise in container security. Image scanning, posture management, and after-the-fact alerts all assume the attack can be evaluated before or after execution. This campaign shows the more difficult truth: once code runs in memory, the meaningful control is whether the workload can be stopped at the point of execution. Practitioners should treat runtime enforcement as a primary control, not a supplementary one.

Fileless cryptojacking creates a governance gap because it exploits the difference between permitted execution and intended execution. The attacker did not need to defeat every defensive layer, only the assumption that runtime activity can safely be reviewed later. That is a control-model problem, not just a malware problem, and it applies wherever ephemeral workloads can launch downloaded code, unpacked loaders, or memory-backed payloads. The practitioner conclusion is to govern execution intent inside the workload, not just deployment state.

Process lineage is the named concept that separates noisy telemetry from actionable containment. Seeing a miner is useful, but seeing which web process spawned it, which child process persisted it, and which connection it opened gives the security team the evidence needed to suppress masquerading and pivot from detection to enforcement. In cloud-native environments, that lineage is what turns a suspicious event into a defensible control decision. Practitioners should demand lineage-aware control points in container operations.

Cryptomining in containers is often an indicator of broader runtime weakness, not an isolated abuse case. The same weaknesses that let a miner run in memory can also support persistence, hidden binaries, and process masquerade. That means the operational question is not whether mining traffic is blocked at the edge, but whether the environment can prevent hostile code from surviving inside the workload long enough to matter. Practitioners should use this pattern as a proxy for runtime control maturity.

What this signals

Runtime control is becoming the decisive control plane for cloud-native compromise. In container environments, the gap is no longer between secure and insecure images but between allowed and disallowed behaviour after the workload starts. That means security programmes need enforcement points that understand process lineage, memory-backed execution, and process-level egress, or they will keep discovering compromise only after the attacker has already acted.

Fileless cryptojacking is a useful proxy for broader workload governance weakness. If an attacker can live inside a container without writing a durable file, the same control blind spots can support hidden binaries, backdoors, and persistence scripts. The practical signal is simple: if your runtime controls cannot stop one class of in-memory abuse, they are unlikely to constrain more adaptive threats either.

For practitioners

• Enable enforcement mode for runtime drift control Move drift prevention out of audit-only mode for baselined workloads so binaries introduced after deployment are blocked before they execute.
• Block fileless execution paths Use workload policies to stop memfd-based and /dev/shm-based execution paths that indicate memory-resident payload delivery.
• Correlate process lineage with outbound egress Tie network connections to the exact parent-child process tree so miner traffic and masqueraded helper processes can be stopped together.
• Review persistence locations inside workloads Inspect cron jobs, rc.d entries, shell profiles, and authorized_keys changes as part of the containment workflow for live container compromise.

Key takeaways

• This campaign shows that container compromise can unfold entirely in memory, which defeats control models built mainly around image inspection and signature matching.
• The evidence points to a full runtime chain that included execution, drift, persistence, and outbound mining communication, not a single isolated alert.
• The most relevant control gap is enforcement at the workload boundary, where suspicious execution can be blocked before the attacker establishes durable presence.

Key terms

• Payloadless Malware: Payloadless malware is a malicious campaign that relies on links, redirection, or staged interaction instead of a traditional attached file. It often evades file-centric detection because the harm depends on user action, web delivery, or credential capture rather than a visible binary on disk.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
• Process lineage: Process lineage is the chain of parent and child execution events that shows how one process led to another inside a running workload. It helps investigators reconstruct container behaviour, identify the origin of suspicious actions, and distinguish normal execution from abuse.
• Container Drift: Container drift is the gap between the workload state that was approved and the state that actually runs. In practice, drift can include unexpected binaries, altered startup behaviour, or hidden execution paths, and it matters because build-time trust does not guarantee runtime trust.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the wider security programme that depends on them.