Real-world attacks

Attacks Whocan would have surfaced first

Every scenario below is based on a documented, real attack. For each we show what happened, what Whocan would have surfaced before exploitation, and the exact RQL query. Whocan closes the IAM gap before it can be used — it doesn't replace your runtime detection.

Attack	Impact	Detectable?
SCARLETEEL — 8 Minutes to Admin	Full admin access, backdoor user created, GPU instances launched for LLMjacking	Yes — before breach
LexisNexis — One ECS Task Role, 3.9M Records	536 Redshift tables, 53 secrets in plaintext, 3.9M records, .gov email users including federal judges	Yes — before breach
S3 Ransomware — 100 GB in Under 2 Minutes	2,000 files (~100 GB) encrypted in 1 minute 47 seconds	Yes — before breach
Capital One — 100M+ Customer Records	100M+ records: names, addresses, credit scores, SSNs	Yes — before breach
Serverless Token Abuse — 10,000% Increase	10,000% increase in serverless token abuse, 305% increase in bulk downloads	Yes — before breach

Sysdig, 2025

SCARLETEEL — 8 Minutes to Admin

Attacker found credentials in a public S3 bucket, injected code into a Lambda function, created access keys for an admin user, and moved laterally across 19 principals in 2 hours.

Attack chain

1. Credentials found in public S3 bucket (RAG data)
2. lambda:UpdateFunctionCode to inject code into existing Lambda
3. iam:CreateAccessKey for an admin user
4. Lateral movement across 19 principals (5 users, 6 roles, 14 sessions)
5. Cross-account OrganizationAccountAccessRole assumption
6. Backdoor admin user created

"The attacker needed 8 minutes. Whocan would have shown the full attack path before there was an attacker."

What Whocan detects

Who can modify Lambda code?

The initial escalation vector — a known attack path.

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

Who can create access keys for other users?

Every principal that can mint new credentials.

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

Full privilege escalation chains

The Lambda + execution role chain flagged as a critical sequence.

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

Attack step	Detected?	How
User with Lambda write access	Yes	who-can(action: "lambda:UpdateFunctionCode")
Lambda → admin escalation chain	Yes	Critical sequence detection
CreateAccessKey for other users	Yes	credentials-access entitlement
Cross-account role assumption	Yes	Transitive assume-role graph
Backdoor admin user created	Yes	Admin population drift monitor

Read the full deep-dive

BleepingComputer, March 2026

LexisNexis — One ECS Task Role, 3.9M Records

An ECS task role for a frontend React app had secretsmanager:GetSecretValue on every secret in the account, including the production Redshift master credential.

Attack chain

1. React2Shell vulnerability exploited in frontend ECS container
2. ECS task role credentials obtained from metadata endpoint
3. secretsmanager:GetSecretValue on every secret in the account
4. 53 secrets retrieved including Redshift master credential
5. Connected to Redshift with master credential
6. 536 tables, 3.9M records exfiltrated (2.04 GB)

"One who-can query would have shown the problem. One monitor would have caught the drift."

What Whocan detects

Who can read production secrets?

The query that would have prevented the breach.

who-can(
    action: "secretsmanager:GetSecretValue"
    resource: secrets
)

Non-admin roles reading secrets

A frontend app role should never appear here.

admin-roles = roles where self.Entitlements.Abilities includes "iam-admin"

secret-readers = who-can(
    action: "secretsmanager:GetSecretValue"
    resource: secrets
)

secret-readers where self not in admin-roles

Who can access the Redshift master credential?

Only DBAs and the Redshift service role should appear.

who-can(
    action: "secretsmanager:GetSecretValue"
    resource: secrets where self.Name ~ /redshift|master|prod/i
)

Attack step	Detected?	How
ECS task role with broad secrets access	Yes	who-can(action: "secretsmanager:GetSecretValue")
Non-admin role reading production credentials	Yes	Entitlement analysis + admin exclusion
Access to Redshift master credential	Yes	Scoped who-can on specific secrets
Blast radius of ECS role compromise	Yes	Entitlement computation for task roles
New secret access granted	Yes	Continuous monitor on secrets access

