AWS API calls indicating SSM privilege escalation
Description
AlphaSOC detected an IAM policy change that grants a principal permissions
enabling privilege escalation through AWS Systems Manager (SSM). This detection
identifies policies that allow either ssm:CreateAssociation or
ssm:UpdateAssociation permissions, which threat actors can exploit to execute
commands with elevated privileges on managed EC2 instances.
AWS Systems Manager State Manager associations are legitimate automation tools designed to apply configurations and run commands across fleets of managed instances. Organizations use them for patch management, configuration drift remediation, and scheduled maintenance tasks. However, these same capabilities become dangerous when granted to unauthorized principals or over-provisioned accounts.
Threat actors with ssm:CreateAssociation or ssm:UpdateAssociation
permissions can create or modify associations to run arbitrary commands on any
managed EC2 instances they can target. The commands execute with the permissions
of the instance's IAM role—often more privileged than the attacker's current
access. This allows them to access instance metadata, retrieve credentials from
the instance profile, read sensitive data, or use the instance as a pivot point
for lateral movement. Because SSM associations are designed for automation, this
activity blends seamlessly with legitimate operational patterns.
This detection triggers on IAM policy creation or modification events
(CreatePolicy, CreatePolicyVersion, PutUserPolicy, PutGroupPolicy,
PutRolePolicy, AttachUserPolicy, AttachRolePolicy, AttachGroupPolicy)
that introduce these SSM association permissions.
Impact
If exploited, the attacker gains the ability to execute arbitrary commands on EC2 instances with the full privileges of their attached IAM roles. This can lead to credential theft from instance metadata, access to sensitive application data, installation of persistence mechanisms, or further lateral movement across the AWS environment—all while appearing as normal Systems Manager automation activity.
Severity
| Severity | Condition |
|---|---|
Low | AWS API calls indicating SSM privilege escalation |
Investigation and Remediation
Check CloudTrail for the specific PutUserPolicy, PutGroupPolicy,
PutRolePolicy, or Attach*Policy event that added SSM association
permissions. Identify the target principal (user, role, or group) and the source
of the change. Review the requestParameters field to examine the exact
permissions granted. Verify whether these SSM permissions are required for the
principal's legitimate role. In most environments, only dedicated automation
roles or system administrators should have association creation or modification
capabilities.
If the permissions were unauthorized, immediately detach or delete the policy.
Review CloudTrail for any CreateAssociation, UpdateAssociation, or
SendCommand actions performed by the affected principal after the policy
change to identify exploitation attempts. Check Systems Manager for any new or
modified associations created by the principal. Examine association targets,
command documents, and execution history. Terminate any suspicious associations
and review affected instances for signs of compromise.
Rotate credentials for the affected principal and any instance roles that may have been targeted. Review instance metadata access patterns and check for unusual credential retrieval attempts.
Known False Positives
- Authorized administrators provisioning SSM permissions for automation frameworks
- Infrastructure-as-code deployments creating service roles for legitimate Systems Manager automation
- DevOps teams setting up patch management or configuration management workflows