For many years now, attackers have pivoted from using primarily custom automated malware to attacks that involve hands-on hacking through utilities that already exist on computers. Known as living of the land, this approach also extends to cloud infrastructure by leveraging services and tools cloud providers make available as part of their ecosystem.
Researchers from incident response firm Mitiga recently showed how the AWS Systems Manager (SSM) agent could be hijacked by attackers and turned into a remote access trojan (RAT). The SSM agent is a tool that AWS customers can deploy on EC2 instances, on-premises servers, as well as virtual machines in other clouds to enable their remote management and monitoring through the AWS-native Systems Manager service.
“The concept is straightforward: when an attacker successfully gains initial execution on an endpoint that already has an installed SSM agent, rather than uploading a separate commercial or internally developed backdoor or RAT, they can exploit the existing SSM agent to control the endpoint, effectively turning it into a RAT itself,” the Mitiga researchers said in their report.
“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, leaving no trace of the intrusion.”
The advantages of hijacking an SSM agent
The SSM agent is a powerful tool that allows remote execution of commands and gathering of data about the machine, much as a trojan program would. The difference is that the SSM agent is open source, is developed and digitally signed by Amazon, and is preinstalled on many Amazon Machine Images (AMIs) that customers can deploy on their EC2 instances such as Amazon Linux, SUSE Linux Enterprise, macOS and Windows Server. It’s also present inside some system images provided by third parties on the AWS Marketplace or developed by the community.
The top benefit for attackers is that the SSM agent is already whitelisted by many endpoint detection and response (EDR) or antivirus solutions that are likely to be deployed on an AWS-managed server. Zero out of 71 antivirus engines of VirusTotal flagged the binary as malicious.
Furthermore, since the SSM agent can be configured to communicate with a particular Amazon AWS account, it offers attackers an easy command-and-control option without having to develop or deploy additional infrastructure that would be typically needed to host a RAT control panel. All they need is an AWS account.
A parallel would be the PowerShell interface native to Windows and designed to automate administrative tasks. Since PowerShell is so powerful and comes with its own scripting language, it has been adopted over the years by a very large number of attackers, forcing Microsoft to add increasing warnings, protections, and security flags. Nevertheless, there are still entire post-exploitation and lateral movement frameworks written in PowerShell, as well as open-source malware.
Running multiple SSM agent instances
Using the SSM agent as a trojan or a backdoor is not a new idea. Other cloud engineers and security researchers have warned about its abuse potential. However, Mitiga took it one step further, showing how to hijack the agent in more subtle ways and even without having root access.
The most direct way of abusing the SSM agent in a post-compromise scenario where the attacker already has root or admin privileges on machine is to stop the service and start it with a new activation code that would link it to an attacker-controlled AWS account and turn its hybrid mode on. In hybrid mode, the agent will set up a persistence mechanism that will allow it to start again at system reboot.
The problem with this approach is that the owner of the account under which the compromised EC2 instance runs will be able to tell that something is wrong right away because they will lose SSM access to that machine on their own account once the agent is hijacked.
To solve this problem, Mitigate looked for ways in which they could leave the original agent untouched and execute a second instance that would be rogue and connect to the attacker’s account. And while the agent is designed not to run if there’s already an SSM agent process, this can be bypassed in multiple ways: by leveraging the Linux namespaces feature to run the agent in a different namespace or by enabling the “container” mode for the second agent instance which does not require root privileges. The container mode is limited because it doesn’t have the RunCommand module, but it does allow attackers to open a remote session to access the machine.
Deploying a second SSM agent process
On Windows machines, the researchers managed to start a second SSM agent process by configuring certain environment variables to place the configuration in a different location.
Ironically one way to deploy a second SSM agent instance without having root privileges on the machine itself is to leverage the existing SSM instance and issue commands through it to set up the second one since the agent is already running with high privileges. This does require access to the victim’s AWS account that’s already being used to manage the machine through SSM.
That said, the requirement of having an AWS account to control a hijacked SSM agent might not be appealing to all attackers. First, if they use the same account to control multiple machines belonging to different victims, it only takes one of them to discover the compromise, report it to AWS and the account will be suspended.
It turns out that the SSM agent does have two configuration options called http_proxy and https_proxy that can be used to route the SSM agent traffic to an attacker-controlled IP address instead of an Amazon one. And the Mitiga researchers were able to build a mock server that an attacker could run on their end to leverage the RunCommand feature without actually relying on the AWS SSM service.
Detecting and preventing attacks through SSM agent
The researchers published some indicators of compromise that could be used to detect if two SSM agent instances are running. They also recommend removing the SSM agent from the allow list of any antivirus or EDR solution so they could scan its behavior and add detection techniques for such hijacking to their SIEM solution.
“The AWS Security team offered a solution to restrict the receipt of commands from the original AWS account/organization using the VPC (Virtual Private Cloud) endpoint for Systems Manager,” the researchers said. “If your EC2 instances are in a private subnet without access to the public network via a public EIP address or NAT gateway, you can still configure the System Manager service through a VPC endpoint. By doing so, you can ensure that the EC2 instances only respond to commands originating from principals within their original AWS account or organization. To implement this restriction effectively, refer to the VPC Endpoint policy documentation.”
Bugs, Data and Information Security, Hacking, Remote Access Security
