The Missing ExternalId: Exploiting AWS Trust Policies

You click a vendor's CloudFormation link to integrate their shiny new posture management tool. The template creates a cross-account IAM role, granting the vendor's AWS account read access to your environment. It feels routine, standard operating procedure for modern cloud architecture. But if that template omits a specific, cryptographically random condition string, you did not just grant access to the vendor. You granted access to every single customer using that vendor.

This is the aws iam confused deputy vulnerability in its purest form. It is a class of privilege escalation that abuses the very mechanism AWS designed for secure, keyless third-party delegation. When you trust a third party to act on your behalf, you make them your deputy. If they cannot distinguish between legitimate instructions from you and malicious instructions from a hostile tenant on their platform, they become confused. The consequences are catastrophic, leading to silent, cross-tenant lateral movement that bypasses your perimeter entirely.

The SaaS Integration Blind Spot

Trusting the Wrong Principal

When a SaaS provider needs to scan your S3 buckets or manage your EC2 instances, they ask you to create an IAM role. The trust policy attached to this role specifies the vendor's AWS account ID as the Principal. This explicitly tells the AWS Security Token Service that the vendor is allowed to execute sts:AssumeRole against your account.

The breakdown happens at the application tier of the SaaS provider. The provider holds the credentials for their own AWS account. When a user logs into the SaaS dashboard and clicks a button to initiate a scan, the SaaS backend uses its own credentials to assume the role in the target AWS account. AWS authenticates the request, verifies the trust policy, and hands temporary session tokens back to the SaaS application. The SaaS application then uses those tokens to issue data plane API calls against the target account.

The Cross-Tenant Pivot

If the SaaS application only asks for your Role ARN and blindly attempts to assume it, an attacker can simply sign up for a free trial on the same SaaS platform. They navigate to the integration page, but instead of providing a Role ARN from their own AWS account, they input your Role ARN.

The SaaS application receives the request, authenticates as its own AWS account, and fires the AssumeRole API call to your account. Because the SaaS application's AWS account is listed as the trusted Principal in your role's trust policy, AWS grants the session tokens. The attacker just used the vendor's legitimate infrastructure to pivot into your environment. You trusted the deputy, but the deputy took orders from the adversary.

Post-Incident Context and Blast Radius

While theoretical examples are neat, the operational reality of this attack vector has driven massive industry shifts. In 2019, security vendor Imperva disclosed a breach affecting their Cloud WAF product, formerly Incapsula. While the root cause involved a compromised AWS API key on an internal compute instance, the incident threw a massive spotlight on how cloud-native supply chains handle cross-account trust.

The attacker stole an internal AWS API key that had been left exposed. Because of how the infrastructure was architected, that single key had the authority to access a database snapshot containing customer API keys and SSL certificates. It was a brutal reminder of blast radius. When you compromise a vendor, you compromise their downstream access to every client.

In a true confused deputy scenario, the attacker does not even need to compromise the vendor's AWS keys. They simply abuse the vendor's intended functionality. The vendor becomes an unwitting proxy. The attacker forces the SaaS platform to request data from an external AWS account, and the platform complies because it possesses the necessary IAM permissions to do so. The access looks entirely legitimate from the victim's perspective because the source IP belongs to the trusted vendor.

Red Team Reconnaissance

Scraping Target Identifiers

To execute a cross-tenant assume role attack, the adversary needs two pieces of information. They need the target AWS Account ID, and they need the name of the IAM role created for the integration. Finding these details is less difficult than most defenders assume.

Account IDs are not considered sensitive secrets by AWS. They routinely leak in public GitHub repositories, public EBS snapshots, and even in the URL structures of public S3 buckets. Reconnaissance tools actively scrape these sources to build massive directories of corporate AWS Account IDs, mapping them back to target organizations.

Guessing the Integration Role

Role names are even easier to acquire. When a SaaS vendor provides an integration guide or a CloudFormation template, they usually hardcode a default role name. Names like VendorName-Security-Audit-Role or DatadogIntegrationRole are ubiquitous across enterprise cloud environments.

