Qubole AWS integration roles abused to steal secrets and S3 data from multiple customer environments (Oct 14-26, 2026)

Linha do tempo

1. securityweek.com ↗ · pub. 10/11/2026 10:27 · coletado 10/11 12:00

   Stale Qubole IAM Roles Abused to Steal Data from Over a Dozen AWS Customer Environments

   ler a análise desta fonte ocultar

   A threat actor used leaked IAM credentials tied to the Qubole AWS account to assume cross-account roles that customers had created for the platform, and pulled data from the AWS environments of more than a dozen organizations. Sentra and Wiz report that many of these roles were never removed after customers stopped using Qubole, and they could read most of the data the attacker targeted. The activity ran from October 14 to October 26 and came from a rented OVH server and the Mullvad VPN, not from Qubole's network. Wiz also describes a separate Qubole-integration campaign from October 8 to 11, in which customer-owned AWS access keys were tested against victim environments and, in some cases, used for compromise. The researchers call the actor opportunistic and found no ties to other public activity, but the motive remains unknown. This record is based on the article alone; Qubole's own advisory was not consulted.

   Technical Details

   • Access: The attacker assumed the cross-account roles that customers had set up for Qubole's AWS account. Those roles are normally protected by an External ID, and the leaked credentials were enough to assume them. The article does not explain how the credentials leaked.
   • Dormancy: The roles stayed unused until the campaign began on October 14 and were used until October 26.
   • Post-access activity: The actor enumerated resources, collected secrets and configurations from common AWS storage locations, tested the harvested credentials with TruffleHog, and exfiltrated data from S3 buckets. In some cases entire buckets were downloaded in one session.
   • Session naming: Role sessions followed a consistent pattern, with the prefix quiam- followed by a suffix describing the action, such as quiam-enum and quiam-scope-full.
   • Payload: Wiz found an ISO file designed to be booted remotely on victim machines to harvest data, but has no evidence that it was deployed.
   • Attribution: Wiz found no ties to other publicly reported activity and said the targeting does not match typical state-backed priorities.

   Remediation

   The article does not describe guidance from Qubole. The following are analyst recommendations derived from the reported facts:

   • Inventory every IAM role in customer AWS accounts that trusts Qubole's account, and remove roles for Qubole deployments that are no longer in use.
   • Review the External ID conditions on the remaining trust policies and check the roles' S3 read scope against actual need.
   • Review CloudTrail and S3 access logs for AssumeRole activity with quiam- session names, and for large bulk downloads from October 8 to October 26.
   • Rotate any secrets, keys and configuration values that were stored in buckets or other common AWS storage locations that the roles could read.
2. gbhackers.com ↗ · pub. 10/11/2026 09:51 · coletado 10/11 10:00

   Qubole's Trusted AWS Access Abused to Breach Dozens of Customer Cloud Accounts and Steal S3 Data

   ler a análise desta fonte ocultar

   A threat actor used IAM credentials tied to an AWS account associated with Qubole to assume cross-account integration roles in customer environments between October 14 and October 26, 2026. Wiz, working with Sentra and Mandiant, investigated the campaign (wiz.io). Sentra said the campaign affected dozens of Qubole customers (csoonline.com). Every malicious role-assumption request supplied the required External ID and succeeded, so that check gave no protection here (csoonline.com). No known threat group has been linked to the operation and no CVE is involved, so the risk comes from vendor trust and configuration rather than a software flaw, which limits exposure to organizations that deployed Qubole integration roles. The active theft of data across several victims still justifies a critical rating.

   Technical Details

   • Initial access: The first calls on October 14 came from Mullvad VPN address 45.83.220[.]211 and originated from AWS account 805246085872, an account Wiz associates with Qubole's platform (wiz.io). From October 18 a second principal, AIDAJYRRH5Y3A7AAJM2HW, appeared with Mullvad address 185.209.199[.]73, and later activity mostly used OVH infrastructure at 57.129.54[.]120. That second principal also appears in legitimate Qubole traffic, so network context is needed to separate malicious sessions.
   • Credential harvesting: After assuming roles, the actor read Lambda environment variables, retrieved Secrets Manager values and accessed Systems Manager Parameter Store. Sentra also documented secrets collected from EC2 user data.
   • Credential validation: TruffleHog tested AWS keys with GetCallerIdentity and checked Microsoft Entra ID service-principal secrets and Okta client credentials against their identity services (wiz.io).
   • Data theft: The actor enumerated buckets, listed objects, inspected metadata and downloaded content with GetObject, sometimes taking entire buckets. Wiz notes that CloudTrail management events record the role assumption and bucket listing but not the object reads, so S3 data events are needed to prove theft (wiz.io).
   • Payload: The sso_agent.iso image found on the OVH address collected host information, polled TCP port 23458 for shell scripts and forced a reboot after 90 minutes. It loads the ntfs3 driver, which suggests targeting of Windows systems, but Wiz found no confirmed deployments (wiz.io).
   • Separate activity: Customer-owned AWS keys believed to support Qubole integrations were abused between October 8 and October 11. Wiz could not link that activity to the main campaign (wiz.io).

   Remediation

   • Review CloudTrail from October 1, 2026 onward for the listed principals, suspicious source networks and later secret or storage access (wiz.io).
   • Restrict role assumption to documented vendor network ranges using AWS source IP or VPC endpoint conditions (csoonline.com).
   • Remove unused vendor trust, restrict permissions and approved networks, rotate exposed secrets and revoke issued sessions.
   • Enable S3 data events or server access logging on sensitive buckets to establish object-level theft.
   • Do not treat External IDs as standalone safeguards.
   • No Qubole security advisory or vendor-side fix was located during research, so the vendor's own remediation guidance is not documented.
