Attacker abuses Qubole's trusted AWS cross-account roles to steal secrets and S3 data from customers

Linha do tempo

1. thehackernews.com ↗ · pub. 09/11/2026 14:51 · coletado 09/11 17:00 primeiro registro

   Attacker abuses Qubole's trusted AWS cross-account roles to steal secrets and S3 data from customers

   ler a análise desta fonte ocultar

   An unidentified attacker used IAM credentials from Qubole's own AWS account between October 14 and October 26, 2026 to assume integration roles that customers had created to trust that account, then operated inside multiple customer AWS environments. Wiz, working with Sentra and Mandiant (wiz.io), reports that the actor listed resources, harvested secrets from Lambda, AWS Secrets Manager and SSM Parameter Store, tested the stolen keys against AWS, Entra ID and Okta, and copied S3 data, sometimes whole buckets. Every attributed AssumeRole call carried the External ID and succeeded, because the trust policies stayed in place even on roles no longer in use. How the attacker obtained the Qubole account credentials has not been disclosed, and neither Qubole nor Idera had published a statement when the article was checked; the research found no Qubole or Idera advisory and no CVE. A separate campaign from October 8 to 11 used customer-owned AWS access keys believed to be set up for Qubole integrations, compromised a small number of environments, and has not been linked to the role abuse. Criticity is critical because the activity is confirmed, active, and has resulted in credential theft and data exfiltration across several customers, although exploitation depends on a trust relationship customers had already configured and no vulnerability in the product is named.

   Technical Details

   • The first observed activity was on October 14 from a Mullvad VPN address, 45.83.220[.]211, using IAM user AIDA3W7DIFLYOLTK63SFS in Qubole's account 805246085872. From October 15 most activity came from an OVH-hosted address, 57.129.54[.]120, and from October 18 the attacker also used IAM user AIDAJYRRH5Y3A7AAJM2HW, which carries legitimate Qubole traffic (wiz.io).
   • Role sessions used the prefix quiam-, for example quiam-enum and quiam-scope-full (wiz.io).
   • Discovery covered buckets, objects, databases, instances and IAM keys. The attacker read Lambda environment variables through GetFunctionConfiguration, listed and read Secrets Manager values, and read SSM parameters (wiz.io).
   • The attacker ran TruffleHog against the victims' AWS access keys, Entra ID client secrets and Okta client credentials. These belonged to the affected organizations, not to Qubole (wiz.io).
   • Data theft was opportunistic: the attacker read from whatever buckets each role could reach. CloudTrail management events show the role assumption and bucket listing but not object reads, so several victims could not tell which objects were taken (wiz.io).
   • Wiz also identified a bootable Linux ISO, sso_agent.iso, hosted on 57.129.54[.]120. It polls a TCP port for commands, and Wiz has not seen it deployed (wiz.io).
   • From October 8 to 11, an actor tested customer-owned AWS keys within a single hour on October 8 and, in a small number of cases, compromised the environment (wiz.io).

   Remediation

   • Review CloudTrail from October 1 onward in every account that holds a Qubole role, looking for AssumeRole calls from account 805246085872 that come from a non-AWS address, and for activity from the listed principal IDs.
   • If a Qubole role was assumed by the attacker, rotate every secret, SSM parameter and Lambda environment variable that role could read, and revoke its active sessions. Rotating credentials does not end sessions already issued.
   • Delete Qubole roles that are no longer needed, or remove Qubole's account from their trust policies.
   • Where Qubole supports it, replace the account-wide :root principal with the specific IAM principal Qubole uses, and add an aws:SourceIp or aws:SourceVpce condition limited to Qubole's documented network ranges.
   • Treat the External ID as non-secret, since it is logged in plain text. Rotate it with Qubole and use a different value per role where possible.
   • Limit each vendor role to least privilege, particularly broad S3 read, Secrets Manager, SSM and Lambda configuration access.
   • Alert on AssumeRole calls from vendor accounts that arrive through VPNs or hosting providers the vendor has not used before. Use an organization trail across all accounts and regions, and enable S3 data events or server access logs for sensitive buckets.
   • No Qubole or Idera fix or advisory was located, so the remediation status of the platform itself is unconfirmed.