On 28 November 2025, Sysdig’s threat research team watched an attacker go from a set of leaked AWS credentials to administrator access in under ten minutes. The credentials were test keys sitting in a public S3 bucket. They belonged to a user with broad permissions on AWS Lambda. The attacker rewrote an existing Lambda function’s code to act as a more privileged role, compromised 19 AWS identities, read secrets and logs, and then used the account’s Bedrock access to run AI models at the victim’s expense. AWS said its services were not affected: this was an account compromised through misconfiguration.
Every step used a misconfiguration that is common. Intruder’s 2026 Cloud Security Index, covering 3,000 organisations, found that 83% of AWS accounts had a policy allowing privilege escalation and 71% had access keys that hadn’t been rotated. Here are five to check, with the AWS commands to start. The same ideas apply to Azure and Google Cloud.
1. Long-lived access keys
Access keys don’t expire. Keys created for a test, a contractor or a laptop years ago often still work, and they end up in repositories, CI logs and storage buckets.
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -dLook for keys older than 90 days and keys that haven’t been used recently. Replace human keys with single sign-on, and workload keys with roles.
2. Wildcard and loose trust policies
A role’s trust policy decides who can assume it. A principal of "*", a cross-account trust without an external ID, or a GitHub Actions OIDC trust without a condition on the repository lets far more people in than intended.
"Condition": {
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:ref:refs/heads/main"
}
}IAM Access Analyzer flags roles that can be assumed from outside your organisation. Run it in every region you use.
3. Permissions that let a user become someone else
The Sysdig attacker didn’t need admin rights. They needed lambda:UpdateFunctionCode on a function whose role was more powerful than they were. The same pattern applies to iam:PassRole combined with the ability to create EC2 instances, Lambda functions or Glue jobs, and to iam:CreatePolicyVersion or iam:AttachUserPolicy on yourself.
For each non-admin identity, ask: can it change code or configuration that runs as a more privileged identity? If yes, it effectively has that identity’s permissions.
4. Stale users, roles and unused permissions
Identities outlive the projects that created them. IAM Access Analyzer’s unused access findings show users and roles that haven’t been used, and permissions that have never been exercised. Remove what isn’t used and narrow what’s left. Fewer identities mean fewer keys to leak.
5. Public storage that holds credentials
The starting point in the Sysdig case was a public bucket. Turn on S3 Block Public Access at the account level, then grant exceptions deliberately. Search your buckets, repositories and CI variables for access keys, and treat any found key as compromised: rotate it first, investigate second.
aws s3control get-public-access-block --account-id <account-id>What to do this week
- Pull the credential report and disable keys older than 90 days that have no clear owner.
- Run IAM Access Analyzer for external and unused access in every account and region.
- List identities with
iam:PassRole,lambda:UpdateFunctionCodeor policy-editing permissions, and justify each one. - Turn on S3 Block Public Access at the account level.
- If you use Bedrock or other AI services, alert on unexpected model invocations. Stolen credentials are now being used to run models, not just mine cryptocurrency.