Identity

On November 9, Wiz published an investigation into a campaign that walked into customer AWS accounts through the Qubole data platform's cross-account integration. From October 14 to at least October 26, someone holding credentials for Qubole's own AWS account, 805246085872, assumed the IAM roles that customers had created for Qubole, then pulled secrets out of Lambda, Secrets Manager and SSM Parameter Store and downloaded S3 data, in some cases whole buckets. Sentra spotted the activity in several customer environments, and Wiz investigated with Google's Mandiant responders.

You are exposed if any of your AWS accounts still has an IAM role whose trust policy names account 805246085872, whether or not you use Qubole today. Wiz says many victims had no legitimate Qubole traffic at all in October: the integration was finished, but the role and its trust policy were still in place. Wiz calls the campaign broad and opportunistic and has not said how many organizations were hit. Neither AWS nor Qubole answered The Register's questions, and Wiz has not explained how the vendor-side credentials were obtained.

How it works

Qubole runs data processing clusters inside its customers' AWS accounts. Rather than handing over long-lived access keys, a customer creates a cross-account IAM role. Its trust policy says which outside principal may assume it. Qubole's setup guide uses the account root, which for this account is arn:aws:iam::805246085872:root, which means any identity in Qubole's account that has permission to call sts:AssumeRole. A condition on sts:ExternalId requires the caller to present a shared value. When Qubole needs to work, it calls sts:AssumeRole with the role ARN and the External ID, and AWS Security Token Service (STS) hands back temporary credentials with whatever permissions the role holds.

That design is sound as long as the vendor's account is safe. Once an attacker controls an IAM user inside it, every customer role that trusts the account is reachable, and the External ID barely slows them down. Wiz points out that it is not a secret: it shows up in plain text in CloudTrail, vendors store it, and it often sits in infrastructure-as-code repositories. Every attributed AssumeRole call in the investigation carried a valid External ID and succeeded.

Integration roles for data platforms tend to have broad read access, because the platform needs to reach data and configuration. That is what made the harvest so productive.

What attackers did

The first call Wiz saw came on October 14 from a Mullvad VPN address, 45.83.220[.]211, using IAM user AIDA3W7DIFLYOLTK63SFS in Qubole's account. Wiz has seen that user only in the attacker's activity. From October 15, most work came from an OVH virtual server, 57.129.54[.]120. On October 18 the attacker switched to a second IAM user, AIDAJYRRH5Y3A7AAJM2HW, which also carries legitimate Qubole traffic, and swept through integration roles in several environments in quick succession. Role session names started with quiam-, such as quiam-enum and quiam-scope-full.

Inside each account the pattern repeated. The attacker listed buckets, databases, EC2 instances, RDS snapshots, roles and KMS keys, then read Lambda function configurations (which return environment variables), called GetSecretValue on Secrets Manager entries and GetParameter on SSM parameters. From October 16 to 19 they ran TruffleHog, an open-source secret scanner, to test what they had found: AWS access keys checked with GetCallerIdentity, Microsoft Entra ID client secrets tried as service principal sign-ins, and Okta client credentials used to request OAuth tokens. That last step means one AWS integration can spill into your identity provider and SaaS tenants.

Wiz also found a separate run from October 8 to 11 in which customer-owned AWS access keys, apparently created for Qubole integrations, were all tested within one hour on October 8. A small number of those led to compromise. Wiz cannot link the two activities. On the attacker's OVH server it also found sso_agent.iso, a bootable Linux image that collects disk details, takes shell commands on TCP port 23458 and hard reboots after 90 minutes; Wiz has not seen it deployed. There is no attribution.

What to do

1. Find every role that trusts Qubole. In the IAM console, open Roles and look at the Trusted entities column for account 805246085872, or list roles with the AWS CLI and search their AssumeRolePolicyDocument for that number. Do this in every account in your organization, not just the data account.
2. Delete what you no longer use. If you have left Qubole, delete the role or remove the account from its trust policy today. Nothing else on this list matters as much for those accounts.
3. If you still run Qubole, narrow the trust policy. Qubole's setup guide has customers trust the whole account (:root); ask Qubole for the specific IAM principal it calls from and name that instead, and add an aws:SourceIp or aws:SourceVpce condition limited to the vendor's published networks. Wiz says a source IP condition alone would have blocked every assumption it observed, because all legitimate Qubole traffic came from AWS infrastructure. Ask Qubole to rotate the External ID, use a different value per role, and trim the role's access to Lambda configuration, Secrets Manager, SSM and broad S3 read.
4. Hunt from October 1. Wiz recommends reviewing CloudTrail from that date in every account that has an integration role. A CloudTrail Lake query along these lines finds the role assumptions:

SELECT eventTime, sourceIPAddress, userIdentity.principalId, userAgent, requestParameters
FROM <event_data_store_id>
WHERE eventName = 'AssumeRole'
  AND userIdentity.accountId = '805246085872'
  AND eventTime > '2026-10-01 00:00:00'

5. Triage the results. Any hit with principal AIDA3W7DIFLYOLTK63SFS is the attacker. Hits from AIDAJYRRH5Y3A7AAJM2HW, or from the account generally, are suspicious when sourceIPAddress is not an AWS address. Also check the indicator IPs in the graphic below and GetCallerIdentity calls with a TruffleHog user agent. Mullvad exits are shared, so one IP match alone proves nothing.
6. Follow each session. For every suspicious session, review everything that followed in Secrets Manager, SSM Parameter Store, Lambda and S3. Management events show bucket listings but not object reads; you need S3 data events or server access logs to know what was downloaded.
7. Rotate and revoke. Rotating a secret does not end sessions already issued. If a role was assumed, use Revoke active sessions on the role in the IAM console, then rotate every secret, parameter and Lambda environment variable the role could read. Check Entra ID service principal sign-in logs and Okta system logs for the same TruffleHog user agent, and rotate any client secrets that lived in AWS.

Vendor trust outlives the vendor

Third-party roles are created during onboarding and rarely reviewed after. The same exposure exists for any analytics, backup, monitoring or cost tool that once asked for a cross-account role. A quarterly report of every trust policy that names an outside account, matched against the vendors you still pay, catches the ones nobody owns. IAM Access Analyzer's external access findings will produce that list for an organization.

Cross-account trust is one of the first things we review in a cloud and Kubernetes security assessment, and security operations can run the CloudTrail hunt above across your accounts. If you are not sure whether an old integration role is still trusted somewhere, open the chat and Yaali, our AI agent, will pass the question to an engineer.

---

Sources: Wiz: Qubole cross-account access abused in the wild, The Register: Attackers backdoor trusted AWS integrations to steal secrets, Qubole docs: Creating a cross-account IAM role for QDS.