Qubole Cross-Account Access Abused in the Wild: AWS Integration Role Assumption Campaign

Key facts

Detection coverage

As of 2026-11-10, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5571 across Splunk SPL, Microsoft KQL and Sigma, covering 20 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: Assumed-Role Harvesting of Secrets Manager, SSM Parameters and Lambda Environment Variables (TL-2026-5571)

Detects role sessions that read Secrets Manager (ListSecrets/GetSecretValue), SSM Parameter Store (DescribeParameters/GetParameter) and Lambda configuration (GetFunctionConfiguration, which exposes environment variables), the credential-harvesting stage of the Qubole integration-role campaign. Fires on the actor's quiam- session names, on actor IPs, or on behavioural breadth (two or more of the three services with 10+ calls in a session).

• Languages: Splunk SPL, Microsoft KQL, Sigma
• ATT&CK: T1555.006, T1552, T1526, T1580
• Data sources: aws_cloudtrail, index=aws sourcetype=aws:cloudtrail, AWSCloudTrail
• Severity: high
• Confidence: high

Splunk SPL

index=aws sourcetype="aws:cloudtrail" "userIdentity.type"=AssumedRole
    ((eventSource="secretsmanager.amazonaws.com" eventName IN ("GetSecretValue","ListSecrets","BatchGetSecretValue"))
  OR (eventSource="ssm.amazonaws.com" eventName IN ("GetParameter","GetParameters","GetParametersByPath","DescribeParameters"))
  OR (eventSource="lambda.amazonaws.com" (eventName="GetFunctionConfiguration*" OR eventName="ListFunctions*")))
```Secrets then SSM then Lambda env-var reads inside one assumed-role session indicate credential harvesting```
| eval arn='userIdentity.arn', src_ip=sourceIPAddress, session=mvindex(split('userIdentity.arn',"/"),-1), svc=mvindex(split(eventSource,"."),0)
| stats count as calls dc(svc) as services dc(eventName) as distinct_apis values(svc) as service_list values(eventName) as apis min(_time) as first_seen max(_time) as last_seen by arn session src_ip userAgent recipientAccountId
| where like(session,"quiam-%") OR in(src_ip,"57.129.54.120","45.83.220.211","185.209.199.73","89.37.63.175") OR like(src_ip,"2001:41d0:70d:7800:%") OR (services>=2 AND calls>=10)
| eval first_seen=strftime(first_seen,"%F %T"), last_seen=strftime(last_seen,"%F %T")
| table first_seen last_seen recipientAccountId arn session src_ip service_list apis calls userAgent

Microsoft KQL

let iocIps = dynamic(["57.129.54.120","45.83.220.211","185.209.199.73","89.37.63.175"]);
AWSCloudTrail
| where TimeGenerated > ago(24h)
| where UserIdentityType == "AssumedRole"
| where (EventSource == "secretsmanager.amazonaws.com" and EventName in ("GetSecretValue","ListSecrets","BatchGetSecretValue"))
    or (EventSource == "ssm.amazonaws.com" and EventName in ("GetParameter","GetParameters","GetParametersByPath","DescribeParameters"))
    or (EventSource == "lambda.amazonaws.com" and (EventName startswith "GetFunctionConfiguration" or EventName startswith "ListFunctions"))
| extend SessionName = tostring(split(UserIdentityArn, "/")[-1]), Svc = tostring(split(EventSource, ".")[0])
| summarize Calls = count(), Services = dcount(Svc), DistinctApis = dcount(EventName), ServiceList = make_set(Svc), Apis = make_set(EventName, 20), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by UserIdentityArn, SessionName, SourceIpAddress, UserAgent, RecipientAccountId
| where SessionName startswith "quiam-" or SourceIpAddress in (iocIps) or SourceIpAddress startswith "2001:41d0:70d:7800:" or (Services >= 2 and Calls >= 10)

Sigma

title: Secrets Manager, SSM and Lambda Config Harvesting by Actor Session or IP
id: 3f1c2a7e-5b4d-4e6a-9c1a-7d2e8b9a1c02
status: experimental
description: Detects Secrets Manager, SSM Parameter Store and Lambda configuration reads from assumed-role sessions using the quiam- prefix or actor IPs (TL-2026-5571). Volume thresholds are covered by the SPL and KQL forms.
references:
  - https://www.wiz.io/blog/qubole-cross-account-access-abused-in-the-wild
