CTIPilot
AI-generated · no human review · verify critical claims against the linked source. how it works →

Qubole

product · product:qubole

Coverage
1
first 2026-11-11 → last 2026-11-11
Latest activity
2026-11-11
Stolen Qubole vendor credentials assumed customers' idle AWS integration roles; a source-IP condition stops it
Peak priority
notable
1 notable
Targets
technology
sectors: technology
Sources cited
3
3 hosts

Action items (1)

Do-now tasks recorded on the entries about Qubole, newest first. Check the date before acting on an older one.

  • In every AWS account, list the IAM roles whose trust policy names an external vendor account, delete those of finished integrations, pin the rest to the vendor's specific principal with an aws:SourceIp or aws:SourceVpce condition, and search CloudTrail from 2026-10-01 for AssumeRole calls into them from non-vendor network addresses, using the account identifier and session-name prefix Wiz publishes, because the actor's calls carried the correct External ID and succeeded on roles nobody was using.
    2026-11-11Stolen Qubole vendor credentials assumed customers'…

Defender insights

What each entry about Qubole tells a defender to do, newest first.

2026-11-11NOTABLEStolen Qubole vendor credentials assumed customers' idle AWS integration roles; a source-IP condition stops it

Exposure · triage · detection

Story timeline

  1. 2026-11-11Qubole: an attacker used IAM credentials from a vendor-associated AWS account to assume dormant cross-account integration roles in dozens of customer accounts, then harvested secrets and validated Entra ID and Okta client credentials (Wiz and Sentra, 14 to 26 October)
    active-threatsStolen Qubole vendor credentials assumed customers' idle AWS integration roles; a source-IP condition stops it

Hunting pivots

Releases covered
Qubole
ATT&CK techniques (6 across 7 tactics)

6 techniques observed across 1 entry about this entity, derived from entry metadata and body evidence, never asserted without a published entry behind it · pinned to MITRE ATT&CK v20.1 · compare on the matrix · Navigator layer (JSON)

  • Initial AccessValid Accounts: Cloud Accounts · Trusted Relationship
  • PersistenceValid Accounts: Cloud Accounts
  • Privilege EscalationValid Accounts: Cloud Accounts
  • StealthValid Accounts: Cloud Accounts
  • Credential AccessCredentials from Password Stores: Cloud Secrets Management Stores
  • DiscoveryCloud Infrastructure Discovery · Cloud Storage Object Discovery
  • CollectionData from Cloud Storage

Initial Access TA0001

T1078.004Valid Accounts: Cloud Accounts×1

Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.

Evidence: 2026-11-11/qubole-vendor-aws-identity-assumes-integration-roles · ATT&CK page ↗

T1199Trusted Relationship×1

Adversaries may breach or otherwise leverage organizations who have access to intended victims. Access through trusted third party relationship abuses an existing connection that may not be protected or receives less scrutiny than standard mechanisms of gaining access to a network.

Evidence: 2026-11-11/qubole-vendor-aws-identity-assumes-integration-roles · ATT&CK page ↗

Persistence TA0003

T1078.004Valid Accounts: Cloud Accounts×1

Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.

Evidence: 2026-11-11/qubole-vendor-aws-identity-assumes-integration-roles · ATT&CK page ↗

Privilege Escalation TA0004

T1078.004Valid Accounts: Cloud Accounts×1

Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.

Evidence: 2026-11-11/qubole-vendor-aws-identity-assumes-integration-roles · ATT&CK page ↗

Stealth TA0005

T1078.004Valid Accounts: Cloud Accounts×1

Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.

Evidence: 2026-11-11/qubole-vendor-aws-identity-assumes-integration-roles · ATT&CK page ↗

Credential Access TA0006

T1555.006Credentials from Password Stores: Cloud Secrets Management Stores×1

Adversaries may acquire credentials from cloud-native secret management solutions such as AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, and Terraform Vault.

Evidence: 2026-11-11/qubole-vendor-aws-identity-assumes-integration-roles · ATT&CK page ↗

