Ghost in the cloud: Abusing AWS SSM sessions for covert access
Learn how red teamers can abuse AWS SSM Session Manager to gain shell access to EC2 instances without SSH, public IPs, or open ports and escalate privileges.
In cloud-native environments, traditional security perimeters have faded. Remote access, automation, and ephemeral infrastructure dominate the operational model. One powerful AWS service that exemplifies this shift is AWS Systems Manager Session Manager — a feature that allows secure shell access to EC2 instances over the AWS control plane, with no need for open ports, bastion hosts, or SSH keys.
This tool is beloved by DevOps teams for its ease of use and central management. However, in the hands of a red teamer or a malicious actor, Session Manager becomes a stealthy post-exploitation vector. In this post, I explain how red team operators can abuse AWS SSM Sessions to gain covert, access to EC2 instances without ever touching a key file or opening a TCP port — all by living off the land.
Thanks for reading 100 Days of Red Team! Subscribe for free to receive new posts and support my work.
At its core, this technique leverages legitimate AWS Systems Manager capabilities to achieve remote shell access to EC2 instances. Normally, administrators use SSM Session Manager to connect to instances for maintenance, troubleshooting, and automation. It works by routing session traffic through the AWS control plane, meaning the target instance doesn’t need to expose any inbound ports. The session is encrypted, recorded if configured, and authorized via IAM.
But from a red team operator's point of view, this setup is a goldmine. If they manage to compromise AWS credentials — whether via leaked keys, metadata theft, or phishing — and those credentials have the right permissions, they can start a session to any EC2 instance that’s online and managed by SSM. No SSH key? No problem. No open ports? Not needed. It’s as if AWS itself is acting as the reverse proxy to your target — invisibly bridging the attacker and victim.
Why this matters in enterprise environments?
The rise of SSM in enterprise settings has been swift. Security-conscious organizations now rely on Session Manager instead of SSH for managing instances. It allows them to shut down public access to port 22, rotate credentials centrally, and log all activity in CloudTrail or CloudWatch — at least in theory.
In practice, many enterprises over-permission IAM roles. EC2 instances are often assigned managed instance profiles like AmazonSSMManagedInstanceCore, granting full access to Session Manager. Worse, developers and automation scripts might be assigned credentials that include ssm:* permissions without proper scoping. These lapses are invisible until someone exploits them.
From a red team perspective, this means that after a successful credential compromise — for example, by extracting temporary keys from the EC2 metadata service — there's a good chance those credentials have access to SSM.
How to abuse AWS SSM for covert access?
To better understand how this works in practice, let’s walk through an end-to-end example. We will assume the red team operator has already compromised AWS credentials that belong to a role or user with the following permissions:
ssm:GetCommandInvocation
ssm:TerminateSession
ssm:StartSession
ssm:SendCommand
ssm:DescribeInstanceInformation
ec2:DescribeInstances
The victim EC2 instance must also meet a few criteria:
It’s running the SSM Agent (installed by default on Amazon Linux 2 and some Ubuntu AMIs).
It has an IAM role attached with the necessary SSM permissions.
It can communicate with SSM endpoints, typically via outbound internet or VPC endpoints.
Enumerating EC2 instances which are managed by SSM
This returns a list of instance IDs, platform types, and online status. From ared team operator’s perspective, this is like identifying open ports on internal servers — except you're doing it via API calls and control-plane traffic, which is much less likely to be caught by EDR or NIDS.
Step 2: Start a Session to a Target Instance
Once a valid target is identified, the attacker can initiate an SSM session using:
This requires AWS Session Manager plugin to be installed on the local machine. Instructions for the same can be found here.
This launches an interactive shell directly into the EC2 instance. No SSH keys. No firewall exceptions. The connection is tunneled through AWS’s control infrastructure, making it nearly invisible to most monitoring tools focused on network or OS-level events.
Step 3: Run Arbitrary Commands with send-command
Even if interactive shell access is blocked or restricted, the attacker can still run one-off commands using send-command:
Fetching the output of the command executed via send-command
A keen eye may have observed that commands executed via send-command execute as the root user. This means we can escalate privileges without needing any additional access or tools.
Verifying root access via send-command
Output of the above command confirms root access via send-command
This is equivalent to remote code execution via an AWS API call. This access can further be exploited to drop advanced payloads or obtain a reverse shell.
OPSEC considerations
While SSM abuse is stealthier than traditional remote access, it’s not entirely invisible. Security teams that properly configure logging can detect or reconstruct SSM usage.
TL;DR
- AWS Systems Manager (SSM) allows shell access to EC2 instances via encrypted API calls — no need for SSH or open ports.
- Attackers with valid AWS credentials and proper permissions can use ssm:StartSession to gain covert access to EC2s.
- SSM agents must be installed and running, and the EC2 instance must have an IAM role with the AmazonSSMManagedInstanceCore policy.
- Red teamers can abuse this to bypass firewalls, avoid detection, and maintain stealthy persistent access.
