What happened
From October 8 to October 11, 2026, a separate unlinked actor used customer-owned AWS keys believed to support Qubole integrations. Between October 14 and October 26, 2026, the main campaign used Qubole-associated IAM credentials to assume customer integration roles. Wiz observed successful AssumeRole calls from Qubole-associated AWS account 805246085872 using IAM principal AIDA3W7DIFLYOLTK63SFS; later activity also used AIDAJYRRH5Y3A7AAJM2HW. Every malicious role-assumption request identified by Wiz included an External ID and succeeded.
Published source addresses include 45.83.220[.]211, 57.129.54[.]120 and 185.209.199[.]73, with role-session names including quiam-enum and quiam-scope-full. The first and third addresses are shared VPN exit nodes, while the second is OVH-hosted infrastructure; address matches require session and identity context. The actor queried Lambda configuration, Secrets Manager, SSM Parameter Store and S3, used TruffleHog to validate AWS, Microsoft Entra ID and Okta credentials, and downloaded accessible S3 data.
Wiz found sso_agent.iso with SHA-256 65f061281c9a712e9502793dc4c5035cae490b84da05f7d4223cefa65ad396e4 and TCP port 23458 on 57.129.54[.]120, but did not identify any deployment and could not confirm its use. On November 9, 2026, Wiz published the campaign and detection guidance. Attribution posture: Wiz has not linked the campaign to a known group and has no direct evidence establishing the actor’s motivation or intended use of stolen data.
Why this matters now
This campaign turns a routine SaaS integration pattern into a direct control-plane intrusion path. Customers had created roles trusting Qubole’s AWS account, and many of those roles remained assumable despite little or no legitimate use. A valid External ID did not prevent access because the attacker supplied it successfully. The decisive control is therefore active governance of trusted principals, source networks, permissions and role lifecycle.
The compromise path crossed identity boundaries after initial AWS access. The actor retrieved secrets from Lambda, Secrets Manager and SSM Parameter Store, tested AWS keys, signed into Microsoft Entra ID service principals, requested Okta OAuth tokens and downloaded S3 data. A single overprivileged vendor role can therefore become a multi-cloud credential broker, making session revocation and downstream secret rotation inseparable from the AWS investigation.
The decision for security leaders
Organisations that have integrated with Qubole should review CloudTrail from October 1, 2026 onward for AssumeRole events where userIdentity.accountId equals 805246085872 and sourceIPAddress is outside AWS infrastructure. Extend the query across every account and region containing external trust roles, then reconstruct all subsequent activity for each matching session rather than closing the alert on the initial role assumption.
If a malicious session is confirmed, revoke the session before rotating credentials because rotation alone does not terminate temporary credentials already issued. Identify every Lambda environment variable, Secrets Manager value, SSM parameter, S3 object and downstream identity credential readable by the role. Remove unused integrations, replace account-root trust with specific principals where supported, and constrain assumptions to documented vendor networks or VPC endpoints.
Evidence of closure
- CloudTrail results cover every account and region containing external trust roles.
- Each suspicious session has a documented activity graph and approved disposition.
- Session-revocation evidence shows malicious temporary credentials are invalid.
- Trust policies show obsolete Qubole access removed.
The Security.io assessment
This is confirmed cross-account compromise observed by incident responders, but the external record lacks first-party confirmation from Qubole or AWS. Wiz did not publish a complete victim list or an authoritative total of affected organisations. The account identifier is also used for legitimate Qubole activity, and the second IAM principal appears in legitimate traffic, so detections must combine identity, source network, session name and subsequent API behaviour.
The strongest closure evidence is not deletion of an IAM role; it is a complete activity graph showing what the assumed session accessed, proof that active sessions were revoked and proof that every readable credential was replaced. The ISO artefact is an important lead but not evidence that victims booted it. Security.io would raise severity if deployments of sso_agent.iso are confirmed or if additional vendor accounts are found using the same method.
Questions for the morning meeting
- Which external AWS accounts can still assume roles in production environments?
- Can responders observe object-level S3 reads after a third-party role assumption?
- Who can revoke vendor sessions and rotate every reachable secret without waiting for the supplier?