I read about attackers abusing legitimate MSP360 remote-management software to maintain access and then deploying ScreenConnect as a second remote-access tool. That got me thinking about how organizations handle this in practice.
If your environment already relies on remote administration tools, how do you distinguish an expected RMM installation from an attacker installing another legitimate tool? Do you block unapproved RMM software by default, alert on new installations, maintain an allowlist, or mainly rely on EDR? I'm still fairly junior and would appreciate examples of controls that work in real environments rather than just sounding good in theory.
5 Answers
A practical starting point is to inventory every remote-access application currently installed, decide which ones are actually needed, and monitor for changes. Custom detections or scripts can flag tools such as AnyDesk, ScreenConnect, or other RMM agents, while firewall rules can restrict connections to the approved service domains. Blocking everything unfamiliar is useful, but make sure your process handles software updates so a legitimate signature or installer change does not cause a major outage.
Some EDR platforms now have specific controls for unauthorized RMM activity. Those can identify that a remote tool is present but not connected to your approved deployment or management environment. That is useful when simply blocking the product name would also break a tool you legitimately use.
A list of vendors and domains can be helpful for an initial blocklist, but it should not be the whole strategy. Attackers can use renamed binaries, compromised accounts, or a tool that is already approved. Combine network restrictions with application control, EDR telemetry, installation alerts, and regular review of which administrators are allowed to deploy remote software.
Use layered controls instead of relying on a single product. Block known unwanted RMM tools at the web and endpoint layers, alert on new software installations and remote-access processes, and configure EDR to prevent tools that your organization does not use. Keep an eye on tools such as TeamViewer, Quick Assist, AnyDesk, and similar products because attackers frequently abuse legitimate remote software.
Even built-in tools need attention. A legitimate remote-help feature may still have tenant or identity restrictions worth testing, rather than assuming it can only be used by your own administrators.
The strongest approach is usually an allowlist. Define exactly which remote tools, versions, installers, domains, and management tenants are approved, then block or alert on everything else. Application control such as AppLocker can help, but building the initial rules takes time and you’ll need to account for updates and legitimate exceptions.
That makes sense. I was especially wondering whether allowlisting can distinguish our approved instance of a tool from someone installing another copy of the same signed product.
This is the key distinction: knowing that a signed ScreenConnect binary exists is not enough. You also want to verify its deployment source, tenant, server, certificate, configuration, and expected user or device.