AutomationService

Create a deployment with an attacker-controlled revision; hook scripts run as root on every EC2/on-prem instance in the deployment group, yielding fleet-wide command execution.

CodeDeploy lifecycle hook scripts (running as root on EC2/on-prem targets) can read the instance profile role credentials from IMDS, exposing them to the attacker's code.

A CodePipeline Deploy stage action invokes the CodeDeploy deployment group; emit CanTrigger from the pipeline's execution identity so cicd-chains propagates pipeline-level trigger capability.

Trigger a deployment to execute orchestration-plane actions as the deployment group's service role - requires a run path.

ssm:StartChangeRequestExecution triggers an Automation runbook with Change Manager approval gating.

A shared SSM Automation document gives the sharing-account identity code control over any BuildWorker in the target account that executes it.

ssm:StartAutomationExecution triggers an existing Automation BuildWorker runner that executes as its AutomationAssumeRole.

ssm:UpdateDocument rewrites a customer-owned Automation document's steps - the executed definition of the BuildWorker runner.

Attach a privileged managed identity to a new or existing Automation Account and trigger a runbook - equivalent to creating a new workload bound to that identity.

An Automation Account sandbox job executes as the bound managed identity; any code running in the sandbox can mint MI tokens from IMDS.

An Automation Account sandbox job exposes its bound MI's token to any code it runs via the IMDS endpoint.

An Automation Account with a legacy RunAs account exposes the RunAs service principal certificate to any runbook via Get-AutomationConnection.

Code executing in an Automation Account sandbox can retrieve a bearer token for the bound MI from IMDS.

An enabled Automation Account webhook with a public URI is internet-triggerable; any holder of the URI can start a runbook job.