topic Disable Protection Rule for Remote Initiated Behavioral Threat in Cortex XDR Discussions

Disable Protection Rule for Remote Initiated Behavioral Threat

CJNTS — Thu, 22 Feb 2024 22:12:52 GMT

We are creating a custom service to handle automatically checking and updating programs (similar to PDQ Deploy, or an RMM tool).

We've signed the the created service and tried several ways to disable it from being blocked. The problem is, we are very limited in what we can target with the disable prevention rules.

Has anyone run into this and actually allowed it through. We could change the commands to not trigger the alerts as we can see what triggered them by getting the alert data.

The point is that if we signed what is running, we'd like to be able to build it out without worrying about coding around XDR's every changing (and hard to extract behavioral rules).

We've already attempted to:

allow our signature in a disable prevention rule
allow the ending powershell process with a wildcard cmd line argument

The problem seems to be that the point where the block is triggered happens before the signer is considered. The artifacts show our service as being signed.

Screenshot of causality chain nodes below.

Disable Prevention Rules does not give us any way to address this.

Re: Disable Protection Rule for Remote Initiated Behavioral Threat

jmazzeo — Fri, 23 Feb 2024 13:11:25 GMT

Hi @CJNTS, thanks for reaching us using the Live Community.

Is the powershell script located in a specific folder?

Have you tried with a Legacy Agent Exception for the Behavioral Threat Prevention module which is the one blocking here?

Re: Disable Protection Rule for Remote Initiated Behavioral Threat

CJNTS — Fri, 23 Feb 2024 13:38:51 GMT

We've looked into that, but don't want to take that route.

As we build things out, different scripts will run from the same folder structure. To create this rule, we'd have to make a bunch of exceptions for each file path, or wild card the last piece (script name).

From what I've looked at if we did it this way we wouldn't be able to also evaluate the signer. I think this may work, but it would be creating a bigger hole in protection than we're aiming for.

If I'm wrong on any of that, please let me know. We really want to evaluate based on the signer. If we could consider a wildcard file path AND the signer, this would be a consideration.