author: Threadlinqs Team
date: 2026-11-09
tags:
  - attack.credential-access
  - attack.t1555.006
  - attack.t1552
  - attack.discovery
  - attack.t1526
logsource:
  product: aws
  service: cloudtrail
detection:
  selection_secrets:
    eventSource: secretsmanager.amazonaws.com
    eventName:
      - GetSecretValue
      - ListSecrets
      - BatchGetSecretValue
  selection_ssm:
    eventSource: ssm.amazonaws.com
    eventName:
      - GetParameter
      - GetParameters
      - GetParametersByPath
      - DescribeParameters
  selection_lambda:
    eventSource: lambda.amazonaws.com
    eventName|startswith:
      - GetFunctionConfiguration
      - ListFunctions
  selection_actor_session:
    userIdentity.arn|contains: '/quiam-'
  selection_actor_ip:
    sourceIPAddress:
      - '57.129.54.120'
      - '45.83.220.211'
      - '185.209.199.73'
      - '89.37.63.175'
  selection_actor_ip6:
    sourceIPAddress|startswith: '2001:41d0:70d:7800:'
  condition: (selection_secrets or selection_ssm or selection_lambda) and 1 of selection_actor_*
fields:
  - eventTime
  - recipientAccountId
  - userIdentity.arn
  - eventName
  - sourceIPAddress
  - userAgent
falsepositives:
  - Legitimate secret-rotation or backup tooling running under a role session from an unusual IP
  - Security scanners enumerating secrets and parameters
level: high

Known false positives:

• Secret-rotation, backup or configuration-management tooling reading many secrets and parameters under one role session
• Cloud security posture scanners and authorized pentests that enumerate secrets

Tuning notes: Allow-list known automation role ARNs and CI/CD sources, then tune the services>=2 / calls>=10 thresholds to your baseline. Pair with remediation: rotate every secret, SSM parameter and Lambda environment variable the matched role could read. Lambda event names carry version suffixes (for example GetFunctionConfiguration20150331v2), hence the prefix match.

• 🔒 AssumeRole with quiam- Session Name or Actor Boto3/aws-cli Fingerprint (TL-2026-5571) · unlock with TL Creds
• 🔒 Bulk S3 Listing and Object Reads by Assumed-Role Session (TL-2026-5571) · unlock with TL Creds
• 🔒 TruffleHog Credential Validation Against AWS, Entra ID and Okta (TL-2026-5571) · unlock with TL Creds
• 🔒 Any AWS API Activity from Qubole Campaign Infrastructure IPs (TL-2026-5571) · unlock with TL Creds
• 🔒 Cloud Resource and Identity Enumeration from quiam- Role Session (TL-2026-5571) · unlock with TL Creds
• 🔒 [indicator] C2 Polling and Upload to [indicator] TCP/23458 (TL-2026-5571) · unlock with TL Creds
• 🔒 Qubole Account 805246085872 AssumeRole from Actor Infrastructure or quiam- Session (TL-2026-5571) · unlock with TL Creds
• 🔒 Role-Assumption Sweep Across Multiple Roles or Accounts from One Non-AWS Source (TL-2026-5571) · unlock with TL Creds

Indicators of compromise

As of 2026-11-10, Threadlinqs Intelligence tracks 20 indicators of compromise for TL-2026-5571.

Sample indicators (3 of 20)

• IP address: 57.129.54[.]120
• File hash: 086d4a83181971e883c53a4c44f46da2
• IP address: 45.83.220[.]211

Defanged, TLP:CLEAR. Full set of 20 indicators: unlock with TL Creds.

Technical analysis

No CVE is involved.

Wiz reports, with Sentra (which identified the suspicious activity) and Mandiant, that a threat actor abused IAM credentials from AWS account 805246085872, a legitimate Qubole-associated platform account, to call sts:AssumeRole on integration roles that customers had created to trust that account. Every attributed AssumeRole request supplied a valid External ID and succeeded. In most affected environments the roles had been otherwise unused in October and their trust policies were still in place. No vulnerability or CVE is involved; the activity abused vendor-trusted cross-account trust relationships and valid credentials.

