Amazon Web Services (AWS) has a novel post-exploitation approach that has been identified by researchers. This technique enables hackers to utilize the platform’s System Manager (SSM) agent as an undetected Remote Access Trojan (RAT).  Since the SSM agent binary has been signed by Amazon, it is automatically recognized as trustworthy and authorized software by endpoint detection and response (EDR) systems and antivirus programs. As a consequence of this, the execution of the SSM agent in the capacity of a RAT may take place without immediately setting off alarms or warnings, hence avoiding initial discovery.

It is recommended to employ the attack idea rather than ordinary malware and backdoors since its misuse will be less likely to be caught by security software. The attack concept was developed by security experts at Mitiga. It affects both Windows and Linux workstations.

The idea behind this is simple: an adversary who has gained high privilege access to an endpoint that also has the SSM agent installed may repurpose the SSM agent, which is a lawful tool used by admins to manage their instances, in order to carry out malicious operations on a continuous basis. This is possible since the SSM agent is deployed on the endpoint. Because of this, an adversary who has gained access to a computer hosted on Amazon Web Services (AWS) or anyplace else may continue to access it and engage in a variety of nefarious behaviors. When an attacker uses SSM agent in this nefarious fashion, rather than utilizing typical varieties of malware, which are often reported by antivirus software, the attacker is able to gain from the reputation and authenticity of this binary, which helps the attacker to mask his tracks.

The SSM agent includes supported functionality such as “RunCommand” or “StartSession,” which enables attackers to easily manage the hacked endpoint from inside their own AWS account. Because of these qualities, they are able to alter the endpoint in any way they like, which gives them extensive control over the operations of the endpoint.

During the course of this investigation, they concentrated on determining whether or not an SSM agent is capable of operating not only on Amazon Elastic Compute Cloud (EC2) instances, but also on machine types that are not associated with EC2. They took use of this function by registering an SSM agent to operate in the “hybrid” mode even though the agent was running on an EC2 instance.

The SSM agent is able to connect with and carry out instructions from a variety of AWS accounts in addition to the primary AWS account that is used to run the EC2 instance. All that is required is the execution of a few basic bash commands. Because of these changes, you now have the capacity to execute several SSM agent processes inside a single endpoint. This enables the rogue agent process to function with our AWS account, while simultaneously allowing the other process to continue working with the initial AWS account without any hindrance.

In addition, by misusing the SSM proxy capability, they were able to have the SSM agent connect with an endpoint that was not associated with an AWS account.

Exploitation

Scenario 1: Hijacking the SSM agent‍

In this hypothetical situation, the attack involves “hijacking” the original SSM agent process by registering the SSM agent to run in “hybrid” mode with a separate AWS account. The SSM agent will then interact with the attacker’s owned AWS account and execute orders received from the attacker.

Scenario 2: Running Another SSM Agent Process [running another SSM agent process]

In this case, the threat actor initiates a second SSM agent process. The original SSM agent is then free to continue interacting with the AWS account it was originally connected to while the malicious agent process interacts with the attacker’s AWS account.

On the Linux platform, you may do this with the help of Linux namespaces . The “Run Command” capability may be accessed by the attacker since the malicious SSM agent process is in use. Another scenario involves operating the agent in “container” mode, which enables the attacker to make advantage of the “Start Session” capability available via the AWS Command Line Interface

Managing the SSM Agent with a Mock Server Instead of an Amazon Web Services Account

‍

Threat actors may find it more convenient to administer agents without utilizing their AWS accounts for a variety of reasons. Because real risk management is essential for any campaign, it’s possible that they would like to produce network traffic to their selected IP rather than have AWS visibility on their C&C.

During the course of our investigation, they came across a feature in SSM that has the potential to be exploited in order to redirect the SSM traffic to a server that is controlled by an attacker. This would make it possible to utilize the valid binary without the traffic ever passing through AWS’s servers. Altering the values of the environment variables ‘http_proxy’ and ‘https_proxy’ enables this function to connect to the server using a proxy.

How to exploit Antivirus and EDR solutions flaws to delete data from victim device without admin rights

Detection

You are able to keep an eye on how the instance data is shifting in the first scenario, which involves the hijacking approach. A new instance ID is assigned to an agent each time it is registered.

The information may be found in a new directory; on Linux, it is located at “/var/lib/amazon/ssm/i-,” while on Windows, it is located at “C:ProgramDataAmazonSSMInstanceDatai-.” If after the hijacking you find more than one directory with a different instance name than the one that corresponds to the original instance ID, this is cause for concern. Also monitoring bash/cmd commands or CreateProcess for launching the “amazon-ssm-agent” binary with the following flags: “register”, “code”, “id”, and “region”. You are able to identify the execution of the “hijack” command. In addition, you may check your AWS account to ensure that the connection to this agent has been terminated.

You are able to determine whether there is more than one instance of the following process: “amazon-ssm-agent” while dealing with the second case. It is recommended that you only run a single instance at a time. If there are two or more of them, it raises further red flags.

If the attack is carried out from the AWS account (by starting a session, running a command, or using any other method to execute code on EC2 from the AWS account), then you should be able to see suspicious activities that are connected to Sessions Manager in the CloudTrail logs. This is true for both attack scenarios.

Recommendations

1. It is highly suggested that you revisit this option if the SSM agent was added to the allow list in your anti-virus or endpoint detection and response solutions. Due to the fact that the SSM agent may have been compromised, as was previously mentioned, it is no longer reliable to depend exclusively on the allow list. As a result, removing the SSM binaries from the list of those that are allowed is strongly recommended. Doing so enables your EDR solution to carry out a comprehensive investigation and analysis of the behavior of these processes, seeking actively for any indicators of malicious activity or anomalous behavior that may be present.
2. We propose that you follow the detection approaches that were stated before and integrate them into your SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation, and Response) platforms in order to effectively identify and react to this malicious behavior. Because you have implemented these detections, your ability to proactively look for and identify instances of this threat have been significantly improved.
3. The AWS security team proposed a way to limit the acceptance of instructions from the initial AWS account or organization by using the VPC (Virtual Private Cloud) endpoint for Systems Manager . Like this you may guarantee that the EC2 instances will only react to instructions that come from principals inside their original AWS account or organization by carrying out the steps outlined in this section.