AWS Security design review - Risk of AWS SSM Agent use as Remote Access Trojan
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.
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:
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.
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.
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.
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.
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.
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.
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
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.
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
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: