Trusted by Default: Qubole Cross

A sophisticated supply chain attack leveraged misused third-party cross-account access within AWS environments associated with the platform Qubole. Threat actors utilized IAM credentials originating from Qubole's AWS account to assume integration roles established by customer organizations between October 14 and October 26, 2026. Initial access points involved IP addresses associated with Mullvad VPN and later a VPS hosted by OVH. Once authorized within victim accounts, the actor engaged in extensive reconnaissance, enumerating resources across storage, identity services, and configuration stores (Lambda, Secrets Manager, SSM Parameter Store). They subsequently harvested credentials using tools like TruffleHog to test access against AWS, Entra ID, and Okta before exfiltrating data from S3 buckets.
The intrusion was characterized by consistent session naming conventions, such as "quiam-enum." The attack chain demonstrated a clear pattern of permission escalation through the exploitation of trusting cross-account policies that remained in place even when vendor activity ceased during the observed period. Furthermore, unrelated to this role assumption event, research uncovered an ISO file hosted on one of the threat actor's IPs, which appeared designed for remote execution against Windows systems. Remediation centers on rigorous inventorying and tightening trust boundaries in cross-account relationships.

Threat actor utilized IAM credentials from AWS account 805246085872 (associated with Qubole) between October 14 and October 26, 2026.
Initial role assumption calls originated from Mullvad VPN IP address 45.83.220[.]211 on October 14, using IAM user AIDA3W7DIFLYOLTK63SFS.
Most activity shifted to VPS hosted by OVH at 57.129.54[.]120 starting October 15.
The threat actor began using IAM user AIDAJYRRH5Y3A7AAJM2HW on October 18, alongside a second Mullvad address (185.209.199[.]73).
Every observed AssumeRole request successfully utilized an External ID.
Discovery involved enumerating services like S3, Lambda configurations, Secrets Manager, and SSM Parameter Store.
Credential harvesting used TruffleHog to test keys against AWS GetCallerIdentity, Entra ID sign-ins, and Okta OAuth tokens.
Data exfiltration from S3 followed a pattern: ListBuckets, ListObjects, HeadObject, then GetObject.
An ISO file (ssoagent.iso) was found hosted on 57.129.54[.]120; this image is suspected to remotely boot and gather system information from Windows targets.
Detection requires reviewing CloudTrail for specific AssumeRole events matching account ID 805246085872 or principal IDs AIDA3W7DIFLYOLTK63SFS/AIDAJYRRH5Y3A7AAJM2HW, particularly when the source IP is external to AWS.

The strength of this advisory lies in meticulously mapping a complex, multi-stage attack that weaponizes established partnership mechanics—cross-account trust relationships—turning convenience into systemic vulnerability. The narrative posits that the widespread adoption of simplified onboarding mechanisms (allowing broad role assumption) creates an enormous surface area where a single compromised vendor credential can serve as a master key across numerous customer trusts. The threat pivots from mere unauthorized access to comprehensive lateral movement, encompassing not only resource enumeration but active credential theft and data exfiltration.
The unstated paradigm driving this attack is the prioritization of operational fluidity over prescriptive security gating in third-party integration architecture. Organizations often accept broad permission sets "for convenience," a cognitive shortcut that masks deep exposure; when one trusted principal (the vendor) inherits trust across dozens of unrelated customer scopes, the blast radius approaches planetary scale relative to individual policy review. The secondary discovery—a remote execution ISO linked to the actor’s infrastructure—suggests this was not purely opportunistic reconnaissance but part of a targeted, persistent threat campaign capable of achieving endpoint compromise alongside cloud data theft.
The critical failure mode illustrated here is procedural complacency: trust policies remain active even when legitimate vendor activity pauses or shifts (as seen by role assumptions occurring outside of regular platform traffic windows). This highlights that relying solely on the *existence* of an External ID check, which can be logged and potentially replicated, does not equate to true assurance.
What systemic changes in vendor lifecycle management could shift this dynamic from opportunistic exploitation toward friction-based defense? How might customers independently audit the implied trust graph—the total scope of every external permission granted to their cloud environment—without requiring deep expertise? Given the overlap between legitimate and malicious activity using principal IDs, how can identity providers enforce behavior profiles across distinct cloud accounts for a single named entity?
Counterstrike scan: A coordinated influence campaign might frame this as an inevitable consequence of digital globalization ("all trust requires risk"), overwhelming technical nuance with existential anxiety. The actual content, however, is highly granular and actionable; its primary goal appears to be knowledge transfer disguised by the immediacy of the "in the wild" framing, rather than ideological persuasion.
Autonomy check: No autonomy signals.