MSPs frequently rely on Remote Monitoring and Management (RMM) tools as a way to remotely manage and monitor their customers’ IT environments, including remotely troubleshooting issues. But for threat actors, MSP RMMs are an easy way to remotely access those customer endpoints, achieve persistence in their attacks, and execute commands while flying under the radar.
When threat actors compromise an MSP’s RMM instance, it allows them to cast a wide net across the MSP’s downstream customer base, effectively hitting multiple organizations through one attack. That’s because once threat actors compromise the MSP’s RMM instance, they then have direct access to the MSP’s entire customer base.
The community saw this play out during the infamous 2021 Kaseya VSA supply chain attack. The ransomware attack impacted between 50 and 60 MSPs and resellers, but the brunt of the impact was felt most directly by their customers, which totaled between 1,500 to 2,000 organizations.
It’s been four years since the Kaseya attack, but Huntress continues to see threat actors compromise RMMs in MSP environments to hit multiple customers. Huntress’ Security Operations Center (SOC) analysts recently saw an incident in June, where a threat actor compromised an MSP’s RMM instance, effectively using that instance to target three of its customers before the Huntress SOC was able to isolate the impacted endpoint and work with the partner to remediate the attack.
In this first of a two-part series, we'll go over this incident. Stay tuned for the second part, where we'll dive into a similar incident that we saw.
One RMM compromise, three businesses hit
In two out of the three reported incidents, Huntress saw the SYSTEM account executing a malicious process (net.exe) to add users to the local administrators group via an RMM. In this case, the threat actor had compromised the MSP’s Atera RMM instance. The Huntress agent was only installed on one of the MSP’s endpoints, limiting visibility and understanding into how the RMM was initially compromised. However, Huntress was able to detect the threat actor’s activity across the downstream customers.
Figure 1 illustrates the process chain leading to net.exe, in this case to perform enumeration. As we can see, the process lineage stemmed back to AteraAgent.exe, indicating that the threat actor had likely compromised the MSP’s Atera RMM instance.
Figure 1: This process tree shows the threat actor executed net.exe via the Atera RMM
Across two out of three of the incidents, the threat actor added different users to the local admin group, including msoit, se91, veean, and vnaee. Of note, there was a commonality across the passwords that the attacker used for these accounts (Passw0rd!12 and Passw0rd!21).
Figure 2 illustrates how the attack played out across the three impacted customers.
Figure 2: An outline of the timeline and actions linked to a recent MSP incident
As Figure 2 shows, the threat actor also installed Cloudflared tunnels on all three customers with the same token (as seen by the following command: C:\Windows\system32\cloudflared.exe"tunnelrun–token [REDACTED]).We have seen other incidents where threat actors installed Cloudflared tunnels to set the stage for persistent access.
Closer inspection of the detection timeline for the Cloudflared tunnel service install process (C:\Windows\system32\cloudflared.exe" service install), illustrated in Figure 3, shows that the lineage traces back to the AgentPackageRunCommandInteractive.exe process, linked to the executable C:\Program Files\ATERA Networks\AteraAgent\AgentPackageRunCommandInteractive\AgentPackageRunCommandInteractive.exe. This reveals that the threat actor also installed the Cloudflared tunnel via the compromised Atera RMM instance.
Figure 3: The threat actor installed a Cloudflared tunnel via the compromised RMM instance
This flurry of incidents could have led to further attacks, such as the threat actor performing data theft and/or deploying ransomware. However, Huntress isolated the impacted endpoints before the attacks progressed any further, and advised the MSP to shut down its RMM instance, rotate all credentials, and remove the newly created user accounts. Previous cases (like the 2021 Kaseya incident) show the spiraling and widespread impacts that these types of incidents can have across a wide customer base, with such attacks proving to be difficult to manage.
RMMs and MSPs: Dual targets ripe for threat actors
RMM abuse is a sweet spot for attackers. They can abuse existing commercial tools, meaning they don’t have to waste time and effort internally developing their own toolsets. RMM abuse is also difficult for security teams to identify, especially because many MSPs use them for legitimate purposes in their customers’ environments.
The SOC frequently sees threat actors abusing RMMs. In Huntress’ 2025 Cyber Threat Report, we found that RMM abuse made up 17.3% of all remote access methods (and RMM abuse made up 6.5% of the most common threat categories overall).
Figure 4: RMM abuse made up 6.5% of the most common threat categories in 2024
We see threat actors abusing RMMs in different ways:
- Attackers hijack and use existing software that's already installed on victims’ endpoints. Last year, we saw an incident where the threat actor obtained initial access via a legacy instance of TeamViewer
- They install their own RMM of choice post-compromise, as we saw in a March incident, where a threat actor installed three different RMM tools
- Threat actors have also exploited vulnerabilities in RMMs. We saw this in the Kaseya incident, where the attack vector was a Kaseya arbitrary file upload and code injection flaw
Threat actors are also actively targeting MSPs themselves—in attacks that can involve RMMs—to take advantage of trusted relationships between providers and their customers. These types of attacks can lead to significant risk for MSPs’ customers, like data theft, ransomware, and espionage.
A complete guide to preventing RMM abuse
Businesses can take several steps to defend against RMM abuse. MSPs should be particularly cognizant of their RMM tools, as well as legacy RMMs installed within their customer environments, due to the impacts outlined above.
Here are some measures that can help reduce your risk:
- Audit, track, and monitor remote access tools to keep tabs on currently used or authorized RMM software, so that unauthorized instances stand out
- Mandate that authorized RMM tools be used from within the network, and from approved remote access solutions like VPNs
- Create application controls that cover RMM programs, including ones that block the installation and execution of unauthorized RMM software
- Review logs for instances where RMM tools were executed in order to detect suspicious use of the programs
- Use endpoint detection and response (EDR) tools to help weed out malicious RMM instances from legitimate RMM uses
- Create an asset inventory that includes installed applications (and that accounts for access controls on a continual basis, taking into account changes like if a business moves to a new MSP)
- Update RMM tools to keep up with the latest vulnerability fixes
Want to learn more about threat actor tradecraft like RMM abuse? Join our team each month for Tradecraft Tuesday, where we dissect hacker techniques, talk tech, and more. Sign up today.
