Someone Else Is Mining Crypto on Your Dime — And Your Cloud Dashboard Is Hiding It

You didn't notice anything wrong. Your applications were running fine. Users weren't complaining. The alerts were quiet. Then your AWS bill landed — and it was three times what you budgeted.

Welcome to the world of silent cryptojacking, the cybersecurity threat that doesn't crash your systems, doesn't steal your data, and doesn't trigger your endpoint detection tools. It just quietly burns through your cloud compute budget while generating cryptocurrency for someone sitting in a completely different country.

This isn't a niche problem. Cloud cryptomining campaigns have been documented against organizations of every size, from scrappy startups running a handful of EC2 instances to Fortune 500 enterprises with multi-cloud architectures sprawling across three providers. And the reason it keeps working? The cloud itself makes it almost perfectly suited for abuse.

Why the Cloud Is the Perfect Cryptomining Playground

Let's talk about what makes cloud infrastructure so attractive to cryptojackers specifically — because it's not just about compute power.

Traditional cryptojacking, where an attacker compromises a physical workstation or server, carries real risk. The machine slows down. Fans spin up. Someone notices. Someone complains. IT gets involved.

Cloud instances don't have that problem — at least not from the victim's perspective. When an attacker spins up mining processes inside a compromised cloud VM, the CPU and memory spikes don't manifest as a sluggish laptop on someone's desk. They manifest as a line item in a billing report that most engineers don't scrutinize until the end of the month. By then, the attacker has had weeks of uninterrupted compute time.

The abstraction layer of cloud environments also complicates visibility. In a traditional on-premise setup, a security team can walk over to a server, pull logs, run a process list, and see what's running. In a cloud environment, especially one leveraging containers, serverless functions, or auto-scaling groups, the attack surface is fluid. Instances spin up and down. Processes come and go. What looked like a mining process at 2 AM on Tuesday might be gone before your SOC analyst starts their shift.

How Attackers Get In

The entry vectors for cloud cryptomining campaigns aren't exotic. They're embarrassingly mundane, which is part of why they're so effective.

Exposed credentials are the single biggest culprit. AWS access keys accidentally committed to public GitHub repositories, misconfigured IAM roles with overly permissive policies, stolen credentials harvested from developer machines through phishing — all of these give attackers a foothold that looks entirely legitimate from the cloud provider's perspective. They're not breaking in. They're logging in.

Misconfigured services are a close second. Kubernetes dashboards left exposed to the internet without authentication, Docker APIs accessible without TLS, Elasticsearch clusters with no access controls — these have all served as entry points for cryptomining campaigns in documented incidents. The TeamTNT threat group, for example, built an entire operational playbook around hunting exposed Docker and Kubernetes APIs at scale.

Vulnerable container images pulled from public registries round out the top three. When a developer pulls a base image from Docker Hub without verifying its integrity, they might be importing a mining payload that activates the moment the container spins up. Supply chain risk in cloud-native environments is real, and cryptomining is one of the more financially motivated ways attackers exploit it.

The Forensic Fingerprints You Should Be Looking For

Here's where it gets practical. If you're a security engineer or a threat hunter trying to figure out whether your environment has been touched, there are specific indicators worth pursuing.

Unusual outbound network connections are often the first signal. Cryptomining operations require communication with mining pool servers, and those connections have recognizable patterns — persistent, low-bandwidth, and often directed at known mining pool infrastructure. Tools like Stratum protocol traffic over port 3333 or 14444 are a dead giveaway if you're capturing and analyzing network flow data.

CPU utilization anomalies matter, but context is everything. A spike in CPU usage on an instance running a data processing job is expected. The same spike on an instance that should be sitting idle at 3 AM is worth investigating. Set up CloudWatch (or the equivalent in your cloud provider) to alert on sustained high CPU across instances that don't have a legitimate workload justification.

Unexpected process names and binary hashes are critical if you can get to them. Mining software like XMRig has well-documented binary signatures, though attackers routinely rename executables and modify code to evade hash-based detection. Look for processes with names that don't match anything in your approved software inventory. Better yet, maintain a baseline of what should be running in each environment type and alert on deviations.

New or modified cron jobs and systemd services are a persistence mechanism attackers love in Linux-based cloud instances. After gaining access, a threat actor will almost always establish persistence before launching the mining payload. Hunting for recently modified cron tabs or unfamiliar systemd unit files can surface infections that the mining process itself has been designed to hide.

IAM activity anomalies in your cloud provider's logs can also surface cryptomining intrusions, particularly if the attacker used stolen credentials to spin up additional instances to scale their operation. Look for API calls that create new compute resources, especially from unfamiliar IP addresses or at unusual hours.

The Billing Anomaly You're Probably Ignoring

Let's be direct: most organizations don't have meaningful cloud cost anomaly detection in place. They set a budget, they get a bill, and unless something is wildly off, finance signs off and moves on.

Attackers know this. Sophisticated cryptomining campaigns are increasingly calibrated to stay below the threshold that would trigger a billing alarm. Rather than maxing out every instance at 100% CPU and generating a bill that doubles overnight, they'll run mining processes at 40-60% utilization — enough to generate meaningful revenue from cryptocurrency, not enough to cause a visible system performance problem or a catastrophic cost spike.

This is why cost monitoring alone isn't sufficient. You need behavioral monitoring at the workload level, combined with network traffic analysis and log-based threat hunting. Cloud-native security tools like AWS GuardDuty, Microsoft Defender for Cloud, and Google's Security Command Center have improved significantly at detecting cryptomining-specific indicators, but they're not a silver bullet — and they need to be properly configured and actively reviewed.

What to Do Right Now

If you're reading this and realizing your environment might be more exposed than you thought, here's a starting point that doesn't require a six-month security transformation project.

Audit your exposed services first. Run a scan against your cloud environment looking for any services accessible from the public internet that shouldn't be. Focus especially on management interfaces, container orchestration dashboards, and any API endpoints without authentication.

Rotate and audit your credentials. Pull a report of all IAM users, roles, and access keys. Identify anything that hasn't been used in 90 days and disable it. Look for access keys that were created but never used — those are often the result of accidental commits that were caught and deleted from the repo, but the key itself was never rotated.

Enable your cloud provider's native threat detection if you haven't already. GuardDuty, for example, has specific finding types for cryptocurrency mining activity. It's not free, but it's significantly cheaper than discovering a month-long cryptomining campaign on your next billing statement.

The attackers running these campaigns aren't particularly sophisticated. They're opportunistic, and they're betting that your environment is misconfigured and under-monitored. More often than not, they're right. The good news is that the same lack of sophistication that makes these attacks common also makes them detectable — if you're actually looking.