What Is Cryptojacking?

Last verified on Nov 8, 2026.

Cryptojacking is the unauthorized use of someone else's computing power to mine cryptocurrency. CISA describes it as malicious actors hijacking the processing power of victim systems, installing cryptomining software by exploiting vulnerabilities, or running mining JavaScript in a website visitor's browser.

Mining needs a lot of processing power, and attackers prefer to spend yours. The victim pays in electricity or cloud spend, and the attacker keeps the coin.

What It Costs You

CISA lists the consequences: degraded system and network performance from monopolized CPU and bandwidth, higher power consumption and crashes, disrupted operations, and financial loss. In cloud environments the cost arrives as a bill. ATT&CK says servers and cloud-based systems are common targets because of the high potential for available resources, and that attackers may consume enough resources to make affected machines unresponsive.

ATT&CK files this under Resource Hijacking (T1496), sub-technique Compute Hijacking (T1496.001). "Cryptojacking" is the common name for the mining case.

How It Gets In

ATT&CK notes that containerized environments are targeted because exposed APIs make deployment easy, and mining can be scaled by running many containers in a cluster. Named examples include TeamTNT, which deployed mining images in Docker and infected Docker containers and Kubernetes clusters. Some mining malware also finds and kills competing malware to keep the resources for itself.

CISA adds that actors spread cryptojacking through weaponized mobile apps, botnets, and exploited flaws in applications and servers.

The entry points are the ones that apply to any intrusion: a vulnerable internet-facing service (check CISA KEV), an exposed management API, default or weak credentials, or a stolen cloud key from account takeover.

Warning Signs in Logs

ATT&CK's detection analytics for compute hijacking name the signals:

Here is an illustrative cloud audit event for the unused-region signal, an instance launched in a region the team never uses:

{
  "eventTime": "2026-11-08T03:41:10Z",
  "eventSource": "ec2.amazonaws.com",
  "eventName": "RunInstances",
  "awsRegion": "ap-southeast-3",
  "userIdentity": { "type": "IAMUser", "userName": "ci-deploy" },
  "sourceIPAddress": "203.0.113.50"
}

A launch like that is a signal because of what is missing: no ticket, no deploy, no history in that region. The check is to compare each launch against the regions and identities that normally create compute.

The bill is where the damage shows up first for many teams, and billing data lags, so put a spend alert on the account and watch CPU too. The setup is in cloud spend anomalies. For events that appear once and never again, such as an unexpected process or a new connection target, see novel events.

Prevention and Response

ATT&CK is blunt: this technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features. Prevention narrows the odds, and detection catches the rest. CISA's list includes:

• Keep software and operating systems patched.
• Use strong, unique passwords and change default credentials.
• Check privilege policies so only those who need administrative rights have them.
• Apply application allow listing so unknown executables cannot launch on their own.
• Monitor for abnormal, sustained CPU activity and investigate drops in processing speed.
• Disable unnecessary services and uninstall unused software.

For cloud and containers, add the equivalents: do not expose management APIs, restrict who can launch compute and in which regions, and alert on instance creation outside those.

When you find a miner, killing the process is not the end. It usually means someone got in. Work out how, check for other changes with privilege changes, and rotate any credentials the host could reach.

Watching Compute with Sazabi

Sazabi, an AI-native observability and security platform, ingests logs from your services and cloud accounts, so cloud audit events and host logs can be searched side by side. For where to start, see security issues.