Picture the master key your help desk carries. You hand it to your own technicians every day, so when it turns a lock at 2 am nobody flinches. Now picture a stranger holding an identical key, walking the same hallways, opening the same doors, signing the same logs. That is RMM abuse.
The tool you sanctioned vs the tool that is running
Every SMB I talk to can name its EDR vendor. Almost no one can name, off the top of their head, every remote access agent allowed to run on their machines. That gap is the whole game.
Remote monitoring and management software is how an MSP keeps a hundred small businesses alive. It pushes patches, fixes printers, and helps with many other operations. It runs scripts at midnight and hands a technician a live screen on demand. It is also, from an attacker’s seat, close to a perfect weapon. It is signed and expected. It survives reboots. It carries file transfer and remote command out of the box. And it produces the exact same telemetry whether the hands on the keyboard belong to your tech or to a ransomware affiliate in another timezone.
The numbers back the worry. RMM abuse showed up in more than 60% of ransomware incidents studied in 2024, and nothing about 2026 suggests that line is bending down. Crews like Black Basta and Akira have relied on legitimate remote tools rather than custom malware for years now because malware gets caught, whereas a trusted agent does not.
For MSPs, this is not abstract. Your RMM is your crown jewel and your largest blast radius in one console. For SMBs, it means the friendly remote support window could be the breach. The rest of this is about closing the distance between the tools you approved and the tools that are actually live on your endpoints right now.
The three doorways
There is no exotic exploit here, which is what makes it frustrating. Watch enough incidents, and the same handful of doorways keep repeating.
The first is the access broker. Someone else does the breaking in, then sells a network with a remote agent already planted. The buyer logs into ScreenConnect or Atera and has a full interactive session in seconds. No payload to detonate, no exploit chain, nothing for an endpoint product to flag, because the only thing that happened was a login to software already trusted.
The second is the help desk con, and this one hits SMBs hardest. An attacker phones or emails, posing as IT, or first hijacks a real executive mailbox, then talks a staffer into installing a support tool to fix a problem that does not exist. AnyDesk goes on, the caller reads off a session code, and the wire transfer happens before lunch. Business email compromise crews have turned this into a script. The victim believes they are being helped while accounts payable is being emptied.
The third is the second agent, and this is the one MSPs miss most. You run NinjaOne across the fleet, so your team is conditioned to read remote management traffic as normal. The attacker drops a different tool, maybe a portable build that does not even install, and it hides inside the noise of activity you already accept. A portable build leaves almost nothing in installed programs, so an inventory that only reads add or remove programs walks right past it. Your sanctioned agent becomes camouflage for the unsanctioned one.
What ties all three together is intent laundering. The action on the wire is identical to legitimate work. Signature detection has nothing to sign. Behavior analytics struggles because remote control, file transfer, screen capture, and script execution are literally the software’s job. The attacker is not evading your tools. The attacker is living in the gap your tools were told to ignore.
Case: When the RMM was the whole intrusion
On February 19, 2024, ConnectWise disclosed two flaws in ScreenConnect, versions 23.9.7 and earlier. CVE-2024-1709 was an authentication bypass that scored a flat 10.0. CVE-2024-1708 was a path traversal. It’s named the pair SlashAndGrab, because the whole bypass was appending a slash and any junk text to the SetupWizard.aspx path, which lets an attacker reach the initial setup logic on an already configured server and overwrite the administrator database.
What happened next is the part MSPs need to sit with. ScreenConnect is a remote support staple, often the one box that reaches every downstream client. Once attackers owned the server, they created their own admin account, uploaded a malicious ASP.NET extension as an .aspx or .ashx file in the App_Extensions folder for code execution, then pulled ransomware installers down with certutil and pinned them in the startup folder so they survived reboots. Black Basta, Bl00dy, LockBit, and a parade of copycats running leaked builders all rode it in. Within a day, scanners counted roughly 3,800 internet-facing instances still vulnerable.
The forensics were small and specific. A temporary User.xml written during the bypass. New .aspx or .ashx files appearing in App_Extensions. certutil reaching out to fetch an MSI. Map it to T1190 for the exploit of the public-facing server, T1136.001 for the rogue admin account, and T1547.001 for the startup persistence. The takeaway is not only to patch faster, but also to patch faster. It is that one trusted remote tool exposed to the internet, the single hinge the whole estate swings on.
For an MSP, the math gets worse as scale increases. Each client may run a different sanctioned RMM, but the attacker uses the same catalog of alternatives against every one of them. Run a hundred tenants, and you are defending a hundred separate baselines against a single shared playbook. Miss the baseline on one tenant, and you have handed an intruder a quiet, signed, proof foothold that looks exactly like the service you bill for.
Defend the baseline, not the binary
The fix is not another detection signature. It is an inventory and a decision.
Start with the question almost nobody can answer cleanly. Which remote access tools are authorized in this environment, on which machines, and run by whom? Write it down per tenant. That list, short and boring, is the single most valuable artifact in this whole problem. Everything not on it is suspect by default.
This is where the LOLRMM project earns its keep. It is a community catalog of remote monitoring tools that attackers have abused, and it documents the parts you can actually hunt on. Executable names and install paths. The domains and ports the agents call home to. Registry keys and log locations. The signing certificates on the binaries themselves. The catalog ships as YAML, exposes a JSON and CSV feed, and bundles detection content you can lift straight into your stack. Pull the domain list and feed it into your monitoring. Watch the wildcards. Plenty of catalog entries are written as a wildcard host, so normalize those to a domain suffix before you match, or you will either miss the call home or drown in false hits.
The detection logic, in plain terms, is a difference query. Take the full catalog of known RMM indicators, subtract the handful your organization actually sanctions, and alert on anything left over that surfaces in process telemetry or DNS. In an identity and audit log pipeline, that means watching for the first appearance of an RMM domain in a tenant that never used it, and for remote tooling tied to fresh OAuth grants or odd sign-ins. A new RMM in an environment is the signal. Authorized minus observed is the gap that bites.
Your sanctioned list is the small subset that gets to live, and everything else is either an alert or a block.
Then turn knowledge into enforcement. Allow your sanctioned tools and block the rest with application control, so a portable AnyDesk on a NinjaOne shop never executes in the first place. Detection tells you it happened. Enforcement means it does not. An SMB should treat any unexpected remote agent as an incident until proven otherwise, not as a curiosity to investigate next week.
Where does this leave you?
Pick one thing to do this week. Build the sanctioned RMM list, per tenant, and get it signed off by whoever owns the environment. Not the full project, not a new platform, just the answer to one question. What is allowed to remotely control these machines?
Once that list exists, the other controls get simple. Hunting has a baseline to subtract from. Application control has an allow list to enforce. Your analysts stop burning two hours per tenant per week chasing remote sessions that turn out to be your own techs.
The attackers have already done their inventory. They know every RMM tool that integrates with your environment, and they have a catalog of them, sorted by which ones get caught and which do not. The only open question is whether you know which ones belong, and whether you find out before an incident forces the answer.
No Slack account needed.
RMM Best Practices
Baseline with Deep Visibility. Query installed agents and signing publishers, then build the sanctioned RMM list per Site, so each tenant carries its own allowed set rather than a single shared assumption.
Detect with STAR. Write custom rules on tgt.process.image.path and src.process.publisher matching the LOLRMM catalog, scoped per Site, so any unsanctioned agent fires on first execution.
Respond automatically. Attach a STAR rule with mitigation set to kill or quarantine, so a portable AnyDesk on a NinjaOne shop dies on launch instead of waiting for the next shift.
Hunt the network. Pivot on event.dns.request and url.address for known RMM domains across all tenants, surfacing the first appearance in a Site that has never used them.
Lock the console. Enforce SSO with MFA and scope RBAC by Site. Restrict remote shell and RemoteOps script execution to named senior roles only.
Kill internet exposure. No on-premises RMM server facing the internet. Patch within hours of vendor release, and front the management plane with VPN or ZTNA.
Explore More Articles in the following link: Research Articles
