Resource Hijacking

Cryptomining rarely arrives as the primary objective of a targeted intrusion. It's the monetization step that follows access an attacker already has for another reason: a webshell left after an unpatched CVE, a stolen cloud access key, an exposed Docker or Kubernetes API, or a secondary payload dropped alongside an infostealer once credentials and wallets have already been harvested. Because the miner adds detectable noise (CPU load, network egress) without buying the attacker anything toward data theft or ransomware, it's often the last stage run on a host before the operator moves on, treating the box as a disposable revenue source rather than a foothold worth protecting.

Sysdig's research on TeamTNT documented the escalation path clearly: initial access via exposed Docker APIs or vulnerable services, XMRig deployment for immediate revenue, then a pivot to harvesting AWS instance-metadata credentials to reach S3 buckets and spin up additional mining compute at the victim's cloud billing rate. TeamTNT and the competing Kinsing group both script automatic removal of each other's miners on the same host, which is itself a detection opportunity: a burst of process-kill activity immediately followed by a new systemd service is a stronger signal than either behaviour alone. For a defender, resource hijacking findings on a server are worth treating as evidence of a broader compromise, not just a nuisance to clean up.

Legitimate workloads spike CPU too: video transcoding, scientific computing, batch ETL jobs, backup compression, and CI/CD build agents can all pin cores near 100% for extended periods. A first-seen-process-plus-high-CPU rule alone will catch a lot of that, especially on build servers and data-science hosts where new binaries appear routinely as part of normal deployment.

The differentiator is destination and command-line shape, not CPU percentage. A legitimate render job doesn't open a Stratum connection to a mining pool domain, and a backup process doesn't take --algo= or --coin=monero as arguments. Allow-list your known batch-compute and CI hosts for the CPU-spike rule, then require the DNS-to-mining-pool or command-line-pattern match to fire regardless of host, since that combination has almost no benign explanation. For cloud environments, tie the alert to unexpected instance-type families (a webapp account suddenly launching GPU instances) rather than raw compute spend, which swings normally with legitimate scaling events.

First, confirm what's actually running: pull the full command line and binary hash, check whether the process was signed or matches a known package, and see whether the DNS or connection destination resolves to a documented mining pool. If the binary is XMRig or a renamed fork with a stratum:// URI, you're not debating intent. Next, check how it got there: a new cron entry, a new systemd unit, a container image pulled from an unfamiliar registry, or a webshell dropped through a known CVE all tell you whether this is an isolated drop or a symptom of a wider compromise.

Kill the process and remove its persistence (cron entry, systemd unit, container) once you've captured the artifacts you need for the investigation; miners rarely have anti-forensic tripwires, so there's little cost to acting immediately versus waiting. If the host is a cloud instance, rotate any IAM credentials the instance could reach through metadata before you consider the incident closed, since resource hijacking is frequently the visible symptom of a credential compromise that also grants broader account access. Escalate to a full compromise investigation, not just a cleanup ticket, whenever the miner shows up alongside worm-style behaviour (killing competing processes, scanning for other hosts) or on any system that shouldn't have external network egress at all.