Remote Access Trojan

Cybersecurity researchers have discovered a new post-exploitation technique in Amazon Web Services (AWS) that allows the AWS Systems Manager Agent (SSM Agent) to be run as a remote access trojan on Windows and Linux environments

"The SSM agent, a legitimate tool used by admins to manage their instances, can be re-purposed by an attacker who has achieved high privilege access on an endpoint with SSM agent installed, to carry out malicious activities on an ongoing basis," Mitiga researchers Ariel Szarf and Or Aspir said in a report shared with The Hacker News.

"This allows an attacker who has compromised a machine, hosted on AWS or anywhere else, to maintain access to it and perform various malicious activities."

SSM Agent is a software installed on Amazon Elastic Compute Cloud (Amazon EC2) instances, on-premise servers, and virtual machines, making it possible for administrators to update, manage, and configure their AWS resources through a unified interface.


The advantages of using an SSM Agent as a trojan are manifold in that it is trusted by endpoint security solutions and eliminates the need for deploying additional malware that may trigger detection. To further muddy the waters, a threat actor could use their own malicious AWS account as a command-and-control (C2) to remotely supervise the compromised SSM Agent.

The post-exploitation techniques detailed by Mitiga presupposes that an attacker already has permissions to execute commands on the Linux or Windows endpoint that also has an SSM Agent installed and running.

Specifically, it entails hijacking and registering an 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. This causes the SSM Agent to execute commands from an attacker-owned AWS account.

An alternative approach uses the Linux namespaces feature to launch a second SSM Agent process, which communicates with the attacker's AWS account, while the already running SSM agent continues to communicate with the original AWS account.

AI vs. AI: Harnessing AI Defenses Against AI-Powered Risks

Ready to tackle new AI-driven cybersecurity challenges? Join our insightful webinar with Zscaler to address the growing threat of generative AI in cybersecurity.

Supercharge Your Skills

Last but not least, Mitiga found that the SSM proxy feature can be abused to route the SSM traffic to an attacker-controlled server, including a non-AWS account endpoint, thereby permitting the threat actor to to commandeer the SSM Agent without having to rely on AWS infrastructure.

Organizations are recommended to remove the SSM binaries from the allow list associated with antivirus solutions to detect any signs of anomalous activity and ensure that EC2 instances respond to commands that only come from the original AWS account using the Virtual Private Cloud (VPC) endpoint for Systems Manager.

"After controlling the SSM Agent, the attackers can carry out malicious activities, such as data theft, encrypting the filesystem (as a ransomware), misusing endpoint resources for cryptocurrency mining and attempting to propagate to other endpoints within the network – all under the guise of using a legitimate software, the SSM Agent," the researchers said.


Following the publication of the story, an AWS spokesperson told The Hacker News that its "software and systems are behaving as designed and there is no need for customers to take any action."

"The issues [...] require an actor to both obtain root level credentials and successfully access an EC2 instance in order to be leveraged. As a security best practice, we recommend AWS customers follow our documentation on properly configuring VPC Endpoints with AWS Systems Manager and to use global condition keys for VPC Endpoints and VPC Endpoint Policies to mitigate the risk of inappropriate access to EC2 instances."

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.