Qubole: unrevoked AWS access was used to steal secrets and data

On 9 November 2026, Wiz disclosed a campaign that hit several companies using Qubole, a cloud data processing platform. Le Monde Informatique set out how it unfolded on 10 November. Unidentified attackers used compromised credentials tied to Qubole’s AWS account to get into these customers’ cloud environments and steal secrets and data. Wiz calls it a broad, opportunistic supply-chain campaign, but has not said how many organisations were affected. The facts reported here come from the investigation by Wiz and by Mandiant’s incident response teams. It began after Sentra, a data security company, reported suspicious activity.

Access that outlives the customer relationship

The mechanism the attackers abused is a standard one. To manage compute resources and reach its customers’ storage, Qubole relies on IAM roles. Each customer uses a trust policy to allow Qubole’s AWS account to assume an integration role inside the customer’s own environment. The model has a real advantage: you never have to hand a provider long-lived AWS access keys.

That trust policy does not go away when you stop using the service. According to Wiz, many organisations left it in place after leaving the platform. That let the attackers reach environments where Qubole was no longer in use. The lesson goes beyond one vendor. Any role open to a third party gives access for as long as the trust relationship exists, whether or not the contract is still running.

From 14 to 26 October

The first malicious activity investigators traced dates from 14 October. Credentials linked to the Qubole account called the sts API to obtain temporary credentials for the integration roles managed by customers. The calls came from AWS account 805246085872, using IAM identifier AIDA3W7DIFLYOLTK63SFS. The activity continued on 15 October. From 18 October, a second IAM user in the same account came into use, and the activity went on until 26 October.

Once inside, the attackers took an inventory of resources, then collected credentials, keys and other secrets stored in Lambda, Secrets Manager and SSM Parameter Store. They pulled data out of S3, sometimes downloading entire buckets. They also used TruffleHog to test victims’ AWS credentials. They found Microsoft Entra ID secrets and requested OAuth tokens using Okta client credentials discovered in the AWS environments. So a cloud access that was never properly closed became a starting point for reaching other services.

Wiz does not attribute the campaign to any group and does not know what became of the stolen data. The researchers also spotted a separate campaign between 8 and 11 October that exploited AWS keys belonging to customers and used for Qubole integrations. It compromised a few environments, but no definitive link to the first campaign has been established.

What affected organisations should check

If your organisation has ever integrated Qubole, whether you still use it or not, you are advised to rotate your credentials. Rotation does not end temporary sessions that have already been issued. Wiz therefore recommends reviewing CloudTrail logs since 1 October and looking for AssumeRole events where the userIdentity.accountId field matches Qubole’s account, particularly when they come from IP addresses outside AWS.

For each session you find, review what was done next, especially in Secrets Manager, SSM Parameter Store, Lambda and S3. If the attacker used an integration role, the researchers recommend rotating every secret, parameter and Lambda environment variable that role could read, then revoking its active sessions. If your organisation has left the service, the integration role no longer has any reason to exist.

The integration role was meant to stop a long-lived key from sitting with a provider. Left in place after the customer left, it ended up doing exactly what a forgotten key does.