Read the full deep-dive

Rhino Security Labs, 2025

S3 Ransomware — 100 GB in Under 2 Minutes

Attacker with S3 write access re-encrypts every object using an external KMS key they control, then demands ransom.

Attack chain

1. Attacker gains S3 write access (leaked creds, overpermissive policy)
2. Creates KMS key in their own account (Encrypt allowed, Decrypt denied)
3. Re-encrypts every object with attacker-controlled KMS key
4. Schedules KMS key deletion (7-day window)
5. Drops ransom note — pay or lose data permanently

"CloudTrail notices after the fact. Whocan shows you every principal with write access right now."

What Whocan detects

Who can write to sensitive buckets?

If this list is too broad, you have found the attack surface.

who-can(
    action: "s3:PutObject"
    resource: var:sensitive-buckets
)

Who can write from OUTSIDE the organization?

Cross-account write access = ransomware prerequisite.

writers = who-can(
    action: "s3:PutObject"
    resource: var:sensitive-buckets
)

writers where self.account() not in var:production-accounts

Attack step	Detected?	How
Excessive S3 write access	Yes	who-can(action: "s3:PutObject")
Cross-account write access	Yes	Filter by external accounts
Missing bucket policy restrictions	Yes	Full chain evaluation (resource + identity + SCPs)
New write access granted	Yes	Continuous monitor fires on drift

Capital One, 2019

Capital One — 100M+ Customer Records

WAF misconfiguration allowed SSRF to steal EC2 role credentials. The role had excessive S3 permissions covering 100M+ customer records.

Attack chain

1. WAF misconfiguration allowed SSRF attack
2. IAM role credentials obtained from EC2 metadata service
3. Role had excessive S3 permissions
4. Data exfiltrated: 100M+ customer records

"A WAF-attached role shouldn't be reading customer PII buckets. Whocan surfaces the gap."

What Whocan detects

Who can read the sensitive buckets?

The over-permissive role would appear in the result set.

who-can(
    action: "s3:GetObject"
    resource: var:sensitive-buckets
)

Non-admin roles with broad S3 access

A WAF-attached role reading PII buckets is the finding.

admin-roles = roles where self.Entitlements.Abilities includes "iam-admin"

s3-readers = who-can(
    action: "s3:GetObject"
    resource: var:sensitive-buckets
)

s3-readers where self not in admin-roles

Attack step	Detected?	How
Role with excessive S3 permissions	Yes	who-can(action: "s3:GetObject") on sensitive buckets
Non-admin role reading PII data	Yes	Entitlement analysis + admin exclusion
Access drift on PII bucket	Yes	Continuous monitor fires on new access

Palo Alto Unit 42, 2025

Serverless Token Abuse — 10,000% Increase

Attackers specifically target IAM credentials from Lambda/serverless functions for lateral movement. 10,000% increase in remote usage of serverless tokens.

Attack chain

1. Attacker obtains Lambda execution role credentials
2. Uses credentials remotely for lateral movement
3. Accesses S3, KMS, Secrets Manager via the role
4. Bulk downloads sensitive data

"Lambda token theft grew 10,000% in 2024. Every Lambda role is a potential entry point. Whocan shows what each one can reach."

What Whocan detects

What can each Lambda execution role access?

Lambda roles with broad access are high-value targets.

roles where self.Name ~ /lambda/i
    map { Name, Arn, Abilities: self.Entitlements.Abilities }

Privilege escalation through Lambda

Anyone who can inject code inherits the execution role permissions.

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

Attack step	Detected?	How
Lambda roles with excessive permissions	Yes	Entitlement analysis for Lambda roles
Lambda code injection capability	Yes	who-can(action: "lambda:UpdateFunctionCode")
PassRole to Lambda escalation	Yes	Critical sequence detection

Don't wait for the breach

Every scenario above was preventable with a single query. Run them on your environment.

Start Free See what you can ask →