Stale cloud access widened the breach
Qubole’s trusted AWS integrations gave an attacker a path into dozens of customer environments, where the intruder collected cloud data and credentials. The activity ran from October 14 through October 26, showing how access can persist after a customer stops using a third party. The exposure came from a familiar cloud arrangement: customers had delegated access to a vendor, but some left that access in place after the relationship was no longer active.
Wiz investigated the campaign with Sentra and Mandiant. Sentra first identified suspicious activity across customer environments and said the attack exploited integrations that some organizations had left active after ending their use of Qubole. The incident illustrates a practical weakness in cloud security: a relationship can be operationally dormant while its permissions remain technically live.
Stale trust relationships opened the door
Qubole integrations use cross-account AWS Identity and Access Management (IAM) roles. Customers configure roles to accept access from Qubole’s AWS account, with an External ID as an additional check. The attacker had credentials that met that requirement, allowing successful role assumptions in customer accounts. That check can help prevent certain forms of confused-deputy abuse, but it doesn't replace the need to control which principals can assume a role or whether the integration is still needed.
Wiz traced the first suspicious attempts to October 14. They came from an IP address associated with Mullvad VPN and targeted customer integration roles from AWS account 805246085872, which Qubole uses for platform operations. The requests used IAM user AIDA3W7DIFLYOLTK63SFS. These details give defenders concrete pivots for reviewing their own audit records, though the presence of a named account or address alone doesn't establish the full scope of an affected environment.
Most later activity came from an OVH-hosted virtual private server at 57.129.54[.]120. On October 18, the attacker began using a second IAM identity linked to Qubole’s AWS account, along with another Mullvad VPN address. Every malicious role assumption Wiz identified included the required External ID and succeeded. That pattern matters: the control was present, but the attacker had what was needed to pass it.
Many targeted roles had no legitimate Qubole activity during October, yet their permissions remained enabled. That gap between a vendor relationship’s actual use and its access settings left a route into customer accounts. For teams managing cloud integrations, unused trust is easy to overlook because it doesn't generate routine activity to draw attention to itself.
Cloud discovery turned into credential collection
Once inside, the attacker mapped customer resources, including S3 buckets, databases, EC2 instances, security groups and IAM identities. The intruder also accessed AWS Secrets Manager, Systems Manager Parameter Store and Lambda configurations, looking for credentials and other sensitive information. This sequence resembles common cloud discovery: identify what exists, locate where secrets may be stored, then determine what can be retrieved with the access already obtained.
The attacker enumerated S3 buckets and objects before downloading data. Wiz said some sessions retrieved entire buckets. Credentials found in the compromised environments were tested with TruffleHog, a secrets-scanning tool. They included AWS access keys, Microsoft Entra ID service principal credentials and Okta OAuth client credentials. The range of credential types suggests that a compromise of one cloud trust relationship can expose access paths into services beyond the cloud account itself.
Sentra reported that more than 100 passwords and keys were read within minutes, with thousands of additional credential records present in downloaded files. The observed activity included no write operations, pointing to a campaign centered on collecting data rather than changing customer environments. That distinction narrows what investigators observed, but it doesn't make the access benign: credentials can enable later activity even when the initial sessions leave no visible configuration changes.
A suspicious Linux image remains unexplained
Wiz found a bootable Linux ISO named “sso_agent.iso” on the attacker’s OVH infrastructure. The image gathers system information, connects to a server over TCP port 23458 and can run shell commands supplied remotely. Its configuration suggests it may have been intended to target Windows systems. The file is a notable clue, but its presence on attacker infrastructure doesn't establish that it was deployed in customer environments.
Researchers found no deployments of the image and couldn’t establish whether it was used against victims. The campaign also remains unattributed to a known threat group. That leaves an important part of the activity unresolved, and investigators should avoid treating the image as proof of a separate intrusion method without evidence of execution.
What the incident means for cloud access
This is more significant than it looks. The campaign shows how a vendor integration can outlive the business process that justified it, leaving a customer account exposed through a trust relationship that may no longer be monitored closely. (And this is the part most people overlook.) A role can be quiet for months and still be usable when an attacker obtains the right vendor-side credentials.
If you're working in this space, the useful question is not only which vendors have access, but whether each active role still serves a current purpose and whether its trust policy is narrow enough. A review should connect IAM configuration to actual use, then check whether the recorded activity matches expected vendor operations. In many cloud environments, access accumulates more easily than it gets removed. That's the operational gap.
Review access and audit records
Wiz recommends reviewing AWS CloudTrail records from October 1, 2026, across accounts with Qubole integration roles. Investigators should examine suspicious AssumeRole events originating from Qubole’s AWS account, especially requests from non-AWS infrastructure and the IAM identities identified in the disclosure. Follow-on access to Secrets Manager, Parameter Store, Lambda and S3 also warrants review. The stated review window and indicators provide a starting point; each organization will need to compare them with its own role configuration and expected activity.
Organizations can reduce exposure by removing integrations they no longer use and limiting role trust to specific vendor IAM principals instead of an entire external AWS account. Wiz also recommends restricting role assumptions to documented vendor network ranges with AWS source IP or VPC endpoint conditions. Those controls narrow the paths available to an attacker, while regular reviews help catch permissions that remain after a service is retired. The practical lesson is clear: third-party access should expire when the business need does.
