Wiz says mostly unused Qubole cross-account AWS roles were abused 14 to 26 Oct; entry route not stated
Wiz says a threat actor used IAM credentials from an AWS account associated with Qubole to assume customer roles from 14 to 26 October 2026, 12 days (derived), mostly on roles nobody was using. How the credentials were obtained is not disclosed.
By Parminder Kumar Sharma · LinkedIn · · 20 min read
12 days, and in most observed environments the vendor account's only calls in October were the actor's
Wiz's post "Trusted by Default: Qubole Cross-Account Access Abused in the Wild" is dated 9 November 2026 by its page data (09:56:32 at UTC minus five hours, which is 14:56 UTC, derived). It says that, working with Sentra and Mandiant, Wiz "observed a threat actor using IAM credentials from an AWS account associated with Qubole between October 14 and October 26, 2026". That is 12 days from the first date to the last (derived; 13 calendar days if both ends are counted), and the last observed date is 14 days before the post (derived). The actor used those credentials to assume IAM roles that customers had created to trust the Qubole associated account. On those roles Wiz says: "Most of the roles the threat actor assumed were not otherwise in use", and in a majority of the environments it observed, the actor's requests were "the only AssumeRole activity from the vendor account in October". The roles were still trusted, and the requests succeeded.
What that does not establish is most of the story. The post does not say how the actor came to hold credentials from that AWS account. It does not say whether Qubole's platform was breached, or whether an account credential was exposed some other way. It prints no number of affected customers or environments, names none, and does not say what or how much data was taken. It carries no statement from Qubole, and this site found none on Qubole's own pages. Every observation here is Wiz's, as read from 20:35 UTC on Monday 9 November 2026; Wiz says it has not identified ties to other publicly reported activity, and that it has no direct insight into the actor's motive.
A note on interest, once: Wiz sells cloud security products and its post names two of them, a Security Graph and Wiz Defend threat detections, beside its advice. Sentra, which first noticed the activity, sells a data security platform and ends its own post with an offer of a demo. Neither is independent verification of the other, and the sources are Wiz, Sentra, the AWS documentation on External IDs and the confused deputy problem, and Qubole's own site. Mandiant is credited by both Wiz and Sentra, and this site found no Mandiant post on the matter.
What Wiz says happened, in its own order
The arrangement. Wiz describes the ordinary design. During onboarding a customer creates a role in its own account whose trust policy lets the vendor's AWS account assume it, "typically gated by an External ID". When the vendor needs to act, an identity in the vendor's account calls the AWS security token service to assume the role with the role ARN and External ID, and gets temporary credentials scoped to that role. The trust policy Wiz prints is reproduced in Technical details.
First activity. Wiz CIRT says the first activity it observed was on 14 October, when an address Wiz says belongs to Mullvad VPN called AssumeRole against integration roles in customer environments. The calls came from an AWS account that Wiz says it observes "Qubole's platform using to assume roles in customer environments", and used an IAM user that Wiz says it has not seen in any other activity in the affected environments. From 15 October most activity came from a VPS hosted by OVH. On 18 October the actor began using a second IAM user in the same account, and Wiz says that user "also carries legitimate Qubole platform traffic from AWS infrastructure". The same day a second Mullvad address assumed integration roles in multiple victim environments in quick succession.
The External ID was no obstacle. Wiz says "Every AssumeRole request we attributed to the threat actor included an External ID, and every one succeeded". The post ties this to roles that were mostly idle: "The trust policies were still in place, so the requests succeeded". The post does not say how the actor knew the External IDs. It says only that the value is logged in plaintext in CloudTrail and is often stored by the vendor and in infrastructure as code.
Inside the environments. The actor enumerated broadly across services (the calls are tabulated in Technical details). Session names followed a fixed pattern, the prefix quiam- followed by a suffix describing the action, such as quiam-enum and quiam-scope-full. It then went to the places where credentials sit: Lambda function configuration, which returns environment variables, then Secrets Manager and SSM Parameter Store. It used TruffleHog to test credentials it found. Wiz says those credentials "belonged to the affected organizations, not to the vendor": AWS access keys checked through GetCallerIdentity in bursts lasting seconds, Entra ID service principal client secrets, and Okta client credentials. Wiz does not say in which store each kind of credential was found.
The data. In the S3 sequence Wiz describes, a role is assumed, ListBuckets shows what it can reach, ListObjects and HeadObject enumerate and inspect, and GetObject downloads. Wiz calls the actor "opportunistic", reading from whatever each role could reach, "in some cases downloading entire buckets in a single session". The post says "CloudTrail management events record the role assumption and the bucket listing, but not the object reads", and that in several affected environments missing logs meant responders could not see which S3 objects were read. So for those environments the post itself says what was taken could not be established from the logs.
The clock: dates Wiz gives, and the ones nobody gives
The access window, discovery, containment, notification and publication are separate dates. Wiz gives an observed activity window and its own publication date. It does not give when the vendor account credentials were obtained, when anyone was told, or when the access was cut. The first observed date is the first date Wiz saw activity, not necessarily the first date it happened.
The dates, who stated each, and the intervals this site counted (derived by script from the stated dates)
| Date (2026) | What it is | Source, and interval |
|---|---|---|
| 8 to 11 October | An actor used customer owned AWS access keys believed created for Qubole integrations. All the keys were tested within a single hour on 8 October | Wiz. Wiz could not link it to the role assumption activity. It ended 3 days before 14 October at its last date (derived: 11 to 14 October) |
| 14 October | First activity Wiz CIRT observed: AssumeRole from a Mullvad VPN address, first IAM user | Wiz. 6 days after 8 October (derived); 13 days after the hunting start date of 1 October (derived) |
| 15 October | Most activity from a VPS hosted by OVH | Wiz, post text and indicator table. 1 day after the first activity (derived) |
| 16 to 19 October | TruffleHog seen validating credentials | Wiz indicator table, first and last seen |
| 18 October | Second IAM user in use; second VPN address assumes roles in multiple environments | Wiz. 4 days after 14 October (derived) |
| 25 October | A third VPN address, registered to a VPN company, used once | Wiz indicator table only; not in the post text |
| 26 October | Last date in the indicator tables | Wiz. 12 days after 14 October (derived); 14 days before publication (derived) |
| 9 November | Wiz publishes; Sentra publishes the same day (12:00 UTC by its page data, modified 20:17 UTC) | Page data. 26 days after the first observed date (derived) |
| Not stated | When the vendor account credentials were obtained; when affected customers were told; when access was cut; any Qubole statement | Wiz and Sentra are silent on each; none on Qubole's pages |
Read the table from the bottom up. The hunting guidance tells defenders to review CloudTrail from 1 October, which is 13 days before the first date Wiz observed (derived). That is Wiz's choice of a baseline, not a finding that anything happened earlier. The publication date, 9 November, is 26 days after the first observed activity and 14 days after the last (both derived), and the post does not say how many of those days the access remained open.
A trust you stopped using still worked, and the External ID checked something else
Two comforting labels carry weight here. The first is the External ID. AWS's own documentation says "The primary function of the external ID is to address and prevent the confused deputy problem." In that problem an entity without permission tricks a more privileged one into acting for it, for example a second customer of a vendor persuading the vendor to use the first customer's role. The AWS documentation also says "AWS does not treat the external ID as a secret." and that the value "is not intended to be a 'secret'".
This is an inference, labelled as one. An External ID tells the customer's role which vendor customer a request is made for. It is not a test of whether the caller is the vendor's legitimate workload. If an actor can call from a principal in the vendor's account, and holds or can learn the External ID, the check passes, and Wiz's account is that it did, every time. Wiz's own recommendation fits that reading: "With these conditions in place, a valid External ID from an unexpected identity or network is rejected", where the conditions are a narrower trusted principal and a source address or VPC endpoint condition. The AWS third party page also carries two descriptions of the value. One says the External ID can be any identifier that is "known only by you and the third party", and another line on the same page says it is not intended to be a secret. Wiz's advice, to treat it as non secret, matches the second.
The second label is the integration itself. Wiz says "Many victim environments had no legitimate vendor traffic during this activity. Those roles still accepted the threat actor's requests". Sentra, describing one affected customer, says the platform was one the customer "had stopped using a while ago" and that its roles "had been dormant since the spring". Those are Sentra's statements about one customer, not a finding across all victims. The point they share is that a role no one uses is not a role no one can use. That is why Wiz calls an AssumeRole from a vendor account through a VPN or an unfamiliar hosting provider "a high-signal detection": in most observed environments the actor's calls were the only vendor account AssumeRole activity in October.
A third claim is worth separating. Wiz says a source address condition alone "would have blocked every role assumption we observed", and Sentra says that "a network restriction alone would have blocked every login we saw". Both are vendor statements about their own observations. They depend on the vendor publishing the network ranges it acts from; Wiz tells SaaS providers to "publish your egress ranges so customers can pin their trust policies". This site did not find where Qubole publishes any ranges, and has not checked whether it does.
What Wiz states, and what it does not
Questions the reader will ask, what Wiz's post states, and what is not stated or differs. Read 9 November 2026.
| Question | What Wiz states | Not stated, or elsewhere |
|---|---|---|
| Where the access came from | IAM credentials from an AWS account associated with Qubole, which Wiz says it observes Qubole's platform using | How the actor obtained them; whether Qubole's platform was breached or a credential exposed. Sentra's post says an attacker "got hold of credentials belonging to Qubole" and gives no evidence for that |
| How many victims | Sentra saw activity across several customer environments; the actor was inside multiple victim AWS environments; a majority of the environments Wiz observed had no other vendor AssumeRole activity in October | No count of customers, accounts or environments in the Wiz post. Sentra says more than a dozen accounts of one customer |
| Which victims | Unnamed | No customer names anywhere read |
| What was taken | Secrets and parameters read; S3 objects downloaded, in some cases whole buckets in one session | What data, how much, which fields. In several environments missing logs hid which objects were read |
| Misuse of the secrets | Credentials were validated with TruffleHog: AWS keys, Entra ID client secrets, Okta client credentials | Whether any validated credential was then used; Wiz says it has no insight into how the stolen data may be used |
| The 8 to 11 October activity | A separate actor activity with customer owned keys; in a small number of cases the actor went on to compromise the victim's cloud environment | Any link to the role assumption activity: Wiz says it could not link them |
| The ISO file | A bootable Linux image hosted on the actor's OVH address; 90 minute timer; polls for shell commands | Any deployment: Wiz has not identified one and cannot confirm if or how it was used |
| Who the actor is | No ties to other reported activity; opportunistic; not typical state backed priorities | Identity, motive, whether any group claims it |
| Victim notification | Not in the Wiz post | Sentra says it warned each affected customer directly |
| What Qubole says | Nothing quoted | No statement found on Qubole's pages; whether the credentials were revoked is not stated |
| What Mandiant found | Named as working with Wiz and Sentra | No Mandiant post found on its threat intelligence blog page when read |
Who Qubole is, from its own pages only: the About page says "With Qubole, an Idera Inc company", and its news page lists "Idera, Inc. Acquires Qubole" under 13 October 2020. Its pages carry a 2024 copyright line, and its security page is a vulnerability disclosure page that asks reporters to use an email address. None of the Qubole pages read mentions an incident, a customer notice, Wiz, Sentra or Mandiant. That shows what those pages say on 9 November 2026, not that Qubole has said nothing elsewhere. Sentra calls Qubole "a legacy big-data platform"; Wiz does not describe it beyond calling it a data processing platform in its background section.
Where the sources differ
The differences are listed rather than resolved. The article follows Wiz's post where Wiz and Sentra differ, because Wiz is the one that says it analysed the activity across environments, and says so. Sentra's post is the account of one affected customer's investigation, written by a vendor that sells data security software, and its page was modified at 20:17 UTC on the day of publication.
Differences between the Wiz post, the Sentra post and the AWS pages, read 9 November 2026
| Point | Wiz | Others say |
|---|---|---|
| How the access was gained | Not disclosed; no statement that the credentials were stolen | Sentra's title and text say one stolen vendor key, and that an attacker got hold of credentials belonging to Qubole. No evidence is printed for how |
| Where secrets were read | Lambda environment variables, Secrets Manager, SSM Parameter Store | Sentra adds EC2 user data, and says secrets read included the vendor's own tokens and ExternalIds, for its customer |
| Speed and scale | No timings | Sentra, for one customer: about 3 minutes to enter every trusting account, more than a dozen; about 100 passwords and keys read in 7 minutes; no write actions |
| Database backups | Not mentioned | Sentra says a final pass from a different VPN address pulled production database backups, and that file access logs showed millions of files across the customer's accounts |
| Dormancy | Most assumed roles were not otherwise in use | Sentra: the customer's Qubole roles had been dormant since the spring |
| Indicators in the post | Text names a second Mullvad address; the table lists five network indicators: three VPN addresses and two OVH addresses, one of them IPv6 | The 25 October VPN address and the IPv6 prefix appear in the table only |
| The External ID | Treat as non secret; logged in plaintext; often in infrastructure as code | AWS says it is not treated as a secret, yet also says it can be an identifier known only by the customer and the third party |
| The post's own typing | The table prints the owner of one address as registered to "Mullvlad VPN AB" | Printed as the post prints it; the text spells it Mullvad |
What to do, in order
Take this with you
Ranked actions. Each item says whose advice it is; Wiz's come from its post, the others are this site's suggestion.
- Wiz: review CloudTrail from 1 October 2026 onward, in every account that holds an integration role, for the AssumeRole patterns printed in Technical details.
- Wiz: for every role session you find, review all later activity from that session, especially Secrets Manager, SSM Parameter Store, Lambda and S3.
- Wiz: if the actor assumed an integration role, rotate every secret, parameter and Lambda environment variable the role could read, and revoke active sessions for the role. Rotating a credential does not end temporary sessions already issued.
- Wiz: check your identity provider's sign in logs for the TruffleHog user agent, because the actor tested Entra ID and Okta credentials as well as AWS keys. TruffleHog is also run by legitimate security teams, so match it only with other indicators.
- Wiz: make sure S3 data events in CloudTrail, or S3 server access logs, are on for buckets holding sensitive data, and use an organization trail covering all accounts and regions. Without them the object reads are not recorded.
- Wiz: inventory every IAM role whose trust policy allows an external account, and delete integration roles you no longer use or remove the vendor account from their trust policies. The AWS documentation points to IAM Access Analyzer for finding principals outside your zone of trust.
- Wiz: where the vendor supports it, replace the account root principal with the specific IAM principal the vendor uses, and add an aws:SourceIp or aws:SourceVpce condition limited to the vendor's documented ranges.
- Wiz: treat the External ID as non secret, use a distinct value per role where supported, rotate it with the vendor after an event like this, and limit what integration roles can reach, including Lambda configuration, Secrets Manager, SSM parameters and broad S3 read.
- This site's suggestion: for every integration role, record the last date the vendor legitimately assumed it. Wiz found many victim environments with no legitimate vendor traffic, so a role with no use this quarter is the first candidate for removal.
- This site's suggestion: if you used Qubole, ask it in writing whether it has revoked the credentials involved, whether it publishes the network ranges it acts from, and whether its principals use short lived credentials. The questions follow Wiz's advice to SaaS providers; no Qubole statement has been found.
Technical details
Everything below is copied from the Wiz post as printed, read 9 November 2026, with the addresses defanged as the post defangs them. Wiz publishes no scanner, script, detection rule file or query text in the post. Its hunting guidance is a list of CloudTrail field filters, and its one query is a link into its own Security Graph product, which this site did not open and does not reproduce. Never visit, resolve or probe any address here. The Mullvad addresses are shared VPN exit nodes, and the post says activity from them alone is not conclusive.
The trust policy pattern. This is the explanatory snippet from the post's background section: the trust policy a customer puts on an integration role. Placeholders are the post's own. A defender uses it to find which of their roles name an external account principal and which require an External ID.
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::<vendor-account-id>:root" },
"Action": "sts:AssumeRole",
"Condition": { "StringEquals": { "sts:ExternalId": "<external-id>" } }
}
The CloudTrail hunting filters. The post says to review CloudTrail from 1 October 2026 onward in every account that holds an integration role, and gives these filters. Run them in CloudTrail Lake, Athena or your SIEM, and for each hit review the whole role session. The account ID and principal IDs are the vendor side identifiers Wiz prints for hunting.
AssumeRole events where userIdentity.accountId is 805246085872 and sourceIPAddress is not an AWS address.
AssumeRole events where userIdentity.principalId is AIDA3W7DIFLYOLTK63SFS.
AssumeRole events where userIdentity.principalId is AIDAJYRRH5Y3A7AAJM2HW and sourceIPAddress is not an AWS address.
Any activity from the IP addresses in the IOC tables below.
GetCallerIdentity calls with a TruffleHog user agent paired with any IOC IP address
Session names. The actor's role sessions started with a fixed prefix. Search the RoleSessionName field for it.
quiam-*
quiam-enum
quiam-scope-full
The API calls Wiz saw, by stage. A defender uses the table to decide which of these calls their logging would have recorded. The post notes that the object reads in the S3 row do not appear in management events.
API calls as the Wiz post lists them, grouped by stage. Read 9 November 2026.
| Stage | Service | Calls as printed |
|---|---|---|
| Enumeration | Storage and data | ListBuckets, ListObjects, GetDatabases, ListTables, DescribeClusters |
| Enumeration | Compute | DescribeInstances, DescribeImages, DescribeSecurityGroups, DescribeVpcs |
| Enumeration | Databases | DescribeDBInstances, DescribeDBSnapshots |
| Enumeration | Identity and keys | ListRoles, ListKeys, ListAliases, DescribeKey, GetKeyPolicy |
| Credential harvesting | Lambda | List functions, then GetFunctionConfiguration on each (returns environment variables) |
| Credential harvesting | Secrets Manager | ListSecrets followed by GetSecretValue |
| Credential harvesting | SSM Parameter Store | DescribeParameters and GetParameter |
| Validation | AWS, Entra ID, Okta | GetCallerIdentity with discovered access keys; Entra ID service principal sign ins with client secrets; OAuth token requests with Okta client credentials, all through TruffleHog |
| Data access | S3 | ListBuckets, then ListObjects and HeadObject, then GetObject |
Network indicators. These are the five rows of the post's network table: the address, the autonomous system owner, first and last seen, and Wiz's note. Block or alert on them only with the post's caution in mind about shared VPN exits.
57.129.54[.]120 | OVH GmbH | 2026-10-15 | 2026-10-26 | Primary address for role assumption, enumeration, and credential harvesting.
2001:41d0:70d[:]7800:: | OVH GmbH | 2026-10-16 | 2026-10-24 | Credential enumeration and verification.
45.83.220[.]211 | 31173 Services AB | 2026-10-14 | 2026-10-15 | Used to assume roles within customer accounts.
185.209.199[.]73 | 31173 Services AB | 2026-10-18 | 2026-10-21 | Used to assume roles within customer accounts.
89.37.63[.]175 | Datacamp Limited (Registered to Mullvlad VPN AB) | 2026-10-25 | 2026-10-25 | Used to assume roles within customer accounts.
Identity indicators. The vendor side AWS account ID and the two IAM user principal IDs, as the post prints them for hunting. They are not customer identifiers.
805246085872 | AWS Account ID | Source account for all observed role assumptions. Also used for legitimate Qubole platform activity
AIDA3W7DIFLYOLTK63SFS | IAM Principal ID | IAM user in 805246085872. Observed only in threat actor activity.
AIDAJYRRH5Y3A7AAJM2HW | IAM Principal ID | IAM user in 805246085872. Used by the threat actor from October 18. Also present in legitimate platform activity from AWS infrastructure
quiam-* | Role session names | Session names used by the threat actor
User agents. Wiz's own caution applies to every row: treat a match as suspicious only alongside the listed addresses, principal IDs or another indicator. The TruffleHog row is also run by legitimate security teams.
Boto3/1.37.9 md/Botocore#1.37.9 ua/2.1 os/linux#6.12.111+deb13-amd64 md/arch#x86_64 lang/python#3.13.5 | 2026-10-15 | 2026-10-26
aws-cli/2.37.12 md/awscrt#0.37.0 ua/2.1 os/linux#6.12.111+deb13-amd64 md/arch#x86_64 lang/python#3.14.6 | 2026-10-21 | 2026-10-26
Boto3/1.43.108 md/Botocore#1.43.108 ua/2.1 os/linux#6.1.0-53-arm64 md/arch#aarch64 lang/python#3.11.2 | 2026-10-18 | 2026-10-21
Boto3/1.43.113 md/Botocore#1.43.113 ua/2.1 os/linux#7.0.0-38-generic md/arch#x86_64 lang/python#3.12.3 | 2026-10-14 | 2026-10-25
TruffleHog | 2026-10-16 | 2026-10-19
The ISO file. Wiz says it found this file through Validin, hosted on the actor's OVH address while the actor controlled it. It calls it a bootable Linux image that it believes is designed to be remotely booted on a victim machine, with a 90 minute timer ending in a hard reboot, and that it loads the ntfs3 driver at boot, which Wiz says suggests a Windows target. Wiz has not identified any deployments. A defender can search file stores and boot media inventories for the name and hashes.
sso_agent.iso
MD5: 086d4a83181971e883c53a4c44f46da2
SHA-1: 1c7437dac21630f53c0b888b50662c6487e23fd7
SHA-256: 65f061281c9a712e9502793dc4c5035cae490b84da05f7d4223cefa65ad396e4
Polling: the same OVH address, TCP port 23458, per the post text
The question the post leaves open
Wiz shows that a role nobody used, trusted by a vendor account, accepted valid requests from a VPN and a rented server for 12 days (derived), and that the External ID was no barrier. It does not say how those requests came to carry the vendor account's credentials, and nobody has yet said so on the record. Which roles in your accounts trust a vendor you no longer use, when did that vendor last assume them, and who in your company would know if someone else did?
Key facts
Sources
- PrimaryTrusted by Default: Qubole Cross-Account Access Abused in the Wild, 9 November 2026 by page data: every observation, the hunting filters and the indicator tables. Read in fullWizaccessed 2026-11-09
- PrimaryOne Stolen Vendor Key, Every Customer's Data Exposed: Inside the Qubole Supply Chain Attack, 9 November 2026 by page data: one affected customer's investigation. Sentra sells a data security platformSentraaccessed 2026-11-09
- PrimaryThe confused deputy problem, IAM User Guide: what the External ID is forAmazon Web Servicesaccessed 2026-11-09
- PrimaryAccess to AWS accounts owned by third parties, IAM User Guide: AWS does not treat the External ID as a secretAmazon Web Servicesaccessed 2026-11-09
- PrimaryAbout Us: describes Qubole as an Idera Inc company; no incident statementQuboleaccessed 2026-11-09
- PrimarySecurity Reporting: a vulnerability disclosure page, no incident statementQuboleaccessed 2026-11-09
- PrimaryNews: lists the Idera acquisition of 13 October 2020; no incident statementQuboleaccessed 2026-11-09
- PrimaryThreat Intelligence blog listing (Mandiant and Google Threat Intelligence Group): no post on Qubole found when readGoogle Cloudaccessed 2026-11-09