Role assumptions began Oct 14, 2026 from a Mullvad VPN address (45.83.220.211) using IAM user principal AIDA3W7DIFLYOLTK63SFS. From Oct 15 most activity moved to an OVH VPS (57.129.54.120), and from Oct 18 the actor also used a second IAM user principal (AIDAJYRRH5Y3A7AAJM2HW), including role-assumption sweeps across multiple victim environments from a second Mullvad address (185.209.199.73). Activity from the OVH VPS ended Oct 26. Sessions used names with the prefix quiam- (for example quiam-enum, quiam-scope-full) and several Boto3 and aws-cli user agents on Linux hosts.

Post-assumption, the actor enumerated storage, compute, databases, identity and KMS keys; read Lambda environment variables via GetFunctionConfiguration, Secrets Manager secrets via ListSecrets/GetSecretValue and SSM Parameter Store values via DescribeParameters/GetParameter; and validated harvested AWS, Entra ID (service principal sign-ins) and Okta (OAuth client-credential token requests) credentials with TruffleHog (Oct 16-19). The actor opportunistically read any reachable S3 bucket (AssumeRole, ListBuckets, ListObjects/HeadObject, GetObject), sometimes downloading entire buckets in a single session.

Wiz also identified a possibly related bootable Linux ISO, sso_agent.iso, which starts a 90-minute timer, collects system information, uploads network interface and disk/partition lists to 57.129.54.120, polls that host on TCP 23458 and executes received input as a shell script, then hard-reboots when the timer expires. It loads the ntfs3 driver, suggesting a Windows target. Wiz has not identified deployments and cannot confirm its use. Separately, Oct 8-11 activity in which an actor tested customer-owned AWS access keys believed created for Qubole integrations (all tested within one hour on Oct 8, with a small number of environments compromised) has not been linked by Wiz to the role-assumption activity. Wiz sees no ties to other publicly reported activity and describes targeting as opportunistic, with unknown motivation.

MITRE ATT&CK techniques by tactic:

Execution

T1059.004 Unix Shell

Initial Access

T1078 Valid Accounts; T1199 Trusted Relationship

Defense Evasion

T1078.004 Cloud Accounts

Discovery

T1082 System Information Discovery; T1087.004 Cloud Account; T1526 Cloud Service Discovery; T1580 Cloud Infrastructure Discovery; T1619 Cloud Storage Object Discovery

Command and Control

T1090 Proxy; T1571 Non-Standard Port

Impact

T1529 System Shutdown/Reboot

Collection

T1530 Data from Cloud Storage

Credential Access

T1552 Unsecured Credentials; T1555.006 Cloud Secrets Management Stores

Resource Development

T1583.003 Virtual Private Server; T1588.002 Obtain Capabilities

Remediation

Immediate actions

• Rotate every secret, SSM parameter and Lambda environment variable the affected integration role could read
• Revoke active sessions for the affected roles; rotating credentials does not end already-issued sessions
• Hunt CloudTrail from Oct 1, 2026 for AssumeRole from account 805246085872 with non-AWS source IPs, principal IDs AIDA3W7DIFLYOLTK63SFS and AIDAJYRRH5Y3A7AAJM2HW, and any activity from the IOC IPs
• Review all activity in each discovered role session, especially Secrets Manager, SSM Parameter Store, Lambda and S3
• Check identity provider (Entra ID, Okta) sign-in logs for TruffleHog user agents and IOC IPs

Workarounds

• Delete unused integration roles or remove the vendor account from their trust policies
• Replace the account :root trust principal with the specific vendor IAM principal
• Add aws:SourceIp or aws:SourceVpce conditions limiting assumption to documented vendor networks (Wiz states a source IP condition alone would have blocked every observed assumption)
• Treat External IDs as non-secret, rotate them with the vendor and use distinct values per role

Longer-term hardening

• Inventory all IAM roles whose trust policies allow external accounts
• Use an organization trail covering all accounts and regions and enable S3 data events or server access logs for sensitive buckets
• Alert on vendor role assumptions from VPNs or hosting providers the vendor has never used
• Limit integration roles' access to Lambda configuration, Secrets Manager, SSM parameters and broad S3 read
• SaaS providers: use short-lived workload role credentials rather than long-lived IAM user keys, publish egress ranges, and monitor own CloudTrail for customer-account AssumeRole from unexpected networks

Affected and fixed versions

• Qubole — Qubole-associated AWS account 805246085872 (cross-account integration trust)
  Vulnerable versions: Customer IAM roles trusting account 805246085872
