Mar 12 2026 AWS Cross-Service Attacks

When conducting AWS Configuration Reviews, something I see time and time again is IAM and resource based policies that are vulnerable to cross-service attacks - or what AWS calls cross-service confused deputy attacks.

Consider the following IAM role trust policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

This would typically be attached to a Lambda execution role, and allows Lambda functions to assume the role and obtain any permissions it holds in order to perform actions within the account. This policy will achieve the desired result and allow the lambda function to assume the role and say access blobs in S3 for example, but it also allows any lambda function in any AWS account to do the same.

Additionally, any internal user that has access to Lambda can also use this role to gain access to S3 by effectively deputising the AWS Lambda service to perform actions on their behalf.

The diagram below from the AWS blog outlines another example using Cloud Trail. Where an attacker can deputise the Cloud Trail service to write files to an unauthorized S3 bucket.

Other common examples include:

• S3 bucket policy that grants the lambda.amazonaws.com service principal s3:GetObject. An attacker in an external account can deputise Lambda to read sensitive objects.
• SNS resource policy that allows the Lambda service principal to subscribe to topics. An attacker can deputise Lambda to receive notifications.
• SQS resource‑based policy that grants the SNS service principal access to a queue. An attacker can deputise SNS to publish messages to the queue.
• IAM role trust policy that trusts the cloudformation.amazonaws.com service principal. An attacker can deputise CloudFormation from another account to create or modify resources in the victim account.
• Step Functions that are allowed to invoke a Lambda function via its execution role. An attacker can deputise the Step Functions service to run arbitrary compute.
• EC2 instance profile that trusts the ec2.amazonaws.com service principal. An attacker can deputise EC2 (via a compromised instance) to assume the role and inherit its permissions.
• SSM permissions that let the service run commands on EC2 instances. An attacker can deputise SSM to execute commands on the victim’s instances from an unauthorized account.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "Service": "lambda.amazonaws.com"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "ArnEquals": {
        "aws:SourceArn": "arn:aws:lambda:us-east-2:111122223333:function:my-function”
      }
    }
  }
}

About the author

Shaun is a Penetration Tester and Bitcoiner, with over a decade in the Security Industry, specialising in Cloud and Infrastructure Security and regularly completing assessments for all manner of companies from global corporations to small charities and non profits.