Qubole AWS integration roles abused to steal secrets and S3 data from customer environments

Linha do tempo

1. theregister.com ↗ · pub. 09/11/2026 16:59 · coletado 09/11 18:00 primeiro registro

   Qubole AWS integration roles abused to steal secrets and S3 data from customer environments

   ler a análise desta fonte ocultar

   Wiz reports that an unidentified threat actor used IAM credentials from the Qubole AWS account to call sts:AssumeRole against integration roles that customers had created to trust Qubole, reaching multiple victim AWS environments between October 14 and October 26, 2026 (wiz.io). Sentra flagged the suspicious activity, and Wiz investigated it with Google Mandiant (wiz.io). Once inside, the intruder enumerated resources, read Lambda environment variables, Secrets Manager and SSM Parameter Store values, validated harvested keys with TruffleHog, and downloaded S3 objects, in some cases entire buckets (wiz.io). Wiz describes the campaign as opportunistic and has not tied it to any known group, and the sources do not give a victim count. No CVE is involved: the roles accepted the requests because their trust policies still named the Qubole account and the attacker supplied a valid External ID, so the risk comes from trust configuration rather than a software flaw. Urgency is high because confirmed compromises span several customers and the stolen secrets remain usable until rotated.

   Technical Details

   • The first observed AssumeRole calls came on October 14 from a Mullvad VPN address (45.83.220[.]211), using AWS account 805246085872 and IAM user AIDA3W7DIFLYOLTK63SFS. From October 15 most activity came from an OVH-hosted VPS (57.129.54[.]120), and on October 18 a second IAM user from the same account and a second Mullvad address (185.209.199[.]73) were used (wiz.io).
   • Most assumed roles were otherwise unused. In most affected environments the attacker's requests were the only AssumeRole activity from the vendor account in October (wiz.io).
   • Session names followed the pattern quiam-*, such as quiam-enum and quiam-scope-full (wiz.io).
   • Okta client credentials and Microsoft Entra ID client secrets found in the victim environments were used to request tokens and sign in as service principals (wiz.io).
   • Wiz also documented a separate Qubole-linked campaign from October 8 to 11 that tested customer-owned AWS access keys believed to belong to Qubole integrations. It could not link that activity to the role-assumption campaign (wiz.io).
   • Wiz found a bootable ISO, sso_agent.iso, hosted on the OVH address during the campaign. It polls that address for shell scripts for 90 minutes, then reboots. Wiz has not seen it deployed (wiz.io).

   Remediation

   • Review CloudTrail from October 1, 2026 onward in every account holding a Qubole integration role. Look for AssumeRole events where the caller account is 805246085872 and the source IP is not an AWS address, and for the listed IAM principal IDs (wiz.io).
   • For each suspicious role session, review all later activity, especially Secrets Manager, SSM Parameter Store, Lambda and S3. Rotate every secret, parameter and Lambda environment variable the role could read, and revoke its active sessions. Rotating a credential does not end sessions already issued (wiz.io).
   • Remove trust for integrations no longer in use. Narrow the trusted principal, add aws:SourceIp or aws:SourceVpce conditions, and do not treat the External ID as a secret (wiz.io).
   • Reduce what integration roles can read, and alert on role assumption from new or unexpected networks (wiz.io).

   Conflicting Reports

   • The article says Qubole works without customers providing long-lived AWS access keys. Wiz's later research describes customer-owned AWS access keys that were believed to support Qubole integrations, so Wiz's account is the more specific one (wiz.io).
   • The article gives October 14 as the start of the activity. Wiz gives October 14 to October 26 as the observed window (wiz.io).