Security

8 Minutes to AWS Admin: How an Open S3 Bucket and an Admin…

An attacker took over an AWS account in eight minutes, according to Sysdig. The path went through an open S3 bucket and a Lambda role with admin rights. The AI only accelerated …

By Alec Chizhik July 6, 2026 6 min read

8 Minutes to AWS Admin: How an Open S3 Bucket and an Admin…

6 Min. Reading time

On November 28, 2025, an attacker seized a full AWS account in just eight minutes, moving from the first stolen access key to full administrator privileges. The incident was documented by Sysdig’s security team. What makes it striking is the speed: an AI completed the investigation and script creation in real time. The initial foothold was a well‑known configuration error.

The Essentials in Brief

Eight minutes to admin: According to Sysdig, an attacker compromised an AWS account in under ten minutes, moving from stolen keys in an open S3 bucket to a self‑created admin user.
The flaw was in the config: A Lambda function carried an execution role with administrator rights. Whoever was allowed to rewrite the function inherited those rights. A new exploit was not needed.
The AI was the turbo: It wrote attack code and explored the account in real time. The industry median for attacks, according to Mandiant, is still 14 days. The eight‑minute case is the exception with special circumstances.

Eight minutes from the S3 bucket to the admin key

The entry was openly accessible on the network. In a publicly reachable S3 bucket, training data for an AI (Artificial Intelligence) system was stored, including valid access keys of an IAM (Identity and Access Management) user. This user was allowed to do little, but a single permission was sufficient: he could modify the code of a specific Lambda function. The function was called EC2-init. It was attached to an execution role with administrative rights.

From here everything moved quickly. The attacker modified the function, had it generate new access keys for an admin user named frick and read the result directly from the function’s response. No detour via an external server, no reverse shell. Subsequently, he accessed 19 different AWS identities, created a second backdoor admin, and secured the access multiple times.

Then it got expensive. Via the AI service Amazon Bedrock, the attacker tapped foreign language models at the victim’s expense. At the same time, he launched a GPU instance for around 30 Euro per hour to run his own models. AWS terminated the instance after five minutes due to capacity limits. Suspiciously, the code itself: Serbian comments and fabricated AWS account numbers revealed that a language model had helped write it.

8 minutes

took the observed attack from the stolen key to admin access. An exception case with long‑lived keys and an admin role in the wrong place.

Source: Sysdig Threat Research Team, Incident from 28. November 2025

No Zero-Day, but a Chain of Known Vulnerabilities

The “eight‑minute” figure may sound like a rupture of everything you thought you knew about cloud security. Yet a closer look at the attack chain tells a different story. There is no zero‑day, no AI‑specific exploit-just a string of well‑known misconfigurations.

Long‑lived access keys were stored in a public bucket. A Lambda execution role carried administrator privileges, even though it never needed them. A low‑privilege user could overwrite foreign code. These three errors together formed the chain. Each one, on its own, has been known for years and is listed in every AWS hardening guide.

AI accelerated and automated the attack. It did not enable it. Anyone who reads the case as proof that AI is making cloud insecure misses the real cause-and the point where defenders can act. The root cause is fixable, completely independent of AI‑based defenses.

Why the Minute Count Is Misleading

A second data point puts the matter in perspective. Google’s security unit Mandiant analyzes hundreds of thousands of hours of incident response each year. In the M‑Trends 2026 report dated March 23, there is a statement that contradicts panic: Do not regard 2025 as the year when attacks first emerged directly from AI.

The numbers back this up. The median dwell time of an attacker in the network rose to 14 days in 2025, up from 11 the previous year. In 52 percent of cases, companies detected the breach themselves first. Exploited vulnerabilities remain the most common entry vector, accounting for 32 percent, for the sixth consecutive year. Most attacks still unfold on a timescale of days and weeks.

The eight‑minute case is real, but it is an outlier, not a new average. It happened so quickly only because the conditions were ideal. For defenders, this is the good news: Anyone who eliminates those conditions removes the basis for a rapid attack.

Five Steps to Harden AWS Accounts Now

No vendor patch resolves the issue, as it stems from the configuration. That’s precisely where it can be addressed. The sequence is ordered by impact.

Retire long-lived credentials. Instead of permanent IAM credentials, short-lived roles and temporary login credentials should be used in regular operations. A leaked key that becomes worthless after one hour no longer opens any doors.
Separate administrative privileges from execution roles. No Lambda function needs administrator rights to perform its task. Each execution role should receive exactly the permissions required for its function, nothing more.
Identify public Amazon S3 buckets. Amazon S3 buckets containing training data often end up accidentally exposed on the internet. A regular scan for open buckets and embedded credentials closes the most common entry point.
Secure Amazon Bedrock with guardrails. Service Control Policies limit who may initiate costly AI services and GPU instances. This caps the damage if an account is compromised.
Monitor activity. New admin users, foreign Bedrock calls, and suddenly started GPU instances are clear signals. Whoever sees them in real time stops the attack mid‑run.

Misconfiguration vs Hardened Setup

The difference between the eight-minute account and a secure environment is not in a new tool. It lies in settings that you must know and apply.

Aspect	The vulnerable case	Hardened Setup
Access key	long-lived, in an open bucket	short-lived roles
Lambda execution role	Administrative rights	only functional rights
S3 Buckets	public with credentials	private, regularly scanned
Effect of a leaked key	Path to account admin	worthless after one hour

What Teams Take From the Incident

The fuss over the eight minutes distracts from the real finding. The attack was swift because basic hygiene was lacking. Short-lived credentials, sparingly assigned roles, and a look at open buckets could have broken the chain at every step. These measures are old, unremarkable, and effective.

One detail should jolt defenders as well. Sysdig warns that the tell‑tale AI traces in the code will soon disappear. Better agents don’t write Serbian comments and no longer invent account numbers. The window in which a AI‑driven attack can be detected in the code is closing. Staying hardened, which already throttles each of these steps today, remains crucial.

Frequently Asked Questions

What is LLMjacking?

In LLMjacking, attackers hijack stolen cloud access to run expensive language models via services such as Amazon Bedrock. The bill is footed by the victim. In the Sysdig case, the attacker also tapped into foreign models and launched an additional GPU instance at the victim’s expense.

Does the eight‑minute figure come from Google or GTIG?

No. The specific eight‑minute figure originates from Sysdig’s security team. Google’s Mandiant M‑Trends 2026 report provides context and cites a median dwell time of 14 days. Together, the two sources give the full picture.

Was an unknown vulnerability involved?

No. The attack relied solely on misconfigurations: long‑lived keys in an open S3 bucket and a Lambda role with admin privileges. No zero‑day was involved, and no patch is required.

What is the fastest mitigation step?

The fastest mitigation step is to replace long‑lived IAM keys with short‑lived roles and never grant admin privileges to Lambda execution roles. This removes both the initial foothold and the ability to pivot to admin for the observed attack.

Editor’s Picks