A threat actor exploited compromised Identity and Access Management (IAM) credentials belonging to cloud analytics platform Qubole to pivot into customer Amazon Web Services (AWS) environments, security researchers have revealed. Between October 14 and October 26, the attacker abused cross-account trust configurations to extract stored credentials and exfiltrate massive volumes of sensitive data from dozens of organizations.

The breach was initially detected by data security firm Sentra, which spotted anomalous behavior in client accounts and collaborated with cloud security company Wiz and cybersecurity firm Mandiant to investigate the activity, as reported by BleepingComputer.

How the Cross-Account Trust Abuse Worked

Qubole, an enterprise data lake and processing platform owned by Idera, relies on AWS integrations to manage client compute clusters and data processing pipelines. Customers configure access by creating an IAM role in their own AWS accounts that establishes a trust policy pointing to Qubole's AWS account (ID 805246085872). When the platform requires access, it calls the AWS Security Token Service (STS) AssumeRole API using a preassigned code known as an External ID.

According to an analysis covered by The Hacker News, the attacker obtained credentials for two internal Qubole IAM users. Because AWS evaluates trust policies based on the trusting relationship between accounts and the presence of the required External ID—which is frequently recorded in plain text across CloudTrail logs and infrastructure-as-code scripts—the attacker successfully executed AssumeRole requests.

Researchers observed that the attacker successfully targeted cross-account roles that were largely dormant or unused by the victim companies, yet remained fully authorized in their cloud environments because the underlying trust relationships had never been deleted or scoped down.

Rapid Credential Validation and S3 Exfiltration

Once inside a victim's AWS environment, the threat actor operated with notable speed. Sentra observed the attacker harvesting secrets at a rate of 100 passwords and cryptographic keys in seven minutes. The intruder surveyed cloud deployments, pulled stored configuration values from AWS Systems Manager (SSM) Parameter Store, accessed AWS Secrets Manager, and inspected environment variables embedded in AWS Lambda functions.

The threat actor then deployed the open-source credential scanner TruffleHog to test the validity of discovered credentials. These included the victim organizations' native AWS access keys, Microsoft Entra ID application client secrets, and Okta administrative credentials.

Following credential theft, the attacker pursued broad data exfiltration across Amazon Simple Storage Service (S3). Rather than locating specific high-value assets, the actor followed an opportunistic methodology: invoking ListBuckets, enumerating directory objects via ListObjects and HeadObject, and downloading contents en masse using GetObject. In one confirmed instance, millions of files were exfiltrated from a single victim enterprise.

In a separate set of intrusions between October 8 and October 11, attackers also leveraged direct AWS access keys generated for Qubole to compromise a smaller number of environments, though researchers have not formally tied that activity to the AssumeRole campaign.

Scope and Vendor Response

The campaign impacted dozens of companies across the multi-week window. Threat researchers noted that the non-discriminatory nature of the data harvesting does not match the traditional targeting profiles of state-sponsored espionage units.

Neither Qubole nor its parent company, Idera, had issued a public statement or advisory regarding the breach at the time of reporting, and investigators have not disclosed the root cause behind the initial compromise of Qubole's internal IAM accounts.

What Defenders Should Do

Security teams that have ever integrated Qubole into their cloud footprint—including organizations that no longer actively use the service—should conduct immediate audits of their environments:

  • Audit CloudTrail logs: Examine all AWS CloudTrail activity from October 1 onward. Search for AssumeRole events originating from account 805246085872 where the source IP address lies outside official AWS ranges.
  • Monitor specific IAM principals: Investigate any actions associated with IAM principal AIDA3W7DIFLYOLTK63SFS, which researchers linked solely to adversary activity, as well as non-AWS traffic tied to principal AIDAJYRRH5Y3A7AAJM2HW.
  • Block known threat infrastructure: Screen network telemetry for connections involving OVH addresses 57.129.54[.]120 and 2001:41d0:70d[:]7800::, Mullvad VPN nodes (45.83.220[.]211, 185.209.199[.]73, 89.37.63[.]175), role session identifiers starting with quiam-, and TruffleHog user-agent signatures.
  • Rotate exposed assets: If an unauthorized session assumed a role, revoke all active STS role sessions immediately. Rotate any AWS access keys, Entra ID secrets, Okta tokens, and application credentials stored in Secrets Manager, Parameter Store, or Lambda configurations accessible to that role.
  • Harden role trust policies: Remove obsolete cross-account vendor roles. For active partnerships, add aws:SourceIp or aws:SourceVpce condition keys to the IAM trust policy to restrict role assumption strictly to the vendor's documented IP CIDR blocks or VPC endpoints.
  • Enable granular object logging: Ensure S3 data events or S3 server access logging are active on sensitive storage buckets, as standard CloudTrail management events do not record individual GetObject read operations.