Weaponizing SSM: Practical Exploits and Hardening Techniques for AWS

Weaponizing SSM: Practical Exploits and Hardening Techniques for AWS

Speakers: Rodrigo Montoro, Director of Research, Clouds

Conference: Cloud Village

YouTube: https://www.youtube.com/watch?v=rnizpZbKyKo

Overview

In his compelling talk at Cloud Village, Rodrigo Montoro, Director of Research at Clouds, delved into the often-underestimated security implications of AWS Systems Manager (SSM). Titled "Weaponizing SSM: Practical Exploits and Hardening Techniques for AWS," Montoro's presentation illuminated the vast potential for abuse within SSM's extensive feature set, a system primarily designed for centralized node management at scale. He candidly expressed his ambivalent relationship with SSM, acknowledging its powerful utility while highlighting the inherent risks posed by over-permissive configurations. The core message revolved around the critical need for robust privilege control and vigilant monitoring to prevent SSM from becoming a significant attack vector within AWS environments.

Montoro, a self-proclaimed blue teamer, approached the topic with a focus on detection and mitigation, meticulously demonstrating how various SSM features can be co-opted for malicious purposes, ranging from remote code execution to persistent backdoor establishment and lateral movement. His research underscores that while SSM itself is not inherently flawed, its complexity and the common practice of granting excessive permissions render it a potent tool for adversaries. The talk provided both offensive insights into how SSM can be weaponized and, more importantly, actionable defensive strategies to safeguard AWS infrastructure against these threats, emphasizing that preventing abuse is paramount.

The significance of this talk lies in its practical demonstrations and its clear articulation of the challenges faced by security operations centers (SOCs) in detecting SSM-related attacks. Montoro’s work builds upon prior research by individuals like Mitiga, Remy McCartney, and Edward, extending the understanding of SSM's attack surface. By dissecting specific abuse patterns and offering concrete hardening techniques, the presentation serves as a vital resource for cloud security professionals striving to secure their AWS deployments against sophisticated and often stealthy threats leveraging native cloud services.

Background

▶ Watch: Introduction to SSM abuse and hardening (0:00)

AWS Systems Manager (SSM) is a powerful suite of tools designed to centrally manage and operate nodes at scale across AWS EC2 instances, on-premise servers, and even other cloud environments like GCP or Azure. At its core, SSM relies on an agent running on managed nodes that communicates with the AWS SSM API, effectively creating a command-and-control (C2) network. Its extensive feature set, spanning over 3,400 pages of documentation, is categorized into node tools, change management, application management, and operational tools. This breadth of functionality, while beneficial for administrators, introduces a complex attack surface that is frequently overlooked.

The problem arises from SSM's inherent power and the common misconfiguration of IAM permissions. When administrators grant overly broad or unchecked permissions to IAM roles or users associated with SSM, they inadvertently create pathways for privilege escalation, remote code execution, and persistence. The ease with which an attacker can gain root access on managed instances, even those in private subnets with no public IP or open security groups, is a significant concern. This capability, where an attacker connects directly via the AWS API to an instance without traditional network access, highlights a paradigm shift in cloud exploitation that demands a re-evaluation of security postures.

Prior research has touched upon SSM's vulnerabilities. Mitiga and Remy McCartney have published extensive blog posts and analyses on SSM abuse, particularly focusing on document poisoning and misconfigurations. Edward has also contributed to understanding run command and its implications. Furthermore, frameworks like Pacu have incorporated SSM exploitation modules, demonstrating its recognized utility in offensive security. Montoro's research expands on this foundation by providing new practical exploitation techniques and, critically, a blue team perspective on detection and mitigation strategies, addressing the specific challenges SOCs face in identifying malicious SSM activity amidst legitimate operations.

Key Findings

▶ Watch: AWS SSM: Definition and feature categories (3:40)

Rodrigo Montoro's research uncovered and demonstrated several critical abuse patterns within AWS Systems Manager, highlighting how seemingly benign features can be weaponized for various malicious objectives. These findings underscore that the primary risk stems not from inherent flaws in SSM's design but from over-permissive IAM configurations.

1. Run Command as Root: The most classic and widely used SSM feature, run command, allows for remote, secure execution of commands on managed nodes. Montoro demonstrated how an attacker with ssm:SendCommand permissions can execute arbitrary commands as root on Linux instances, or SYSTEM on Windows, across potentially thousands of machines simultaneously. This provides immediate, high-privilege access without direct network connectivity to the target.

