CUDA Kernel-Based Cryptomining: Hiding Inside Legitimate AI Workload Signatures
For executives
The previous article covered why cryptomining detection fails at the utilisation level. This article covers the technical execution: how a CUDA-based cryptomining payload embeds itself in a GPU container to look like a legitimate workload, what signals distinguish it from legitimate AI execution, and why detection requires visibility into the CUDA execution layer.
CUDA as the common execution platform
Both AI training workloads and cryptomining algorithms run on the GPU via CUDA. Both launch CUDA kernels. Both allocate GPU memory. Both sustain high GPU utilisation. The CUDA programming model is what makes them similar at the surface level.
Below the CUDA API, the execution patterns diverge.
How a mining payload embeds in a GPU container
A straightforward approach: include a compiled CUDA mining binary in the container image and execute it alongside the declared workload.
A more sophisticated approach: compile the mining algorithm as a CUDA kernel and call it from within the legitimate workload's process. At the process level, there is one Python process running the declared workload. At the CUDA level, it is launching both training kernels and mining kernels.
The CUDA context as the detection boundary
A legitimate AI training process creates one CUDA context and launches training-related kernels from it. A container that is also running mining code either:
Creates a second CUDA context for the mining computation — detectable as an additional CUDA context in a container where only one is expected. Or launches mining kernels from the same CUDA context as the training kernels — detectable by the kernel sequence being inconsistent with a pure training workload.
GPU module load detection and hash verification
When a CUDA program launches a kernel, the GPU kernel code must be loaded into the GPU. The GPU module has a deterministic hash. Known legitimate AI framework kernels have known hashes. A mining kernel has a different hash.
Monitoring which GPU modules are loaded into a CUDA context, and verifying those hashes against a known-good baseline for the declared workload, identifies the presence of unexpected code on the GPU regardless of how the payload is packaged.