Qubole's AWS trust model turned against users

The intrusion did not begin with a phishing email or a zero-day. According to cloud security firm Wiz, it began with an AWS account that customers had deliberately wired to trust Qubole's platform — and that trust was enough to carry an attacker into accounts belonging to multiple Qubole customers. Stored secrets and data were taken. How the attacker obtained the credentials in the first place has not been disclosed.

Wiz, which reported the campaign and published a technical analysis of it, places the account compromises between October 14 and October 26. The activity was first spotted by Sentra in several of its customers' environments, which then alerted the researchers.

How the handshake is supposed to work

Qubole, a data lake platform owned by Idera, runs inside its customers' AWS accounts rather than purely from the outside. To get in, a customer creates an IAM role — an AWS identity carrying a defined set of permissions — and attaches a trust policy allowing Qubole's AWS account to assume that role. Each assumption, an API call named AssumeRole, must carry a matching code from Qubole known as an External ID.

That architecture is common for SaaS platforms that need to touch data inside a customer's cloud estate. The role is the door; the trust policy names who may open it; the External ID is the code the visitor must recite. In this campaign, the visitor was reciting the right code — because the attacker was using Qubole's own account.

Unused roles still answered the door

One detail from Wiz's review stands out. Most of the roles the attacker assumed were not in active use by the customers who owned them, according to the researchers. But each of those roles still trusted Qubole's account, so the attacker's AssumeRole requests were accepted anyway.

Every AssumeRole request tied to the attacker carried an External ID and was accepted, the researchers said. AWS grants the request when it arrives from the trusted account and includes the correct External ID. As AWS's external ID guidance explains, the code is not treated as a secret — anyone with access to the role can view it.

The practical consequence is that a dormant integration retains a live key. A customer who stopped using Qubole but never removed the role left a trust relationship standing, and that relationship was exercised.

"a source IP condition alone would have blocked every role assumption we observed."

— Wiz researchers, in their technical analysis of the campaign

What the attacker went looking for

Inside the accounts the researchers examined, the intruder hunted for stored credentials. It read environment variables belonging to Lambda functions, pulled secrets out of Secrets Manager, and read values from the SSM Parameter Store. It then ran what it found through TruffleHog, a credential-scanning tool, to test whether the secrets actually worked.

The credentials in question were the victims' own AWS access keys, Entra ID client secrets, and Okta client credentials. The attacker also copied data out of S3, pulling from any bucket a role could reach rather than targeting specific objects, and in some cases downloading an entire bucket within a single session.

Wiz has not tied this campaign to any other publicly reported activity. The researchers also said the targeting does not resemble what state-backed groups typically pursue.

A second, separate strand with access keys

Qubole lets customers connect by handing over AWS access keys instead of creating a role. Between October 8 and October 11, an attacker used customers' own AWS access keys — which the researchers believe had been configured for Qubole — and compromised a few of the victims' cloud environments. Wiz has not linked that activity to the AssumeRole abuse.

The two strands sit alongside each other in the reporting without a stated connection. What they share is the integration itself as the point of entry.

What to search for in CloudTrail

Wiz's hunting guidance covers CloudTrail logs from October 1 onward, in every AWS account that holds a Qubole role. The central signal is an AssumeRole request originating from the account Qubole's platform uses, 805246085872, arriving from an address outside AWS — the researchers observed Qubole's genuine traffic coming only from AWS ranges.

Beyond that core check, the guidance lists these indicators:

• IAM principal ID AIDA3W7DIFLYOLTK63SFS — any activity from this user should be investigated, since only the attacker used it in the accounts the researchers examined.
• IAM principal ID AIDAJYRRH5Y3A7AAJM2HW, when the source address is outside AWS. The attacker used this IAM user from October 18, but Qubole's normal traffic uses it too.
• IP addresses 57.129.54[.]120 and 2001:41d0:70d[:]7800::, OVH-hosted addresses the attacker used.
• IP addresses 45.83.220[.]211, 185.209.199[.]73 and 89.37.63[.]175, which are Mullvad VPN addresses. Other VPN users share them, so a match on its own is not proof.
• Role session names beginning with quiam-, such as quiam-enum.
• The TruffleHog user agent on GetCallerIdentity calls made from one of the addresses above. The same user agent may appear in an identity provider's sign-in logs.

For any suspicious session, the guidance is to review everything that followed it, with particular attention to Secrets Manager, SSM Parameter Store, Lambda, and S3.

The logging gap that limits the answers

CloudTrail management events record each AssumeRole request and bucket listing, but they do not capture which S3 objects were read. That requires S3 data events or S3 server access logs. Several victims lacked the necessary logs, according to Wiz, which meant responders could not determine which objects the attacker had actually read.

That gap matters for anyone deciding how far to extend remediation. Without object-level visibility, the safe assumption is broader rather than narrower.

Closing the route, and hardening the role

Wiz's recommended response starts with rotation and revocation. If the attacker assumed one of your Qubole roles, rotate all secrets, parameters, and Lambda environment variables that role could reach, and revoke the role's active sessions. Rotating a credential does not end sessions that were already issued.

Then reduce what the trust relationship permits:

• Remove any Qubole role you no longer need, or take Qubole's account out of its trust policy.
• Where Qubole supports it, replace the account-wide :root principal in the trust policy with the specific IAM principal Qubole uses.
• Add an aws:SourceIp or aws:SourceVpce condition restricting AssumeRole requests to the vendor's documented network ranges.
• Treat the External ID as visible to others. It is logged in plain text in CloudTrail, and vendors and infrastructure-as-code files often store it, so it should not be the only control. After an incident like this, change it to Qubole and use a different value for each role where possible.
• Review what each vendor role can reach. Qubole's setup guide includes a sample S3 policy that lets the role read every bucket in the account. Vendor roles are often granted access to Lambda settings, Secrets Manager, SSM parameters, and broad S3 read permissions for convenience, according to the researchers.
• Set alerts for AssumeRole requests from a vendor account arriving through a VPN or a hosting company the vendor has not used before.
• Log every account and region with an organization trail, and enable S3 data events or server access logs for buckets holding sensitive data.

As of The Hacker News's check, neither Qubole nor Idera had posted a statement about the attack on their websites. The researchers did not say whether the credentials involved have since been disabled, or whether the activity has stopped.

Why it matters for anyone with a vendor role

The uncomfortable lesson here is about the shape of third-party cloud access rather than about one vendor. A trust policy is a standing grant. It does not expire because the integration went quiet, and it does not care whether the customer still thinks of the tool as connected. This campaign suggests that dormant roles deserve the same scrutiny as active ones, and that inventorying them may be the highest-value hour a cloud team spends this quarter.

The controls that would have helped most, according to the researchers' own account, are unglamorous: a source IP condition, a narrower principal, deletion of what nobody uses. None of them require new products. What they require is knowing what your estate trusts — including the parts you have stopped paying attention to. Organizations that connected Qubole to AWS at any point should treat a CloudTrail review from October 1 onward as immediate work rather than a follow-up task.