{"id":4129,"date":"2026-11-10T09:50:35","date_gmt":"2026-11-10T17:50:35","guid":{"rendered":"https:\/\/cyber.mag212.com\/?p=4129"},"modified":"2026-11-10T09:50:35","modified_gmt":"2026-11-10T17:50:35","slug":"qubole-aws-account-abused-customer-iam-roles-cross-account","status":"publish","type":"post","link":"https:\/\/cyber.mag212.com\/fr\/qubole-aws-account-abused-customer-iam-roles-cross-account\/","title":{"rendered":"Le compte AWS personnel de Qubole a \u00e9t\u00e9 utilis\u00e9 pour usurper les r\u00f4les IAM des clients et d\u00e9rober des secrets li\u00e9s au cloud et \u00e0 l'identit\u00e9."},"content":{"rendered":"\n

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\u2019s 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 (The Hacker News<\/a>). Many of the roles had not been used in years but still trusted the vendor.<\/p>\n\n\n\n

What<\/strong><\/td>Abuse of customer IAM roles that trust Qubole\u2019s AWS account 805246085872<\/code><\/td><\/tr>
When<\/strong><\/td>AssumeRole intrusions 14\u201326 October 2026; a separate, unlinked access-key campaign 8\u201311 October<\/td><\/tr>
Data at risk<\/strong><\/td>Lambda environment variables, Secrets Manager, SSM Parameter Store, S3 buckets, plus AWS, Entra ID and Okta credentials found there<\/td><\/tr>
Victims<\/strong><\/td>\u201cMultiple\u201d, number not disclosed<\/td><\/tr>
Vendor statement<\/strong><\/td>None from Qubole or Idera when The Hacker News checked<\/td><\/tr>
Evidence<\/strong><\/td>Reported (The Hacker News summarising Wiz; Wiz\u2019s own post not retrieved at press time)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

What happened<\/h2>\n\n\n\n

According to the reporting, Sentra noticed the activity in several of its customers\u2019 environments and alerted Wiz. The attacker made AssumeRole calls from Qubole\u2019s 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\u2019 own AWS access keys, an access option Qubole supports (The Hacker News<\/a>; primary: Wiz<\/a>).<\/p>\n\n\n\n

Who is affected<\/h2>\n\n\n\n

Any AWS account that contains an IAM role trusting Qubole\u2019s account is in scope, including roles nobody uses any more<\/strong>. The reporting notes that Qubole\u2019s setup guide includes a sample S3 policy that lets the role read every bucket in the account (The Hacker News<\/a>; Qubole documentation<\/a>). MAG212 CYBER analysis:<\/strong> 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.<\/p>\n\n\n\n

How the attack works<\/h2>\n\n\n\n

The reported sequence:<\/p>\n\n\n\n

    \n
  1. Assume the customer\u2019s role from Qubole\u2019s AWS account, presenting the expected External ID.<\/li>\n\n\n
  2. Read Lambda environment variables, Secrets Manager secrets and SSM Parameter Store values.<\/li>\n\n\n
  3. Validate harvested credentials with the open-source tool TruffleHog. They included victims\u2019 AWS keys, Entra ID client secrets and Okta client credentials.<\/li>\n\n\n
  4. Copy S3 data, sometimes an entire bucket in a single session.<\/li>\n\n<\/ol>\n\n\n\n
    \"Flow
    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<\/figcaption><\/figure>\n\n\n\n

    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\u2019s credentials, how many organisations were affected, or whether Qubole will publish its own account.<\/p>\n\n\n\n

    What to look for<\/h2>\n\n\n\n

    Wiz published indicators, as reported by The Hacker News (The Hacker News<\/a>):<\/p>\n\n\n\n

    Indicator<\/th>Context<\/th><\/tr><\/thead>
    Account 805246085872<\/code><\/td>Qubole\u2019s account; flag AssumeRole calls from non-AWS IP addresses<\/td><\/tr>
    Principal AIDA3W7DIFLYOLTK63SFS<\/code><\/td>Seen only with the attacker; investigate all of its activity<\/td><\/tr>
    Principal AIDAJYRRH5Y3A7AAJM2HW<\/code><\/td>Also used legitimately by Qubole; suspicious only from outside AWS<\/td><\/tr>
    57.129.54[.]120<\/code>, 2001:41d0:70d[:]7800::<\/code><\/td>OVH addresses<\/td><\/tr>
    45.83.220[.]211<\/code>, 185.209.199[.]73<\/code>, 89.37.63[.]175<\/code><\/td>Mullvad shared VPN exits; not proof on their own<\/td><\/tr>
    Role session names starting quiam-<\/code><\/td>Attacker session naming, e.g. quiam-enum<\/code><\/td><\/tr>
    TruffleHog user agent on GetCallerIdentity<\/code><\/td>Credential validation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Wiz\u2019s exact detection queries were in its primary post, which we could not retrieve, so we are not reproducing any queries.<\/p>\n\n\n\n

    Investigate, contain and fix<\/h2>\n\n\n\n
      \n
    1. Review CloudTrail from 1 October 2026 in every account that holds a role trusting Qubole.<\/li>\n\n\n
    2. Revoke active sessions for any abused role. Rotating keys alone does not end sessions already issued.<\/li>\n\n\n
    3. Rotate everything the role could reach, including Entra ID and Okta application credentials stored in AWS.<\/li>\n\n\n
    4. Delete vendor roles you no longer need.<\/li>\n\n\n
    5. Where Qubole supports it, replace a :root<\/code> trust principal with Qubole\u2019s specific principal.<\/li>\n\n\n
    6. Add an aws:SourceIp<\/code> or aws:SourceVpce<\/code> condition. The researchers say \u201ca source IP condition alone would have blocked every role assumption we observed\u201d (The Hacker News<\/a>).<\/li>\n\n\n
    7. Turn on an organisation-wide CloudTrail and S3 data events or server access logs; management events don\u2019t show object reads.<\/li>\n\n<\/ol>\n\n\n\n

      Why the External ID did not help<\/h2>\n\n\n\n

      An External ID exists to stop the \u201cconfused deputy\u201d problem: it makes sure a vendor acting on behalf of one customer cannot be tricked into using another customer\u2019s role. It was never designed to protect against someone who controls the vendor\u2019s own account, because that party already has the External ID it would normally present (AWS guidance<\/a>). 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<\/code> adds something the vendor\u2019s stolen credentials cannot supply on their own.<\/p>\n\n\n\n

      Questions to ask your other cloud vendors<\/h2>\n\n\n\n

      MAG212 CYBER analysis:<\/strong> the same pattern can apply to any SaaS product that reaches into your cloud through a cross-account role. Useful questions for each one:<\/p>\n\n\n\n