Compromised Qubole AWS credentials abused to steal customer secrets

Attackers used compromised credentials associated with Qubole’s AWS account to assume customer-managed integration roles, inspect cloud resources and steal secrets and data from Amazon S3. The activity exploited cross-account access relationships created to let the cloud data-processing platform work in customer environments.

Google’s cloud-security team Wiz described the incident as a broad, opportunistic supply-chain campaign affecting multiple customer environments. It did not disclose how many organizations were involved. Wiz said it had not attributed the activity to a specific threat group and had no visibility into how the attackers were using the stolen information.

Abuse of trusted integration roles

Qubole uses cross-account AWS Identity and Access Management (IAM) roles to manage compute and access storage for customers. This arrangement avoids requiring customers to give the platform long-lived AWS access keys, but it also depends on trust policies that authorize the integration. Wiz said some organizations had left those policies active after they had stopped using the platform, allowing the attackers to assume the associated roles.

Wiz, working with Google’s Mandiant incident responders after AI data security company Sentra flagged suspicious activity, traced the main campaign to October 14. The attackers used credentials connected to Qubole’s AWS account, 805246085872, to call AWS Security Token Service’s sts:AssumeRole API and obtain temporary credentials for customer-managed integration roles. Wiz researchers Zack Morrow, Sean Johnstone and Benjamin Read reported that activity continued on October 15. On October 18, the attackers began using a second IAM user from the same AWS account.

The first identified IAM user had the ID AIDA3W7DIFLYOLTK63SFS. Wiz said its incident response team had not observed that user in other activity beyond the activity associated with this threat actor. The use of temporary role credentials gave the attackers access within customer environments under the permissions granted to the integration roles.

Secrets and storage were targeted

After gaining access, the attackers examined AWS services and sought credentials and other sensitive values in Lambda, AWS Secrets Manager and Systems Manager (SSM) Parameter Store. Wiz said they also used TruffleHog to test AWS credentials belonging to victims, identify Microsoft Entra ID secrets and request OAuth tokens using Okta client credentials found during their exploration.

The attackers also accessed customer S3 storage and, in some cases, downloaded entire buckets. Wiz characterized the behavior as opportunistic rather than evidence of an operation focused on particular data. The scope of any downstream use of the stolen material remains unknown, according to the researchers.

Wiz separately identified activity from October 8 to October 11 involving customer-owned AWS access keys for Qubole integrations. A small number of those cases also led to unauthorized access to customer AWS environments. The researchers said they could not definitively connect that earlier activity to the later campaign, so organizations should treat the relationship as unconfirmed.

Review trust policies and cloud activity

Organizations that have integrated with Qubole should determine whether any cross-account roles or trust policies remain enabled, including for deployments no longer in use. The incident illustrates that a third-party integration can remain an access path after a customer believes the service has been retired. Periodic reviews of role permissions and external principals can help identify such dormant relationships.

Wiz advised affected organizations to rotate credentials and review AWS CloudTrail records from October 1 onward. Investigators should look for AssumeRole events in which the caller’s account ID is 805246085872, paying particular attention to requests originating from non-AWS IP addresses. Each relevant role session should then be examined for subsequent activity, especially access to Secrets Manager, SSM Parameter Store, Lambda and S3.

Credential rotation alone may not terminate temporary sessions that have already been issued. Wiz therefore recommended revoking active sessions for any role the attackers assumed. Organizations should also rotate every secret, parameter and Lambda environment variable that the role could read, then assess whether the same credentials were reused to reach identity services such as Microsoft Entra ID or Okta.

The incident highlights a practical challenge for cloud identity security: a trusted integration can provide legitimate access while it is needed, but its permissions can become a liability if the relationship is not removed or constrained when circumstances change. Reviewing third-party trust relationships, monitoring role assumptions and limiting the data each integration role can access can reduce the impact of a compromised provider credential.