Qubole AWS Trust Abuse Shows Why Dormant Cloud Integrations Stay Dangerous

Qubole AWS Trust Abuse Shows Why Dormant Cloud Integrations Stay Dangerous

An attacker used credentials associated with Qubole's AWS account to enter multiple customer environments through cross-account IAM roles that had been created for the data platform. Wiz, working with Sentra and Mandiant, says the activity ran from October 14 to October 26, 2026, and involved resource discovery, secret harvesting, and S3 data access.

This is a supply-chain attack without a poisoned package or malicious update. The abused trust relationship was the integration itself: customers had authorized a vendor account, and the attacker used vendor-side credentials to request temporary access as if the vendor were performing normal work.

The forgotten role was the attack surface

Qubole integrations use customer-created IAM roles so the platform can orchestrate workloads in a customer AWS account. Those roles can remain active after a project ends, creating a dormant attack surface that is easy to overlook in cloud inventories.

Wiz observed calls to sts:AssumeRole from the Qubole-associated AWS account 805246085872. In affected environments, the actor used credentials tied to Qubole's account, then accessed roles that still trusted the vendor. The requests included the expected external ID, so the additional condition did not protect customers once the vendor-side credentials had been compromised.

The campaign was not limited to one account. A single vendor identity could test the same trust path across many customers, turning a third-party credential problem into a multi-tenant cloud intrusion. Wiz has not published a complete victim count, so organizations should not infer that they are safe because no public incident notice names them.

What the actor looked for

After assuming a role, the actor enumerated resources and searched for credentials in locations that are common in AWS environments:

• Lambda function configuration, which can expose environment variables.
• AWS Secrets Manager values and secret metadata.
• Systems Manager Parameter Store parameters.
• S3 buckets and objects reachable by the assumed role.

Wiz also observed the actor validating credentials found in customer environments, including AWS access keys, Microsoft Entra ID client secrets, and Okta credentials. That turns a cloud role compromise into a potential identity and SaaS compromise. The most important lesson is that a trusted integration role may reach more than the service it was originally created to operate.

Sentra's account of one affected customer describes roughly 100 passwords and keys read from three storage locations in seven minutes. It also reported no write actions in that investigation. Read-only theft can therefore remain invisible to teams that alert mainly on destructive changes, privilege escalation, or ransomware behavior.

Hunt before the logs expire

Wiz recommends reviewing CloudTrail from October 1, 2026 onward in every account that contains a Qubole integration role. Start with:

1. AssumeRole events where the caller account is 805246085872 and the source address is not normal AWS infrastructure.
2. Sessions or role activity associated with the IAM principal IDs identified in the Wiz report.
3. Rapid role assumptions across several accounts, especially with unusual quiam- session names.
4. Calls to ListSecrets, GetSecretValue, GetParameter, GetFunctionConfiguration, and S3 listing or object-read APIs immediately after role assumption.
5. Credential validation from unexpected infrastructure, including calls that test AWS, Entra ID, or Okta credentials.

CloudTrail management events may show the role assumption and secret APIs, but S3 object access requires the relevant data events or server-access logs. Preserve those records before normal retention removes them. This is a practical incident response exercise even when the investigation finds no evidence of successful exfiltration.

Close the trust path

Cloud teams should take these actions for Qubole and every other historical SaaS integration:

• Inventory all vendor-trusted roles across every AWS account, including roles with no recent use.
• Remove unused Qubole roles. For active integrations, narrow permissions to the exact resources and actions required.
• Review trust policies, external IDs, session duration, source conditions, and role chaining. An external ID helps prevent confused-deputy abuse, but it cannot compensate for stolen vendor credentials.
• Rotate every secret, key, token, and certificate that an affected role could read. Check downstream identity providers, not only AWS.
• Enable and retain CloudTrail, S3 data events, and alerts for unusual cross-account role use.
• Require an owner and review date for every third-party trust relationship; automatically flag roles that outlive the service they support.

The durable fix is not to ban cross-account access. It is to make the trust explicit, least-privileged, observable, and temporary wherever possible. A vendor integration that no one remembers is still an identity boundary—and attackers are willing to search every forgotten door.

References

1. Trusted by Default: Qubole Cross-Account Access Abused in the Wild
2. Inside the Qubole Supply Chain Attack: How Sentra Found It
3. Attackers backdoor trusted AWS integrations to steal secrets
4. AWS and Qubole Native Integrations