Notifications
Clear all
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.
NHIMG editorial — based on content published by Aqua Security: How Did Aqua Catch a Cryptomining Attack Hiding in Memory?
Questions worth separating out
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.
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: 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.
Practitioner guidance
- 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.
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.
👉 Read Aqua Security's analysis of fileless cryptojacking in containerised workloads →
Fileless cryptojacking in containers: are runtime controls enough?
Explore further
11/08/2026 3:27 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Fileless cryptojacking in containers shows why runtime control matters
