RMM Guard - Approved Paths Clarification
in progress
N
Nathan
Wouldn't it make more sense to approve tooling based on hash vs "approved installation paths"? For example, a common method for TA is using a trojanized installer from a valid (compromised) source, and installing to a standard location on endpoint. If I approve the install location, then doesn't that open up a potential method for TA to drop into an "approved" location to bypass this tool?
Chris Bisnett
marked this post as
in progress
Chris Bisnett
I think this is a place where our UI doesn't give enough details. We always allow and block RMMs based on the signing certificate or the file hash for unsigned files. What that means is that if ScreenConnect is not allowed, we'll block it no matter where it's run from. But, if ScreenConnect is allowed, by default it could run from anywhere. This is how Application Control generally works. The problem with this approach, is as you pointed out, attackers can run ScreenConnect from anywhere (downloads, temp, etc.) and it would be allowed. So the question then becomes, how do we allow ScreenConnect, but only the one used by the customer?
Our answer to that is to have the customer specify the path where they install ScreenConnect. This way we can only allow ScreenConnect when run from that location and nowhere else. So we need the path where you install ScreenConnect so that we can use that for the allow. Our system will pick up the paths where we saw matching RMM binaries and will provide those as suggestions. If you install ScreenConnect there, then an attacker would have to overwrite ScreenConnect (which you can't on Windows if the executable is running) to be able to bypass the deny policy.
I'm going to update the Approve/Reject flow a bit anyway, but I'll make sure this is spelled out a bit better so that users understand what they are approving and how it works.