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.
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.
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.
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.
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.
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).
We see threat actors abusing RMMs in different ways:
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.
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:
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.
Get insider access to Huntress tradecraft, killer events, and the freshest blog updates.
