Topic starter
11/08/2026 3:14 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Aqua Security: “How Did Aqua Catch a Cryptomining Attack Hiding in Memory?”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: This campaign shows that container compromise can unfold entirely in memory, which defeats control models built mainly around image inspection and signature matching.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 8 hours ago by NHI Mgmt Group
11/08/2026 3:27 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Fileless cryptojacking in containers shows why runtime control matters
This post was modified 8 hours ago by NHI Mgmt Group