1. Session Manager for Shell Access: Session Manager enables interactive shell access to managed instances, even those residing in private subnets without public IPs or open security groups. An attacker can leverage ssm:StartSession to gain an interactive shell as the ssm-user, which can then easily escalate to root using sudo su. This capability bypasses traditional network perimeter defenses, making it a stealthy and potent method for direct instance compromise.

1. SSM Document Abuse: SSM Documents define actions for Systems Manager to execute. Montoro showed two critical abuse vectors:

• Sensitive Data Exposure: Documents often contain sensitive data (e.g., API keys, credentials) embedded within them for automation purposes, which can be exfiltrated by attackers with read access.
• Document Sharing & Poisoning: Malicious documents can be created and explicitly shared with target AWS accounts, appearing in their document list without requiring approval. Building on Remy McCartney's research, Montoro emphasized the risk of "document poisoning," where attackers create documents with identical names to legitimate vendor-provided ones but include malicious payloads, leading unsuspecting administrators to execute them.

1. Distributor for Persistence: The Distributor feature, designed for packaging and publishing software to AWS instances, can be repurposed to deploy custom malicious software packages. Attackers can create packages containing reverse shells or other backdoors, deploy them via run command or state manager, and establish persistent access. This method leverages SSM's native deployment capabilities for covert operations.

1. State Manager for Scheduled Persistence: State Manager automates the process of keeping managed nodes in a defined state, executing scripts regularly. Montoro demonstrated how an attacker can create an SSM document containing a reverse shell and associate it with target instances via State Manager. This allows for scheduled, persistent execution of malicious payloads (e.g., hourly, daily), effectively creating a recurring backdoor.

1. Automation for Service Interaction & Persistence: SSM Automation allows for complex workflows that interact with various AWS services. Attackers can create custom runbooks that not only execute commands on instances but also interact with other services (e.g., RDS, S3) for data exfiltration or broader impact. This offers a powerful mechanism for multi-stage attacks and persistence, especially when coupled with rate control for stealthier deployments.

1. Hybrid Activations for Cross-Account Persistence: Perhaps one of the most stealthy findings, Hybrid Activations allow non-EC2 machines (on-prem, other clouds, local VMs) to become managed nodes within an AWS account. Montoro showed how creating a hybrid activation generates a code that, when used to register an external machine, causes that machine to assume a specified IAM role within the AWS account. If this role is over-permissive (e.g., AdministratorAccess), it creates an incredibly persistent and hard-to-detect backdoor, as the malicious "managed instance" operates from outside the traditional AWS perimeter.

These findings collectively paint a picture of SSM as a highly privileged and versatile platform that, if mismanaged, can become a central point for compromise, lateral movement, and persistence within an AWS environment.

Technical Deep Dive

▶ Watch: Visualizing potential SSM abuse patterns (6:00)

AWS Systems Manager offers a rich set of features, each with distinct mechanisms that, when misused, can become powerful tools for attackers. Montoro meticulously detailed several of these, providing practical examples of their exploitation.

Run Command: Unfettered Execution

Run Command is the bedrock of many SSM operations, allowing administrators to execute commands on managed instances remotely. The critical aspect is that these commands are executed with elevated privileges, typically as root on Linux or SYSTEM on Windows. This means an attacker who gains ssm:SendCommand permission effectively has full control over the target instance.

The exploitation flow is straightforward:

1. Identify Targets: An attacker first lists available managed instances using aws ssm describe-instance-information.
2. Send Command: Using the instance ID, a command is dispatched. Montoro demonstrated this with a simple id command:

The output clearly showed uid=0(root) gid=0(root), confirming execution as root.

This capability, scalable across hundreds or thousands of instances, makes run command a prime target for initial compromise or rapid-response actions by an attacker.

Session Manager: Interactive Shells Anywhere

Session Manager provides interactive shell access to managed instances without requiring open inbound ports, public IPs, or bastion hosts. It routes traffic through the AWS API, making it particularly effective for instances in private subnets. This feature bypasses traditional network security controls like security groups and NACLs.

To initiate a session, the AWS CLI with the Session Manager plugin is required. Montoro's example showed:

Upon connection, the user typically lands as ssm-user. However, on most Linux distributions, ssm-user has sudo privileges, allowing a quick escalation to root via sudo su. This grants an attacker a full interactive shell with root privileges, effectively bridging the air gap for private instances. Crucially, SSM Session Manager can be configured to log all session activity to Amazon S3 or CloudWatch Logs, a vital defensive control.

