Compromised AWS Credentials Linked to Qubole Gave Attacker Access to Customer Environments

Researchers at Wiz and Sentra described a campaign in which an attacker entered AWS accounts belonging to Qubole platform customers through trusted IAM roles and obtained secrets and S3 data.

Qubole AWS credentials were used by an attacker to enter customers’ cloud environments through trusted cross-account IAM roles. According to Wiz researchers, the activity took place between October 14 and 26, 2026. The attacker obtained configurations and secrets and accessed objects stored in Amazon S3.

The Qubole platform used the affected AWS account to access customer environments. If a customer still trusted that account through an IAM role using AssumeRole, valid credentials could have allowed the attacker to assume the role and act within the scope of its permissions.

Qubole AWS Credentials and Access Through AssumeRole

Wiz said it observed unauthorized access to multiple AWS environments. The attacker used a trusted relationship configured between the AWS account associated with Qubole and customer accounts. This was therefore not a theoretical configuration flaw: researchers describe actual access to customer resources and data exfiltration.

Within the affected environments, the actor reportedly collected data from AWS Secrets Manager, SSM Parameter Store, and environment variables of AWS Lambda functions. These services and settings may contain passwords, access keys, tokens, or other data needed to access additional systems. Wiz also recorded downloads of objects from S3.

Sentra said the campaign affected more than a dozen organizations. SecurityWeek independently reproduced this number based on the researchers’ findings. However, the identities of the affected organizations have not been publicly confirmed, nor has the full extent of the data obtained.

External ID Does Not Protect Against Compromised Credentials

The case concerns third-party access in the cloud. An organization can allow an external provider to assume a specific IAM role in its AWS account, for example to operate an integrated service. External ID may also be used in such a setup to help distinguish individual customers.

The case also shows that External ID alone may not be sufficient if an attacker obtains valid provider credentials and the information needed to use the trusted relationship. The scope of the assigned role’s permissions, reviews of existing trust policies, and regular removal of access no longer needed by the integration are therefore also important.

It has not been publicly confirmed how the attacker obtained the credentials associated with the Qubole AWS account. Wiz did not attribute the attack to a specific group or state and did not disclose the actor’s motivation. Researchers found an ISO file on the actor’s infrastructure, but did not confirm that it had been deployed against victims.

What Qubole Customers Should Check

Wiz published indicators of compromise and recommended that Qubole customers review AWS CloudTrail records from October 1, 2026. The review should focus in particular on unusual AssumeRole events and subsequent activity in services that handle sensitive data or data storage.

  • Verify whether AWS accounts still contain trusted IAM roles for Qubole or related integrations.
  • Remove unused roles or restrict their permissions to the necessary scope.
  • Review CloudTrail from October 1, 2026, including role assumptions and access to Secrets Manager, SSM Parameter Store, Lambda, and S3.
  • Rotate available secrets, especially if they may have been read from the affected services or environment variables.
  • Compare findings with the indicators of compromise published by Wiz.

Wiz also described separate activity from October 8 to 11, during which someone tested customer AWS keys created for Qubole integrations. The connection between this activity and the main campaign has not yet been reliably confirmed.

What Comes Next

Further information may come from statements by Qubole, Idera, or AWS, particularly regarding the origin of the compromised credentials and notification of customers. Researchers may also publish new indicators of compromise, revised recommendations, or more precise data on the number of affected organizations and the extent of the exfiltration.

Sources

  • Wiz – Researchers’ primary technical findings on the timeline, abuse of AssumeRole, theft of secrets and S3 data, as well as indicators and mitigation steps.
  • Sentra – Sentra’s findings on the campaign’s scope, the impact on more than a dozen organizations, and abuse of inactive trusted roles.
  • SecurityWeek – Independent reporting on the number of affected organizations and the nature of the stolen data.

Verified and updated: November 10, 2026 15:29

Sharing