Security Operations

Qubole’s trusted AWS role abused to raid customer clouds: how to hunt

An attacker used Qubole’s AWS account to assume dormant customer roles, steal secrets and copy S3 data. How to hunt for it and harden vendor trust.

Radar graphic illustrating hunting for abused vendor IAM roles in AWS cloud accounts

An attacker holding credentials for Qubole’s own AWS account walked into customer cloud environments through integration roles that, in most cases, were no longer in use. Wiz has published hunting guidance, and any organisation that ever connected Qubole should be working through its CloudTrail logs this week.

What happened

On 9 November 2026 Wiz disclosed a campaign in which a threat actor abused the cross-account trust that Qubole customers grant to the data platform’s AWS account. Wiz investigated alongside Sentra and Mandiant. Qubole, a data lake service now owned by Idera, runs workloads inside customers’ AWS accounts through IAM roles that its platform account is allowed to assume.

Between 14 and 26 October, someone used IAM credentials belonging to that Qubole-associated account to assume those customer roles. Each request carried the correct External ID, so AWS accepted it. How the attacker obtained the vendor-side credentials has not been made public. Once inside, the intruder hunted for stored secrets in Lambda, Secrets Manager and SSM Parameter Store, checked which still worked, and copied S3 data, sometimes whole buckets.

According to Wiz, the harvested material included AWS access keys, Microsoft Entra ID client secrets and Okta client credentials. Wiz also describes a separate cluster of activity between 8 and 11 October, in which customer-owned access keys thought to have been created for Qubole integrations were tested and, in a few environments, used successfully. It has not linked the two, has not attributed the campaign and would not give a victim count. Neither Qubole, Idera nor AWS had commented publicly at the time of writing.

The technical picture

The striking detail is how quiet the abused roles were. Wiz reports that in most affected environments, the attacker’s role assumptions were the only ones made from the vendor account during October. Most of the abused roles were no longer in use but still trusted Qubole’s account, leaving dormant roles nobody was watching.

The External ID did not help. It exists to stop the “confused deputy” problem between a vendor’s customers and was never meant to be a secret. As Wiz and other reporting point out, it appears in plain text in CloudTrail and is often stored by the vendor and in infrastructure-as-code, so anyone with access to the vendor side can usually supply it.

The attacker left useful traces. Role sessions were named with a “quiam-” prefix. Requests came largely from OVH-hosted infrastructure and Mullvad VPN addresses rather than from inside AWS, which is where Qubole’s legitimate traffic would be expected to originate. The validation calls made with TruffleHog show up as GetCallerIdentity events with that tool’s user agent. Wiz has published the vendor account ID (805246085872), two IAM principal IDs, one of which it says only the attacker used, and a list of IP addresses, while warning that the Mullvad exits are shared and a match alone proves little.

The biggest gap for responders was visibility. CloudTrail management events record that an S3 bucket was listed or accessed in broad terms, but they do not record which individual objects were read. Several victims had not enabled S3 data events or server access logs, so they could see the attacker arrive but could not say exactly what left.

Checklist of six hunting and hardening steps for AWS roles that trust third-party vendors such as Qubole

Why it matters for UK organisations

No UK victim has been named, but the pattern is not specific to Qubole or to any country. UK businesses use many SaaS products that ask for an IAM role in their AWS accounts, from monitoring and backup to analytics and security tooling. Every one of those roles is a standing door that opens to whoever controls the vendor’s credentials. When a supplier is compromised, your own MFA and endpoint controls do nothing, because the request looks legitimate.

This is exactly the supplier risk that the UK’s Cyber Security and Resilience legislation and the NCSC’s supply chain guidance are pushing organisations to manage. There is a data protection angle too: if personal data sat in a reachable bucket and logs cannot show it was untouched, the UK GDPR assessment gets harder, and the ICO’s 72-hour clock does not wait.

The Entra ID and Okta secrets matter too: they offer a route from the cloud account into identity platforms behind Microsoft 365 and other business systems.

Expert view

In my experience, cross-account roles are one of the least reviewed parts of an AWS estate. When we test cloud environments, we routinely find trust policies naming vendors the organisation stopped paying years ago, often granting broad read access because the vendor’s onboarding template asked for it. The Hacker News reports that Qubole’s sample S3 policy grants read access to every bucket.

The encouraging point is that this attack was very detectable. Dormant roles suddenly being assumed, from VPN and hosting ranges a vendor has never used, should be a high-fidelity signal with few false positives. Wiz says a source IP condition on the trust policy alone would have stopped every role assumption it observed.

The lesson I would stress to SOC teams is that rotating a secret is not the same as evicting an attacker. Temporary role credentials already issued remain valid until they expire, so incident responders need to revoke active sessions explicitly as well as rotating whatever the role could reach.

What to do now

  1. Hunt first. In every account that has, or ever had, a Qubole role, review CloudTrail from 1 October 2026. Look for AssumeRole events from the Qubole account originating outside AWS, “quiam-” sessions and TruffleHog user agents. Check Entra ID and Okta sign-in logs for service principals behaving unusually.
  2. If you find a hit, scope widely. Treat every secret, SSM parameter and Lambda environment variable the role could read as compromised. Rotate them, revoke the role’s active sessions, and assume any reachable S3 data may have been copied unless data events prove otherwise.
  3. Inventory external trust. List every IAM role that trusts an account outside your organisation. Delete roles for retired integrations and any role with no clear owner. This maps directly to the Cyber Essentials secure configuration and user access control requirements.
  4. Tighten the trust policies you keep. Name the specific vendor principal rather than the whole account, add source IP or VPC endpoint conditions using the vendor’s published ranges, and trim permissions to the buckets and services the integration genuinely needs.
  5. Treat External IDs as public. Rotate them with the vendor after any incident and use a unique value per role.
  6. Close the logging gap. Run an organisation-wide trail across all accounts and regions, and enable S3 data events or server access logs for buckets holding sensitive or personal data.
  7. Alert on the pattern. Build a detection for vendor role assumptions from networks that vendor has not used before, and for any assumption of a role that has been idle for more than 30 days.

Bottom line

The Qubole campaign did not need a vulnerability in AWS or a single phishing email to a customer. It simply used trust that customers had granted and then left in place. Every AWS customer should find its forgotten vendor roles, lock them down or delete them, and make sure the logs exist to show what was taken if one is ever abused.

Sources

Related Posts