An attacker used credentials from an AWS account associated with data platform Qubole to break into the cloud accounts of multiple Qubole customers and steal stored secrets and data, cloud security company Wiz disclosed on Monday, 9 November.

Wiz said the activity ran from 14 to 26 October 2026. Working with Sentra, which first spotted suspicious activity across several of its customers, and Google's Mandiant incident responders, Wiz traced the attack to credentials for AWS account 805246085872, the account Qubole's platform uses to reach its customers.

Qubole, a data lake platform owned by Idera, operates inside its customers' AWS accounts. To let it in, a customer creates an IAM role with a trust policy that allows Qubole's AWS account to assume it, usually gated by a code known as an External ID. The attacker called the AssumeRole function with those credentials and received temporary access scoped to each customer's role.

Most of the roles the attacker assumed were not otherwise in use, Wiz said, but their trust policies were still in place, so the requests succeeded. Every AssumeRole request attributed to the attacker included an External ID, and every one was accepted. AWS does not treat the External ID as a secret, and it is logged in plain text in CloudTrail.

Secrets harvested and S3 data copied

Once inside a customer account, the attacker enumerated resources broadly, including storage buckets, databases, compute instances and identity roles. It then targeted the places where credentials are commonly stored: Lambda function environment variables, Secrets Manager and the SSM Parameter Store.

The attacker ran the credentials it found through the open-source tool TruffleHog to test whether they worked. Wiz said these were the victims' own credentials, including AWS access keys, Entra ID client secrets and Okta client credentials.

The attacker also copied data out of S3 storage. Wiz said it retrieved data from any bucket a role could reach rather than searching for specific data, and in some cases downloaded an entire bucket in a single session. The researchers described the targeting as opportunistic and said they had not linked the campaign to any other publicly reported activity, or to the priorities usually associated with state-backed groups.

How the credentials were obtained is not known

How the attacker obtained Qubole's credentials has not been disclosed. Wiz did not say whether the credentials have since been disabled or whether the activity has stopped. Neither Qubole nor its owner Idera had posted a statement about the incident when the findings were published.

Wiz also found a separate set of malicious activity from 8 to 11 October, in which an attacker used customers' own AWS access keys believed to have been created for Qubole integrations. In a small number of cases, that activity went on to compromise the victim's cloud environment. Wiz said it had not been able to link that activity to the role-assumption campaign.

Researchers also found a bootable Linux image, named sso_agent.iso, hosted on an OVH address used by the attacker. Wiz said the image appeared designed to gather system information and run scripts sent to it, but it had not identified any deployments of it and could not confirm whether or how it had been used.

What Qubole customers should check

Wiz advised any organisation that has connected Qubole to AWS, even one that no longer uses it, to review its CloudTrail logs from 1 October 2026 onward. The signs to look for include AssumeRole requests from account 805246085872 arriving from an address outside AWS, activity from IAM user AIDA3W7DIFLYOLTK63SFS, and role sessions with names starting with quiam-.

For any role the attacker assumed, Wiz said organisations should rotate every secret, parameter and Lambda environment variable the role could read, and revoke the role's active sessions. It also advised removing Qubole roles that are no longer needed, narrowing trust policies to the specific principal Qubole uses, and adding a source IP or VPC endpoint condition. Wiz said a source IP condition alone would have blocked every role assumption it observed.

Read Wiz's technical analysis and the report on the attack by The Register.