Stop AWS Cryptomining Fast With AI Credential Defense

A cryptomining attack that takes about 10 minutes from initial access to running miners isn’t “advanced hacking.” It’s ops. The hard part for the attacker is getting in; once they have valid AWS IAM credentials, the rest can look like routine cloud administration—until your bill explodes.

That’s why this week’s AWS-reported cryptomining campaign is such a useful case study for our AI in Cybersecurity series. The attackers didn’t break AWS. They broke the part most organizations still underinvest in: identity behavior monitoring and automated response.

If your detection depends on a human spotting a weird EC2 launch two hours later, you’ve already lost. The only practical defense against “credential-to-crypto in minutes” is real-time anomaly detection, paired with automated containment that acts faster than an attacker can scale.

What this AWS cryptomining campaign tells us (and why it’s different)

The core lesson is simple: stolen credentials turn cloud APIs into an attacker’s control plane. In this campaign, the threat actor used compromised IAM credentials to access customer environments and then abused legitimate services—primarily Amazon EC2 and Amazon ECS—to mine cryptocurrency.

What made this campaign stand out wasn’t just speed. It was discipline:

• Recon that blends in: Checking EC2 quotas and validating permissions with DryRun calls is a smart way to confirm access without immediately launching costly resources.
• Multi-service abuse: Using both EC2 and ECS increases blast radius and gives the actor flexibility.
• Persistence designed to slow you down: Enabling termination protection (“disable API termination”) adds friction to incident response and can break naïve auto-remediation.

Here’s the uncomfortable truth: in many environments, this activity looks like a busy engineer automating infrastructure. That’s exactly why AI-powered cloud threat detection matters.

The shared responsibility model doesn’t save you from shared credentials

AWS emphasized that there was no AWS infrastructure vulnerability being exploited. The attacker used valid, stolen credentials to operate inside the customer’s security boundary.

This is where teams get stuck: “We have GuardDuty” becomes “We’re covered.” But cloud-native detections are only half the story. You also need:

• identity-centric detections (who is acting “out of character”?)
• cross-account context (is this pattern showing up elsewhere?)
• response automation that doesn’t require a ticket and a meeting

How attackers go from stolen IAM keys to miners in ~10 minutes

The attack chain matters because it tells you exactly what to detect—and what to automate.

Phase 1: Permission discovery that avoids footprints

The actor started with external probing using compromised IAM credentials, then:

• Queried EC2 service quotas (GetServiceQuota) to learn how big they could scale.
• Called RunInstances with the DryRun flag multiple times to validate permissions without deploying.

Defender takeaway: “DryRun storms” are a behavioral signal. Most legitimate automation doesn’t repeatedly test the same launch path from a new network origin unless something’s broken.

Phase 2: Creating roles that make the attack easier to run (and harder to unwind)

The actor created IAM roles that supported scaling and automation, including:

• CreateServiceLinkedRole (used for autoscaling-related operations)
• CreateRole for Lambda
• Attached AWSLambdaBasicExecutionRole

Defender takeaway: Role creation plus policy attachment is common in real cloud work. The difference is context: new principals, unusual source IPs/ASNs, odd timing, and sequences that don’t match your team’s deployment pipelines.

Phase 3: Fast deployment across EC2 and ECS

Once setup was complete, miners were deployed across EC2 and ECS and operational quickly. AWS also noted a malicious container image used for mining that was hosted publicly (and later removed).

Defender takeaway: Container image pull + sudden compute expansion + unusual egress to mining pools is a classic combo. You need detections that correlate these signals, not treat them as isolated alerts.

The persistence trick that slows incident response

The campaign used ModifyInstanceAttribute to set termination protection (“disable API termination”) to true. That means your cleanup scripts may fail, and responders have to explicitly re-enable termination before deleting resources.

This matters because cloud incident response is often built on two assumptions:

1. We can terminate what we didn’t approve.
2. Our automation will work the same way every time.

Termination protection breaks both assumptions.

What AI can do here that static rules often can’t

Static rules might catch “termination protection enabled,” but they often miss why it’s suspicious.

An AI-driven detection approach can flag it based on patterns like:

• the principal enabling termination protection has no history of doing so
• the action follows a short sequence of quota checks → DryRun → role creation → compute launch
• the activity is coming from a never-seen-before network origin

That sequence-level understanding is where machine learning and graph-based analytics shine.

AI-powered detection: the only realistic way to beat the clock

If the attacker can deploy miners in 10 minutes, your detection and response loop has to be shorter than 10 minutes.

That’s not a staffing problem. It’s a systems problem.

1) Behavioral baselining for cloud identities

The most valuable AI model for this scenario isn’t “malware classification.” It’s identity behavior analytics:

• What does this IAM role normally do?
• Which regions does it operate in?
• Which services does it touch?
• What’s the usual time-of-day pattern?
• What source networks does it use?

When stolen credentials are used, the attacker typically introduces at least one anomaly: new region, new IP space, new API sequence, new resource types, or new velocity.

