TL;DR: A multistage fileless XMRig cryptojacking campaign in containerized Node.js applications was exposed by a runtime behavioral detection engine, according to Aqua Security. The activity spanned in-memory execution, drift, persistence and outbound mining communication, showing that scanners and post-alert visibility are not enough when attackers live inside running workloads and move at machine speed.
At a glance
What this is: This is Aqua Security’s analysis of a fileless cryptojacking campaign in containerized Node.js workloads, with the key finding that runtime enforcement can break the attack chain before the miner persists or phones home.
Why it matters: It matters because IAM-adjacent runtime control, workload context and egress enforcement determine whether cloud-native attacks remain visible only after the fact or are stopped before unauthorized execution and persistence take hold.
By the numbers:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
👉 Read Aqua Security's analysis of fileless cryptojacking in containerised workloads
Context
Fileless cryptojacking is a governance problem as much as a malware problem. When an attacker executes in memory, conventional image scanning, signature matching and delayed alerting are all working from the wrong point in the attack chain, especially in containerised environments where process context and egress behaviour matter more than static artefacts.
The article sits at the intersection of cloud security and identity governance because the compromise path depended on runtime workload context, not just malware detection. That makes it relevant to practitioners who manage NHI, secrets, workload identity and control boundaries in modern application platforms.
Key questions
Q: What breaks when fileless attacks are not stopped at runtime?
A: When fileless attacks are not stopped at runtime, the attacker can execute directly in memory, establish persistence and begin outbound abuse before scanners or analysts can react. That means the environment may look clean on disk while the workload is already compromised. Containment must happen at execution time, not after the alert lands.
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: How do security teams know if runtime protection is actually working?
A: Look for evidence that suspicious behaviour is detected fast enough to contain it before the session or workload expands the blast radius. Effective runtime protection produces actionable alerts, ties them to containment steps, and shows that abnormal access can be limited during active execution, not only reviewed afterward.
Q: Who is accountable when workload access leads to cryptomining abuse?
A: Accountability usually sits with both the platform team that exposed the access path and the security team that failed to govern it as a privileged control. If SSH, service credentials, or remote administration rights can reach production compute, those paths need the same ownership discipline as any other privileged identity.
Technical breakdown
Why fileless execution defeats scanner-first security
Fileless execution avoids the controls most teams deploy first. A payload loaded through memory-only mechanisms such as memfd or shell piped execution never needs to land as a durable file, so image scanners and post-build inspection never see the malicious code in the right state. In containers, that gap is wider because the workload may start clean and become compromised only after runtime begins. Visibility tools can observe the event after the kernel has allowed it, but that is not the same as prevention.
Practical implication: teams need runtime controls that can block memory-resident execution, not just alert on it.
How container drift and process lineage expose hidden implants
Container drift occurs when binaries, scripts or processes appear after deployment and were not part of the original image. When paired with process lineage, defenders can see which workload launched a suspicious child process and whether the behaviour fits the intended application pattern. This matters because attackers often mask implants with service-like names, cron jobs or companion processes. A lineage view turns masquerading into an anomaly even when the filename looks legitimate.
Practical implication: enforce drift prevention and review parent-child process relationships in workload telemetry.
Why process-level egress control is central to cryptojacking defense
Cryptomining is often missed at the network layer because mining traffic can resemble ordinary outbound application traffic and use standard ports. The difference appears when telemetry is tied to the specific process that initiated the connection, rather than to the host alone. That process-level linkage is what lets defenders distinguish legitimate application egress from a miner contacting a pool and keep the response tied to the exact workload that generated the traffic.
Practical implication: pair process-aware detection with egress enforcement so mining traffic can be blocked before sustained abuse continues.
Threat narrative
Attacker objective: The attacker’s objective was to convert compromised container workloads into persistent Monero mining infrastructure while evading file-based detection and delaying removal.
- Entry began with exploitation of a Next.js application in a containerised Node.js environment, allowing the attacker to execute code inside the running workload.
- Escalation took the form of fileless loader execution, drifted binaries, persistence via cron and shell profile changes, and an SSH key backdoor on compromised hosts.
- Impact was sustained cryptomining through XMRig activity and outbound communication to a mining pool, while anti-removal steps made cleanup harder.
NHI Mgmt Group analysis
Runtime enforcement is now the decisive control boundary for cloud-native attacks. This campaign shows that prevention cannot stop at build time when the adversary executes inside a live workload. Scanners, posture tools and delayed alerts may document the problem, but they do not prevent the first malicious action. For cloud security programmes, the meaningful control is the point where execution is blocked before the kernel, not the point where telemetry is reviewed later.
Fileless cryptojacking creates a detection gap that looks like normal application behaviour until it is too late. The attacker used memory-resident execution, process masquerading and standard-port mining traffic to blend into a container environment. That combination turns file-centric assumptions into a blind spot. Detection-response latency: the longer a team relies on alert queues instead of inline controls, the more likely it is that mining, persistence and cleanup resistance are already in place by the time humans intervene.
Cloud runtime telemetry is becoming an identity control problem as much as a malware problem. The campaign depended on understanding which process was authorised to act, which workload spawned it and whether that action matched the expected identity of the container. That is an identity question in operational form. Practitioners should treat workload identity, process lineage and egress enforcement as a single governance surface, not separate tools.
For CNAPP programmes, drift prevention and fileless execution controls are the real test of maturity. Alerting on suspicious binaries after deployment is useful, but this article shows that the bar is whether the platform can stop unauthorised action in real time. The practical conclusion is straightforward: if a control cannot prevent memory-resident execution or associated egress, it is not yet a containment control.
What this signals
Detection-only cloud security programmes will continue to miss the highest-value intrusions. The lesson here is not simply that runtime matters, but that containment must happen where execution occurs. For teams running containerised applications, that means policies for drift, fileless execution and egress need to be measured as operational controls, not logged as post-incident evidence.
Process lineage will become a more important control signal than binary reputation. As attackers keep hiding inside legitimate application flows, practitioners should expect more emphasis on behavioural telemetry that answers who launched what, under which workload identity, and whether that behaviour was authorised. The governance gap is not lack of alerting, it is lack of enforceable runtime context. NHI Lifecycle Management Guide
The next maturity step for CNAPP programmes is to connect runtime containment to identity governance across workloads and secrets. That means treating workload identity, secret exposure and outbound process behaviour as a single control surface rather than separate product dashboards. Where teams already track secret sprawl, the more important question is whether compromised execution can still move laterally or persist after the first signal.
For practitioners
- Enable inline block policies for memory-resident execution Turn on controls that specifically block memfd and /dev/shm style execution paths in workloads where fileless behaviour is not expected, and verify they operate in enforcement mode rather than audit mode.
- Enforce drift prevention on baselined workloads Treat binaries, scripts and companion processes introduced after deployment as a containment event, and block them before they can establish footholds or spawn persistence mechanisms.
- Tie outbound mining traffic to the initiating process Require telemetry that maps network egress back to the exact process and parent lineage, then block connections to known mining pools or anomalous destinations at the workload layer.
- Review persistence locations inside containers and hosts Inspect cron jobs, init scripts, shell profiles and authorized_keys entries for changes that indicate post-compromise persistence, then remove any artefacts linked to unexpected workload activity.
- Validate containment against process masquerading Test whether security teams can still identify an unexpected child process when the attacker renames it to resemble a legitimate service, because filename-based detection will miss that condition.
Key takeaways
- This campaign demonstrates that fileless cryptojacking can evade scanner-first security while still establishing persistence and mining at scale.
- The evidence points to runtime enforcement, process lineage and egress control as the controls that separate visibility from containment.
- Cloud security teams should treat container drift, memory-resident execution and workload identity as one governance problem, not three disconnected alerts.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0002 , Execution; TA0003 , Persistence; TA0011 , Command and Control | The attack used fileless execution, persistence and mining egress. |
| NIST CSF 2.0 | PR.AC-4 | Workload access and execution boundaries need enforceable control. |
| NIST SP 800-53 Rev 5 | SI-4 | The article centres on detecting and stopping malicious runtime behaviour. |
| CIS Controls v8 | CIS-10 , Malware Defenses | Cryptomining is malware behaviour that requires active containment. |
| NIST Zero Trust (SP 800-207) | The article relies on continuous verification of workload behaviour. |
Map runtime detections to execution, persistence and C2 tactics, then block the behaviours that match them.
Key terms
- Fileless Execution: Fileless execution is malicious activity that runs without leaving a conventional on-disk payload for scanners to inspect. It reduces obvious forensic artefacts and shifts detection toward behavioural controls, memory inspection, and runtime enforcement rather than file-based hygiene alone.
- 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.
- 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.
- 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.
What's in the full article
Aqua Security's full post covers the operational detail this post intentionally leaves for the source:
- The step-by-step telemetry sequence showing process execution, drift and mining egress in the customer environment.
- The specific indicators of compromise, including hashes, network destinations and payload infrastructure.
- The policy modes that distinguish audit-only visibility from inline enforcement in runtime controls.
- The container and Linux persistence locations that defenders should inspect during containment.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management in the context of modern identity risk. It helps practitioners connect identity controls to the broader security programmes their environments depend on.
Published by the NHIMG editorial team on August 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org