In a highly interconnected world, remote monitoring and management (RMM) tools are critical to reducing cost and increasing efficiencies. However, these tools pose challenges and even significant risk if not properly managed. Huntress analysts have observed the use of legacy RMM tools in attempts to install ransomware, and have provided insights regarding the overall use of RMM tools by threat actors as a means of maintaining persistence.
As illustrated in Figure 1, the Huntress 2025 Cyber Threat Report provides insight into what Huntress has observed as the top abused remote access tools.
Figure 1: Top abused remote access tools, per Huntress
Looking beyond the Huntress aperture, Figure 2 illustrates, from the 2025 Arctic Wolf Threat Report, that 93.0% of ransomware and data extortion cases were the result of external exposure, with 59.4% of cases being the result of external remote access/RMM tools.
Figure 2: Root causes of ransomware & data extortion IR cases (source: Arctic Wolf)
Critically, this illustrates the challenges associated with interconnectivity across any enterprise environment. However, this is more particularly the case within the managed services provider (MSP) and managed detection and response (MDR) space. For example, Huntress has responded to incidents where the means of initial access was achieved through compromise of a legacy RMM that was in place prior to a business moving to a new MSP.
However, threat actors compromising legacy RMM tools or installing their own RMM once they’ve gained access to an endpoint still doesn’t illustrate the entire picture. Huntress has observed incidents where multiple RMM tools were in legitimate use, sometimes by multiple vendors or service providers. In these incidents, the time it takes to determine the scope of the incident is extended, as such tools often require identification, then retrieval of and detailed examination of individual log files to determine “normal” usage.
Threat actors using RMM tools
Huntress analysts have observed incidents where threat actors have used various means to install RMM tools such as SimpleHelp or Mesh Agent. In some instances, threat actors have accessed endpoints via SMB/RPC or the MSSQL instance to enable RDP or to install other RMM tools.
Incident 1
During an incident identified on 7 Feb 2025, evidence indicated that UltraVNC had been installed on 14 May 2023, and that since that time, it had been subject to brute force password guessing attacks. In fact, the available logs illustrated 2,189 failed login attempts from various public IP addresses. Following the failed login attempts, Figure 3 illustrates a series of successful UltraVNC login/logoff events leading up to and including the date and time of the incident.
Figure 3: UltraVNC logon/logoff events
Note that the final logon session illustrated in Figure 3 lasted less than a minute; however, the investigative timeline illustrated that during that timeframe, the threat actor installed AteraAgent via the following command line:
"C:\Windows\System32\msiexec.exe" /i "C:\Users\<user>\Music\setup.msi"
This event in the timeline was followed by MsiInstaller events illustrating the successful installation of AteraAgent. Shortly after the installation was completed, the file C:\Windows\TEMP\unpack\setup.msi was launched, successfully installing SplashTop Streamer. The SplashTop Streamer installation pointed to a public IP address that was also the source of 168 failed login attempts (per the available logs).
The investigative timeline then showed that at 2025-02-07 05:02:35Z, a successful login occurred to SplashTop Streamer, multiple files were transferred to the compromised endpoint via that connection, and several credential theft tools were run, including mimikatz and the XenArmor browser password recovery tool.
One of the files downloaded to the endpoint was named EreignisseLoeschen.bat, which, in German, refers to “delete events.” This file could not be recovered from the endpoint, but Windows Event Logs were successfully retrieved from the endpoint. As such, it’s unclear exactly what the contents of the file were, but it may not have been executed, as the threat actor’s activities were thwarted before they got to that point in their attack.
In this incident, the threat actor gained access to an endpoint via a legacy RMM, and installed another RMM tool while retaining access to the original initial access vector.
Huntress has also observed incidents where threat actors have installed multiple RMM tools. Yes, you read that right…multiple RMM tools.
Incident 2
During the final week of March 2025, Huntress Security Operations Center (SOC) analysts reported an endpoint on which Akira ransomware had been deployed. An investigation into the incident indicated that three days prior to the incident, a threat actor had accessed the endpoint via RDP that was not protected via MFA, and ran netscan to enumerate endpoints on the network. The investigation revealed that this access originated from a workstation that Huntress had previously observed associated with Akira ransomware incidents.
On the day that the ransomware was deployed, the threat actor accessed the reported endpoint from another legitimate endpoint on the customer’s network, one that did not have a Huntress agent installed, and was therefore not being managed via the Huntress SOC. The threat actor moved laterally between the endpoints via RDP, and within minutes of accessing the reported endpoint, installed the Chrome Remote Desktop Host, RustDesk, and AnyDesk, all in rapid succession.
Shortly after this installation activity completed, the threat actor launched the file C:\Users\<user>\AppData\Local\Temp\AVDefenderUninstall.bat, which appeared (based on subsequent EDR telemetry) to include attempts to remove various security tools. Based on several MsiInstaller messages observed in the investigative timeline, several of these attempts succeeded. Finally, the threat actor launched the Akira ransomware via commands such as the following:
win_locker.exe -remote -n=3 -p=\\192.168.x.x\C$
In this incident, the threat actor took advantage of remote access (RDP) that was widely enabled throughout the infrastructure without the benefit of MFA, and then installed not one, not two, but three different RMM tools.
Conclusion
A solid security foundation starts with an accurate asset inventory, because you can’t secure what you don’t know you have. This inventory consists not only of physical and virtual assets, but also includes the applications that should be (in accordance with the business use) running on the systems.
Once you have an accurate inventory, the next step is to perform attack surface reduction, configuring those systems for resiliency in accordance with their business use. For example, the Bitdefender blog post regarding RedCurl ransomware describes the initial access vector as a phishing email with an attached .img file; when a user double-clicks this file, by default, Windows will automatically mount and open the file, presenting the user with whatever is inside the file. This functionality often has no legitimate business use and poses a risk to the environment; as such, default behavior can be disabled without impacting the overall business function of the endpoint using the method described in the Huntress blog post, “Addressing Initial Access.”
Once these steps have been completed, apply security tooling for the appropriate level of visibility for your organization. EDR and similar monitoring tools should be installed on all endpoints within the infrastructure, as any gaps in coverage leave an opening for threat actors to exploit.
