Skip to main content

Cryptojacking in ML Containers: Protecting Your GPUs

The "Free Compute" Problem​

Machine Learning infrastructure is the perfect target for cryptojacking. Why? Because ML engineers deploy massive GPU clusters (A100s, H100s) with high-bandwidth networking.

For an attacker, compromising a Kubernetes pod running a training job is like winning the lottery. They can run miners for days before anyone notices the performance degradation.

How It Enters the Pipeline​

  1. Malicious Docker Images: An attacker uploads a "CUDA-optimized" base image to Docker Hub that contains a hidden miner.
  2. PyPI Supply Chain: A typo-squatted package (e.g., pytorch-gpu-opt) installs a miner in the background during pip install.
  3. Compromised Notebooks: A Jupyter Notebook with RCE vulnerability allows an attacker to run wget xmrig && ./xmrig.

Detection Signatures​

Miners are noisy. They need to communicate with mining pools. We can detect them by looking for specific configuration patterns and protocol strings in your file system or code.

Common Indicators:

  • Binaries: xmrig, minerd, ethminer, nanominer.
  • Protocols: stratum+tcp://, stratum+ssl://.
  • Pool Domains: nanopool.org, ethermine.org, nicehash.com.

Automated Scanning​

Veritensor scans your artifacts (Docker build contexts, Python scripts, Notebooks) for these mining signatures.

# Veritensor Signature Example
- "regex:(?i)stratum\\+tcp"
- "regex:(?i)xmrig"

If you find these strings in a "helper script" or a dependency, your infrastructure is likely being used to mine Monero on the company dime.