Dormant AWS trust links became a backdoor

As of October 14, someone was quietly using credentials tied to a third-party data platform's AWS account to borrow the identity of its customers. The intruder did not need stolen passwords or a zero-day. According to research published Monday by Google-owned cloud security firm Wiz, the attackers simply assumed the integration roles that customers had once granted Qubole when they connected the data processing platform to their own AWS environments. From there they probed services, harvested secrets, and pulled data out of S3 buckets.

The attack targeted the quiet plumbing that cloud platforms rely on: cross-account IAM trust, a mechanism that lets a vendor work inside a customer's cloud tenant without the customer handing over long-lived access keys. Wiz described the incident to The Register as a "broad, opportunistic supply chain campaign" affecting "multiple" customer environments. It declined to say how many organizations were hit. Neither AWS nor Qubole answered The Register's questions about the campaign.

The trust link that stayed live

Qubole, a cloud data processing platform, connects to customer AWS accounts using cross-account IAM roles. This design is deliberate: it removes the need to share permanent AWS access keys, which are easy to lose and hard to audit. Instead, the customer creates a role that Qubole's own AWS identity is permitted to assume and uses it to run compute and read storage inside the customer's environment.

The weakness that Wiz describes was not in the role mechanism itself, but in what happened after customers stopped using the platform. Many organizations left those trust policies in place even after deprecating Qubole. To an attacker holding credentials for Qubole's AWS account, that leftover trust was as good as a standing door key. Wiz said the intruder was able to assume integration roles, enumerate cloud resources, harvest secrets, and siphon data precisely because those policies remained active.

The researchers' account puts third-party integrations in an uncomfortable light. A cloud integration that is no longer in active use can still be an open authority path unless someone goes back and removes it, and the customer may have no reason to think about it until it is abused.

A timeline traced from one API call

The trail starts, according to Wiz, with a specific API call. On October 14, credentials associated with Qubole's AWS account were used to call sts:AssumeRole and obtain temporary credentials for customer-managed integration roles. The calls came from Qubole AWS account 805246085872 and used IAM user ID AIDA3W7DIFLYOLTK63SFS.

The activity continued the next day, October 15, and on October 18 the intruders began using a second IAM user from the same Qubole account. Wiz analysts Zack Morrow, Sean Johnstone, and Benjamin Read wrote that across the affected environments, the firm's incident response team has not observed that IAM user engaged in anything other than this threat actor's activity.

Wiz said its investigation was prompted after Sentra, an AI data security company, flagged suspicious activity. Wiz then worked with Google's Mandiant incident responders to trace what had happened. The researchers said they have not attributed the campaign to any particular group and have no insight into how the stolen data is being used.

What the intruders took, and from where

Once inside a customer's environment, the attackers swept across services rather than settling on one target. Wiz said they stole credentials, keys, and other secrets stored in Lambda, Secrets Manager, and SSM Parameter Store. They also read customer data out of S3 storage, in some cases downloading entire buckets.

The profile that emerges from Wiz's account is opportunistic rather than targeted. The firm described the attackers as largely taking what was available, in contrast to state-sponsored spies hunting for specific material. The integration roles gave them the reach to look broadly; the data they took appears to have been whatever they could find.

The attackers also used a credential-scanning tool to press their advantage beyond AWS. Wiz said they ran TruffleHog against victim organizations' AWS credentials, discovered Microsoft Entra ID secrets, and requested OAuth tokens using Okta client credentials they had uncovered while rummaging through the AWS environments. That means an intrusion that began as an AWS trust issue had a path into identity infrastructure outside AWS entirely.

Old keys, older weaknesses

The pattern Wiz describes is not exotic: long-lived or forgotten credentials left behind after a service is retired, and a trust relationship that nobody remembered to tear down. Neither part requires a novel exploit. The combination, however, turned a vendor integration into an entry point for multiple customer environments at once.

The firm's write-up emphasizes that rotating a credential on its own does not end sessions that were already issued. If a role session was created during the attack window, revoking the underlying credential leaves that session alive until it expires or is explicitly revoked. That distinction is central to the cleanup steps Wiz outlined.

While investigating, Wiz also spotted a separate campaign running between October 8 and October 11 that likewise used customer-owned AWS access keys for Qubole integrations. A "small number" of those incidents also resulted in compromised AWS environments, but Wiz said it could not definitively connect the two sets of malicious activity.

What customers are being told to check

For organizations that integrated with Qubole, Wiz's guidance is to rotate credentials and then look for evidence of role assumption. Its instructions are specific enough to follow directly in an AWS account:

• Rotate credentials associated with the integration, while remembering that rotation does not end temporary sessions already issued.
• Review CloudTrail logs from October 1 onward for AssumeRole events where userIdentity.accountId matches Qubole's AWS account ID, 805246085872, particularly those originating from non-AWS IP addresses.
• For every role session found, review all subsequent activity from that session, especially in Secrets Manager, SSM Parameter Store, Lambda, and S3.
• If the threat actor assumed an integration role, rotate every secret, parameter, and Lambda environment variable that role could read, and revoke active sessions for the role.

Wiz's researchers laid out the reasoning behind the sweep in their response to The Register: "Because many organizations left trust policies active even after deprecating the platform, the attacker was able to successfully assume integration roles, enumerate cloud resources, harvest secrets, and siphon data."

— Wiz researchers, in an emailed response to The Register

The appeal of borrowed identity

The campaign illustrates why cross-account roles are attractive to intruders. There is nothing to phish and no password to guess. If the vendor's own account is compromised, every customer who trusted that vendor's identity inherits the risk. The trust policy is the attack surface, and in this case it stayed in place long after the business relationship had gone quiet.

That is also why the detection advice centers on identity events rather than network signatures. An AssumeRole call from the vendor's account ID looks legitimate to most monitoring because, structurally, it is legitimate — it exercises a permission the customer granted. The signal that matters is context: whether the call came from an unusual IP address, and what the resulting session did next.

Wiz's observation that the IAM user appeared only in this threat actor's activity underscores how discrete the incursion was. There was no history of normal use to blend into, which made the abuse stand out once researchers went looking.

Why this matters for cloud customers

The practical lesson for any organization running third-party integrations in AWS is that decommissioning a platform is not the same as decommissioning its access. A retired vendor's trust policy can remain live indefinitely, and as this campaign suggests, attackers are willing to test exactly those forgotten relationships. Customers who once connected Qubole should treat the October window as a starting point for review, not an edge case, and should assume that any secret a leftover role could read may need replacing.

More broadly, the Wiz findings suggest that the supply-chain risk in cloud environments increasingly sits in identity configuration rather than in code dependencies. An integration role granted for convenience can outlive the service it was built for, and the temporary credentials it issues can persist beyond the moment someone remembers to rotate the keys. For security teams, the work is less about spotting a malicious payload and more about knowing, at any given time, which external accounts are still allowed to become you.