Remote Support Tools Are Now a Worm's Favorite Ride

Yes, remote monitoring and management (RMM) tools such as ScreenConnect are increasingly the vehicle attackers use to spread between machines. Not because the software is broken, but because it's already trusted, already installed, and rarely watched closely. The fix is tightening who can install these tools, how they authenticate, and what happens when a new one shows up on a host that never had it before, not banning them outright.

What's actually happening

Instead of dropping custom malware that an EDR agent might flag, attackers who get a foothold on one machine look for a legitimate remote access tool already present, or quietly push one out themselves. Once installed, that tool gives them a signed, whitelisted, admin-level channel that looks like ordinary IT support traffic.

From there, they use the same tool, or the credentials behind it, to jump to the next host, and the next. It behaves like a worm, but it's riding infrastructure your team already approved. That's what makes it hard to catch with signature-based tools alone.

The simplest tell: a remote access tool appearing on a host, or making a new outbound connection, without a corresponding IT ticket. If you can't answer "who authorized this install and why" in under a minute, treat it as an incident until proven otherwise.

Why RMM tools make such a good ride

Three properties make remote support software attractive to an attacker once they're inside:

• They're pre-trusted. Security tools are tuned to ignore known-good remote access software, so it rarely triggers an alert on its own.

• They carry admin rights. Remote support tools are built to let a technician do anything on the endpoint, which is exactly what an attacker wants too.

• They're often multi-tenant. If your remote support comes through an MSP or a shared console, one compromised technician credential can reach every client behind it, not just yours.

Decision rule: if your business relies on a third party (an MSP, vendor, or contractor) for remote support, ask them directly how technician access is segmented between clients and whether MFA is enforced on every login to that console. If they can't answer clearly, that's a real risk, not a hypothetical one.

The checklist: are you exposed right now?

This is doable in an afternoon, not a quarter:

• Inventory every remote access tool with elevated privileges across your endpoints, not just the one you sanctioned, all of them.

• Flag duplicates. If you find more than one remote support tool on a single host, that's a red flag worth investigating immediately.

• Check MFA on every console that can trigger a remote session, your own, and any vendor's.

• Check versioning. Old, unpatched builds of remote access software are a known target; confirm auto-update is on or that patching is tracked manually.

• Confirm alerting exists for new installs of remote access software on any endpoint, and for a single tool connecting to an unusual number of hosts in a short window.

What to fix this week

Once you know what's on your fleet, the hardening is straightforward:

• Pick one sanctioned tool and block everything else at the endpoint level using application control or your EDR's allowlist feature.

• Require phishing-resistant MFA on every account that can initiate a remote session. This is the single control that breaks the "steal a technician credential, ride it everywhere" pattern.

• Alert on new installs of remote access software as a standing rule, the same way you'd alert on a new admin account.

• Segment support access so a support session on one host doesn't implicitly grant reach into your broader network.

• Watch for rapid, sequential connections. One remote tool reaching several new hosts in a short period is the lateral-movement signature, not normal support behavior.

Programs like our managed security service are built around exactly this kind of monitoring: catching the behavior pattern, not just the tool name.

"We can't just ban our remote support tool"

Fair. Most businesses genuinely need remote access for IT support, and ripping it out isn't realistic or necessary. The goal is control, not elimination.

If your remote support comes through an MSP or vendor and they're slow to answer questions about MFA, technician segmentation, or logging, don't wait for a perfect answer before you act. Tighten what you control on your end now: endpoint allowlisting, alerting on new installs, MFA on your own accounts. Treat the vendor's response time itself as a data point. A vendor who can't explain their access controls quickly is telling you something about how they'll respond during an actual incident.

If you suspect a remote access tool has already been used to move laterally in your environment, that's an active incident, not a hardening project. Our incident response team can help contain it before it spreads further.

What this looks like in practice

In one engagement with a venture-backed technology company that had no dedicated security hire, we contained an active intrusion as part of a broader cloud and endpoint security review. This is the kind of situation where knowing exactly what has admin-level access to your endpoints, and how fast you can spot something new, determines whether an incident stays small. You can read more in the full case study. CISA has also published general guidance on the risks of legitimate remote access software being misused, worth a look if you want the broader threat landscape: cisa.gov.

Where to start

You don't need a big program to close this gap. You need a clear inventory, MFA everywhere, and alerting on anything new. If you want a second set of eyes on what's actually running across your endpoints, a free security review is a quick way to find out before an attacker does.