ARTICLE ORIGINAL MAG212 CYBER

Le compte AWS personnel de Qubole a été utilisé pour usurper les rôles IAM des clients et dérober des secrets liés au cloud et à l'identité.

10 novembre 2026 · El Mostafa Ouchen

MAG212 CYBER illustration: a vendor cloud account linked by trust arrows to several customer accounts, one arrow highlighted red, headline 'A vendor's AWS account turned on its customers'.

An attacker holding credentials for the AWS account of Qubole, a data lake platform owned by Idera, used that account to step into the AWS environments of Qubole’s customers. They did it the way Qubole itself would: by assuming the IAM roles customers had created to trust Qubole, complete with the correct External ID. Research by Wiz, reported by The Hacker News on 9 November, says the attacker then read secrets, tested the credentials they found and copied S3 data (Les actualités des hackers). Many of the roles had not been used in years but still trusted the vendor.

QuoiAbuse of customer IAM roles that trust Qubole’s AWS account 805246085872
QuandAssumeRole intrusions 14–26 October 2026; a separate, unlinked access-key campaign 8–11 October
Data at riskLambda environment variables, Secrets Manager, SSM Parameter Store, S3 buckets, plus AWS, Entra ID and Okta credentials found there
Victimes“Multiple”, number not disclosed
Vendor statementNone from Qubole or Idera when The Hacker News checked
PreuveReported (The Hacker News summarising Wiz; Wiz’s own post not retrieved at press time)

Ce qui s'est passé

According to the reporting, Sentra noticed the activity in several of its customers’ environments and alerted Wiz. The attacker made AssumeRole calls from Qubole’s account into customer-created roles, supplying the right External ID each time. Most of the roles involved were no longer in use, yet still trusted Qubole. From 18 October the attacker also used a Qubole IAM user. Separately, between 8 and 11 October, an actor not linked to the first used customers’ own AWS access keys, an access option Qubole supports (Les actualités des hackers; primary: As).

Qui est concerné ?

Any AWS account that contains an IAM role trusting Qubole’s account is in scope, y compris des rôles que plus personne n'utilise. The reporting notes that Qubole’s setup guide includes a sample S3 policy that lets the role read every bucket in the account (Les actualités des hackers; Qubole documentation). Analyse CYBER MAG212 : MSPs should assume a forgotten vendor role exists in at least some client accounts until an inventory proves otherwise, and the lesson applies to every third-party integration, not just Qubole.

Comment fonctionne l'attaque

The reported sequence:

  1. Assume the customer’s role from Qubole’s AWS account, presenting the expected External ID.
  2. Read Lambda environment variables, Secrets Manager secrets and SSM Parameter Store values.
  3. Validate harvested credentials with the open-source tool TruffleHog. They included victims’ AWS keys, Entra ID client secrets and Okta client credentials.
  4. Copy S3 data, sometimes an entire bucket in a single session.
Flow diagram: Qubole's AWS account assumes customer IAM roles with an External ID, reads Lambda, Secrets Manager, SSM and S3, then validates AWS, Entra ID and Okta credentials with TruffleHog; a band lists six defences.
How trusted vendor access became the attack path, with the defences that would have blocked it. Based on Wiz research as reported by The Hacker News. Diagram: MAG212 CYBER

The step from AWS secrets to Entra ID and Okta credentials matters: a cloud-storage incident can become an identity incident. We do not know how the attacker obtained Qubole’s credentials, how many organisations were affected, or whether Qubole will publish its own account.

Que rechercher

Wiz published indicators, as reported by The Hacker News (Les actualités des hackers):

IndicateurContexte
Compte 805246085872Qubole’s account; flag AssumeRole calls from non-AWS IP addresses
Principal AIDA3W7DIFLYOLTK63SFSSeen only with the attacker; investigate all of its activity
Principal AIDAJYRRH5Y3A7AAJM2HWAlso used legitimately by Qubole; suspicious only from outside AWS
57.129.54[.]120, 2001:41d0:70d[:]7800::OVH addresses
45.83.220[.]211, 185.209.199[.]73, 89.37.63[.]175Mullvad shared VPN exits; not proof on their own
Role session names starting quiam-Attacker session naming, e.g. quiam-enum
TruffleHog user agent on GetCallerIdentityCredential validation

Wiz’s exact detection queries were in its primary post, which we could not retrieve, so we are not reproducing any queries.

Enquêter, contenir et réparer

  1. Review CloudTrail from 1 October 2026 in every account that holds a role trusting Qubole.
  2. Revoke active sessions for any abused role. Rotating keys alone does not end sessions already issued.
  3. Rotate everything the role could reach, including Entra ID and Okta application credentials stored in AWS.
  4. Delete vendor roles you no longer need.
  5. Where Qubole supports it, replace a :root trust principal with Qubole’s specific principal.
  6. Ajouter un aws:SourceIp ou aws:SourceVpce condition. The researchers say “a source IP condition alone would have blocked every role assumption we observed” (Les actualités des hackers).
  7. Turn on an organisation-wide CloudTrail and S3 data events or server access logs; management events don’t show object reads.

Why the External ID did not help

An External ID exists to stop the “confused deputy” problem: it makes sure a vendor acting on behalf of one customer cannot be tricked into using another customer’s role. It was never designed to protect against someone who controls the vendor’s own account, because that party already has the External ID it would normally present (Conseils AWS). In this case the attacker was, in effect, Qubole, so every check the customer had configured was satisfied. A network condition such as aws:SourceIp adds something the vendor’s stolen credentials cannot supply on their own.

Questions to ask your other cloud vendors

Analyse CYBER MAG212 : the same pattern can apply to any SaaS product that reaches into your cloud through a cross-account role. Useful questions for each one:

  • Which fixed IP ranges or VPC endpoints do you use, so we can pin the role to them?
  • Can the trust policy name a specific principal rather than your whole account?
  • What is the least-privilege policy you actually need, instead of the sample in your setup guide?
  • How will you notify us if your own AWS account is compromised?

Comment confirmer que vous êtes propre

  • No role trusting Qubole, or any other vendor, remains without a source condition or a current business owner.
  • The rotated secrets are the ones applications now use, and old ones are disabled.
  • S3 data-event logging is active, and CloudTrail shows no further activity from the indicators above.

Leçons pour les administrateurs, le personnel et les dirigeants

  • Cloud admins: don’t treat an External ID as a secret; it prevents confused-deputy mix-ups, not theft of the vendor’s own access (Conseils AWS).
  • MSPs: today’s task is an inventory of vendor cross-account roles across every client AWS account, with an owner and a last-used date for each.
  • Dirigeants : every integration you approve leaves a standing door. Ask for a list of vendor access that has not been used in 90 days, and close it.

Ce que nous ignorons encore

  • How the attacker obtained Qubole’s account credentials.
  • How many customers were affected.
  • Whether Qubole or Idera will issue guidance or notifications.

Sujets connexes sur MAG212 CYBER

Sources