Cybersecurity researchers at Mitiga revealed a new and sophisticated cyber threat that exploits the Amazon Web Services (AWS) Systems Manager (SSM) agent to gain control over Linux and Windows machines.
The research team, during their ongoing investigation into cloud and Software as a Service (SaaS) attacks and forensics, found this method of abusing the SSM agent – a legitimate tool used by administrators to manage their instances.
The attackers have found a way to re-purpose the SSM agent as a Remote Access Trojan (RAT), granting them ongoing access to the compromised endpoints.
AWS agent hijack: Deceptively simple
According to the Mitiga advisory, The concept behind this attack is pretty straightforward: once attackers achieve high privilege access on an endpoint with an SSM agent installed, they can manipulate the agent to perform malicious activities covertly.
“Once attackers gain their initial entry into a machine, they take the following step by uploading and installing trojans or backdoors,” Or Aspir, Head of Research at Mitiga, told The Cyber Express.
According to Or, these tools serve two key purposes.
First, they help the attackers retain ongoing access to the compromised endpoint, ensuring persistence. Second, they provide a more versatile means of controlling the endpoint while masking their activities.
What sets this attack apart is that the SSM agent binary is signed by Amazon, initially rendering it trusted and approved software by Antivirus (AV) and Endpoint Detection & Response (EDR) solutions.
As a result, the execution of the SSM agent as a RAT often goes unnoticed, evading immediate alarms and alerts, which makes detection challenging for organizations.
The researchers identified several key benefits that attackers gain by exploiting the SSM agent in this manner:
1. AWS Agent Hijack for AV and EDR Evasion: The legitimacy of the SSM agent binary allows attackers to operate without triggering immediate alarms from security solutions.
2. AWS Agent Hijack Eliminates the Need for New RAT Binaries: Attackers do not need to upload and execute new Remote Access Trojan (RAT) binaries, preventing potential detection by AV and EDR products.
3. AWS Agent Hijack Enables Legitimate Command and Control (C&C) Communication: Attackers can leverage their malicious AWS account as a Command and Control server, making their communication appear legitimate and challenging to detect.
4. No Need for Custom Code: The attackers solely rely on the SSM service and agent, eliminating the need for complex attack infrastructure development.
5. Broad Control over Endpoints: The SSM agent’s supported features like “RunCommand” or “StartSession” grant attackers effortless control over compromised endpoints.
6. Larger Attack Surface: The widespread installation and active use of the SSM agent in default Amazon Machine Images (AMIs) within the AWS ecosystem expand the potential target pool for adversaries.
AWS agent hijack: The two scenarios
According to the Mitiga advisory, there are two attack scenarios where the SSM agent could be exploited:
Scenario 1 – Hijacking the SSM agent:
In this attack, the adversaries hijack the original SSM agent process, registering it to work in “hybrid” mode with a different AWS account.
This maneuver allows them to communicate with the compromised endpoint from their own AWS account. Linux and Windows machines with an active SSM agent are susceptible to this type of attack. However, it requires the attacker to run as root on Linux or as administrator on Windows.
Scenario 2 – Running another SSM agent process:
In this scenario, attackers run an additional SSM agent process, separate from the original one, which communicates with the attacker’s AWS account.
The original SSM agent continues to operate as usual. This technique is achievable on both Linux and Windows platforms but requires the attacker to have at least non-root privileges on Linux or administrator privileges on Windows.
The threat actor must be able to run as at least non-root (but still highly) privileged user on the targeted Linux machine, or as administrator on the targeted Windows system,” said Aspir told The Cyber Express.
“The organization always needs to think about the least privilege approach in their environment and endpoint, so if something gets compromised, the attack will be still limited.”
The researchers also disclosed the potential detection methods for each attack scenario to help organizations identify suspicious activities and respond promptly.
AWS agent hijack: How to mitigate the threat
Exacerbating the situation, that attackers could bypass AWS’s servers by routing SSM traffic to attacker-controlled servers, using a proxy feature of the SSM agent, the researchers found.
This allows attackers to use the legitimate binary without AWS visibility, making it challenging to trace the attack back to the source.
AWS software and systems “are behaving as designed” and there is no need for customers to take any action, an AWS spokesperson told The Cyber Express.
The issues described in the Mitiga report require an actor to both obtain root level credentials and successfully access an EC2 instance in order to be leveraged, the spokesperson pointed out.
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,” the spokesperson said.
Mitiga team got in touch with Amazon Web Services. Acknowledging the issue, AWS suggested a few mitigation steps.
By utilizing a Virtual Private Cloud (VPC) endpoint, you can ensure that only authorized users or services within your AWS account or organization can send commands to your EC2 instances.
Even if your instances are in a private subnet without direct internet access, the Systems Manager service can still be configured securely through the VPC endpoint.
This way, you establish a restriction that limits communication to your EC2 instances from trusted sources within your own AWS account or organization, enhancing overall cloud infrastructure security.
To implement this restriction effectively, you can set up a VPC Endpoint policy to define who has access to communicate with your EC2 instances through Systems Manager.
