An AI Broke Into AWS Faster Than You Can Imagine

I read something last week that genuinely stopped me for a second. A security firm called Sygnia investigated an AWS breach where the attacker used four different stolen access keys, from four different accounts, all from the same IP address, all within the same observed second.

Read that again. Not the same hour. The same second. I don't know anyone who can type that fast, let alone juggle four separate credentials while doing it.

The full incident went from first foothold to complete takeover in about 72 hours, and that one detail is the reason I wanted to write about it. Most of us build our security assumptions around having some amount of time to react: a key leaks, someone eventually notices, it gets rotated, the blast radius stays small. That assumption is starting to look shaky.

Worth saying up front: there was no zero-day here. The attacker got in the boring way, a leaked secret and a permission that was more generous than it should have been. The same kind of thing sitting in plenty of AWS accounts right now, probably including a few you or I have touched. What's different is what happened after they found it.

This post starts from zero. If you run anything in AWS, you should know what happened and what actually stops it.

First: what does "compromise an AWS account" mean?

AWS accounts run on identities - IAM users, roles, and access keys. An access key is a username and password, but for machines. A script, a pipeline, an app uses it to say "I'm allowed to do this."

AWS can't tell a stolen key from the real owner. The key is the permission. Whatever it can do, the attacker can now do.

So the real question isn't "how did they get in." It's "how far could that one key reach."

How they got the first key

The entry was mundane. They exploited a bug in an internet-facing app and grabbed a credential. Not a cloud misconfiguration on day one - a normal web bug that happened to sit in front of AWS.

From there, they found more credentials in two common places:

• S3 buckets holding secrets - config files, .env dumps, backups that got stored "temporarily" and never got cleaned up
• CI/CD environments, where pipelines routinely hold cloud credentials so they can deploy on your behalf

Neither is exotic. Most teams have something like this somewhere. That's the point.

The real shift: "waves," not stages

Classic intrusions run in stages. Get in. Look around. Escalate. Move sideways. Do damage. One step at a time.

This one didn't. Sygnia calls it overlapping waves. Each new credential immediately triggered its own round of discovery, secret-hunting, and damage - while the last wave was still running.

Think of stage-based hacking as one person searching a building room by room. This was several people entering through different doors at once, each searching their own room, radioing back what they find, while more keep arriving through doors the first group just opened.

The evidence: four access keys, four different accounts, same IP, same user-agent, same second. That's not a script running a fixed routine. That's something deciding what to do with each new credential on the spot.

Why they suspect AI

A few things pointed past a hand-written bot, toward AI-assisted tooling:

• Adaptation, not repetition. Several hundred unique SQL queries across dozens of databases. A normal tool reuses one query template everywhere. Writing hundreds of distinct, context-appropriate queries at that pace looks like something generating new ones on the fly - the way you'd ask an LLM "here's this schema, write me a query for X."
• Fast relationship-mapping. The attacker went from "I have this credential" to "here's everything it touches" almost instantly - work that normally takes a human analyst real time.
• A strange framing choice. Some of the attacker's own artifacts described the activity as an authorized "pentest." One theory: if the attacker is driving an AI agent, framing it as an authorized test may be a way to get the agent to comply with actions it would otherwise flag.

None of this is proof. It's forensic inference. But multiple security firms are separately converging on the same read: offense is starting to move at machine speed. Sygnia lays out the AI indicators in detail in their write-up of the investigation.

Not a one-off: the 8-minute Lambda takeover

A separate incident from November 2025, investigated by the Sysdig Threat Research Team, makes the point even sharper. An attacker went from initial access to full AWS admin control in eight minutes, via a poisoned Lambda function. The initial credentials were found in public S3 buckets, and AI-driven automation then carried out recon, privilege escalation, and lateral movement across 19 distinct AWS identities - faster than a coffee break. (The AI fingerprints were almost comical: the tooling tried to assume roles in made-up account IDs like 123456789012, and left session names like claude-session in the logs.)

No zero-day there either. Just stolen credentials, automation, and an environment that let one identity's access snowball into eighteen more.