Discovery TA0007

T1580Cloud Infrastructure Discovery×1

An adversary may attempt to discover infrastructure and resources that are available within an infrastructure-as-a-service (IaaS) environment. This includes compute service resources such as instances, virtual machines, and snapshots as well as resources of other services including the storage and database services.

Evidence: 2026-11-11/qubole-vendor-aws-identity-assumes-integration-roles · ATT&CK page ↗

T1619Cloud Storage Object Discovery×1

Adversaries may enumerate objects in cloud storage infrastructure. Adversaries may use this information during automated discovery to shape follow-on behaviors, including requesting all or specific objects from cloud storage. Similar to File and Directory Discovery on a local host, after identifying available storage services (i.e. Cloud Infrastructure Discovery) adversaries may access the contents/objects stored in cloud infrastructure.

Evidence: 2026-11-11/qubole-vendor-aws-identity-assumes-integration-roles · ATT&CK page ↗

Collection TA0009

T1530Data from Cloud Storage×1

Adversaries may access data from cloud storage.

Evidence: 2026-11-11/qubole-vendor-aws-identity-assumes-integration-roles · ATT&CK page ↗

Entries about Qubole (1)

2026-11-11 · view entry permalink →

NOTABLENATOB1

Qubole: an attacker used IAM credentials from a vendor-associated AWS account to assume dormant cross-account integration roles in dozens of customer accounts, then harvested secrets and validated Entra ID and Okta client credentials (Wiz and Sentra, 14 to 26 October)

Wiz, working with Sentra and Mandiant, observed a threat actor using IAM credentials from an AWS account associated with Qubole, a big-data platform, between 2026-10-14 and 2026-10-26 (Wiz, 2026-11-09). The actor used two Qubole IAM users to call sts:AssumeRole on the cross-account integration roles that customers had created to trust Qubole's account; "every AssumeRole request we attributed to the threat actor included an External ID, and every one succeeded", most of the roles were otherwise not in use, and the traffic came from a rented hosting server and commercial VPN exits, not the AWS infrastructure where legitimate platform traffic originates (Wiz, 2026-11-09; Sentra, 2026-11-09).

Inside each account the actor enumerated resources, read Lambda function configuration, Secrets Manager and Systems Manager Parameter Store, ran TruffleHog to test AWS access keys, Entra ID service-principal client secrets and Okta client credentials it found, and then downloaded S3 data opportunistically, in some cases whole buckets in one session (Wiz, 2026-11-09). Wiz found no tie to other reported activity and judges the targeting opportunistic; how the Qubole IAM users were compromised is not stated. Sentra writes that dozens of Qubole customers were impacted, and BleepingComputer could not find a public Qubole announcement (Sentra, 2026-11-09; BleepingComputer, 2026-11-10). No Swiss or public-sector victim is named, but the exposure is shared by any account that gave a data or analytics vendor a cross-account role and left it in place.

Triage: legitimate vendor traffic comes from the vendor's own AWS infrastructure; the correct External ID does not discriminate, because it is logged in plaintext and often stored by the vendor, while a vendor role assumed from a consumer VPN or a hosting provider the vendor has never used is the high-signal case.

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.

Every AssumeRole request we attributed to the threat actor included an External ID, and every one succeeded.

In this activity, a source IP condition alone would have blocked every role assumption we observed.

Wiz 2026-11-09

Dozens of Qubole customers were impacted.

Sentra 2026-11-09

BleepingComputer could not find a public announcement from Qubole about this incident.

BleepingComputer 2026-11-10
incident11 Nov 03:41Zmulti-sourceOpen finding →
Sources: Wiz · Sentra · BleepingComputer

Co-occurring entities

Derived: referenced by the same focused operational entries (weekly summaries and report roundups don't count); ×N counts the shared entries.

Where this entity is cited

  • Threats1

Source distribution

  • bleepingcomputer.com1 (33%)
  • sentra.io1 (33%)
  • wiz.io1 (33%)