SSM Documents: The Blueprint for Malice

SSM Documents are JSON or YAML files that define the actions Systems Manager performs. They can be Command documents, Automation runbooks, Session documents, or Package documents. Their power lies in their reusability and ability to encapsulate complex workflows.

Montoro highlighted two key abuse patterns:

1. Sensitive Data in Documents: Organizations often embed sensitive data directly within SSM documents for automation, such as database connection strings or API keys. An attacker with ssm:GetDocument permissions can retrieve these documents and extract valuable secrets.

This mirrors the common anti-pattern of embedding secrets in user data or Lambda environment variables.

1. Document Sharing and Poisoning: A particularly insidious technique involves sharing malicious documents. An attacker can create a custom SSM document with a payload (e.g., a reverse shell) and explicitly share it with a target AWS account. The document appears in the target account's list without requiring explicit acceptance. This facilitates document poisoning, a technique popularized by Remy McCartney. An attacker creates a malicious document with the exact same name as a commonly used, legitimate vendor-provided document (e.g., AWS-RunShellScript or a DataDog agent installation document). If an administrator in the target account executes the document by name without specifying the owner, there's a risk they execute the attacker's poisoned version instead of the official one, leading to compromise. This highlights a critical trust issue and the need for rigorous document verification (e.g., by owner ID).

Distributor: Custom Software Deployment

Distributor allows users to package and publish their own software to managed instances. This feature can be weaponized to deploy persistent backdoors or custom malware.

The process involves:

1. Package Creation: The attacker creates a .zip file containing their malicious software (e.g., a reverse shell executable) and a manifest file. The manifest (.json) specifies details like the package version, the name of the .zip file, and most importantly, install and uninstall scripts. The install script contains the malicious payload.

Montoro's example install.sh included:

where /tmp/reverse_shell is the attacker's compiled reverse shell binary.

1. Publish Package: The package is published using aws ssm create-document with DocumentType set to Package, referencing an S3 bucket where the .zip file is stored. This package can be created in the attacker's account and made public, or uploaded to an S3 bucket accessible by the target.
2. Deploy Package: The package is then deployed to target instances using ssm:SendCommand (for one-time execution) or ssm:CreateAssociation via State Manager (for persistent deployment).

Montoro demonstrated deploying a reverse shell that connected back to his Netcat listener. A crucial defensive point highlighted here is the default egress rule in AWS security groups: Any port, Any protocol is allowed by default. This enables outbound connections for reverse shells unless explicitly restricted.

State Manager: Scheduled Persistence

State Manager automates the process of keeping instances in a defined state, executing actions on a schedule. This provides a powerful mechanism for persistent execution of malicious payloads.

1. Malicious Document: An attacker creates an SSM document (e.g., AWS-RunShellScript) that contains their desired malicious command, such as a reverse shell.

1. Create Association: An ssm:CreateAssociation action links this document to target instances and specifies a schedule (e.g., hourly, daily).

This ensures the reverse shell attempts to connect back on a regular basis, maintaining persistence. Montoro emphasized that while he used a simple reverse shell, an attacker could implement far more sophisticated data collection, exfiltration, and staging operations.

Automation: Orchestrated Attacks

SSM Automation allows for the creation of complex workflows (runbooks) that can interact with various AWS services, not just EC2 instances. This makes it a potent tool for multi-stage attacks and broader service compromise.

1. Custom Runbook: An attacker creates an automation runbook that defines a sequence of actions. This runbook can accept parameters, allowing for dynamic control (e.g., changing C2 IPs/ports).
2. Service Interaction: Unlike run command, automation runbooks can call other AWS APIs directly. If the IAM role executing the automation has broad permissions (e.g., to RDS, S3, Lambda), the runbook can be crafted to dump database contents, exfiltrate S3 data, or trigger other malicious functions.
3. Execution: The ssm:StartAutomationExecution action initiates the runbook. Montoro demonstrated an automation runbook triggering a reverse shell on a target instance, showcasing parameter passing for C2 details.

Hybrid Activations: Stealthy Cross-Cloud Persistence

Hybrid Activations enable non-EC2 machines (on-premises servers, virtual machines in other clouds, or even a local VirtualBox instance) to register as managed nodes within an AWS account. This is a critical vector for establishing stealthy, long-term persistence.

