Resource Hijacking

Attack (MITRE ATT&CK T1496) in which an adversary uses a compromised system's compute, bandwidth, or services for their own tasks — from cryptojacking to LLMjacking.

Resource Hijacking is an attack in which an adversary uses the compute power, network bandwidth, or services of a compromised system to run their own resource-hungry tasks — without the owner’s consent and usually without their knowledge. In MITRE ATT&CK (a widely used map of attacker methods) it is listed as technique T1496 in the Impact group, because excessive resource use can slow down — and sometimes outright stall — a system or service. The most common forms are cryptojacking (cryptocurrency mining), proxyjacking (reselling someone else’s bandwidth), cloud service abuse, and — increasingly — LLMjacking (stealing access to AI models).

How does Resource Hijacking work?

The goal is always the same: turn someone else’s resources into a free supply of compute or bandwidth that the attacker profits from. The victim foots the bill — electricity, cloud costs, hardware wear. The attack rarely destroys data. The harm is the hidden, parasitic consumption that can run for months before anyone notices.

It usually unfolds like this:

  1. Getting in — through stolen passwords, a web application flaw, an unsecured API (e.g. Docker, Kubernetes, Jenkins), a misconfigured cloud, or phishing.
  2. Dropping the payload — installing mining software (e.g. XMRig), a proxy-network client, an in-browser script, or invoking a cloud service with someone else’s keys.
  3. Settling in — cron entries, systemd units, Windows services, CI/CD jobs, or containers re-created after a restart, so the attack survives.
  4. Working quietly — the miner or proxy process runs in the background, often with throttled CPU usage, disables monitoring agents, and masks its traffic to avoid drawing attention.

What are the T1496 sub-techniques in MITRE ATT&CK?

MITRE splits Resource Hijacking into four sub-techniques, based on which resource is abused:

  • Compute Hijacking (T1496.001) — hijacking processing power, most often to mine cryptocurrency (cryptojacking). Monero (XMR) dominates here because it is anonymous and still pays off when mined on an ordinary CPU.
  • Bandwidth Hijacking (T1496.002) — hijacking the network link and reselling it through proxy networks (proxyjacking). The attacker profits by offering the victim’s link as an exit point for traffic.
  • SMS Pumping (T1496.003) — generating artificial SMS traffic (e.g. through forms that send verification codes) to rack up fees paid to a colluding operator.
  • Cloud Service Hijacking (T1496.004) — abusing cloud services, such as bulk messaging platforms (spam) or AI/LLM services, charging the cost to the victim’s account.

How does cryptojacking differ from proxyjacking and LLMjacking?

These are three variants of the same technique. What differs is the type of resource stolen and how easy each one is to spot:

  • Cryptojacking steals compute power. It is the easiest to detect, because it produces high, sustained CPU or GPU load, rising temperatures, and characteristic traffic to mining pools (the Stratum protocol, typically ports 3333, 5555 or 14444).
  • Proxyjacking steals the network link. CPU load is low, so the attack is easier to hide. The signals are unusual, long-lived outbound connections to proxy services and a rise in transfer with no clear reason.
  • LLMjacking steals access to paid AI models using stolen API keys or cloud credentials (e.g. for services like Amazon Bedrock). It installs nothing on the victim’s machine — the cost only surfaces on the cloud bill, which can reach tens of thousands of dollars a day. Watching the CPU won’t help here; you have to analyze logs (e.g. CloudTrail) and unusual calls to AI services.

The common thread is always the same: the victim pays for resources they never use, while the attacker profits from them or resells them on illicit markets.

Why are cloud, containers, and APIs the main targets?

Servers and cloud environments are the most tempting, because they hold plenty of resources and can scale elastically. The most exposed are:

  • Exposed container APIs — an unsecured Docker API or Kubernetes dashboard lets attackers deploy miners and multiply them by spinning up more containers across a cluster.
  • Cloud environments (IaaS) — stolen credentials or misconfiguration let attackers launch virtual machines and functions purely to mine.
  • CI/CD pipelines — injecting a payload into a pipeline grants both compute power and a way to spread further.
  • User machines — these are taken over directly, while browsers are hit by drive-by mining: scripts (JavaScript/WebAssembly) planted on compromised websites.

Well-known campaigns such as TeamTNT and the Rocke Group specialized in mass abuse of poorly secured cloud and container infrastructure.

How do you detect Resource Hijacking? (SOC and NDR angle)

MITRE explicitly notes that this technique cannot easily be blocked up front, because it abuses ordinary, legitimate system features. That is why detection rests on telemetry — data about what is happening in the system and on the network — and on combining several signals at once:

  • System data — sustained, unusual CPU or GPU usage that deviates from the norm, thermal spikes, unknown processes, and changes to cron, systemd, or services. The disabling of monitoring agents is itself worth treating as a sign of a breach.
  • Network data (NDR/NetFlow) — steady, low-volume outbound connections to unknown mining pools, Stratum traffic on typical ports, mining-pool domains showing up in DNS queries, and — for proxyjacking — long sessions to proxy providers. Watching the flows reveals connections you can’t see from a single machine.
  • Identity and cost anomalies (cloud) — sudden bill spikes, dev credentials used in production, unusual API calls to AI services, and review of audit logs (CloudTrail, GCP/Azure logs).
  • Combining signals — a single indicator (e.g. high CPU load) is often a false alarm. Confidence comes from pairing the load with traffic to a mining pool or with a credential anomaly.

How do you reduce the risk of Resource Hijacking?

Since the attack can’t be fully blocked, protection rests on shrinking the attack surface and detecting quickly:

  • Keep APIs (Docker, Kubernetes, Jenkins) off the public internet and require authentication on them.
  • Patch web-application flaws promptly, since they’re a common way in.
  • Apply least privilege to cloud credentials, rotate API keys, and turn on billing alerts.
  • Set a baseline for resource usage and network traffic, then watch for deviations (EDR/XDR plus NDR/flow monitoring).
  • Segment the network to make it harder to reach external pools and proxy services.

Learn more