Attackers Abuse Qubole's AWS Trust to Steal Customer Data

An attacker used credentials belonging to Qubole's own Amazon Web Services account to walk into customer cloud environments, steal stored secrets and copy S3 data, according to research Wiz published on November 9, 2026, after working with Sentra and Mandiant. The activity ran from October 14 through October 26. Qubole is Idera's data-lake product. How the credentials were obtained has not been disclosed. Sentra, which first noticed the activity across several of its own clients, said the campaign reached dozens of Qubole customers. Wiz declined to give The Register a count. The companies did not have to be broken into on their own. The path in was a vendor relationship they had already approved.

Customers normally let Qubole in by creating an IAM role in their own account whose trust policy allows Qubole's AWS account, 805246085872, to assume that role. A matching External ID is supposed to stop anyone else from doing the same. Wiz wrote that every AssumeRole call it tied to the attacker carried that code, and that AWS accepted each of them. The calls did not come from AWS. They began on October 14 from a Mullvad VPN address, then moved mostly to a rented OVH server, and later used a second Mullvad exit. Wiz said the genuine Qubole traffic it observed came only from AWS infrastructure. The first IAM user in Qubole's account, identified as AIDA3W7DIFLYOLTK63SFS, appeared only in this attacker's work in the environments Wiz reviewed. From October 18 the actor also used a second user in the same account, one that also carries genuine Qubole traffic.

The more unsettling finding was how many of the doors were old. In most environments Wiz examined, the attacker's requests were the only October activity from the vendor account against those roles. Those trust rules had been left intact, so AWS accepted the requests. Sentra wrote that some of the Qubole roles it saw had sat idle since the spring, and that one of those idle roles could still reach nearly all of the data later taken. In the pattern Sentra described, the attacker first tried the credentials on a low-value role and copied thousands of customer-profile files, then within minutes assumed the rest of the still-trusted Qubole roles and began large transfers that continued for days. A later pass from a different VPN address, Sentra said, pulled production database backups. The activity then stopped, but the trusts were still open, so the path back in remained.

Once inside, the actor looked for stored credentials. Wiz said it listed Lambda functions and read their environment variables, pulled values from Secrets Manager, and read parameters from Systems Manager Parameter Store, then ran what it found through TruffleHog to see whether the secrets still worked. Those were the victims' own AWS keys, Entra ID client secrets and Okta OAuth credentials, not the vendor's. Sentra reported about 100 passwords and keys read in seven minutes from those stores, plus thousands more credential records inside downloaded files, and no writes in the environments it reviewed. On S3, Wiz said the actor took whatever a given role could reach rather than hunting for a particular data set, and in some sessions copied an entire bucket. Several victims, Wiz noted, lacked the extra CloudTrail data-event or server-access logs needed to see which S3 objects left.

Wiz told any organization that has ever connected Qubole to AWS, including former customers whose roles still trust the vendor, to review CloudTrail from October 1 onward for AssumeRole events from account 805246085872 that arrived from an address outside AWS, and to treat any use of the first IAM user as hostile. Role sessions whose names start with quiam- also belong in that review. Wiz warned that changing a secret does not end temporary credentials already issued. Neither AWS nor Qubole answered questions from The Register, and The Hacker News found no statement from Qubole or Idera when it checked on November 9. Researchers had not said whether the stolen credentials had been disabled or the activity had stopped.

The controls that were supposed to help did not, because they treated the vendor's identity as the whole test. The External ID appears in plain text in CloudTrail, Wiz noted, so it should not be the only gate. A source-IP or VPC-endpoint condition limited to the vendor's documented ranges, Wiz wrote, would have rejected every role assumption the firm observed. Sentra said the secrets that left in the environments it handled had been reachable through permissions the platform did not need for the job.

The incident underscores that a vendor role left in a cloud account is a standing door, even when the product is no longer in use. Banks and insurers should inventory every IAM role that trusts an outside AWS account, delete or untrust integrations that are no longer needed, replace account-wide root principals with the specific identity the vendor uses, and pin role assumption to the vendor's published network ranges. Auditors can test CloudTrail from October 1 for the Qubole account and the attacker-only IAM user, confirm that S3 data events or server-access logs are on for buckets that hold customer or credential data, and check that any role the attacker assumed has had its secrets rotated and its sessions revoked. The same review belongs on other data-platform vendors whose roles can still read Secrets Manager, Lambda settings or broad S3 prefixes after the contract has ended.