Ssm — CraftedSignal Threat Feed

AWS SSM Session Manager Child Process Execution Abuse

hello@craftedsignal.io — Fri, 01 May 2026 20:57:28 +0000

AWS Systems Manager (SSM) Session Manager provides interactive shell access to EC2 instances and hybrid nodes without the need for bastion hosts or open inbound ports. Attackers can abuse this functionality by leveraging compromised AWS credentials or IAM roles with ssm:StartSession permissions to gain unauthorized access to target systems. This allows for remote execution of commands and lateral movement within the AWS environment. The technique involves spawning child processes from the SSM session worker process to perform malicious activities. Defenders should monitor for unusual process execution patterns originating from SSM sessions to identify potential abuse.

Attack Chain

Attacker gains access to valid AWS credentials or IAM role with ssm:StartSession permissions.
Attacker initiates an SSM session to a target EC2 instance or hybrid node using the compromised credentials.
The ssm-session-worker process is started on the target instance to manage the interactive session.
Attacker executes commands within the session, spawning child processes from the ssm-session-worker process.
Attacker may use scripting languages such as PowerShell or Bash to execute malicious code (e.g., using awsrunPowerShellScript or awsrunShellScript).
These scripts perform reconnaissance, download additional tools, or attempt credential access.
Attacker moves laterally to other instances or resources within the AWS environment.
The ultimate objective is often data exfiltration, privilege escalation, or maintaining persistent access.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, compromise of critical systems, and lateral movement within the AWS environment. The impact can range from data breaches to complete control of the compromised infrastructure. The number of affected systems depends on the scope of the compromised credentials and the attacker’s ability to move laterally. Organizations using AWS SSM are at risk.

Recommendation

Deploy the Sigma rules in this brief to your SIEM and tune for your environment to detect suspicious child processes spawned by ssm-session-worker.
Correlate process activity with AWS CloudTrail logs for StartSession and related API calls to identify the IAM principal initiating the session (see the overview section for API names).
Implement strict IAM policies and regularly review AWS credentials to minimize the risk of credential compromise.
Monitor process.command_line, process.executable, process.user.name for unusual activity within SSM sessions.

AWS SSM Command Document Created by Rare User

hello@craftedsignal.io — Fri, 10 Apr 2026 16:27:52 +0000

This rule identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. The rule focuses on detecting anomalous creation of SSM command documents. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, and data exfiltration. The rule utilizes AWS CloudTrail logs to monitor the CreateDocument API call within the SSM service. This activity is flagged when the user or role creating the document deviates from established patterns, indicating a potential security risk. This detection is relevant for organizations using AWS SSM for managing their infrastructure and aims to prevent unauthorized command execution on managed instances.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or an exposed IAM role.
The attacker attempts to create a new SSM Command document using the CreateDocument API call.
The CreateDocument API call is logged by AWS CloudTrail with details about the user identity, request parameters, and document description.
The detection rule analyzes CloudTrail logs, specifically looking for the CreateDocument event with a document type of Command.
The rule identifies the user or role associated with the CreateDocument API call by inspecting the aws.cloudtrail.user_identity.arn field.
If the user or role is considered rare or unusual for creating SSM Command documents within the organization, the rule triggers an alert.
The attacker could then use the created document to execute arbitrary commands on managed instances.
Successful execution of these commands leads to various impacts, including unauthorized access, command and control, data exfiltration, or disruption of services.

Impact

The successful exploitation of this technique can lead to unauthorized access to AWS resources, potentially affecting all systems managed by AWS SSM in the targeted environment. The creation of malicious SSM command documents can lead to data exfiltration, system compromise, or denial of service. If successful, this can impact hundreds or thousands of systems depending on the scope of AWS SSM usage in the organization.

Recommendation

Deploy the Sigma rule “AWS SSM Command Document Created by Rare User” to your SIEM, ensuring proper indexing of CloudTrail logs (index = [“filebeat-*”, “logs-aws.cloudtrail-*”]).
Review the aws.cloudtrail.request_parameters.content field in the CloudTrail logs for any suspicious commands within the created SSM document.
Restrict SSM document creation permissions to specific, trusted roles or users to prevent unauthorized document creation as mentioned in the overview.
Monitor the SendCommand API call related to the created SSM document to see if it is used to execute commands on managed instances, as described in the triage section.

AWS EC2 LOLBin Execution via SSM SendCommand

hello@craftedsignal.io — Fri, 10 Apr 2026 16:27:52 +0000

This threat brief focuses on detecting the execution of Living Off the Land Binaries (LOLBins) or GTFOBins on Amazon EC2 instances via AWS Systems Manager (SSM) SendCommand API. The technique involves correlating AWS CloudTrail SendCommand events with endpoint process execution by matching SSM command IDs. While AWS redacts command parameters in CloudTrail logs, this correlation technique reveals the actual commands executed on EC2 instances. This is critical because adversaries may abuse SSM to execute malicious commands remotely without requiring SSH or RDP access. They can leverage legitimate system utilities for various malicious purposes, including data exfiltration, establishing reverse shells, or facilitating lateral movement within the cloud environment. The rule was last updated on 2026-04-10.

Attack Chain

An attacker gains initial access to AWS via compromised credentials or an exposed IAM role.
The attacker uses the AWS CLI or API to initiate an SSM SendCommand to a target EC2 instance. The DocumentName parameter is set to AWS-RunShellScript.
The SSM agent on the EC2 instance receives the SendCommand request.
The SSM agent executes a shell script (_script.sh) within a dedicated directory for orchestration.
The shell script executes a LOLBin, such as curl, wget, python, or perl, to perform malicious actions. The parent process of the LOLBin will be the SSM shell script.
The LOLBin is used to download a malicious payload, establish a reverse shell, or exfiltrate data.
The attacker uses the established reverse shell to perform further actions on the EC2 instance.

Impact

Successful exploitation can lead to unauthorized access to EC2 instances, data exfiltration, deployment of malware, and lateral movement within the AWS environment. Although a number of impacted organizations is not available, this attack is able to bypass traditional network security controls. Organizations in any sector utilizing AWS EC2 instances and SSM are potentially at risk. The lack of required SSH or RDP access makes this technique particularly stealthy.

Recommendation

Enable AWS CloudTrail logging to capture SendCommand events and monitor for AWS-RunShellScript in the request_parameters.
Deploy the Sigma rule “Detect AWS EC2 LOLBin Execution via SSM SendCommand” to your SIEM and tune for your environment.
Monitor endpoint process execution logs for the execution of LOLBins like curl, wget, python, perl, nc, etc., with parent processes related to SSM.
Implement strict IAM policies to restrict SSM SendCommand permissions to only authorized users and roles.
Review and audit existing SSM configurations to identify and remediate any overly permissive settings.