Between October 14 and October 26, an attacker exploited IAM credentials from Qubole's AWS account to assume cross-account roles in customer environments. Each malicious request used the correct External ID and succeeded. Many of the targeted roles hadn't seen legitimate Qubole activity in October, yet their permissions remained active.
This highlights a key issue: while the External ID functioned as intended, the trust relationship was the weak link.
The Decision You Are Facing
For every third-party cross-account role in your AWS setup, you need to decide its fate: leave it, narrow it, or remove it. Many teams default to "leave it alone" because nothing seems broken. However, this is an unmanaged risk, and an auditor will eventually question who approved it.
This guide helps you make a decision for each role. Apply it per vendor, per account.
Key Factors Affecting Your Choice
Consider these questions before deciding.
Is the vendor still in active use? Check contract records and CloudTrail. A role with no AssumeRole events recently is a candidate for removal.
How is trust scoped? A trust policy that names an entire external AWS account allows any principal in that account to assume the role if it has valid credentials. A policy naming a specific vendor IAM principal is much narrower.
What can the role access? Review attached policies. In this incident, the attacker accessed S3 data, read AWS Secrets Manager and Systems Manager Parameter Store, and inspected Lambda configurations. Secrets accessed through one role became keys to other systems, including Microsoft Entra ID and Okta OAuth credentials.
Can you restrict where the vendor connects from? AWS source IP and VPC endpoint conditions can limit role assumption to documented vendor network ranges. Some malicious requests came from Mullvad VPN and OVH-hosted infrastructure, not vendor-owned ranges.
Who owns the relationship? A role without a named business owner won't get reviewed.
Path A: Revoke the Integration
Choose this when: the vendor is no longer used, the contract has ended, or CloudTrail shows no legitimate activity for the role.
This is the clearest case, and the incident highlighted its importance. Organizations that had stopped using the platform were still vulnerable because the integrations remained trusted. Deleting the role removes the attack path entirely.
Framework drivers for this path:
- ISO/IEC 27001:2022 Annex A 5.19 to 5.22 covers supplier relationships, including monitoring and managing changes to supplier services. Offboarding is part of the supplier lifecycle, and access removal is essential.
- Annex A 5.18 requires access rights to be reviewed and removed or adjusted on change or termination.
- SOC 2 CC6.2 addresses removing access when it's no longer authorized, and CC9.2 covers vendor risk management.
Before deleting, search CloudTrail for recent activity to ensure removal won't disrupt live operations. After deletion, retain the ticket, the CloudTrail query, and the approver as evidence for both frameworks.
If you find suspicious AssumeRole activity before revoking, preserve logs first. Review CloudTrail records across all accounts with integration roles, looking for AssumeRole calls from the vendor's account that originate from non-AWS infrastructure, then follow up on Secrets Manager, Parameter Store, Lambda, and S3 access.
Path B: Keep the Integration, but Narrow It
Choose this when: the vendor is in active use and the business needs the integration.
Narrowing involves three actions, and you should implement all:
- Tighten the trust policy. Replace account-level trust with specific vendor IAM principals.
- Add network conditions. Restrict role assumption to documented vendor network ranges using source IP or VPC endpoint conditions.
- Cut the permission set. Remove access to Secrets Manager and Parameter Store unless necessary. Scope S3 access to specific buckets rather than wildcards.
An External ID is a confused-deputy control, not an authentication control. It prevents one customer's configuration from being used to access another's. It doesn't protect you if the vendor's credentials are stolen. Treat it as one layer, not the only layer.
Framework anchors for this path:
- Annex A 8.2 and 8.3 (privileged access rights and information access restriction) support least privilege on the role itself.
- Annex A 5.15 requires access control rules based on business and security requirements.
- SOC 2 CC6.1 and CC6.3 cover logical access restrictions and role-based access consistent with least privilege.
- ISO/IEC 27036 offers supplier relationship guidance for technical and contractual requirements.
Document the narrowing as a Risk Treatment Plan item with an owner and a date. If you can't apply a particular restriction because the vendor doesn't publish stable IP ranges, record that as an accepted risk with management sign-off, not a silent gap.
Path C: Keep It and Monitor It Harder
Choose this when: you can't narrow the role now due to vendor constraints or a migration in progress, but you must keep the integration.
This is a temporary position, not a final solution. Compensating detection should focus on the behavior seen in this campaign:
- AssumeRole events from the vendor's account originating from IPs outside the vendor's documented ranges.
- Bursts of Secrets Manager or Parameter Store reads from a vendor role.
- Bulk S3 downloads, including entire buckets in single sessions.
- Resource enumeration across S3, databases, EC2, security groups, and IAM in one session.
Annex A 8.15 (logging) and 8.16 (monitoring activities) support this directly. For SOC 2, CC7.2 covers monitoring for anomalies. Set a review date for moving the role to Path B, and track it. A "temporary" exception with no expiry is just Path A's problem delayed.
Summary Matrix
| Question | Path A: Revoke | Path B: Narrow | Path C: Monitor |
|---|---|---|---|
| Vendor in active use? | No | Yes | Yes |
| Trust policy can be scoped to vendor principals? | Not needed | Yes | Not yet |
| Network restrictions feasible? | Not needed | Yes | Not yet |
| Primary drivers | A.5.18, A.5.19 to 5.22, CC6.2, CC9.2 | A.5.15, A.8.2, A.8.3, CC6.1, CC6.3 | A.8.15, A.8.16, CC7.2 |
| Evidence to retain | Deletion ticket, CloudTrail query, approver | Updated trust policy, condition keys, permission diff | Alert rules, review records, exception expiry |
| Residual risk | Lowest | Moderate | Highest; time-box it |
What to Do This Week
Export every IAM role in every account whose trust policy references an external AWS account. Match each to a vendor and a business owner. Pull last-used data. Anything with no owner or no recent use goes to Path A. Everything else gets a Path B ticket or a dated Path C exception.
Then integrate the review into your recurring cycle. Supplier access reviews belong in your Performance Evaluation under Clause 9.1 of ISO/IEC 27001, and in your SOC 2 vendor management evidence. The goal is that a vendor's compromised credentials land against roles you've already trimmed, not roles nobody remembered.
