Because the Qubole platform often requests broad S3 read permissions for operational convenience, the attacker was able to download sensitive data without triggering specific file alerts. This breach, discovered by security researchers at Wiz, occurred between October 14 and October 26, targeting the trusted link between the Qubole data lake platform and its customers’ Amazon Web Services accounts. By obtaining internal credentials for Qubole’s own AWS account, unauthorized actors were able to assume Identity and Access Management roles within numerous customer environments. This allowed them to bypass traditional perimeter defenses and directly access sensitive data stored in S3 buckets, AWS Secrets Manager, and Lambda environment variables. The incident underscores a significant risk in the modern cloud ecosystem where third-party service integrations, while essential for operations, can become a massive liability if the vendor’s own root credentials are compromised. This exploit effectively turned a trusted operational tool into a silent bridge for data exfiltration across a diverse array of enterprise cloud tenants.
1. Systematic Identification of Compromised Account Activity
Organizations that have ever connected the Qubole platform to their AWS environment must perform an immediate audit of their CloudTrail logs, going back to at least October 1. The most critical indicator of compromise is an AssumeRole request where the userIdentity.accountId is identified as 805246085872, which belongs to the Qubole platform. While legitimate Qubole traffic typically originates from within the AWS network, the attackers in this campaign used source IP addresses located outside of AWS. Furthermore, security teams should look for actions associated with the IAM principal ID AIDA3W7DIFLYOLTK63SFS. Analysis by researchers indicated that this specific principal was utilized exclusively by the attacker to navigate through customer environments. If this ID appears in your logs, it is a high-confidence signal that your account was actively targeted. Monitoring these specific identifiers allows security administrators to distinguish between routine platform operations and the targeted malicious activity that characterized this breach.
Beyond identifying specific account and principal IDs, investigators must track technical markers such as session names and source IP addresses to map the extent of the intruder’s movement. Malicious actors utilized session names beginning with the prefix quiam-, including sessions like quiam-enum, which were used to enumerate available resources. The attack traffic was also traced to OVH-hosted IP addresses, such as 57.129.54.120 and the IPv6 address 2001:41d0:70d:7800::. Additionally, the attackers frequently used Mullvad VPN addresses, specifically 45.83.220.211, 185.209.199.73, and 89.37.63.175, to mask their true locations. Another notable tactic involved the use of the TruffleHog tool to scan for and validate stolen credentials. This can be detected by searching for the TruffleHog user agent string within GetCallerIdentity API calls in your CloudTrail history. By correlating these network-level indicators with specific API activity, organizations can effectively isolate unauthorized sessions and begin the process of determining which data assets were potentially exposed during the campaign.
2. Immediate Remediation and Strengthening Trust Policies
If any evidence of unauthorized role assumption is discovered, the priority shifts to immediate containment and the neutralization of the attacker’s persistent access. Administrators should rotate every secret, configuration parameter, and environment variable that the compromised Qubole role had permission to access. This is essential because the attackers were observed specifically targeting AWS access keys, Okta credentials, and Entra ID secrets to deepen their reach. Simply updating the credentials is not enough; it is vital to revoke all active sessions for the compromised role to ensure that any current unauthorized access is terminated. Furthermore, organizations should conduct a cleanup of their IAM environment by deleting any Qubole-related roles that are no longer required for current workflows. If the service is still in use but requires hardening, companies should remove the broad account-wide root principal from the role’s trust policy and replace it with the specific IAM principal used by the vendor to reduce the overall attack surface.
In addition to credential rotation, implementing network-level restrictions is one of the most effective ways to prevent the re-exploitation of trusted third-party roles. By adding aws:SourceIp or aws:SourceVpce conditions to the IAM trust policy, organizations can ensure that the AssumeRole action is only successful when it originates from the vendor’s approved IP ranges or VPC endpoints. In this specific breach, such a policy would have successfully blocked the attacker’s attempts, as their traffic came from external hosting providers and VPNs. Furthermore, the role of the External ID must be treated with caution; it is not a robust secret since it is often logged in plain text or stored in shared infrastructure-as-code files. Following this incident, it is recommended to change the External ID to a new, unique value for every role. By combining network-based restrictions with more granular trust policies, security teams can create a defense-in-depth strategy that protects their cloud resources even if a vendor’s primary credentials are compromised by an external threat actor.
3. Long-term Governance and Enhanced Data Visibility
The difficulty many organizations faced in determining the full impact of this breach highlighted a critical need for deeper logging and more rigorous data governance. While standard CloudTrail management logs capture broad API calls, they often lack the granularity to show which specific objects were read within an S3 bucket. To ensure future resilience, security leaders recognized that enabling S3 data events or server access logs for buckets containing sensitive information was a non-negotiable requirement. Without these logs, forensic teams were left unable to confirm exactly what data was stolen, leading to broader and more costly disclosure requirements. The breach also emphasized the danger of granting broad read permissions for the sake of operational convenience. The most successful mitigation strategies involved moving toward a model where vendor roles were restricted to specific S3 buckets and resources rather than being granted account-wide access. This approach ensured that any potential compromise would be localized, preventing a single point of failure from exposing the entire data lake.
Looking ahead, the response to this incident proved that maintaining a static security posture was insufficient for managing modern cloud-to-cloud relationships. Proactive organizations shifted toward a continuous monitoring model, where alerts were established for any AssumeRole requests coming from unfamiliar hosting providers or VPN services. They also began conducting regular audits of third-party permissions to ensure that the principle of least privilege was strictly enforced as operational needs evolved. By implementing organization-wide trails across all regions, these companies ensured that no activity occurred in unmonitored silos. The transition toward a zero-trust mindset for third-party integrations allowed for more robust protection of sensitive cloud assets. Ultimately, the industry learned that while vendor platforms provide significant value, the responsibility for securing the data within those platforms remains firmly with the customer. These measures provided a scalable framework for mitigating future risks while maintaining the benefits of high-performance cloud data processing.
