Update, Nov 10. SecurityWeek, citing Wiz and Sentra, reports the campaign pulled data from over a dozen organizations. Sentra says many of the abused roles were left over from companies that had stopped using Qubole but never deleted the role, and that those roles could read nearly all the data taken. Wiz also found a separate Oct 8–11 campaign that tested customer-owned AWS access keys tied to Qubole integrations against victim environments, in some cases successfully. If you ever onboarded Qubole, delete its cross-account role now and check CloudTrail for session names starting quiam-.
What happened. Qubole, a data lake platform owned by Idera, works inside customers' AWS accounts through an IAM role, an AWS identity whose trust policy lets Qubole's AWS account step in. Wiz says that starting Oct 14, someone used IAM credentials from an AWS account associated with Qubole (account 805246085872) to call AssumeRole against those roles in multiple customer environments, first from Mullvad VPN addresses and then mostly from an OVH-hosted server. Every request carried an External ID and every one succeeded. Activity ran through Oct 26.
What the attacker took. Once inside, it enumerated storage, compute, databases and keys, then went after the usual places credentials hide: Lambda environment variables, Secrets Manager and SSM Parameter Store. It ran what it found through TruffleHog, an open-source secret scanner, confirming victims' own AWS access keys, signing in as Entra ID service principals and requesting Okta OAuth tokens. It also downloaded S3 data opportunistically, sometimes pulling a whole bucket in one session.
The uncomfortable detail. In most environments Wiz examined, the attacker's requests were the only AssumeRole activity from the vendor account in October. Many of these roles were no longer in use, but the trust was still in place, so the door opened anyway.
Why this matters to an enterprise. Every SaaS tool you let into your cloud through a cross-account role is a standing key held by someone else. If you ever connected Qubole, search CloudTrail for AssumeRole calls from account 805246085872 since Oct 14, delete or lock down the role if you no longer use it, and rotate any secrets, AWS keys, Entra client secrets and Okta client credentials that role could read. Then do the same review for every other vendor trust policy you have forgotten about.