SCARLETEEL: 8 minutes to admin, and the path was visible the whole time

In the SCARLETEEL intrusion documented by Sysdig, an AI-assisted attacker went from a single leaked credential to full AWS administrator in about eight minutes — then spent the next two hours moving across nineteen principals. The unsettling part is not the speed. It is that every hop the attacker used was a standing access path that existed in the account the day before, and the day before that.

What happened

The entry point was mundane: long-lived credentials sitting in a public S3 bucket alongside RAG training data. From there the attacker did not exploit a vulnerability in the usual sense. It used permissions that were already granted.

1. 1.Found credentials in a public S3 bucket (RAG data).
2. 2.Used lambda:UpdateFunctionCode to inject code into an existing Lambda function.
3. 3.Called iam:CreateAccessKey to mint keys for an admin user.
4. 4.Moved laterally across 19 principals — 5 users, 6 roles, 14 sessions.
5. 5.Assumed the cross-account OrganizationAccountAccessRole.
6. 6.Created a backdoor admin user and launched GPU instances for LLMjacking.

Sysdig caught the activity at runtime — that is what runtime detection is for, and it worked. But by the time an alert fires, the attacker is already inside the path. The more interesting question is the one you can ask before any of this: who could have walked this route?

The path was queryable before there was an attacker

Each step above corresponds to a permission relationship that was true at rest. A principal that can rewrite the code of a Lambda inherits whatever that function execution role can do. A principal that can create access keys for another user inherits the privileges of that user. Chain those together and you have a privilege-escalation sequence — one that no single policy review reveals, because no single policy is wrong on its own.

These are exactly the questions Whocan is built to answer. Three of them would have surfaced the entire route.

1. 01

   Who can modify Lambda code?

   The initial escalation vector — and a known, enumerable attack path.

   rql

   who-can(
       action: "lambda:UpdateFunctionCode"
       resource: lambdas
   )

2. 02

   Who can create access keys for other users?

   Every principal that can mint new long-lived credentials for someone else.

   rql

   who-can(
       action: "iam:CreateAccessKey"
       resource: users
   )

3. 03

   Full privilege-escalation chains

   The Lambda-plus-execution-role chain, flagged as a critical sequence rather than two unrelated permissions.

   rql

   users where self.Entitlements.Abilities includes "iam-privilege-escalation"
       map { Name, Arn, Sequences: self.Entitlements.Sequences }

Detection and prevention are different jobs

Whocan does not replace runtime detection — it closes the IAM gap before runtime detection ever has to fire. Mapped against the attack chain, every step was knowable as a standing access fact:

• User with Lambda write access — who-can(action: "lambda:UpdateFunctionCode").
• Lambda-to-admin escalation chain — critical sequence detection.
• CreateAccessKey for other users — credentials-access entitlement.
• Cross-account role assumption — transitive assume-role graph.
• Backdoor admin user created — admin population drift monitor.

The takeaway

Eight minutes is not a lot of time to respond. The good news is you do not have to win that race if you have already closed the path. Audit the route, not the alert: ask who can reach admin, through which hops, before an attacker asks the same question with worse intentions.