Eight Minutes to AWS Admin: How an Open S3 Bucket and an Admin Lambda Were All It Took
An attacker took over an AWS account in eight minutes, according to Sysdig. The path led through an open S3 bucket and a Lambda role with admin rights.
6 min read
On 28 November 2025 an attacker took over an entire AWS account in eight minutes-from the first stolen access key to full administrator privileges. The incident was documented by the security team at Sysdig. What makes it explosive is the speed: an AI handled reconnaissance and script generation in real time. The entry point itself was a well-known configuration error.
Key Takeaways
- Eight minutes to admin: According to Sysdig, an attacker compromised an AWS account in under ten minutes. Starting with stolen keys from an open S3 bucket, they escalated to a self-created admin user.
- The flaw sat in the config: A Lambda function carried an execution role with administrator rights. Anyone who could rewrite the function inherited those rights-no new exploit required.
- The AI was the turbocharger: It wrote attack code and explored the account in real time. Mandiant still cites a 14-day industry median for attacks. The eight-minute case is the exception, enabled by very specific conditions.
Related:How an Argo CD flaw opens the entire Kubernetes cluster / AWS and Azure under EU supervision
From open S3 bucket to admin key in eight minutes
The entry point was wide open. A publicly accessible S3 bucket held training data for an AI system, including valid access keys for an IAM user. That user had limited rights, but one permission was enough: it could modify the code of a specific Lambda function named EC2-init. Attached to the function was an execution role with administrator privileges.
From there, everything moved at lightning speed. The attacker rewrote the function, triggered it to generate fresh access keys for a new admin user called “frick,” and read the results straight from the function’s response-no external server, no reverse shell. Next, they accessed 19 different AWS identities, created a second backdoor admin, and layered multiple persistence mechanisms.
Then the bill arrived. Using the Amazon Bedrock AI service, the attacker invoked third-party language models at the victim’s expense. At the same time, they spun up a GPU instance costing roughly €30 per hour to train their own models. AWS terminated the instance after five minutes due to capacity limits. The giveaway? Serbian comments and invented AWS account numbers in the code revealed that a language model had been co-authoring the attack.
No Zero-Day, but a Chain of Known Flaws
The eight-minute figure sounds like a break from everything we know about cloud security. A closer look at the attack path shows the opposite. No unknown vulnerability, no AI-specific exploit. Each step exploited a documented misconfiguration.
Long-lived access keys sat in a public bucket. A Lambda execution role carried admin rights it never needed. A weakly permissioned user could overwrite foreign function code. These three flaws together formed the chain. Each on its own has been known for years and is listed in every AWS hardening guide.
The AI accelerated and automated the attack. It did not enable it. Anyone reading this case as proof that AI makes the cloud unsafe misses the real cause-and with it the place where defense works. The cause is fixable, entirely without AI countermeasures.
Why the Eight-Minute Figure Misleads
A second data point puts things in perspective. Google’s security unit Mandiant analyzes hundreds of thousands of incident-response hours every year. In the M-Trends 2026 report dated March 23, one sentence contradicts the panic: “Do not view 2025 as the year attacks originated directly from AI.”
The numbers back that up. The median dwell time of an attacker inside a network rose to 14 days in 2025, up from 11 the year before. In 52 percent of cases, companies discovered the breach themselves first. Exploited vulnerabilities remain the most common entry point at 32 percent, for the sixth year running. Most attacks still unfold on the scale of days and weeks.
The eight-minute case is real, but it is the outlier, not the new normal. It only moved that fast because the conditions were perfect. For defenders, that’s the good news: remove those conditions and you remove the foundation of a fast attack.
Five Steps to Harden AWS Accounts Now
No vendor patch fixes this because the issue lies in the setup. That’s exactly where it can be fixed. The order is sorted by impact.
- Eliminate long-lived keys. Replace permanent IAM keys with short-lived roles and temporary credentials as standard practice. A leaked key that expires after an hour no longer opens any doors.
- Separate admin from execution roles. No Lambda function needs admin rights to do its job. Give each execution role exactly the permissions its function requires, no more.
- Find public buckets. S3 buckets holding training data often end up exposed by accident. Regular scans for open buckets and any credentials inside them close the most common entry point.
- Guard Bedrock with guardrails. Service Control Policies limit who can even launch expensive AI services and GPU instances. That caps the damage if an account is ever compromised.
- Monitor runtime behavior. New admin users, unfamiliar Bedrock calls, and suddenly launched GPU instances are clear signals. Seeing them in real time lets you stop the attack mid-run.
Misconfiguration versus hardened setup
The difference between an eight-minute account compromise and a secure environment is not a new tool. It comes down to default settings that teams must know and enforce.
| Aspect | The vulnerable case | Hardened setup |
|---|---|---|
| Access keys | long-lived, stored in an open bucket | short-lived roles |
| Lambda execution role | administrator privileges | only functional rights |
| S3 buckets | public with credentials | private, regularly scanned |
| Impact of a leaked key | direct path to account admin | worthless after one hour |
What teams should take away from the incident
The fuss over the eight minutes distracts from the real finding: the attack succeeded because basic hygiene was missing. Short-lived credentials, sparingly assigned roles, and a quick scan of open buckets would have broken the chain at every link. These measures are old, unglamorous, and effective.
One detail should jolt defenders awake. Sysdig warns that the tell-tale AI traces in code will soon vanish. Better agents write no Cyrillic comments and invent no account numbers. The window in which an AI-assisted attack can be spotted in the code is closing. What remains is hardening that already slows every step of such an attack today.
Frequently Asked Questions
What is LLMjacking?
In LLMjacking, attackers hijack stolen cloud access to run expensive language models via services like Amazon Bedrock. The victim foots the bill. In the Sysdig case, the intruder tapped into third-party models and spun up an additional GPU instance at someone else’s expense.
Does the eight-minute figure come from Google or GTIG?
No. The specific eight-minute incident was reported by Sysdig’s security team. Google’s Mandiant M-Trends 2026 report provides context, citing a median dwell time of 14 days. Together, the two sources paint the full picture.
Was a previously unknown vulnerability involved?
No. The attack relied solely on misconfigurations: long-lived keys in an open S3 bucket and a Lambda execution role with admin privileges. No zero-day was exploited, and no patch is required.
What’s the fastest defensive move?
Replace long-lived IAM keys with short-lived roles and never grant an execution role admin rights. That removes both the entry point and the path to admin observed in the attack.
Editor’s Reading Picks
Image source: AI-generated (July 2026)
