Summary
- Researchers observed attackers using Qubole-associated AWS account credentials to access customer environments between 14 and 26 October.
- The activity included cloud reconnaissance, access to stored secrets and exfiltration from Amazon S3.
- Some abused third-party integration roles had otherwise been largely dormant, highlighting the risks of persistent supplier permissions.
Attackers gained access to multiple organisations’ Amazon Web Services environments by abusing trusted credentials associated with data platform Qubole, exposing weaknesses in integrations that retain privileged access long after their original purpose has changed.
Cloud security researchers from Wiz, working with Sentra and Google’s Mandiant, identified unauthorised activity between 14 and 26 October 2026 involving an AWS account used by Qubole’s platform.
The findings, published on 9 November, establish that the attacker used credentials associated with the vendor account to assume AWS Identity and Access Management roles created by customers to trust that account.
Once access was established, the attacker examined cloud resources, collected configuration information, retrieved stored secrets and downloaded data from Amazon S3 buckets.
Wiz has not established publicly how the attacker originally obtained the vendor-associated credentials. Its research therefore identifies the mechanism used to enter customer environments without confirming the initial compromise of the third-party identity.
Qubole is a data processing and analytics platform that can operate against resources inside customers’ AWS accounts. To support those integrations, customers may establish IAM roles allowing the vendor to perform approved actions within their environments.
Those permissions create an intended relationship between the two organisations. The attacker exploited that existing trust rather than needing to compromise every customer’s cloud account directly.
Valid trust relationships permitted access
AWS cross-account IAM roles allow an external principal to receive temporary credentials granting the permissions associated with a customer-defined role.
Such arrangements commonly include an external identifier intended to help ensure that the correct customer relationship is being used. However, an external identifier does not independently establish that a request came from a legitimate operator when the trusted vendor identity itself is compromised.
In the observed campaign, the attacker’s role assumption requests supplied the expected external identifiers and succeeded. The customer environments accepted the requests because they matched the established trust policies.
Wiz found that many of the targeted roles were rarely used for legitimate operations. In most of the environments it examined, the attacker’s requests were the only observed role assumption activity associated with that vendor account during October.
This suggests that some relationships had continued to retain access even though regular platform activity was limited or absent.
Once inside the affected accounts, the attacker examined storage, compute, databases, encryption configuration and identity resources. The activity included inspecting AWS Lambda function configurations, Secrets Manager entries and Systems Manager Parameter Store data.
Those services can contain application configuration and credentials needed to connect to other business systems. Depending on permissions and the information stored, access to one cloud account may therefore expose authentication material usable beyond AWS itself.
Researchers observed the use of the open-source credential discovery tool TruffleHog to validate material obtained from the affected environments, including AWS access keys and credentials associated with Microsoft Entra ID and Okta.
The validation activity does not establish that every discovered credential was subsequently used to compromise another service. It does demonstrate that the attacker examined whether the material could provide additional access.
Data theft crossed established cloud boundaries
Wiz confirmed data exfiltration from Amazon S3. The attacker used the permissions available through assumed roles to list storage resources and retrieve objects, in some cases downloading extensive contents from accessible buckets.
The attack therefore involved more than exploratory scanning. Researchers observed the retrieval of cloud data through permissions that had been legitimately granted to a trusted integration.
Sentra, which first identified suspicious activity in customer environments, contributed to the investigation and described how researchers traced affected data back to accessible S3 resources.
In one investigated environment, Sentra documented rapid access to numerous stored credentials, while Wiz identified related behaviour across multiple customers. The precise scale and content of data exposure must be assessed separately for each affected organisation.
The incident reflects a broader cloud security problem: trusted identities created for suppliers can remain active without receiving the same scrutiny as employee accounts or internally managed application identities.
Traditional authentication checks may show that a permitted role was used successfully. They do not necessarily establish whether the action was consistent with the supplier’s expected behaviour or whether the supplier identity remained under legitimate control.
Where integration roles carry excessive permissions, an attacker can exploit the entire range of authorised actions. Limiting those permissions and reviewing whether integrations remain necessary can reduce the amount of data exposed through a compromised trust relationship.
Wiz also identified a separate set of suspicious activity involving customer-owned AWS keys associated with Qubole integrations during 8–11 October. The researchers have not established that this activity was conducted by the same threat actor, and it should not be combined with the principal campaign as one confirmed operation.
The October intrusion demonstrates that cloud supply chain compromises need not involve malicious software updates or direct attacks against every customer. A compromised identity belonging to a trusted supplier can provide a route into multiple environments through ordinary access mechanisms.
Investigators have published indicators and guidance for examining AWS activity associated with the campaign. Their findings confirm abuse of established cross-account permissions and data theft from customer environments, while leaving the initial acquisition of the vendor-associated credentials unresolved.
