Between October 14 and October 26, multiple customer AWS accounts connected to Qubole were breached, with attackers stealing secrets and data. The intrusion stemmed from compromised credentials tied to an AWS identity (IAM role) that Qubole uses to access its clients’ cloud environments. It remains unclear exactly how those credentials fell into attackers’ hands.
Qubole, the data lake solution now owned by Idera, requires its customers to define an IAM role within their own AWS account. That role’s trust policy is configured to allow Qubole’s AWS account—via an assume-role function using an External ID—to access customer permissions. Normally, when Qubole calls AssumeRole it provides that External ID to verify the request. In this case, attackers exploited roles that trusted Qubole’s AWS account and used the correct External IDs.
What Attackers Extracted
Researchers with cloud security firm Wiz found attackers abused the AssumeRole feature to traverse into customers’ environments. Once inside, they scanned Lambda environment variables, extracted secrets from AWS Secrets Manager, accessed configuration data in the SSM Parameter Store, and deployed TruffleHog to sift through discovered credentials—including access keys, Okta credentials, and Entra ID secrets. Attackers also copied data from accessible S3 buckets, sometimes exfiltrating entire buckets in single sessions.
In a related but separate phase during October 8–11, attackers used AWS access keys that customers had previously issued for Qubole. That led to the compromise of additional environments, though it was not tied directly to the AssumeRole abuse.
Signs to Watch For & How to Respond
Organizations using Qubole should immediately audit their CloudTrail logs from October 1 onwards. Indicators of compromise include AssumeRole requests from Qubole’s AWS account (account ID: 805246085872) made from IPs outside of AWS, especially from OVH-hosted servers or VPN services such as Mullvad. Specific IAM principal IDs—namely AIDA3W7DIFLYOLTK63SFS and AIDAJYRRH5Y3A7AAJM2HW—are tied to malicious activity. Also, be alert for session names starting with “quiam-,” and usage of TruffleHog during identity checks.
To limit exposure, it’s advised to rotate all secrets, revoke any active sessions tied to compromised roles, and remove any unneeded Qubole roles or eliminate trust policies granting access to Qubole’s AWS account. Where possible, restrict AssumeRole actions through trust policy conditions such as aws:SourceIp or aws:SourceVpce to only approved vendor network segments. Ensure each External ID in vendor roles is unique, and assume it may be exposed—stored or logged in plaintext in many infrastructures.
Further hardening includes reviewing least privilege access for vendor roles—especially those that allow broad S3 bucket reads, Secrets Manager access, or wide permissions over Lambda and SSM. Enabling S3 data events or server access logs for sensitive buckets is critical. Many impacted customers lacked sufficient logging to determine exactly which data objects were accessed.
The breach has yet to be publicly addressed by Qubole or Idera, and it remains uncertain whether the compromised credentials have been revoked.
What this means and what to watch: This incident exposes the fragility of vendor access models relying heavily on AssumeRole and External IDs, especially when trust policies are broad and undifferentiated. As cloud supply-chain risks grow, organizations must enforce strict trust boundaries, isolate vendor roles, and demand granular network and identity restrictions. The key takeaway: without vigilant least privilege and logging controls, even unused roles can become a gateway for major data breaches.
