I read a recent security report about attackers abusing legitimate MSP360 remote-management software to establish persistence and then deploying ScreenConnect as a second remote-access tool. It made me wonder how this is handled in real environments that already rely on remote administration software.
How do you distinguish an expected RMM installation from an attacker installing another legitimate tool? Do you block unapproved RMM applications by default, alert on new installations, maintain an allowlist, or mainly depend on EDR? I'm still fairly junior, so I'm especially interested in controls that work in practice rather than only sounding good on paper.
5 Answers
EDR can be useful when it supports RMM-specific detections or can distinguish your managed instance from another installation of the same signed product. I’d pair that with alerts for new services, unexpected agent installs, unusual parent processes, and outbound connections to unfamiliar control servers. Signatures alone aren’t enough because attackers can abuse the exact same legitimate binaries your administrators use.
We use a self-hosted remote-support platform with a unique domain under our organization’s main domain, and block other remote-access tools through our web security controls. That gives us a fairly clear baseline: connections to the approved service are expected, while other RMM traffic or newly installed agents generate an alert. It still needs occasional maintenance, but it becomes fairly stable once the approved inventory is accurate.
That sounds more manageable than trying to identify every possible RMM product individually. The important part seems to be tying access to your own tenant, domains, and management servers rather than trusting the software’s signature alone.
Blocking unapproved RMM tools by default is a good baseline. Application control through AppLocker or a similar product works well after you’ve identified the applications users actually need, but creating the initial rules can be labor-intensive. Also test the boundaries of approved tools—for example, verify whether a remote-help product only works from accounts in your tenant or could be abused from another tenant.
A practical starting point is to inventory all installed software and remote-management services, then create a short approved list. Alert on new RMM installations, new persistence services, and RMM network activity from machines that should not use it. You can supplement that with a maintained list of well-known RMM products and scripts or firewall rules for tools your organization definitely does not use.
The strongest approach is usually an allowlist: explicitly approve the RMM products, installers, domains, and management infrastructure your organization actually uses, then block or alert on everything else. Application control tools such as AppLocker can help, although building and maintaining the rules takes time. It’s also useful to monitor common RMM products you never use, since attackers frequently rely on legitimate tools such as TeamViewer, Quick Assist, AnyDesk, or ScreenConnect.
Exactly. We had a legitimate ScreenConnect update trigger EDR because its signature changed, so you need a process for validating vendor updates and tuning the detection rather than simply disabling it.