An attacker simply concatenates the scraped AWS Account ID with the vendor's default role name to construct the full Amazon Resource Name. They paste this ARN into their own instance of the SaaS application and wait to see if the integration succeeds. If it does, they have established persistent, credential-free access to the victim's cloud control plane.

Tracing Unauthorized Activity in CloudTrail

When a confused deputy attack occurs, the victim's CloudTrail logs will show a successful AssumeRole event. To the untrained eye, this event looks identical to routine operational traffic. The source IP address resolves to the vendor's infrastructure, and the userAgent matches the vendor's expected API client.

To spot the anomaly, SOC analysts must parse the requestParameters and userIdentity blocks of the CloudTrail event. The logs will explicitly state which role was targeted and the session name the vendor attempted to apply.

"eventName": "AssumeRole", "requestParameters": { "roleArn": "arn:aws:iam::111122223333:role/VendorIntegrationRole", "roleSessionName": "vendor-session" } — CloudTrail Event Log Excerpt

The critical failure in visibility is that the victim account has no concept of the SaaS tenant ID that initiated the request. The CloudTrail log shows the vendor's AWS account ID assuming the role, but it does not tell you if it was your user or the attacker's user inside the vendor's application.

This is why relying solely on behavioral anomaly detection for cross-account roles is a losing game. The attacker is using the exact same role, from the exact same source IP, at potentially the exact same time of day as the legitimate vendor service. You cannot detect your way out of a fundamentally flawed identity architecture. You have to fix the trust policy.

Enforcing the Architecture Fix

The defense against this attack relies entirely on a single IAM condition block. AWS introduced the ExternalId condition key specifically to solve the cross-tenant confused deputy problem. It forces the external principal to prove they are acting on behalf of a specific, authorized tenant.

When you configure the integration, the SaaS provider must generate a unique, cryptographically secure string tied exclusively to your tenant workspace. You take this unique string and embed it into the Condition block of your IAM role's trust policy.

"Condition": { "StringEquals": { "sts:ExternalId": "a1b2c3d4-unique-tenant-id-5678" } } — IAM Trust Policy Condition Block

When the SaaS application attempts to assume your role, it must include this ExternalId in its sts:AssumeRole API request. If an attacker inputs your Role ARN into their own tenant workspace, the SaaS application will attach the attacker's ExternalId to the STS request. AWS STS will evaluate the trust policy, see that the provided ExternalId does not match the one hardcoded in your policy, and outright deny the request with an AccessDenied exception.

The external identifier acts as a secret passphrase that only your specific tenant workspace knows. It bridges the gap between the AWS identity plane and the SaaS provider's application identity plane. If a vendor asks you to create a cross-account role and their documentation does not explicitly require configuring an ExternalId, push back immediately.

The Operational Reality of Delegated Trust

Securing cloud infrastructure requires abandoning the assumption that authenticated entities are inherently trustworthy. A vendor's AWS account might be authenticated, but without strict condition bounds, its authority is dangerously malleable. Every integration is a bridge into your network, and you are responsible for checking the toll.

Review your IAM trust policies today. Look for any principal that belongs to a third party and verify that a stringent StringEquals condition enforces a unique external identifier. When investigating suspicious cross-account activity in MailSleuth.AI, pivoting from CloudTrail AssumeRole events to the associated trust policy configurations is the fastest way to determine if a delegated access path has been weaponized. Fix the conditions, cut the lateral movement paths, and force adversaries to find a harder way in.

The takeaway

Securing cloud infrastructure requires abandoning the assumption that authenticated entities are inherently trustworthy. A vendor's AWS account might be authenticated, but without strict condition bounds, its authority is dangerously malleable. Every integration is a bridge into your network, and you are responsible for checking the toll.

Review your IAM trust policies today. Look for any principal that belongs to a third party and verify that a stringent StringEquals condition enforces a unique external identifier. When investigating suspicious cross-account activity in MailSleuth.AI, pivoting from CloudTrail AssumeRole events to the associated trust policy configurations is the fastest way to determine if a delegated access path has been weaponized. Fix the conditions, cut the lateral movement paths, and force adversaries to find a harder way in.