Atacante used Qubole AWS credentials to assume roles in client accounts and steal secrets

Between 14 and 26 October, an attacker exploited credentials associated with the AWS account using the Qubole platform to access the environments of several clients and extracted secrets and data, according to Wiz researchers' analysis. The method used was to assume roles (AssumeRole) that customers had created to allow Qubole to act within their accounts; those roles trusted the Qubole account (ID 805246085872) and required an External ID, which in this case the attacker could correctly include. The researchers also document previous activity, between 8 and 11 October, in which another actor - or possibly the same with a different technique - used AWS access keys of customers configured for Qubole; that preliminary stage was linked to commitments in some environments, but has not been publicly correlated with the abuse of AssumeRole that followed.

Facts confirmed: Wiz published a technical report detailing the campaign, and the investigation was initiated following alerts from Sentra. The attacker read Lambda function environment variables, extracted secrets from AWS Secrets Manager, obtained parameters from the SSM Parameter Store and downloaded S3 objects - sometimes by downloading an entire bucket if the role allowed. To validate removed credentials, the attacker used automated tools like TruffleHog. In addition, the researchers identified reproducible operational signatures: the Qubole 8052460872 account, two relevant main IAM IDs (AIDA3W7DIFLYOLTK63SFS, associated with the attacker in the cases examined, and AIDAJYRH5Y3A7AAAJM2HW, used by Qubole and also by the attacker since 18 October), public IP addresses linked to OVH and VPN servers (for example 57.129.54.120 and 45.83.220.211), which began with names and which, for example, it was known as "the" "" and "" the "" "" Haukrayr "of which,"

What allowed access and why it worked: Technically, Qubole works within the client's account through an IAM role whose confidence policy allows the Qubole account to take over the role. AWS validates that the AssumeRole application comes from the reliable account and that the External ID matches. The key problem in this incident was not a vulnerability in AWS, but the credentials that the attacker had on the supplier's side (the Qubole account) could be used to issue valid applications to roles still configured to trust that account. In addition, the External ID is not secret according to AWS's own guide: it is recorded in CloudTrail and is visible in infrastructure files and templates, so its knowledge by the attacker is not surprising. More technical details and general recommendations on selling roles are found on the Wiz research page and the AWS documentation on External ID ( Wiz Research, AWS External ID guidance).

To whom it affects and practical scope: any organization that has given an IAM role to Qubole, even if it no longer actively uses the platform, is potentially affected. In the environments examined, the attacker sought and took advantage of secrets that could unlock other resources and services: AWS access keys (which allow direct operation of the API), identity vendor secrets (e.g. enter / Okta) and application credentials. Where there was a lack of detailed S3 (S3 data events or server access logs), the response teams were unable to determine precisely which objects were read or copied, thus increasing the risk of exposure of sensitive information.

Which parts of the story are still not publicly confirmed: Wiz and the investigators have not publicly stated how the credentials that allowed the attacker to operate from the Qubole account were initially obtained or whether those credentials have already been revoked; neither had Qubole or his Idera matrix issued a public statement at the time the information was verified. There is no public and confirmed link between this campaign and other major incidents or conclusive evidence that it is an operation sponsored by an actor state; Wiz notes that the objectives do not conform to the usual pattern of state groups.

Actual and potential consequences: The exposure of secrets and access keys can allow the lateral climbing attacker within accounts, persistence through new credentials or integrations, data theft, and in environments integrated with other clouds or SaaS, commitment of federated identities. The lack of detailed records makes it impossible to determine the exact extent of exfiltration in all those affected, which complicates the response and mediation.

Specific and immediate measures to be taken by any equipment affected or used by Qubole with AWS: first, track the events in CloudTrail from October 1 onwards looking for AssumeRole where you will Identity.accountId = 805246085872 and source IPAddress is not an AWS address; investigate sessions whose session starts with "quiam-," called GetCallerIdentity with user-agent Truffleg and activity from the PIs identified by the researchers. Activate a comprehensive review of Secrets Manager, SSM Parameter Store, Lambda environment variables and S3 reading permissions that the role could reach; immediately roll all credentials (access keys, application secrets, client secrets) to which the role had visibility and change passwords or external tokens that may have been exposed. Note that rotating a secret that does not invalidate time sessions already issued; to block active sessions, remove or modify the confidence policy of the role (for example by removing the Qubole account from the trust policy or by replacing the main account with the specific MIU that the supplier documents) and, if appropriate, delete roles that are not used. Add conditions to the trust policy, such as aws: SourceIp or aws: SourceVpce, to limit from where the roles can be assumed - researchers indicate that in this case an IP condition would have blocked the observed assumptions. Implement an organizational trail and enable S3 data events or serve access logs in sensitive buckets to audit future object readings (see CloudTrail guide: AWS CloudTrail).

Finally, review and reduce the scope of permits granted to third-party roles: it is common to see the role of suppliers with wide reading permission on S3, access to Secrets Manager and SSM parameters "for convenience"; limit those permits to the minimum necessary and set up alerts for AssumeRole coming from VPS, hosting networks or VPN PIs not documented by the supplier. These actions do not ensure that a past commitment will no longer have consequences, but drastically reduce the window of future abuse and facilitate containment and audit.

This incident underlines that cross-trust between accounts and the management of credentials in vendor integrations require specific policies and records: it is not enough to delegate access, it is necessary to implement it and to restrict it proactively. Keep an eye on official Qubole or Idera communications and Wiz technical reports for additional updates and detections.