5 Signals That Catch Cloud Cryptojacking Before the Invoice

Unauthorized cloud cryptojacking is a billing event before it is a security event: the attacker’s workload burns compute you pay for, and that consumption leaves a trace in spend telemetry hours before anyone triages an alert. The dependable way to catch it is to wire five signals — cost anomalies, DNS and network patterns, runtime process telemetry, resource metrics and configuration drift — into a single escalation path. The economics alone justify the effort: a cryptominer campaign documented by Netlify mined only around $6,500 in cryptocurrency for its operators yet was estimated to cost victims upwards of $20,000 – $30,000 a month in wasted cloud spend while active, meaning victims collectively paid several times more than the attackers ever earned.

Why spend telemetry detects mining

Miners are volume businesses. An attacker holding stolen credentials wants as many CPU-hours or GPU-hours as possible before the keys are revoked, and every one of those hours is metered and billed to you. That makes spend unusually hard to spoof compared with log-based indicators, which skilled operators throttle, rename or time to off-peak windows. Google’s own threat research underlines how dominant this attack pattern has become in container estates, reporting that 86% of attacks observed in container environments stem from cryptojacking, ahead of every other container attack category measured in that dataset. The same dynamic that makes mining profitable for the intruder — relentless, sustained consumption — is exactly what makes it visible in cost curves, provided somebody is watching them.

Five signals worth monitoring

No single signal is conclusive on its own; a batch job can spike CPU, and a data migration can spike spend. Correlation across the five signals below is what separates a mining incident from a legitimate workload change, and each one has a different detection latency you should plan around.

Configuring AWS cost monitors

On AWS, the starting point is Cost Anomaly Detection, which evaluates net unblended cost with machine learning that accounts for seasonality and organic growth, so a Friday batch run does not page anyone. Know its cadence before you rely on it: AWS Cost Anomaly Detection runs approximately three times a day against net unblended costs, and because it consumes Cost Explorer data it can take up to 24 hours to detect an anomaly after a usage occurs. A brand-new service subscription also needs about ten days of history before its anomalies become detectable, so pair the monitor with hard budget alarms during that blind window. Out of the box, an alert fires only when anomalous spend exceeds both 40% of expected spend and a fixed minimum of $100 — thresholds tuned to avoid noise across all customer sizes. For accounts running GPU instances or spot fleets, that floor is far too generous: create customer-managed monitors per environment with tighter thresholds, route alerts through SNS into the same channel your security on-call watches, and treat a matched pair of cost anomaly plus GuardDuty finding as a single incident.

GuardDuty network and runtime findings

Cost telemetry tells you something is consuming resources; threat detection tells you what. The classic indicators of cryptomining are connections to known mining pool ports such as 3333, sustained high CPU or GPU usage that does not align with normal operations, and DNS queries to domains associated with crypto activity — patterns GuardDuty surfaces through findings like CryptoCurrency:EC2/BitcoinTool.B for direct mining-pool communication and its DNS-based variant for domain resolution. Enabling Runtime Monitoring extends coverage inside the workload, catching the miner binary at execution time even when operators rename it or tunnel traffic. Google Cloud’s Container Threat Detection plays the equivalent role in GCP estates, raising findings when a container process communicates over the Stratum protocol commonly used by mining software. Because miners frequently arrive via leaked static keys, the exposure paths overlap heavily with the hygiene gaps covered in S3 bucket exposure prevention controls, and remediating those is cheaper than detecting the aftermath.

Response workflow when alerts fire

Speed matters more than elegance: every hour of delay is metered compute on your invoice. A workflow that survives a real 2 a.m. page looks like this:

1. Confirm the anomaly source in Cost Explorer, filtered to service, account and usage type ranked by dollar impact.
2. Correlate with GuardDuty findings and CloudWatch metrics for the same window and affected resources.
3. Snapshot volatile evidence — process list, network peers, IAM activity in CloudTrail — before destroying anything.
4. Isolate or terminate the implicated instances, then rotate every credential the compromised identity could reach.
5. Close the entry path: the exposed keys, the public bucket, or the over-permissive role that enabled the launch.

Automating steps three and four with EventBridge and Lambda shrinks containment from hours to minutes, which on a large GPU fleet is the difference between a rounding error and a five-figure line item. Teams that want the full groundwork — egress defaults, credential hygiene, logging decisions — should start from the cloud security baseline for the first 90 days and add the mining-specific monitors on top of it.

Sources

• Netlify Threat Intelligence Brief: Anatomy of an Abusive Cryptominer Campaign
• Detecting Cryptojacking Containers Using eBPF-Based Security Runtime and Machine Learning (Electronics, MDPI)
• AWS Documentation — Detecting unusual spend with AWS Cost Anomaly Detection
• AWS Cost Anomaly Detection FAQs
• AWS Security Blog — Detecting and preventing crypto mining in your AWS environment