How the attacker used Qubole's trusted AWS access
Wiz's investigators say the intruder leveraged credentials for an AWS account that Qubole's platform uses to access customer environments. Qubole operates inside customer AWS accounts by having each customer create an IAM role whose trust policy allows Qubole's AWS account to assume the role. Every AssumeRole request in the incidents Wiz examined included an External ID and was accepted.
AWS will accept an AssumeRole request when it comes from the trusted account and includes the correct External ID, but the External ID is not treated as a secret and can be viewed by anyone with access to the role, according to AWS's external ID guidance cited by the researchers. How the attacker obtained the Qubole credentials has not been disclosed.
What the attacker accessed and exfiltrated
In the accounts Wiz examined, the attacker searched for and read stored credentials and configuration data: environment variables for Lambda functions; secrets in AWS Secrets Manager; and values in the SSM Parameter Store. The intruder tested harvested credentials with TruffleHog to see whether they worked, using victims' own AWS access keys, Entra ID client secrets, and Okta client credentials.
The attacker also copied data from S3. Rather than hunting for particular files, the intruder retrieved data from any bucket a compromised role could access and in some sessions downloaded an entire bucket. Wiz's researchers noted that most of the roles the attacker assumed were unused, but because they still trusted Qubole's account the attacker's AssumeRole requests succeeded.
Wiz has not linked this campaign to other publicly reported activity and said the targeting does not match what state-backed groups usually pursue. Separately, between October 8 and October 11 an attacker used customers' own AWS access keys — believed to have been set up for Qubole — to compromise several victims; Wiz did not link that activity to the AssumeRole abuse.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadDetection indicators and logging limits identified by Wiz
Wiz published specific hunting guidance for organizations that have connected Qubole to AWS. Key indicators to search for in CloudTrail logs from October 1 onward include:
- AssumeRole requests where userIdentity.accountId is 805246085872 and sourceIPAddress is not an AWS address.
- IAM principal ID AIDA3W7DIFLYOLTK63SFS — any activity from this user should be investigated because only the attacker used it in the accounts examined.
- IAM principal ID AIDAJYRRH5Y3A7AAJM2HW when the source address is outside AWS — Qubole's normal traffic also uses this principal, but the attacker used it from October 18.
- OVH-hosted addresses 57.129.54[.]120 and 2001:41d0:70d[:]7800::, and Mullvad VPN addresses 45.83.220[.]211, 185.209.199[.]73 and 89.37.63[.]175 (recognizing VPN addresses are shared and not by themselves proof).
- Role sessions whose names start with quiam-, such as quiam-enum, and GetCallerIdentity calls where the user agent is TruffleHog coming from the noted IPs.
Wiz also warned that CloudTrail management events log AssumeRole requests and bucket listings, but do not log which specific S3 objects were read. That requires S3 data events or S3 server access logs; several victims lacked those logs, preventing responders from determining exactly which objects the attacker accessed.
How to close the route: Wiz's recommended remediations
Wiz issued a set of concrete remediation steps. If the attacker assumed one of your Qubole roles, rotate all secrets, SSM parameters, and Lambda environment variables the role could reach, and revoke the role's active sessions — rotating credentials alone does not terminate already issued sessions.
- Remove any Qubole role you no longer need, or take Qubole's account out of the role's trust policy.
- Where supported, replace an account-wide :root principal in the trust policy with the specific IAM principal Qubole uses.
- Add an aws:SourceIp or aws:SourceVpce condition to limit AssumeRole requests to the vendor's documented network ranges — Wiz said a source IP condition alone would have blocked every observed role assumption in this campaign.
- Assume others can see the External ID: it is logged in CloudTrail and often appears in vendor documentation or infrastructure-as-code files, so do not use it as your only control. Wiz recommends changing it after an incident and, where possible, using a different External ID value for each role; specifically, they advise changing it to Qubole after an incident and using unique values per role.
- Review the reach of each vendor role — sample policies may grant broad S3 read access and access to Lambda settings, Secrets Manager, and SSM parameters for convenience.
- Set alerts for AssumeRole requests from a vendor account when they arrive via a VPN or a hosting company the vendor does not use, enable an organization trail across accounts and regions, and enable S3 data events or server access logs for buckets that store sensitive data.
What this means for technologists, procurement leaders, and affected enterprises
Technologists and security teams should hunt CloudTrail logs from October 1 forward for account 805246085872 and the listed indicators, rotate any exposed secrets, revoke role sessions, and enable S3 data events or server access logs where missing. Sentra's detection of the activity in customer environments was an early warning that researchers leveraged; defenders should map vendor roles and their effective permissions.
Procurement and cloud operations teams should remove unused vendor roles, require least-privilege trust policies (avoid :root where possible), and insist vendors document network ranges to support aws:SourceIp or aws:SourceVpce controls.
Affected enterprises that used AWS access keys for Qubole between October 8 and October 11 should treat those keys as suspect: Wiz believes an attacker used customers' own access keys in that window to compromise environments, and that activity has not been linked to the later AssumeRole abuse.
Wiz's researchers did not say whether the compromised credentials have been disabled or whether the activity has stopped. Neither Qubole nor Idera had posted a statement about the attack on their websites when The Hacker News checked.