3. theregister.com ↗ · pub. 09/11/2026 16:59 · coletado 09/11 18:00

   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).
4. thehackernews.com ↗ · pub. 09/11/2026 14:51 · coletado 09/11 17:00

   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.
5. wiz.io ↗ · pub. 09/11/2026 11:56 · coletado 09/11 14:00 primeiro registro

   Threat actor abuses Qubole AWS integration roles to reach customer environments and exfiltrate S3 data

   ler a análise desta fonte ocultar

   Between October 14 and October 26, 2026, a threat actor used IAM credentials from an AWS account that Qubole uses for its platform to assume AWS IAM roles that customers had created to trust that account. Wiz CIRT, working with Sentra and Mandiant, observed the activity across several customer environments, and Sentra's detection prompted the investigation, which Wiz calls a broad supply chain attack. Inside the environments, the actor mapped resources, pulled secrets from Lambda, Secrets Manager and SSM Parameter Store, validated the credentials it found, and read S3 data, in some cases downloading entire buckets. The article does not say that Qubole's own systems were breached, and Wiz has no insight into the actor's motive. Criticity is critical because the abuse is active, data was taken and the trust model reaches many customers; the limits are that exploitation needed roles whose trust policies were still in place and a valid External ID, and no CVE or vendor fix is involved. No Qubole advisory was retrieved during the research, so the vendor's own account is not available.

   Technical Details

   • Initial access: on October 14 a Mullvad VPN address (45.83.220[.]211) called AssumeRole against integration roles, using IAM user AIDA3W7DIFLYOLTK63SFS in account 805246085872. From October 15 most calls came from an OVH VPS (57.129.54[.]120). On October 18 a second IAM user (AIDAJYRRH5Y3A7AAJM2HW) and a second Mullvad address (185.209.199[.]73) joined. Every attributed request carried an External ID and succeeded, and in most affected environments these were the only vendor-account AssumeRole calls in October.
   • Session naming: sessions used the prefix quiam- followed by a suffix describing the action, such as quiam-enum and quiam-scope-full.
   • Discovery and credential access: the actor queried storage, compute, database and key-management metadata, called GetFunctionConfiguration on Lambda functions to read environment variables, and retrieved Secrets Manager values and SSM parameters.
   • Credential validation: TruffleHog called GetCallerIdentity on harvested AWS access keys across several accounts in bursts of seconds, signed in as Entra ID service principals with discovered client secrets, and requested Okta OAuth tokens with discovered client credentials.
   • Data theft: through the assumed roles the actor ran ListBuckets, ListObjects, HeadObject and GetObject. Targeting appears opportunistic. CloudTrail management events show the role assumption but not the object reads, so S3 data events are needed to see the exfiltration.
   • sso_agent.iso: a bootable Linux image hosted on 57.129.54[.]120 (SHA-256 65f061281c9a712e9502793dc4c5035cae490b84da05f7d4223cefa65ad396e4). Once started it runs a 90-minute window, sends system, interface and disk data to that IP, polls TCP port 23458 for shell scripts to run, then hard-reboots to erase traces. It loads the ntfs3 driver, which suggests a Windows target. Wiz found no deployment of it.
   • Separate activity: from October 8 to 11 an actor tested customer-owned AWS keys believed to have been created for Qubole integrations, testing all of them within one hour on October 8. In a small number of cases the victim environment was compromised. Wiz has not linked this to the role-assumption activity.

   Remediation

   • Review CloudTrail from October 1, 2026 in every account that holds an integration role. Filter AssumeRole events for account 805246085872 with non-AWS source IPs, for the two IAM user IDs above (the second one only from non-AWS addresses), and for GetCallerIdentity calls with a TruffleHog user agent from the listed IPs. Check identity provider sign-in logs for the same agent.
   • For every role session found, review what followed, especially Secrets Manager, SSM, Lambda and S3. Rotate every secret, parameter and Lambda environment variable the role could read and revoke its active sessions, since rotating a credential leaves already-issued temporary sessions valid.
   • Inventory roles whose trust policies allow external accounts, and delete or un-trust integrations no longer in use.
   • Replace the account-root principal with the specific vendor principal, and add source IP or VPC conditions that limit assumption to the vendor's documented ranges. Wiz states that a source IP condition alone would have blocked every observed assumption.
   • Treat the External ID as non-secret: it is logged in plaintext. Rotate it with the vendor and use a distinct value per role where supported.
   • Apply least privilege to vendor roles, limiting access to Lambda configuration, Secrets Manager, SSM parameters and broad S3 reads.
   • Alert on third-party AssumeRole calls arriving through VPN or hosting networks the vendor has never used.
   • Use an organization-wide CloudTrail and enable S3 data events or server access logs for sensitive buckets.
   • SaaS providers should assume customer roles from short-lived workload credentials, restrict those principals with source IP or VPC conditions, publish egress ranges, and monitor their own CloudTrail for unexpected AssumeRole calls.