loader
high risk Endpoint / Cloud compute / Network current

Cryptojacking and Self-Propagating Malware

Two consequences of the same access: quietly spending your compute for the operator's benefit, or spreading automatically to everything reachable.

Defender-oriented briefing. This page describes behavior, observable signals, prevention and response. Operational attack instructions are intentionally excluded.

How it works

Stolen access is used to run sustained high-resource workloads that earn the operator money, or propagation is embedded into the payload so exploitation and credential abuse spread without operator involvement.

The quiet one and the fast one

These two behaviours sit together because they are what an attacker does with access when the goal is neither theft nor extortion. One is deliberately quiet and open-ended; the other is deliberately fast and indiscriminate.

Cryptojacking wants to remain undetected indefinitely, because revenue accrues with time. Worms want to reach as many systems as possible before anyone reacts, because reach is the objective.

Both are frequently treated as lesser incidents — no data was taken, nothing was encrypted. That reading is a mistake for the same reason in each case: the access that permitted them permits anything else too.

Cryptojacking is a credential alarm

In cloud environments cryptojacking is usually the visible symptom of leaked credentials. The bill is the detection mechanism, which is a poor one — it arrives late and lands with finance rather than security.

The right response is to treat compute abuse as evidence of credential compromise rather than as a cost problem. Someone had enough access to create resources; mining is simply what they chose to do with it, and it is the least damaging option available to them.

Detection worth having: alerting on spend rate and on resource creation outside deployment workflows, both as security signals with an owner. Instances appearing in unused regions is a particularly reliable indicator, because legitimate deployments rarely wander.

On endpoints the equivalent signal is sustained maximum utilisation with no corresponding user activity, often throttling when a user is present specifically to avoid notice.

Worms and the speed problem

Self-propagating malware embeds spread into the payload: each compromised host scans, exploits or authenticates onward automatically. Growth is exponential and operator-independent, which means it continues even if the operator does nothing.

The defining constraint is time. A human-driven response cannot outpace automated propagation across a flat network, so containment must be automatic — EDR-driven isolation that quarantines a host on detection without waiting for a decision.

Segmentation is the structural control. Propagation requires reachability, and a network where every host can reach every other host on administrative ports is a network built for this. Disabling unnecessary lateral services is frequently more effective than patching faster, because it removes the path rather than one vulnerability in it.

Shared lessons

Both categories reward the same preparation, which is worth noting because neither is usually what an organisation is planning for.

Know what normal resource consumption looks like, per host and per account, so an anomaly is visible without a signature. Restrict lateral reachability so an automated spread has a small perimeter. And treat any unexplained compute — a process, a container, an instance — as unauthorised access rather than as a performance issue, because the question that matters is not what it is doing but how it got there.

Also known as

cryptomining malware worm self-propagating malware

What defenders may observe

  • Unexplained CPU, GPU or cloud cost growth
  • Mining pool or unfamiliar workload traffic
  • Short-lived compute resources created outside deployment workflows
  • East-west scanning surges from one host
  • Similar failures appearing across many hosts in a short window

Prevention and mitigation

  • Alert on cloud spend and compute anomalies as security signals
  • Allow-list workloads and monitor runtime behaviour
  • Rotate any exposed cloud credential immediately
  • Segment networks and disable unnecessary lateral services
  • Patch rapidly on internet-facing and lateral-movement paths
  • Automate host isolation so spread is contained without waiting for a human

Initial response priorities

  • Isolate affected systems without destroying volatile evidence.
  • Activate the incident-response and continuity plans.
  • Scope initial access, persistence, lateral movement and affected identities before recovery.

Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.

Authoritative references

MITRE ATT&CK — Enterprise Techniques