Create Known Good RMM Profiles | Voters

Create Known Good RMM Profiles

Alex Payne

Partners could establish what RMM they use and if another RMM appears on a machine under their management, an alert/isolation could take place. This could prevent an attacker from leveraging what's typically viewed as trusted RMM software as a persistence mechanism other than an autorun.

September 1, 2021

Matthiew Morin (Huntress)

Merged in a post:

Provide functionality for customers to list expected RMMs in their environment.

Mark O'Halloran

I believe having a feature that can help an analyst quickly determine if a RMM is expected is if customers are able to provide a RMM whitelist. I was thinking that this functionality would be similar to the "expected VPNS/countries" in ITDR.

This would help the SOC scope on potential compromises by rapidly being able to identify known good RMM usage and can provide a threat hunting opportunity by hunting for RMMs not on the allow list.

October 13, 2025

Matt Wilson

+1 here. We use NinjaOne RMM + SentinelOne Complete & have ScreenConnect. Attacker used Atera Agent + outdated ScreenConnect calling home to a Netherlands IP. Went undetected for far too long, unfortunately, so no EDR nor WinEvent data to review leading up to and following the breach. :-/

Matthiew Morin (Huntress)

Merged in a post:

Known Good RMM Instances

Ryan Sipes

It would be helpful to be able to add known RMMs in an organization so that the Huntress team has more insight into anomalous RMM installs in co-managed environments. For example, we have a software team that installs CWC/SC across some of our client environments. Being able to add those instances to a whitelist would allow Huntress to know that those CWC/other RMM installs are allowed but any other instances should potentially be investigated/looked at more closely

September 10, 2025

Shawn Weisz

This is a great idea.

Joe Miller

FWIW, I have had Huntress catch known, rogue ScreenConnect instances.

Joel DeTeves

Yes please, RMM's are used by threat actors all the time. We also encounter scenarios where we have to weed through all the RMMs left behind by the old MSPs who often don't remove them cleanly when handing over a client!

Autopilot

Merged in a post:

Specify Primary MSP RMM for Enhanced Threat Detection

Marcel Pawlowski

While working an incident in which a threat actor deployed RMM agents to live of the land, we came to the conclusion that it would probably be helpful to the SOC to have a note on the account of what the RMM solution of the MSP is.

For example, if the MSP uses Kaseya VSA as their primary RMM and Atera agents are deployed unexpectedly or start enumerating a domain remotely, it could be a indicator of compromise as the commands to not originate from the MSP's RMM.

February 3, 2025

Milena Khlabystova

Agreed - and similar situation here. Threat actor deployed MeshAgent to maintain remote access.
Ideally, we would like to see EDR reporting/ alerting on remote access/RMM tools in the same way ITDR reports on VPN usage:
-	Incident is created for any remote access mechanisms/RMM tools installed
-	Ability to whitelist specific tool or instance (e.g. Screenconnect) per machine or per client or per organization
-	Do not necessarily need to isolate the machines if an unapproved remote access solution is found, but this could be a configurable option

Alex Perrot

Great idea. This also needs to support multiple RMMs/tools per organization - for instance, macOS devices may use a different platform than Windows devices within the same organization.

Joel DeTeves

Alex Perrot same here, we use Addigy for our Apple customers!

Talbot Menear

I really like this idea, but I believe it needs the ability to be differentiated by organization where applicable.

→