1. Create Activation: An ssm:CreateActivation command is used to generate an activation code and ID. Crucially, this action also specifies an IAM service role that the external managed instance will assume.

If an attacker can create an activation with an over-permissive role (e.g., AdministratorAccess), they've created a powerful backdoor.

1. Register External Machine: The attacker takes the activation code and ID and uses it to install and configure the SSM agent on their external machine.

1. Role Assumption: Once registered, the external machine appears as a managed instance (with an mi- ID instead of i-) in the AWS account. It automatically assumes the specified IAM role.

Montoro demonstrated how the external machine, now a managed instance, could use aws sts get-caller-identity to confirm it was operating with the permissions of the AdministratorAccess role. This creates a highly durable persistence mechanism that is difficult for SOCs to detect, as the originating machine is entirely outside AWS infrastructure, and the activity appears as legitimate SSM management from a managed node. Detection relies heavily on monitoring IAM trust relationships for SSM and scrutinizing permissions granted to activation roles.

Demo / Proof of Concept

▶ Watch: Deep dive into Run Command execution flow (7:40)

Throughout the presentation, Rodrigo Montoro provided practical, hands-on demonstrations and proof-of-concept (PoC) code snippets for each identified abuse pattern. While there wasn't a single, consolidated "demo" section, the talk was replete with live and screenshot-based examples showcasing the ease of exploitation.

For Run Command, Montoro presented Python code (also achievable via AWS CLI) to list instances and then execute the id command on a target. The output, displaying uid=0(root), clearly demonstrated root-level command execution. Similarly, for Session Manager, the PoC involved using aws ssm start-session to connect to a private instance, followed by sudo su to achieve root access within the interactive shell, bypassing traditional network controls.

The SSM Documents section included examples of listing documents and retrieving their content using aws ssm get-document and jq, illustrating how sensitive data might be exposed. Crucially, he demonstrated the document sharing mechanism by modifying permissions on a custom document, making it visible and usable by another AWS account without explicit approval. This set the stage for the document poisoning scenario.

The "not so classic" exploits also featured clear PoCs. For Distributor, Montoro walked through the process of creating a custom package manifest (including install.sh to execute a reverse shell) and publishing it. He then showed how deploying this package via run command resulted in a Netcat listener on his attacker machine receiving a root shell callback from the target instance. State Manager was demonstrated by creating an SSM document with a reverse shell payload and then creating an association to execute it hourly, proving persistent access.