A practical stance: treat IAM keys like credit cards. If spending patterns change abruptly, block first and investigate second.

2) Sequence detection (attack-chain logic, not single-event alerts)

This campaign is a great example of why single-event alerts are noisy:

• RunInstances happens constantly.
• CreateRole happens in legitimate automation.
• Even quota checks happen during scaling work.

But the ordered sequence within a short window—especially from a new identity or origin—is a strong signal.

What works well in the field is combining:

• time-window correlation (e.g., 5–15 minutes)
• rare action scoring (how often does this principal do CreateServiceLinkedRole?)
• graph relationships (principal → role → policy → compute resources)

3) Automated response that contains without breaking production

Automation fails when it’s too aggressive. The goal is safe containment.

A solid AI-assisted playbook for suspected cryptomining via stolen AWS credentials looks like this:

1. Step-up authentication / session disruption
   • Revoke active sessions for the suspected principal.
   • Rotate access keys immediately.
2. Contain identity permissions
   • Attach a temporary “deny all except incident response” policy boundary.
   • Remove high-risk permissions (IAM write, EC2/ECS launch) if your tooling supports safe rollback.
3. Stop cost bleed fast
   • Quarantine or stop newly launched instances matching the suspicious time window.
   • For ECS, scale services to zero in a quarantine cluster/account.
4. Handle termination protection explicitly
   • Detect it and auto-remediate by re-enabling termination where policy allows.
5. Preserve evidence
   • Snapshot instance metadata, user-data, and container task definitions before deletion.

AI’s role isn’t to “auto-delete everything.” It’s to choose the safest containment action based on confidence and blast radius.

What to monitor right now (high-signal checks)

If you’re a cloud security lead and want fast wins, focus on monitoring that’s hard for attackers to avoid.

CloudTrail signals that deserve high priority

• Repeated RunInstances calls with DryRun=true
• CreateRole, CreateServiceLinkedRole, and rapid policy attachment events
• ModifyInstanceAttribute enabling termination protection, especially on recently created instances
• Sudden spikes in RunTask (ECS) or new task definitions pulling unfamiliar images

Cost and infrastructure signals that catch cryptomining early

• Sudden increase in GPU-optimized instance families or high-CPU instance launches
• Unusual Spot instance usage patterns (attackers love Spot for cheaper compute)
• New autoscaling groups or scaling policies created outside deployment pipelines

Network signals: mining pools and lookalikes

Mining campaigns often rely on known pool infrastructure or short-lived domains. Even when the exact domains change, the pattern doesn’t:

• persistent outbound connections to a small set of hosts
• high throughput and long-lived TCP sessions
• connections that begin minutes after instance creation

This is where AI helps again: it can cluster “pool-like” behavior even when indicators change.

Hardening AWS against stolen credentials (the controls that actually matter)

The campaign is fundamentally an identity failure, so the fixes are identity-first.

Make long-term credentials rare (and painful to misuse)

• Prefer temporary credentials over long-lived access keys.
• Restrict who can create access keys at all.
• Alert on access keys that haven’t been used for 30–90 days suddenly being used again.

Require MFA—and enforce it where it counts

MFA isn’t a checkbox if your high-privilege paths still work without it. Enforce MFA for:

• IAM changes (role creation, policy attachment)
• key management actions
• privilege escalation paths

Reduce permissions to shrink the attacker’s menu

Most companies say “least privilege” and then keep wildcard permissions because it’s convenient.

A more realistic approach I’ve found works:

• start by removing IAM write permissions from day-to-day roles
• separate “builder” roles (CI/CD) from “operator” roles (runtime)
• put permission boundaries on roles that can create roles

Centralize logs so AI can see the full story

AI detection is only as good as the telemetry. Aggregate CloudTrail and related logs into a central account, keep retention long enough to spot slow credential theft, and make sure you’re collecting:

• identity events
• network flow data where feasible
• container and instance launch metadata

Practical Q&A (what security teams ask after reading this)

“If the credentials are valid, how do we tell attacker from employee?”

By behavior and sequence. Employees are consistent; attackers are opportunistic. AI models built on identity baselines and API-call chains can flag “valid but wrong” activity fast.

“Is cryptomining just a cost issue?”

No. It’s also a sign of account takeover. The same access used to mine can be used to exfiltrate data, plant backdoors, or pivot into other cloud services.

“What’s the fastest way to reduce risk this week?”

Kill long-lived access keys where you can, enforce MFA for privileged actions, and implement an automated playbook that can contain suspicious compute launches within minutes.

Where this fits in the AI in Cybersecurity story

This AWS cryptomining campaign is a clean example of a broader trend: attackers don’t need exotic exploits when identity is the soft target. As cloud environments get more complex, human review and static rules don’t scale—especially when the attacker’s timeline is measured in minutes.

If you want a practical next step, focus your AI investments on two outcomes: detect anomalous credential use in real time and automate safe containment before compute scales. That’s how you stop cryptomining attacks before they become a line item your CFO notices.

What would you catch in your environment first: the stolen credential, the unusual API sequence, or the cost spike after the miners are already running?