Cryptojacking: when someone else mines using your machines
Unauthorised mining rarely destroys anything, which is why it runs for months undetected. How it gets in, what it costs, and the signals that actually catch it.
A crypto mine is hardware doing the computational work that secures a proof-of-work blockchain, in exchange for newly issued coins. Run on your own equipment with your own electricity, it is a business. Run on someone else's without permission, it is cryptojacking — and it is one of the most common outcomes of a cloud compromise.
Why attackers like it
Compared with ransomware it is unglamorous and low-risk. There is no negotiation, no victim contact, no payment infrastructure to be seized, and no deadline. The attacker simply consumes resources quietly and is paid by the network itself.
It is also the natural monetisation of a compromise that yields nothing else worth stealing. A misconfigured container host holding no interesting data is still perfectly good at arithmetic.
Almost all of it mines Monero, for two reasons: it is designed to be mined on ordinary CPUs rather than specialised hardware, and its transactions are private by design, so proceeds cannot be traced the way Bitcoin's can.
How it gets in
- Exposed container and orchestration APIs. An unauthenticated Docker daemon or Kubernetes API on the internet is a remote code execution service.
- Stolen cloud credentials. Keys committed to a repository, found in a build log, or taken from an over-permissive metadata endpoint. The attacker launches instances in your account, and you receive the bill.
- Unpatched internet-facing applications. Mining payloads are a standard follow-on to mass exploitation of a new vulnerability.
- Compromised dependencies. Malicious packages published to npm or PyPI with names close to popular ones.
- CI/CD abuse. Free build minutes on public repositories are a recurring target.
What it costs
The mining revenue is usually trivial — often a few dollars a day per machine. The cost to the victim is not. Cloud autoscaling responds to sustained CPU load by adding instances, so the bill grows while the workload does nothing useful. Bills in the tens of thousands over a weekend are routinely reported.
The more serious cost is what the presence of a miner means: someone had enough access to run arbitrary code as a privileged user, and chose mining. The same access supports anything else.
Detection signals that work
Sustained CPU with no corresponding work
Mining is not bursty. It pins cores at close to 100% indefinitely. A process consuming a full core continuously while request rates are flat is the clearest single signal.
# Top CPU consumers, sorted
ps -eo pid,ppid,user,pcpu,etime,comm --sort=-pcpu | head -15
# Processes with a deleted binary on disk — common for dropped payloads
ls -l /proc/*/exe 2>/dev/null | grep deletedMining pool traffic
Miners must reach a pool, usually over the Stratum protocol on ports such as 3333, 4444, 5555 or 14444. Egress filtering catches this cheaply, and DNS logs often show pool domains before anything else is noticed.
# Established outbound connections and the processes behind them
ss -tnp state established '( dport = :3333 or dport = :4444 or dport = :5555 )'Scheduled persistence
Payloads reinstall themselves. Check cron for both the user and the system, and systemd units with unfamiliar names:
for u in $(cut -f1 -d: /etc/passwd); do crontab -l -u "$u" 2>/dev/null; done
ls -la /etc/cron.d/ /etc/cron.hourly/
systemctl list-timers --allCloud billing anomalies
A budget alert at a threshold slightly above normal spend is one of the highest-value detections available in a cloud account, and it costs nothing to configure.
Browser-based mining
A separate variant: JavaScript that mines while a page is open, either placed there by the site owner or injected through a compromised third-party script. Coinhive's closure in 2019 ended the large-scale version, but injected miners still appear on compromised sites. A Content Security Policy restricting script-src to known origins prevents the injected case, which is the one that matters.
Responding
Killing the process is not the response — it is the first thing that will be undone. Treat it as the compromise it is: identify the entry point, rotate every credential that machine could reach, rebuild rather than clean, and only then work out how the miner got there. A host that has run attacker-controlled code should not be returned to service by deleting a binary.
