ApplicationPlatform

Retarget InstanceRoleArn to a more-privileged role via UpdateService + PassRole.

Modify code/image of a service that already has an instance role -> run as that role.

Beanstalk EC2 instances leak the instance profile creds via IMDS (169.254.169.254).

Code on a Beanstalk instance (or SSRF against the app) reads the instance profile creds from IMDS.

Principal with codepipeline:CreatePipeline can deploy new pipelines to the CodePipeline platform.

opsworks:UpdateStack lets a principal change the custom cookbook source URL, enabling cookbook supply-chain injection.

OpsWorks App secure environment variables are credentials accessible to all deployment code on the stack.

opsworks:CreateDeployment lets a principal run arbitrary Chef recipes or commands on stack instances as the instance profile role.

opsworks:CreateDeployment (non-execute_recipes flavors) triggers a deployment with the stack's current cookbook definition - CanTrigger into the instance for cicd-chains rule 2.

OpsWorks Stack's control plane operates as the stack's service role.

opsworks:SetPermission lets a principal grant any OpsWorks user admin or deploy rights on a stack, enabling self-escalation to deployment capability.

opsworks:UpdateStack can redirect the custom cookbook source to an attacker-controlled repo, making all future cookbook deployments run attacker code as the instance profile role.

s3:PutObject on a bucket that is a verified code-artifact deployment source (Lambda, CodePipeline, CloudFormation) for a compute workload equals modifying that workload's code.

An MLflow Tracking Server executes as its RoleArn.

SageMaker compute surfaces (notebook/training/processing job/pipeline/Studio app) expose execution-role credentials to all code running inside them via IMDS or the container credentials endpoint.

A compute resource is internet-exposed when its security group has an inbound rule allowing 0.0.0.0/0 (or ::/0) on a port, the resource has a public IP, and the subnet has a route to an Internet Gateway. All three conditions must be observed facts.

Attach a privileged user-assigned MI to a site the attacker can already run code on, then execute as that MI. This is an existing-site chain (CanExecuteAs), NOT a create-new-workload chain.

Config modification (startup command / app settings) on a site + the site runs as an MI => execute as that MI.

Code/config modification on a site + the site runs as an MI => execute as that MI (via the MSI token endpoint).

Code modification on a Function app + the app runs as an MI => execute as that MI (via the identity endpoint).

Config modification (run-from-package / image / startup) + ExecutesAs => execute as the MI.

A Standard Logic App with a bound MI exposes that MI's credential to any code/action running in the app.

Code/actions in a Standard Logic App can mint a bearer token for each bound MI via the App Service identity endpoint.

An MI-enabled SF application leaks a usable credential for its managed identity via the per-node localhost token service environment.

Code in a managed-identity-enabled SF service can mint a bearer token for the app's MI from the per-node localhost token service.

Deploy/upgrade an SF app with attacker code + the app runs as an MI => execute as that MI via the localhost token service.

A Static Web App exposes its deployment token as a credential for the CI/CD pipeline identity.

Repoint SWA's source repository to an attacker-controlled repo, modifying build code.

A holder of the SWA deployment token can modify the build runner's deployment when a runner with a service identity exists.

A serving App Engine version is reachable at its appspot.com URL (modeled as a PublicEndpoint node) unless ingress-restricted.

A Cloud Scheduler App Engine HTTP job triggers an App Engine service on schedule. App Engine targets are always same-project. OIDC/OAuth2 auth model applies identically to HTTP targets.