• Amazon Web Services — Customer AWS environments (IAM, Lambda, Secrets Manager, SSM Parameter Store, S3)
  Vulnerable versions: Environments with Qubole integration roles whose trust policies remain in place

Timeline

Last updated 2026-11-10 · 2 updates · revalidated 2× · latest source

• 2026-10-08 Separate activity: an actor tested customer-owned AWS access keys believed created for Qubole integrations, all within one hour; a small number of environments were compromised. Wiz has not linked this to the role-assumption activity (activity spanned Oct 8-11).
• 2026-10-14 Mullvad VPN IP locked-ioc-8 began calling sts:AssumeRole on customer integration roles using IAM user principal AIDA3W7DIFLYOLTK63SFS.
• 2026-10-15 Most activity shifted to OVH VPS locked-ioc-7 for role assumption, enumeration and credential harvesting.
• 2026-10-16 TruffleHog credential validation against harvested AWS, Entra ID and Okta credentials began (observed Oct 16-19); OVH IPv6 locked-ioc-4 used for credential enumeration and verification (Oct 16-24).
• 2026-10-18 Actor began using second IAM user principal AIDAJYRRH5Y3A7AAJM2HW; Mullvad IP locked-ioc-6 assumed roles across multiple victim environments in quick succession (through Oct 21).
• 2026-10-21 aws-cli/2.37.12 user agent first seen in the role-assumption activity (observed Oct 21-26).
• 2026-10-25 locked-ioc-10 (Datacamp Limited, registered to Mullvad VPN AB) assumed roles.
• 2026-10-26 Last observed activity from OVH VPS locked-ioc-7, ending the Oct 14-26 role-assumption window.
• 2026-11-09 Sentra published 'Inside the Qubole Supply Chain Attack': each trusted role assumed in about one second after testing stolen credentials on one low-value role first; EC2 user data scraped; a final pass from a different VPN address pulled production database backups; no write actions observed; millions of files and thousands of credential records taken from one company, with 'more than a dozen' to 'dozens' of organizations affected (figures not reconciled).
• 2026-11-09 Wiz published 'Trusted by Default: Qubole Cross-Account Access Abused in the Wild' with Sentra and Mandiant, including IOCs and hunting guidance.
• 2026-11-10 SecurityWeek reports over a dozen organizations were hit in the Qubole supply chain attack, citing Wiz and Sentra analyses.

Update history

• 2026-11-10 — Qubole Cross-Account IAM Role Abuse: Attacker Assumes Trusted Roles to Access Customer AWS Accounts and Download S3 Buckets: What changed No change to severity (HIGH), exploitability (ACTIVE) or status. New indicators (1) Indicator values are withheld at this access level.
• 2026-11-10 — Qubole Supply Chain Attack: Compromised IAM Credentials Abuse Cross-Account AWS Roles, Over a Dozen Organizations Hit: What changed No field escalation: severity HIGH, exploitability ACTIVE, status ACTIVE and LOW attribution confidence are unchanged.

Sources cited

• Sentra (identified the suspicious activity) sentra.io · Vendor report
• Mandiant (investigation collaborator) Google Cloud · Vendor report
• Wiz: Black Hat 2021 - How isolated is your AWS cloud environment? (cross-account background) Wiz · Research
• Praetorian: AWS IAM Assume Role Vulnerabilities (External ID background) praetorian.com · Research
• Wiz: Experiencing an incident Wiz · Vendor report
• Trusted by Default: Qubole Cross-Account Access Abused in the Wild (Wiz) Wiz · Blog · 2026-11-09

More in cloud

• AntiFox agentic AI pentest platform (ARTEX fork) abused in IIS webshell to AWS credential-theft intrusions
• CVE-2026-109469 - Microsoft Entra Device Registration Elevation of Privilege (CVSS 10.0)
• LLMjacking Bills Reach $1M (Mandiant/GTIG; LiteLLM CVE-2026-40217), Trezor Safe 5 Reseller Implant, SAP Flaws Weaponized Within Days
• Key Eater: Stolen Microsoft Entra ID Application Credentials Used to Breach 27 Organizations
• The Rise of LLMJacking: Threat Actors Monetize Compromised Cloud and Model Resources (UNC6993, D1337-KAIROS, CVE-2026-40217)