AI Cloud Defense: Stop AWS Crypto Mining Fast

A compromised IAM credential can turn into a five-figure AWS bill before your first incident-response meeting even starts. In a recent AWS crypto mining campaign, attackers got from “valid login” to “miners running” in about 10 minutes—and they didn’t need a cloud vulnerability to do it.

Most teams still treat identity events (new roles, API calls, weird quotas) as low-signal noise until something breaks. That’s backwards. In cloud environments, identity is the control plane, and crypto miners are the easy “profit now” payload that proves how quickly attackers can monetize access.

This post is part of our AI in Cybersecurity series, and it uses this real-world AWS campaign to show a practical point: AI-driven anomaly detection is one of the few defenses fast enough to matter when valid credentials are abused at scale.

What happened in this AWS crypto mining campaign (and why it worked)

Attackers succeeded because they behaved like automation: quick discovery, rapid provisioning, and persistence designed to slow you down. The campaign observed by AWS security tooling started with compromised IAM user credentials that had admin-like permissions.

Once inside, the attacker moved through a short, efficient chain:

• Discovery at API speed: They enumerated permissions and environment limits (especially compute quotas).
• Permission testing without launching instances: They used the EC2 RunInstances API with the DryRun flag. That’s the tell: it confirms what they can do without creating resources or immediate cost signals.
• Resource deployment across services: They spun up mining via ECS (Fargate) and EC2, creating large numbers of clusters (in some cases 50+ in one environment).
• Persistence and response friction: They toggled instance termination protection by calling ModifyInstanceAttribute with disableApiTermination=True, making “delete the miner” harder and slower.

Here’s the uncomfortable truth: nothing about this requires novel malware. It’s mostly cloud-native abuse.

Why crypto mining is still a top cloud attacker move

Crypto mining campaigns persist because the economics are straightforward:

1. Low operational risk compared to ransomware (no negotiation, no noisy encryption phase).
2. Fast time-to-cash once compute is online.
3. Blends into “normal cloud activity” if your baseline is weak.

Teams often detect miners only after:

• Spend alarms trigger,
• performance degrades,
• engineers notice runaway autoscaling,
• or GPU instances appear “mysteriously.”

By then, the attacker has already won the first round.

The attacker tradecraft you should actually model in detections

A lot of cloud detection programs focus on “bad IPs” and “known malware hashes.” That’s not where this fight is. This campaign highlights several behaviors that make excellent detection anchors.

1) DryRun usage as an early-stage signal

The purposeful use of DryRun is a gift to defenders. It’s rarely used in day-to-day operations at scale, and when it appears suddenly—especially from a principal that doesn’t normally perform infrastructure provisioning—it’s an early intent signal.

Detection stance: treat bursts of DryRun calls (especially RunInstances) as suspicious unless explicitly tied to known automation pipelines.

2) Sudden creation of service-linked roles and new IAM roles

The campaign used CreateServiceLinkedRole and CreateRole, then attached policies like AWSLambdaBasicExecutionRole. This is how attackers set themselves up for durable access and multi-service execution.

Detection stance: new roles + new policy attachments + unusual trust relationships (or overly broad permissions) should be correlated, not reviewed as isolated events.

3) ECS cluster explosions and suspicious task definitions

Creating dozens of ECS clusters and registering a task definition that pulls an unfamiliar container image is classic “burst provisioning.” It doesn’t look like steady-state platform engineering.

Detection stance: alert on cluster count spikes, new task definitions that request high CPU, and images not previously seen in your environment.

4) Autoscaling ranges that scream “abuse”

Scaling targets like 20 to 999 instances aren’t “misconfiguration.” They’re an attempt to consume quotas and maximize mining throughput.

Detection stance: policy guardrails should reject absurd scaling parameters, and detection should flag any change that expands scaling beyond approved ranges.

5) Termination protection used as anti-response

disableApiTermination=True is a smart move by attackers because it directly attacks your playbooks and auto-remediation.

Detection stance: any enablement of termination protection outside a narrow allowlist should page someone. It’s rare in many orgs—and it’s high-impact when abused.

Snippet-worthy rule: When valid credentials are abused, the “malicious artifact” is the API sequence—not the malware binary.

Where AI-driven anomaly detection fits (and where it doesn’t)

AI helps most in cloud incidents when it’s doing two things humans can’t do fast enough: baseline normal behavior and correlate weak signals across services.

This campaign is a clean example. Each event alone can look plausible:

• a DryRun call,
• a new IAM role,
• a new ECS cluster,
• a new autoscaling group.

But together, in a short time window, they describe an obvious story.

What AI can catch early in this scenario

A well-tuned AI security monitoring system (or “AI SOC” workflow) should be able to flag:

• Impossible speed: environment enumeration + role creation + compute provisioning in minutes.
• Novel combinations: a principal that historically reads S3 suddenly creating ECS clusters and autoscaling groups.
• Behavioral drift: admin-like API calls from a user that normally performs narrow tasks.
• Cross-service correlation: IAM → ECS → EC2 → Lambda events tied to the same identity/session.

The practical outcome is earlier containment: not “after the bill,” but before scaling ramps.

Where AI won’t save you

AI can’t fix foundational identity mistakes:

• long-lived access keys sitting in repos,
• over-privileged IAM users,
• no MFA,
• missing CloudTrail coverage,
• noisy environments with no asset ownership.

If your identity layer is messy, AI will still alert—but you’ll drown in alerts.

A practical defense plan: hardening + AI monitoring + response automation

Most companies get this wrong by investing only in monitoring. You need three layers that reinforce each other.

1) Identity hardening that removes “easy mode” for attackers

Start here because it reduces both breach likelihood and blast radius.

• Eliminate long-term access keys wherever possible. Prefer short-lived, automatically rotated credentials.
• Enforce MFA for all human IAM users (and remove console access where it isn’t needed).
• Apply least privilege aggressively. If a principal can create IAM roles and provision compute, assume it’s a future incident.
• Use permission boundaries / SCPs to prevent risky actions even for powerful roles.

If you do only one thing: block or tightly gate role creation and policy attachment. That’s where cloud breaches become cloud takeovers.

2) AI-powered anomaly detection tuned to cloud control-plane behavior

To make AI detection actionable, define a small set of high-signal behaviors and let AI baseline the rest.

High-signal rules to feed and tune:

1. RunInstances:DryRun bursts or any DryRun from unusual principals.
2. Cluster count spikes (ECS/EKS) and task definitions requesting abnormal CPU.
3. Autoscaling configuration changes expanding min/max instance counts beyond policy.
4. Termination protection enablement (disableApiTermination=True).
5. New IAM user creation + high-privilege policy attachment (especially email-sending permissions like SES if your org doesn’t use it).

AI works best when it can answer, quickly:

• “Is this identity behaving like itself?”
• “Is this workflow consistent with known deployments?”
• “Does this sequence match a known attack pattern?”

3) Automated containment that assumes speed matters

When miners go live in 10 minutes, a ticketing workflow is not a response strategy.

Automate the first steps:

• Quarantine the principal (disable keys/sessions, require re-auth, block suspicious roles).
• Stop scale-out immediately (freeze autoscaling groups, cap desired counts).
• Isolate compute resources (security group lockdown, remove public egress if appropriate).
• Re-enable termination where attackers disabled it so your tooling can clean up.

A useful stance is: contain first, investigate second. If it’s a false positive, you can roll back. If it’s real, you just saved real money.

“People also ask” answers (quick, practical)

How do crypto miners usually get into AWS?

Most commonly through compromised credentials (stolen access keys, phished logins, exposed secrets) and over-privileged IAM. This campaign required valid IAM access, not an AWS service vulnerability.

What are the earliest signs of cryptomining in AWS?

The earliest signs are control-plane events, not CPU graphs:

• DryRun permission probes,
• sudden role and policy creation,
• rapid ECS cluster/task creation,
• autoscaling spikes,
• and termination protection changes.

Can AI detect crypto mining before costs spike?

Yes—when it’s monitoring identity and API behavior across services and correlating events in time windows. AI is less effective if you only watch instance metrics after compute is already running.

The stance I’d take going into 2026

If your cloud security strategy still assumes attackers need malware, you’re defending the wrong layer. The cloud attack surface is mostly APIs, identities, and misused permissions. This AWS crypto mining campaign is a sharp reminder that valid credentials are the new exploit kit.

For teams building their 2026 roadmap, here’s the priority order that actually holds up:

1. Reduce credential exposure and privilege (so compromise doesn’t equal catastrophe).
2. Use AI-driven anomaly detection to spot control-plane abuse fast.
3. Automate containment so you can respond at attacker speed.

If you’re planning to add AI to your SOC this year, ask a blunt question during evaluation: Can it detect a compromised IAM principal provisioning ECS/EC2 at abnormal speed—and can it trigger containment automatically? If the answer is vague, keep shopping.