AWS Crypto Mining Detection: Finding and Stopping Mining Before the Bill Arrives

Cryptocurrency mining is the most financially motivated form of AWS account compromise. An attacker with access to AWS credentials has a clear profit motive: launch high-CPU instances in every available region, run mining software, and collect cryptocurrency until the credentials are revoked. The profit is real and immediate; the cost is entirely your AWS bill.

AWS aggressively monitors for mining activity and will suspend accounts they believe are being used for unauthorized mining. An account suspected of mining gets suspended — with all your legitimate workloads offline — while you work through the support process to demonstrate the mining was unauthorized and not your operation. This can take days.

The goal is to detect and terminate mining within minutes of launch, before AWS detects it, before a significant bill accumulates, and before suspension becomes a risk.

How Mining Attacks Work

Crypto mining attacks follow a predictable pattern driven by the attacker's time pressure. Once credentials are obtained, the attacker:

1. Quickly checks available regions and permissions with lightweight API calls (DescribeRegions, GetCallerIdentity)
2. Launches EC2 instances in multiple regions simultaneously — often p3, p4 (GPU), or c5, c6i (high-CPU) instance types optimized for mining efficiency
3. Configures instances with user data or post-launch scripts that install mining software and point it to their pool
4. Sometimes creates new IAM users or access keys to maintain access if the original credential is revoked

The whole sequence from credential theft to running miners can happen in under 10 minutes. The time between "attacker has credentials" and "instances are mining" is shorter than most manual alert response times, which is why automated detection and automated or near-automated response is essential.

GuardDuty: The Fastest Detection

GuardDuty generates findings for crypto mining activity within minutes of detection:

• CryptoCurrency:EC2/BitcoinTool.B: EC2 instance communicating with Bitcoin-related mining pools
• CryptoCurrency:EC2/BitcoinTool.B!DNS: DNS queries to cryptocurrency mining domains
• Execution:EC2/MaliciousFile: malware execution detected on an instance (including some mining malware)

GuardDuty correlates IP traffic and DNS queries against threat intelligence to identify mining pool communications. This detection happens even if the mining software uses obfuscated domain names or hops through proxies — the threat intelligence is updated continuously.

Configure GuardDuty's HIGH-severity findings to trigger immediate PagerDuty or SMS alerts. CryptoCurrency findings should have an automated response: EventBridge rule → Lambda function that terminates the mining instances and notifies the security team. The Lambda function can also automatically request the API call that launched the instances from CloudTrail to identify the compromised credential, and disable it. Automated response within 60 seconds of GuardDuty detection limits mining runtime to under 2 minutes.

CloudTrail Indicators Before Mining Starts

GuardDuty detects mining after instances are running and making network connections. CloudTrail can detect the launch pattern before mining software begins communicating:

Alert on RunInstances calls for high-powered instance types from unexpected principals. The threshold for "unexpected" is your organization-specific normal: if your infrastructure automation role launches c5 instances regularly, that's expected; the same instance type from a developer's personal access key is not.

Alert on RunInstances calls from unusual geographic locations. A CloudTrail event with a sourceIPAddress in a region where you have no employees or infrastructure is worth immediate investigation. Combine this with instance type filtering to reduce false positives.

Alert on RunInstances calls in multiple regions within a short time window. Legitimate workload launches are typically regional; an attacker launching instances in 5 regions within 60 seconds is a strong signal.

Billing Anomaly Detection as a Backstop

Billing anomaly detection is slower than CloudTrail and GuardDuty — cost data arrives with multi-hour delay — but provides a backstop for detection failures. Configure AWS Cost Anomaly Detection with a low threshold for EC2 spend. An account where EC2 spend triples overnight should trigger an alert even if GuardDuty missed the mining activity.

The practical value of billing detection is catching mining that occurred through a vector your other detections missed: a region where GuardDuty wasn't enabled, a mining pool that GuardDuty's threat intelligence didn't yet recognize, or a gradual ramp-up that didn't trigger threshold-based GuardDuty rules. See billing anomaly detection configuration for threshold setup.

Prevention: The Access Key Problem

Most crypto mining attacks start with stolen IAM access keys. The most effective prevention is reducing the number of long-lived access keys in your environment:

• EC2 instances, Lambda functions, and ECS tasks should use IAM roles, not access keys. Roles have temporary credentials that rotate automatically and can't be stolen from code repositories.
• CI/CD systems should use OIDC federation with GitHub Actions, GitLab CI, or similar to get temporary credentials without long-lived keys.
• Audit all existing access keys and delete any that aren't actively needed. Rotate all remaining keys every 90 days.
• Enable GitGuardian, GitHub's secret scanning, or similar tools to detect keys committed to repositories before they're exploited.

Use SCPs to deny launches of high-powered GPU instance types (p3.*, p4d.*) except from your infrastructure automation role. Most organizations don't have legitimate uses for GPU instances from every IAM principal — an SCP that restricts these instance types to approved roles significantly limits the damage from credential compromise.

Related Reading

• GuardDuty setup — enabling the primary mining detection tool
• Detecting unauthorized EC2 instances — the launch detection layer that catches mining before it starts
• Why AWS accounts get suspended — how mining leads to suspension
• CloudTrail alerting — real-time alerts on mining-related API patterns

FAQ

Will AWS detect mining activity in my account even if GuardDuty is disabled?

Yes. AWS monitors all accounts for Acceptable Use Policy violations including unauthorized mining, regardless of whether you have GuardDuty enabled. GuardDuty is your own detection; AWS's detection exists independently. The problem is that AWS detecting mining leads to account suspension, while your own detection leads to termination of the mining instances. You want to detect it yourself first.

If I terminate unauthorized mining instances, will my account be suspended?

Terminating the instances reduces the risk of suspension, but if AWS has already flagged your account for AUP review, the suspension may still occur. File a proactive AWS Support case explaining the situation: your credentials were compromised, you've terminated the unauthorized instances, you've revoked the compromised credentials, and you're requesting confirmation that your account is in good standing. Proactive communication with AWS Support typically prevents suspension in cases where the account owner clearly didn't initiate the mining.

How can I verify whether my account has been used for mining?

Check GuardDuty findings for any CryptoCurrency finding type. Review CloudTrail for RunInstances calls you didn't initiate, particularly in regions you don't normally use. Check EC2 running instances across all regions for instances you don't recognize. Review your last 30 days of billing in Cost Explorer for EC2 compute charges in unexpected regions or for instance types you don't use. Any of these is sufficient to trigger an investigation.