How Hackers Breached AWS Through a Trusted Partner

Hackers used a trusted partner's credentials to breach multiple customer AWS accounts, exposing a critical supply-chain vulnerability in cloud security.

A sophisticated threat actor executed a supply-chain attack by compromising the cloud credentials of a third-party service, according to a report from BleepingComputer. The attackers targeted the big data platform Qubole, stealing its internal AWS Identity and Access Management (IAM) credentials. With these keys in hand, they were able to pivot into the AWS environments of multiple Qubole customers, accessing and exfiltrating sensitive data. This incident demonstrates a critical vulnerability in modern cloud architecture: the trust relationships established with vendors. The attackers did not need to breach each victim individually; they simply targeted the single vendor that held the keys to many kingdoms, turning a trusted partner into an unwitting entry point.

The technical mechanism behind this attack exploits a common and powerful feature of AWS: cross-account IAM roles. To integrate a service like Qubole, a customer creates an IAM role within their own AWS account that the vendor's account is trusted to assume. This role grants the vendor specific permissions to access resources like S3 buckets or databases. In this case, the attackers compromised Qubole's primary AWS account, which gave them the ability to assume these pre-approved roles in all of its customers' environments. The attack's brilliance lies in its simplicity. It didn't rely on a zero-day vulnerability or complex malware, but rather on the exploitation of legitimate, configured access. The very permissions granted to enable the service were the same ones used to breach it, making the malicious activity difficult to distinguish from normal operations.

This event is part of a broader and troubling trend of supply-chain attacks moving into the cloud infrastructure layer. While software supply-chain attacks like the SolarWinds incident targeted code dependencies, this new vector targets service dependencies and the trust models that underpin them. Modern technology stacks are rarely monolithic; they are complex ecosystems of first-party code and dozens of third-party services for analytics, security, monitoring, and operations. Each integration that requires delegated permissions creates a potential backdoor. Security teams have historically focused on protecting their own perimeter, but this attack proves that the perimeter is now porous and extends to every vendor with privileged access. The attack surface is no longer just what you build, but also who you trust.

For engineering and security leaders, this incident forces a fundamental shift from a model of implicit trust to one of continuous verification and least privilege. It is no longer sufficient to vet a vendor only during procurement. Teams must now treat third-party IAM roles with the same scrutiny as internal administrator accounts. The immediate takeaway is to conduct a thorough audit of all cross-account roles, ensuring they grant only the absolute minimum permissions necessary for the service to function. Implementing fine-grained monitoring and anomaly detection for actions taken by these roles is also crucial for early threat detection. Looking ahead, we can expect to see a greater emphasis on tools like AWS IAM Access Analyzer and a new class of security solutions designed specifically to manage and secure the sprawling web of third-party cloud integrations.

This incident is a stark reminder that delegated IAM permissions create a shared fate. Even with perfect internal security, a vendor's compromised credentials can grant attackers direct access to your cloud environment, completely bypassing your own perimeter defenses and security controls.

The breach demonstrates a significant supply-chain risk that can lead to data exfiltration, regulatory fines, and reputational damage. Companies must now re-evaluate the security posture of all third-party vendors with access to their cloud infrastructure, as a partner's vulnerability becomes their own.