What Wiz and Sentra reported on 9 November about 14 to 26 October: how a leftover cross-account role let a vendor’s stolen credentials in, and the check that finds yours.
Between 14 and 26 October an attacker holding credentials from an AWS account linked to Qubole, a big-data platform, used them to enter the AWS accounts of more than a dozen organisations, through access those organisations had once given Qubole.12 Most of those roles were not otherwise in use, and in some cases whole S3 storage buckets were downloaded.1 No victim has been named, and neither Wiz nor Sentra, the two security companies that reported it on 9 November, says how the credentials were obtained.12
Software that works inside a customer’s AWS account usually gets in through a role. The customer creates the role and writes a trust policy naming the vendor’s AWS account; the vendor then asks AWS for temporary credentials to act as that role.13 Nothing about the arrangement expires when the customer stops using the vendor.
A forgotten cross-account role accepts anyone who holds the vendor’s credentials and External ID
How a third-party AWS role is set up and how it was used, 14–26 October
The customer creates a role
The vendor assumes it
The customer leaves
Stolen credentials arrive
Source: Wiz; Sentra; AWS IAM documentation · as of 9 November 2026
The External ID was no protection here. Every request Wiz tied to the attacker carried one, and every one succeeded; AWS itself says it “does not treat the external ID as a secret”.13 In most of the environments Wiz saw, the attacker’s were the only role assumptions from Qubole’s account all October.1
Once inside, the attacker listed what each role could reach and read credentials from Lambda settings, Secrets Manager and Parameter Store, then tested them against AWS, Entra ID and Okta.1 Sentra counted about 100 passwords and keys read in seven minutes, and no write actions at all.2 Both companies say a single condition limiting the role to Qubole’s own network addresses would have blocked every login they saw.12
Find the roles. In every AWS account you hold, list the roles that trust Qubole’s account (the ID is Wiz’s):
aws iam list-roles --query "Roles[?contains(to_string(AssumeRolePolicyDocument), '805246085872')].RoleName" --output text
For every vendor at once rather than one, an IAM Access Analyzer external-access analyzer reports roles shared outside your account.4
See when each was last used. The listing call does not return this, so ask for each role:5
aws iam get-role --role-name ROLE_NAME --query Role.RoleLastUsed
AWS only reports the trailing 400 days, so an empty answer does not prove a role has never been used.6
Remove what you no longer use. Delete the role or take the vendor out of its trust policy.1 For vendors you keep, narrow the trusted principal and add an aws:SourceIp condition.1
If you ever used Qubole, read the logs. Wiz advises reviewing CloudTrail from 1 October for AssumeRole events from that account where the source address is not an AWS one. If you find any, rotate every secret the role could read and revoke its active sessions, because rotating a credential does not end temporary sessions already issued.1 CloudTrail’s management events will not show what was read from S3: object reads need data events or server access logs, and in several affected environments the missing logs meant responders could not tell which files had gone.1
Sources
Disclosure. TechBag is a software reseller: it earns a margin when a reader buys through it, including from vendors named here. The analysis is TechBag’s own; no vendor paid for or saw this piece before publication. Facts are labelled reported, TechBag count or our view.