Attacker Exploits Qubole AWS Access to Steal Secrets and Data from Multiple Customer Accounts

Cybersecurity researchers have disclosed a cloud security incident in which an attacker compromised AWS environments belonging to multiple Qubole customers and accessed sensitive credentials and stored data between October 14 and October 26, 2026.

According to cloud security company Wiz, the attacker abused credentials belonging to an AWS account used by Qubole, a data lake platform owned by Idera, to access customer environments. The method through which the attacker obtained those credentials has not been disclosed.

Qubole operates within customer AWS accounts using cross-account access. Customers typically create an AWS Identity and Access Management (IAM) role that allows Qubole's AWS account to assume the role and perform authorized operations.

The trust policy associated with the role permits access from Qubole's account and requires a matching External ID with each AssumeRole request.

However, the attacker was able to use these permissions to access multiple customer environments. Wiz noted that many of the roles exploited during the campaign were no longer actively used, but they continued to trust Qubole's AWS account.

How the Attacker Gained Access to Customer AWS Accounts

The attack involved abusing AWS cross-account role assumption through the AssumeRole API operation.

When a customer integrates Qubole with AWS, the customer grants the platform permission to assume a specific IAM role. This arrangement allows Qubole to access selected AWS resources without requiring customers to share their primary account credentials.

The attacker used credentials associated with Qubole's AWS account, identified as:

805246085872

The researchers observed that the attacker's AssumeRole requests included valid External IDs and were accepted by the affected customer accounts.

AWS does not treat External IDs as secret credentials. They are designed to help prevent confused deputy attacks, but anyone who can access the relevant role configuration may be able to view them.

As a result, the External ID alone was not sufficient to prevent unauthorized access once the attacker's requests originated from the trusted AWS account.

Sentra initially identified suspicious activity across several customer environments and alerted researchers to the incident.

Sensitive Credentials and S3 Data Exposed

After gaining access to customer AWS environments, the attacker searched for stored credentials and sensitive information.

Wiz identified several activities performed during the intrusions:

  • Reading environment variables configured for AWS Lambda functions.
  • Retrieving secrets stored in AWS Secrets Manager.
  • Accessing sensitive values in AWS Systems Manager Parameter Store.
  • Collecting AWS access keys belonging to affected customers.
  • Accessing Microsoft Entra ID client secrets and Okta client credentials.
  • Testing discovered credentials using TruffleHog.
  • Downloading data from accessible Amazon S3 buckets.

Researchers observed that the attacker did not appear to search for specific files before accessing S3 data. Instead, the attacker retrieved data from buckets available through the assumed IAM roles, sometimes downloading entire buckets in individual sessions.

The researchers have not connected the campaign to other publicly reported threat activity. They also stated that the targeting did not resemble the typical objectives of state-sponsored threat groups.

A Separate AWS Access Key Compromise

Wiz also identified another suspicious activity involving Qubole integrations.

Between October 8 and October 11, an attacker used AWS access keys belonging directly to customers. Researchers believe these keys had been configured for Qubole access.

This activity resulted in compromises of several customer cloud environments. However, researchers have not linked this incident to the later AssumeRole abuse campaign.

The distinction is important because the two incidents involved different access mechanisms and should be investigated separately.

How to Identify Suspicious AWS Activity

Wiz recommends that organizations that have ever integrated Qubole with AWS review their CloudTrail logs from October 1, 2026, onward, including accounts where Qubole integrations are no longer active.

The following indicators can help identify potentially malicious activity.

AWS Account ID

Investigate AssumeRole requests where:

userIdentity.accountId = 805246085872

Pay particular attention to requests originating from IP addresses outside AWS infrastructure. Researchers reported that legitimate Qubole traffic in their investigation originated only from AWS.

IAM Principal IDs

Investigate activity involving the following IAM principal IDs:

  • AIDA3W7DIFLYOLTK63SFS: Researchers observed this principal being used only by the attacker in the examined environments.
  • AIDAJYRRH5Y3A7AAJM2HW: Investigate activity from this principal when it originates outside AWS. The attacker used it from October 18, although Qubole's legitimate traffic also used it.

Suspicious IP Addresses

Researchers identified the following infrastructure during the campaign:

  • 57.129.54[.]120
  • 2001:41d0:70d[:]7800::
  • 45.83.220[.]211
  • 185.209.199[.]73
  • 89.37.63[.]175

The first two addresses were associated with OVH-hosted infrastructure, while the remaining addresses were associated with Mullvad VPN services. Because VPN infrastructure can be shared by multiple users, an IP match alone does not confirm malicious activity.

Additional Indicators

Security teams should also investigate:

  • IAM role sessions beginning with quiam-, including names such as quiam-enum.
  • TruffleHog user-agent activity associated with GetCallerIdentity requests from suspicious IP addresses.
  • Matching user-agent activity in identity provider sign-in logs.

For every suspicious session, investigators should examine subsequent activity involving Secrets Manager, SSM Parameter Store, Lambda functions and S3.

CloudTrail management events can record AssumeRole requests and bucket-listing operations. However, they do not automatically record which individual S3 objects were accessed. Investigators need S3 data events or S3 server access logs to determine which objects may have been downloaded.

Wiz noted that several affected organizations did not have the required logging enabled, making it impossible to establish exactly which S3 objects the attacker accessed.

Security Recommendations for AWS Customers

Wiz recommends that organizations review their Qubole integrations and strengthen cross-account access controls.

Key security measures include:

  1. Rotate exposed credentials: If an attacker assumed a Qubole role, rotate all secrets, parameters and Lambda environment variables accessible through that role. Revoke active role sessions as well, because rotating credentials does not automatically terminate sessions that have already been issued.
  2. Remove unused IAM roles: Delete Qubole roles that are no longer required or remove Qubole's AWS account from their trust policies.
  3. Restrict trusted principals: Where supported, replace the account-wide :root principal in the trust policy with the specific IAM principal used by Qubole.
  4. Apply source restrictions: Add aws:SourceIp or aws:SourceVpce conditions to restrict AssumeRole requests to documented vendor network ranges. Researchers stated that a source IP restriction alone would have blocked all the role assumptions they observed during the attack.
  5. Do not rely solely on External IDs: External IDs can appear in CloudTrail logs, vendor configurations and infrastructure-as-code files. Organizations should treat them as visible identifiers rather than secret credentials. Where possible, use different External ID values for individual roles.
  6. Review vendor permissions: Limit third-party IAM roles to the resources and operations they genuinely require. Broad S3 access, Lambda configuration permissions, Secrets Manager access and SSM Parameter Store permissions can significantly increase the impact of a compromised vendor account.
  7. Monitor suspicious role assumptions: Create alerts for AssumeRole requests originating from VPN providers, hosting companies or network ranges not normally associated with the vendor.
  8. Improve cloud logging: Enable organization-wide CloudTrail logging across accounts and regions. Configure S3 data events or server access logging for buckets containing sensitive information.

Why the Incident Matters

The Qubole incident demonstrates how third-party cloud integrations can become an entry point into multiple customer environments.

Cross-account IAM roles are designed to provide controlled access between cloud accounts, but unused roles, broad permissions and insufficient source restrictions can leave organizations exposed long after an integration is no longer actively used.

Organizations that previously connected Qubole to AWS should review historical CloudTrail activity, investigate suspicious role assumptions and rotate potentially exposed credentials.

The incident also highlights the importance of monitoring vendor identities with the same level of scrutiny applied to internal privileged accounts.