Automation also featured a reverse shell PoC, highlighting the ability to pass C2 parameters to the automation runbook and showing the successful callback. Finally, the Hybrid Activations PoC was particularly impactful. Montoro showed creating an activation that granted AdministratorAccess to an external machine. He then demonstrated registering a non-EC2 machine (implicitly, an attacker's machine) as a managed instance, and subsequently, from that external machine, using aws sts get-caller-identity to confirm it had assumed the powerful AdministratorAccess role within the target AWS account, establishing a highly stealthy and persistent backdoor.

Across all demonstrations, the common thread was the use of simple AWS CLI commands or Python scripts to achieve significant compromise, often resulting in root-level access or persistent backdoors, all contingent on over-permissive IAM roles.

Defensive Implications

▶ Watch: Demonstrating Run Command for root access (8:40)

Securing AWS environments against SSM abuse requires a multi-faceted approach focusing on least privilege, robust monitoring, and proactive configuration. Montoro provided a comprehensive set of defensive implications for organizations:

1. Implement Strict Least Privilege: This is the foundational defense. Review all IAM roles and users that have permissions related to SSM. Ensure they only possess the absolute minimum permissions required for their function. Over-permissive roles, especially those with ssm:* or AdministratorAccess combined with SSM trust relationships, are critical vulnerabilities. Monitor IAM roles' trust relationships to ensure SSM is not granted excessive permissions to assume roles.

1. Monitor Key SSM Actions: Implement comprehensive CloudTrail logging and establish alerts for suspicious SSM activities. Critical actions to monitor include:

• ssm:StartSession: Indicates interactive shell access.
• ssm:SendCommand: Remote command execution.
• ssm:CreateAssociation: State Manager configurations (potential persistence).
• ssm:CreateActivation, ssm:RegisterManagedInstance: Hybrid activation events (potential cross-account persistence).
• ssm:CreateDocument, ssm:ModifyDocumentPermissions: Document creation or sharing (potential for malicious documents).
• ssm:GetCommandInvocation: To retrieve command output, which might contain sensitive data or indicate reconnaissance.

1. Control Egress from Security Groups: The default "allow any outbound" rule (0.0.0.0/0 on all ports) for security groups is a significant enabler for reverse shells and data exfiltration. Implement strict egress filtering, allowing only necessary outbound connections (e.g., to specific services, known update servers, or proxy endpoints). This makes it significantly harder for attackers to establish C2 channels or exfiltrate data.

1. Enable Session Manager Logging: For ssm:StartSession activities, enable logging to Amazon S3 buckets and/or CloudWatch Logs. This captures all commands executed within an interactive session, providing crucial forensic evidence and visibility into potentially malicious activity.

1. Verify SSM Documents: Be extremely cautious with SSM documents.

• Know Your Documents: Maintain an inventory of legitimate SSM documents, including their exact names and owner IDs.
• Validate Owner: When executing or relying on SSM documents, explicitly specify the owner (e.g., Self or Amazon) to prevent execution of poisoned documents with identical names.
• Scan for Sensitive Data: Regularly audit custom SSM documents for embedded sensitive information that should be stored in AWS Secrets Manager or Parameter Store.

1. Disable Unused SSM Features via SCPs: If certain SSM features (e.g., Distributor, Hybrid Activations) are not used in your organization, consider disabling them at the AWS Organization level using Service Control Policies (SCPs). This removes entire attack vectors. For example, a SCP blocking ssm:CreateActivation can prevent unauthorized hybrid instance registrations.

1. Enhance SOC Contextualization: Raw CloudTrail events often lack sufficient context (e.g., activation IDs, association IDs). SOC analysts need tools and processes to enrich these events by querying AWS APIs (e.g., ssm:DescribeActivations, iam:GetRolePolicy) to understand the full implications of an action (e.g., what role was assumed by a hybrid instance, what permissions it has). This is crucial for distinguishing legitimate activity from malicious intent.

1. Monitor Source IPs and Usernames: Pay close attention to the source IP addresses and usernames associated with SSM actions in CloudTrail.

• Source IP: If a ssm:SendCommand or ssm:StartSession comes from an unexpected external IP, it could indicate abuse. However, be aware that service-initiated actions (e.g., State Manager, Automation) originate from AWS internal IPs, making IP filtering alone insufficient.
• Username: Look for unexpected usernames like state-manager.ssm.amazonaws.com or automation.ssm.amazonaws.com performing actions directly, and correlate them with expected automation. Unexpected user activity from an ssm-user or a role associated with a hybrid instance should raise flags.

By rigorously applying these defensive strategies, organizations can significantly reduce their SSM attack surface and enhance their ability to detect and respond to potential compromises.

Key Takeaways

• SSM's Power is a Double-Edged Sword: AWS Systems Manager offers immense operational capabilities but, if misconfigured, presents a vast and potent attack surface for adversaries.
• Least Privilege is Paramount: Over-permissive IAM roles with SSM access are the root cause of most exploitation paths, enabling remote code execution, persistence, and privilege escalation.
• Traditional Network Defenses are Bypassed: SSM Session Manager and Hybrid Activations allow interactive shell access and persistence to instances even in private subnets without public IPs or open security groups, bypassing traditional perimeter security.
• Egress Control is Critical: Default permissive egress rules in security groups facilitate reverse shells and data exfiltration; strict egress filtering is a vital defense.
• Vigilant Monitoring is Essential: Comprehensive CloudTrail logging of SSM actions, combined with contextual enrichment (e.g., for activation IDs and associated roles), is crucial for detecting abuse, as many attacks are stealthy.
• SSM Documents are a Trust Boundary: Be wary of untrusted or unverified SSM documents, as document sharing and poisoning techniques can lead to the execution of malicious payloads.

About the Speaker(s)

Rodrigo Montoro is the Director of Research at Clouds. Based in Florianópolis, Brazil, he is an experienced cloud security professional and educator, having previously taught AWS trainings in Brazil. Montoro holds two US patents unrelated to cloud technology. He is a proud father and husband, and a former triathlete who now engages in powerlifting. His work primarily focuses on blue team research, simulating attacks to develop robust detection and mitigation strategies, as evidenced by his detailed analysis of AWS SSM abuse patterns. This was not his first time presenting at Defcon, having previously presented research on App Streaming in 2022.