Amazon's AWS SSM agent can be used as post-exploitation RAT malware

Researchers have discovered a new post-exploitation technique in Amazon Web Services (AWS) that allows hackers to use the platform's System Manager (SSM) agent as an undetectable Remote Access Trojan (RAT).

The attack concept, devised by security researchers at Mitiga, impacts both Windows and Linux machines and is preferable to using common malware and backdoors as its abuse will less likely be detected by security software. 

"We strongly believe that threat actors will abuse this in real-world attacks if they do not do so already," warns Mitiga in the report.

Abusing AWS SSM Agent as a RAT

AWS Systems Manager (SSM) is an Amazon-signed binary and comprehensive endpoint management system used by administrators for configuration, patching, and monitoring AWS ecosystems comprising EC2 instances, on-premise servers, or virtual machines.

It is a very popular tool that comes pre-installed on many popular operating system template images (AMI) that can be used to launch new AWS instances. Therefore, attackers have a large pool of hosts where the new attack surface can be abused, with others previously raising concerns about SSM in 2019 and 2021.

Mitiga's discovery is that the SSM agent can be configured to run in "hybrid" mode even from within the limits of an EC2 instance, allowing access to assets and servers from attacker-controlled AWS accounts.

When configuring SSM to be in hybrid mode, it allows an AWS account to manage non-EC2 machines, including on-premise servers, AWS IoT devices, and virtual machines, including those in other cloud environments.

"In our research, we focused on the ability of an SSM agent to run not only on Amazon Elastic Compute Cloud (EC2) instances, but also on non-EC2 machine types (Servers on your own premises and Virtual machines aka VMs, including VMs in other cloud environments)," explains Mitiga's security advisory.

"We abused this feature by registering an SSM agent to run in "hybrid" mode even if the agent runs on an EC2 instance."

Additionally, bash commands allow the SSM agent to communicate and execute commands using AWS accounts not associated with the compromised EC2 environment. SSM's proxy feature can also be abused to pass network traffic outside any AWS infrastructure.

"We found a unique way to abuse the SSM service, allowing it to function seamlessly as a fully integrated trojan infrastructure, making the agent in the endpoint to communicate with different AWS account (which can be used by the attacker) than the original AWS account," explains Mitiga

"By executing commands from a separate, maliciously owned AWS account, the actions carried out by the SSM agent will remain hidden within the original AWS account, making the process of detecting the malicious activity cumbersome."

If hijacking existing SSM agents is unattainable due to a lack of permissions, hackers can run another SSM agent process, which works parallel to any existing processes and gives attackers access to the "Run Command" feature.

However, the attack is easier to detect in this case as it leaves more traces, and establishing persistence becomes more difficult.

Abusing the SSM agent allows attackers to breach AWS accounts to execute commands remotely without being detected, as the traffic looks like regular activity generated by the agents.

Defending against this attack

After disclosing the post-exploitation method to Amazon, the AWS security team said it's possible to restrict the reception of commands in EC2 instances using the VPC endpoint for Systems Manager, setting the original AWS account or organization as the only approved source.

Furthermore, Mitiga suggests removing the SSM agent from the allow-list of antivirus or EDR solutions and integrating the detection techniques presented in its report into your SIEM and SOAR platforms.

"The widespread popularity and initial trust associated with the SSM agent further amplify the need for organizations to take immediate action to mitigate this new technique," concludes Mitiga's report.

---

Update 8/4: An Amazon spokesperson has sent BleepingComputer the following comment:

AWS software and systems are behaving as designed and there is no need for customers to take any action.

The issues described in the Mitiga publication, titled “Mitiga Security Advisory: Abusing the SSM Agent as a Remote Access Trojan,” 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.