AWS Security design review - Risk of AWS SSM Agent use as Remote Access Trojan

published: Aug. 2, 2023

Take action: An awareness topic for your DevOps and Architects team, so you educate them to use a more locked down process of using AWS infrastructure. Persuading the DevOps team that they are at risk will not be trivial since most think they are impervious to cybersecurity attacks. But it's good to educate and raise awareness, it will have them reconsider a bit on the next implementation.


Learn More

Cybersecurity researchers have made a concerning discovery regarding Amazon Web Services (AWS). They found that the AWS Systems Manager Agent (SSM Agent), a legitimate tool made by AWS and used by administrators to manage their instances, can be repurposed by attackers as a remote access trojan in both Windows and Linux environments.

In this article we take a look at SSM Agent use cases, how it's exploited and design considerations to mitigate the risk of exploiting SSM Agent.

For the more experienced readers, there is an easy comparison between AWS SSM Agent and Netcat tool (nc) which is a versatile networking utility often referred to as the "Swiss Army knife" of networking tools. However, due to its potential for misuse and frequent use by hackers as a tool on compromised systems, today most systems detect Netcat as a malicious tool.

What is SSM Agent?

AWS Systems Manager (SSM) Agent is a software component that facilitates communication between managed instances (Amazon EC2 instances, on-premises servers, or virtual machines) and the AWS Systems Manager service. It enables you to perform various management tasks and actions on your instances, making it easier to manage and maintain your infrastructure at scale. Here are some of the primary use cases and features of SSM Agent:

  1. Run Command: SSM Agent allows you to execute commands remotely on your managed instances. This can be helpful for tasks such as installing software, running scripts, configuring applications, and performing system updates across multiple instances simultaneously.

  2. State Manager: SSM Agent enables you to define and apply standard configurations to your instances. You can define a document specifying the desired state of an instance (e.g., specific software versions, configurations) and apply it using the SSM service.

  3. Patch Manager: With SSM Agent, you can manage and automate the process of applying patches and updates to your instances. It simplifies patch management by allowing you to define patch baselines and automatically apply patches across your fleet.

  4. Session Manager: SSM Agent enables interactive shell access to your instances through the AWS Systems Manager Console. This provides a secure alternative to SSH/RDP, as it doesn't require inbound connections and can be audited and logged.

  5. Automation: SSM Agent supports automation workflows, allowing you to create and schedule multi-step tasks that can be executed across multiple instances. This is useful for complex maintenance tasks and configuration management.

  6. Distributed Tracing and Insights: SSM Agent can be configured to collect inventory and operational data from your instances, which can be used to gain insights into the health and performance of your infrastructure.

  7. Hybrid Environments: SSM Agent extends its functionality to on-premises servers or virtual machines, allowing you to manage your hybrid environments from the AWS Systems Manager Console.

SSM Agent in a couple of simple examples

  1. Running Commands on Multiple EC2 Instances Use SSM Agent's "Run Command" feature to update the web application code on multiple EC2 instances simultaneously, avoiding manual connections to each instance.
  2. Applying Patches to EC2 Instances Automate patching using SSM Agent's "Patch Manager" feature to keep EC2 instances up-to-date with the latest security patches, organized by logical groups and scheduled maintenance windows.
How is SSM Agent exploited as a RAT malware?
Cybersecurity researchers have discovered a post-exploitation technique that allows the SSM Agent to be run as a remote access trojan on Windows and Linux environments.
The advantages of using an SSM Agent as a trojan are in that it is trusted by endpoint security solutions and eliminates the need for deploying additional malware that may trigger detection.
 
If an attacker has achieved an elevated privilege access on an endpoint with SSM agent installed (DevOps laptop), they can abuse the agent to maintain access to cloud instances and perform various malicious activities on them:
  1. The post-exploitation techniques involve registering the SSM Agent to run in "hybrid" mode, allowing it to communicate with different AWS accounts other than the original AWS account where the EC2 instance is hosted and collect commands from a Command and Control system in another AWS account.

  2. An alternative approach is for the attacker to use the Linux namespaces feature to launch a second SSM Agent process, communicating with the attacker's AWS account while the original SSM Agent continues to communicate with the original AWS account

  3. Another method discovered involves abusing the SSM proxy feature to route the SSM traffic to an attacker-controlled server, including a non-AWS account endpoint. This grants the threat actor control over the SSM Agent without having to rely on AWS infrastructure.

How to mitigate the risk of AWS SSM Agent being exploited?

While there is no complete solution to defending from a legitimate tool, there are several mitigation techniques:

  1. Work with the DevOps team to secure and lock down all endpoints where SSM Agent is present and educate the DevOps team persistently on phishing and social engineering attacks. This way you make the original exploitation step much more difficult to achieve.
  2. Remove the SSM binaries from the allow list associated with antivirus solutions, so the antivirus solution can have a chance to detect communication from the SSM binary to untrusted networks and IP addresses recognized as C&C servers. 
  3. Design your AWS SSM Agent setup so that the EC2 instances only respond to commands from the original AWS account using the Virtual Private Cloud (VPC) endpoint for Systems Manager:
    1. A Virtual Private Cloud (VPC) endpoint for Systems Manager is a service that allows secure and private communication between Amazon EC2 instances and the AWS Systems Manager service. AWS Systems Manager provides a set of tools and features for managing and configuring your infrastructure and applications
    2. By default, when an EC2 instance needs to communicate with AWS Systems Manager, it does so over the internet. However, in some security-conscious scenarios, direct internet communication may not be desirable due to security policies or compliance requirements.
    3. To address this, AWS offers VPC endpoints for Systems Manager. A VPC endpoint is a private connection between a VPC and a supported AWS service, in this case, AWS Systems Manager. When you create a VPC endpoint for Systems Manager, the endpoint is assigned a private IP address from your VPC's IP address range.

AWS Security design review - Risk of AWS SSM Agent use as Remote Access Trojan