Twenty-Five Minutes: One Leaked Key to Account Takeover

Series: Building the Agentic SOC – Part 2

The Setup

In Part 1 I argued that response has to be designed alongside defense, and that the agentic SOC is becoming the architect's problem. Before we build the defender, we have to see what it is up against. So this part is just the attack.

The ground rules, so nobody can wave this away as a scripted demo:

The attacker starts with one stolen credential and nothing else. A single leaked access key, the kind that shows up in a public commit, a CI log, or a pasted chat message every day. No zero-day, no malware, no insider knowledge.

An AI agent drives the attack, not a script. CDRGoat ships deterministic attack scripts, and I did not use those. I gave the agent the key and an objective, escalate and reach sensitive data, and let it decide every step, including the wrong ones.

It runs in a real cloud account, in a public CDRGoat scenario you can deploy yourself with Terraform and run against your own tooling.

The leaked key belongs to a low-privileged IAM user whose only real power is broad access to Lambda. That sounds harmless. Watch what an AI does with it.

The Attack, Step by Step

Timings are measured from the agent's first API call.

‍

Read the shape of it, not just the steps. In under four minutes the agent went from "a user who can only touch Lambda" to "arbitrary code running as a role that manages identities." That is the whole game in cloud: you rarely need to break in twice, you need one identity that can hand you a more powerful one. The management Lambda's execution role was that hinge.

Then it did something very human: it chased the wrong lead. The role could read S3, so the agent spent fifteen minutes trying to guess the name of a bucket it could not see, and got nothing. This is worth showing rather than hiding, because it is the honest picture of an autonomous attacker. It is not a flawless script. It explores, it backtracks, it wastes time. And it still wins, because a wrong turn costs it minutes, not the attack.

The move that actually worked is not clever, it is patient. The role could not list the account's users, so the agent could not look up a privileged target. What it could do was try. It pulled its own username apart to learn the naming pattern, took a standard first-name wordlist, and asked the API to create an access key for each guessed name until the API stopped saying "no such user." Two minutes later it had maria. And maria, whose own policy looked identical to the throwaway user we started from, carried admin privileges through a group that was invisible from her own credentials. The winning move in a modern cloud attack was old-fashioned credential guessing, enabled by one over-permissive API on one Lambda role.

Under half an hour, wrong turns included, and the attacker held the keys to the account. All of it from a single leaked key, with no exploit.

Why the Human SOC Is Already Behind

None of this speed is magic, and it is worth being precise about why, because it is what the defense has to be designed against. The agent holds the entire enumerated environment in context and reasons over all of it at once. It does not tab away to documentation to remember how Lambda execution roles work. It does not take notes, get pulled into a meeting, or wait for a second opinion. Even when it guesses wrong, it fails fast and moves on.

Now put a human SOC against that. The activity generates alerts, but the alert lands in a queue with a triage SLA measured in hours, not minutes. By the time an analyst opens the ticket, the Lambda has been weaponized and the brute-force is well underway. The human SOC is not bad at its job. It is running a relay race against a sprinter, and it started late.

What This Attack Actually Generated

Here is the detail that sets up the rest of the series. This single attack, one actor, one chain, did not produce one clean alert. It was loud, and loud in several different ways at once: a management Lambda's code and configuration were tampered with and then invoked, twelve thousand s3:ListBucket calls swept the account, thousands of iam:CreateAccessKey calls hammered it in a brute-force pattern, new access keys appeared on multiple users, and a normally quiet identity started enumerating everything in sight. Different resources, different detection rules, all firing inside the same half hour.

To a human analyst pulling tickets one at a time, those look like separate problems. They are not. They are the same attacker, seen from different angles. Whether your SOC understands that, fast, and whether it can act on it, is the whole question.

The obvious next move is to point AI at those alerts. But if you spawn an investigation agent per alert, you rebuild every weakness of the overloaded human SOC at machine speed and machine cost. Part 3 is about the design that actually works: one linked case, not a swarm. Then, in Part 4, we watch a real AI SOC take this exact attack apart in the backend, and cut it off before it ever reaches maria.

Want to run this scenario yourself? CDRGoat is open source.