Qubole-Linked AWS Credentials Exposed More Than a Dozen Organizations

Avatar photo

ByRyan Mitchell

November 11, 2026

Researchers say attackers abused Qubole-related AWS credentials and dormant customer roles to steal cloud data, prompting urgent reviews of access, secrets and active sessions.

Attackers used compromised credentials associated with big-data platform Qubole to enter the Amazon Web Services environments of more than a dozen organizations and steal data, according to research from Wiz, Sentra and Mandiant. The campaign shows how access granted to a vendor can remain a risk after customers stop using its service.

The attackers used Qubole-related AWS credentials to assume roles that customers had created for the platform. Cross-account roles are a standard way for cloud services to access customer environments. Customers typically grant a vendor’s AWS account permission to assume a role, using an External ID as an additional check. Researchers said every attributed request included the valid External ID and succeeded.

Wiz and Sentra observed the main campaign from October 14 to October 26. The attackers enumerated cloud resources, collected secrets and configurations, and accessed data. Wiz identified role sessions beginning “quiam-,” including “quiam-enum” and “quiam-scope-full.” In many observed environments, the attacker was the only entity assuming the vendor role during October.

Some roles had been left in place after customers stopped using Qubole. Sentra said certain roles could read nearly all the data the attackers sought. A dormant integration can therefore remain a route into a cloud account when the credentials it trusts are compromised.

The attackers searched AWS storage locations for secrets, tested credentials with TruffleHog, then took data from customer S3 buckets. Wiz said the activity appeared opportunistic: attackers read what each role could reach, sometimes downloading entire buckets. Stolen material included AWS keys, Microsoft Entra ID service-principal secrets, Okta OAuth credentials, source-control and CI credentials, database and identity-provider secrets, monitoring keys and vendor tokens, Sentra reported.

Researchers also identified a separate Qubole-related campaign active October 8–11. Attackers tested customer-owned AWS access keys created for Qubole integrations and, in a small number of cases, used them to compromise cloud environments. This was distinct from the later abuse of Qubole’s credentials and customer roles.

The activity came through rented OVH infrastructure and Mullvad VPN connections, not Qubole’s network, Sentra said. Wiz found an attacker-hosted bootable Linux image, `sso_agent.iso`, on the OVH infrastructure. It gathered system information, communicated over TCP port 23458 and could execute remotely supplied shell commands. Wiz found no evidence it was deployed against victims and could not confirm it was used in the attacks.

Small IT teams should check whether Qubole integrations and AWS roles remain necessary. Wiz recommends reviewing CloudTrail from October 1 for `AssumeRole` activity involving Qubole-related roles, including sessions with the “quiam-” naming pattern. Remove obsolete roles. For integrations still in use, restrict permissions to the resources and actions they require.

Rotate every secret, parameter and Lambda environment variable accessible to the assumed roles, and revoke active sessions. Credential rotation alone does not end temporary sessions that have already been issued. Teams should also review S3 access for unusual reads and investigate whether exposed credentials were used elsewhere. Since stolen material included credentials for other services, rotation may need to cover source control, CI, identity providers and databases as well as AWS.

The activity has not been attributed to a known threat group. Wiz said it found no links to other publicly reported campaigns and could not determine the attacker’s motive or intended use of the stolen data. Researchers’ findings point to an immediate priority for affected organizations: close unneeded access and establish which data and credentials were exposed.

Leave a Reply

Your email address will not be published. Required fields are marked *