Elena' s AI Blog

Eight minutes to admin: when AI meets weak cloud security

11 Oct 2026 (updated: 26 Oct 2026) / 26 minutes to read

Elena Daehnhardt

Generated by Midjourney. Prompt: Abstract cloud computing architecture illustration.


TL;DR:
  • On 28 November 2025 an AWS intruder went from stolen credentials to administrator access in roughly eight minutes; Sysdig assesses that an LLM helped with the code.
  • The path was ordinary: credentials in public S3 buckets, an IAM user that could overwrite a Lambda function, and a function running as an administrator. No zero-day was involved.
  • Restricting what LLMs can generate helps at the margins but cannot be the foundation of a defence.
  • What scales is unglamorous: least-privilege IAM, short-lived credentials, SCP guardrails, and detection that can contain an attack in minutes.

Previous: Part 4 — The Digital Butler or Trojan Horse? A Privacy Playbook for Persistent AI Agents

Next: Part 6 — I Gave My AI Agent the Keys to My Inbox — Then Tried to Break Into It Myself

Where this fits:Safety and regulation Explore the AI Landscape →

Eight minutes to admin: why AI-assisted attacks shrink cloud response time

I read a breach report from The Register recently that stuck with me, not because an attacker used AI — that is not news any more — but because of how ordinary the rest of the story was. An intruder got from stolen credentials to administrative privileges in an AWS account in about eight minutes, according to Sysdig’s analysis. The intrusion happened on 28 November 2025, and Sysdig published its report on 3 February 2026. No novel exploit, no zero-day. Just a familiar attack path, run faster than a human would manage alone because, in Sysdig’s assessment, an AI copilot was helping with the code.

That is the part worth sitting with. Not “AI can attack you,” which we already knew, but “AI has quietly deleted the response-time cushion you were counting on.”

Three things are true at once right now, and they do not resolve into a tidy story:

  • LLMs help attackers reason, plan, and generate exploit code faster than before.
  • LLM APIs are themselves valuable cloud resources now, which makes them targets — credential theft, quota abuse, and what the security world calls LLMjacking. LLMjacking is the theft of cloud or LLM API credentials to run a victim’s paid model access at the victim’s expense.
  • LLMs are embedded deep inside production systems used by hundreds of millions of people, sitting in the same blast radius as your databases and queues.

Banning AI use is not a serious answer to any of this — I am not going to pretend it is. The real question is narrower and more useful: how do you design infrastructure that stays resilient when the attacker on the other end has an AI copilot too? That is what this post is about.

How a stolen credential became an administrator

Sysdig’s reconstruction reads like a checklist of things that were each individually plausible. A test IAM user, likely created on purpose to automate Bedrock tasks with Lambda, had its credentials sitting in public S3 buckets that held RAG data. The attacker did not have to break anything. They simply used what that user was allowed to do.

How a stolen credential became administrator access in about eight minutes Six steps from test credentials found in public S3 buckets, through an IAM user that can modify Lambda functions, an overwritten function that runs as an administrator, and injected code that creates admin access keys, to a new backdoor-admin user. Four green boxes show where the chain could have been broken: private buckets, limiting who can update function code, least privilege on the execution role, and alerting on new admin users. Observed attack path Where to break the chain Test credentials found in public S3 buckets The buckets held RAG data for AI models · 0:00 Keep AI data buckets private No credentials in public objects The IAM user can read and write Lambda functions Plus ReadOnlyAccess via a group and limited Bedrock access Code of an existing Lambda function overwritten Three attempts; function timeout raised from 3 s to 30 s Limit UpdateFunctionCode to named functions and principals The function runs with an administrator role The role was already attached to the function Least privilege on the Lambda execution role Injected code creates admin access keys The keys come back in the function's output · about 0:08 New user backdoor-admin gets AdministratorAccess About 0:11 · later: Bedrock abuse and a GPU instance Alert on new admin users and access keys, then contain
Figure 1. How an exposed credential led to administrator access through a writable Lambda function. Reconstructed from Sysdig's report; times are approximate, and the green boxes are the mitigations Sysdig recommends plus one alert I would add.

Notice what is missing: a zero-day. Every step is an ordinary permission doing exactly what it was told to. The whole operation lasted about two hours and touched 19 principals, but the eight minutes to administrator is the part that matters for defenders.


Agentic attacks in 2026: JADEPUFFER and the marimo database breach

Two terms get blurred in the headlines. In an AI-assisted attack, a human uses an LLM to research, generate or adapt code. In an agentic attack, software drives an LLM in a tool-execution loop: it runs a command, reads the result, chooses the next action and adapts, with little or no human in between. Sysdig describes the eight-minute breach as the first kind, with LLMs used throughout the operation. It has since documented two cases it assesses to be the second kind. Those are the researchers’ conclusions from observed evidence, not proof that every stage was autonomous.

The first, published on 1 July 2026, is what Sysdig assesses to be the first documented case of agentic ransomware, tracked as JADEPUFFER; CyberScoop reported it. The entry point was a Langflow vulnerability (CVE-2025-3248, an unauthenticated remote code execution flaw in the /api/v1/validate/code endpoint of Langflow before 1.3.0). CyberScoop reports more than 600 distinct payloads in rapid succession, and that the agent accessed OpenAI, Anthropic, DeepSeek and Gemini keys while gathering information about the victim. Sysdig is careful about what it claims: it cannot see the operator’s prompt or configuration, so its conclusion that an LLM drove the operation end to end rests on inferences from the payloads.

The second happened on 10 May 2026. Sysdig described an LLM agent (report published 26 May) moving from a vulnerable marimo notebook (CVE-2026-39987) to an internal PostgreSQL database in four pivots and about an hour: remote code execution, replayed AWS credentials, an SSH key held in AWS Secrets Manager, and an SSH bastion. Different entry points, same underlying story: the skill and time an attack used to require have both dropped, and the defence has to be structural rather than reactive to keep up.


Key takeaways: least privilege, fast detection, small blast radius

🔒 Subscribe to keep reading.

References

🔒 Subscribe to keep reading.

You've hit a Deep Dive tutorial.

I spend dozens of hours researching, coding, and breaking things to write these guides. This content is free, but reserved for my subscriber community. Drop your email below to unlock this guide (and all past/future deep dives):

Already a subscriber? Use the magic link from your last newsletter, or reset your password.

New subscribers get an inbox mail: Set a password to unlock articles. The form does not log you in — use the same email afterwards.

desktop bg dark

About Elena

Elena, a PhD in Computer Science, simplifies AI concepts and helps you use machine learning.



Citation
Elena Daehnhardt. (2026) 'Eight minutes to admin: when AI meets weak cloud security', daehnhardt.com, 11 October 2026. Available at: https://daehnhardt.com/blog/2026/10/11/protecting-infrastructure-in-an-era-of-ai-assisted-attacks/
All Posts