What actually made this possible

Strip away the AI framing and the causes are old:

1. Secrets left in the wrong place. S3 buckets and CI/CD are the two most common spots for a forgotten credential.
2. Long-lived credentials. A key that never expires is valuable forever, to anyone who finds it.
3. Over-permissioned identities. If one credential reaches 19 others, one leak becomes a full takeover.
4. No automated containment. By the time a human notices and rotates a key by hand, a machine-speed attacker has already finished.

AI didn't invent these weaknesses. It just made chaining all of them, at once, cheap enough to automate. The mistakes are old. The speed is new.

What actually stops this

1. Kill long-lived credentials.

A key that doesn't expire is a permanent liability the moment it's created. Prefer short-lived credentials: IAM roles via STS, OIDC federation from CI/CD (GitHub Actions → AWS, no stored keys at all), instance roles instead of embedded ones. A key that expires in an hour is a much smaller incident than one valid forever.

2. Scope permissions - and scope who can even assume the role.

Least privilege is old advice, still correct. But scope both halves: the permissions policy (what this role can do) and the trust policy (who's allowed to become this role at all). A role only your deploy workflow can assume, touching one bucket and one CloudFront distribution, gives a stolen credential almost nowhere to go.

3. Get secrets out of S3 and CI/CD env vars.

Use a real secrets manager with tight IAM access, not config files in a bucket or variables baked into a pipeline. If a secret must live in CI, treat it as radioactive: rotate it often, restrict who reads it, never let it hit logs.

4. Automate the response, not just detection.

Sygnia's recommendation worth taking seriously: automate rotation and containment to match attacker speed. If your plan assumes a human notices and rotates a key manually, that window needs to be minutes, not hours - and for machine-speed attacks, minutes might not be enough. CloudTrail alerting on abnormal API velocity, paired with automated key disabling, closes a gap no on-call engineer can close by hand.

5. Treat identity as the perimeter.

The old model was "firewall the network." In the cloud, identity is the perimeter. MFA everywhere. Aggressive session revocation on anything suspicious. Immediate disabling on any sign of compromise - for machine identities too, which usually reach further than any human ever does.

The uncomfortable takeaway

Nothing here needed a novel vulnerability. It needed things already sitting in a lot of AWS accounts right now: a secret in a bucket, a credential that never expires, a role that reaches too far. AI didn't invent those problems. It just showed up with the patience and speed to find and chain every one, in a single weekend.

The fix is boring, on purpose: short-lived credentials, tight scoping, secrets out of buckets, detection that doesn't wait on a human. None of it is new advice. What's new is the cost of skipping it, because the thing exploiting the gap doesn't sleep, doesn't get tired, and doesn't work one task at a time.

The whole post in four lines

• An attacker took over a large AWS environment in ~72 hours using leaked secrets and zero exploits - ordinary entry, extraordinary speed.
• Four access keys used in the same second, plus hundreds of adaptive SQL queries, point to AI-assisted tooling running in parallel "waves," not linear stages.
• A separate incident hit full AWS admin control in 8 minutes via a compromised Lambda function. Not a one-off.
• The fix is the same old list, just faster: kill long-lived credentials, scope permissions and trust policies tightly, get secrets out of buckets and CI, automate detection instead of waiting on a human.

Machine-speed attacks need machine-speed defenses. If your response plan still assumes a human has time to think, it's already out of date.

Sources and further reading

• Sygnia: How AI Supercharged a 72-Hour Cloud Attack. The primary investigation write-up from the firm that responded to the incident.
• Sygnia press release: AI-accelerated attack lets a lone actor compromise an enterprise cloud. The short official summary of the findings.
• Sysdig: AI-assisted cloud intrusion achieves admin access in 8 minutes. The separate November 2025 Lambda incident referenced above.
• CSO Online: From credentials to cloud admin in 8 minutes. Independent reporting on that Lambda incident.
• Dark Reading: Lone Attacker Uses AI to Breach AWS Cloud Environment in 72 Hours. Independent reporting on the Sygnia case.