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

Linha do tempo

1. 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.