Advice Request ASR Rule: Block executable files from running unless they meet a prevalence, age, or trusted list criteria

[notabot]

There's an ASR rule "Block executable files from running unless they meet a prevalence, age, or trusted list criteria" . I find this quite vague.

This is effectively a form of cloud whitelisting. Per Rule: Block executable files from running unless they meet a prevalence, age, or trusted list criteria · Issue #1593 · MicrosoftDocs/windows-itpro-docs this is controlled by Microsoft.

But is there a place where we can see what's allowed and what's blocked? what are the criteria?

Recently I updated a perfectly legit executable that I need ( the update also being perfectly legit ) and after wasting time on why it didn't work anymore, it turned out disabling this did the trick.

Does anyone have more info on what's in the list, what are the criteria used to enter the list etc?
Also does this even work when offline ?

 

[shmu26]

There's an ASR rule "Block executable files from running unless they meet a prevalence, age, or trusted list criteria" . I find this quite vague.

This is effectively a form of cloud whitelisting. Per Rule: Block executable files from running unless they meet a prevalence, age, or trusted list criteria · Issue #1593 · MicrosoftDocs/windows-itpro-docs this is controlled by Microsoft.

But is there a place where we can see what's allowed and what's blocked? what are the criteria?

Recently I updated a perfectly legit executable that I need ( the update also being perfectly legit ) and after wasting time on why it didn't work anymore, it turned out disabling this did the trick.

Does anyone have more info on what's in the list, what are the criteria used to enter the list etc?
Also does this even work when offline ?

It's pretty much what it says. If a file is prevalent enough, or old enough, it will be allowed. I think that certain sigs are trusted right away, that's the "trusted status" category. This rule produces a very high amount of FPs, because it is actually a soft default/deny setup (when coupled with a decent AV, that is).

 

[Andy Ful]

There's an ASR rule "Block executable files from running unless they meet a prevalence, age, or trusted list criteria" . I find this quite vague.

This is effectively a form of cloud whitelisting. Per Rule: Block executable files from running unless they meet a prevalence, age, or trusted list criteria · Issue #1593 · MicrosoftDocs/windows-itpro-docs this is controlled by Microsoft.

But is there a place where we can see what's allowed and what's blocked? what are the criteria?

Recently I updated a perfectly legit executable that I need ( the update also being perfectly legit ) and after wasting time on why it didn't work anymore, it turned out disabling this did the trick.

Does anyone have more info on what's in the list, what are the criteria used to enter the list etc?
Also does this even work when offline ?

In most cases, the file will be allowed to run offline and after running it once (without disabling WD real-time protection) this ASR rule will not check the file again. Disabling WD real-time protection is not a good idea, because after enabling it again many WD advanced features do not work properly until computer reboot.
If the software is popular then usually after one day or two it is allowed to run.
Disabling the ASR rule is not necessary.

 

[notabot]

In most cases, the file will be allowed to run offline and after running it once (without disabling WD real-time protection) this ASR rule will not check the file again. Disabling WD real-time protection is not a good idea, because after enabling it again many WD advanced features do not work properly until computer reboot.
If the software is popular then usually after one day or two it is allowed to run.

Thanks Andy, I'll give it a few days then and try again, though the binary is already about a month old.

btw I disabled the ASR rule, not WD real time protection. Security is nice but being able to work is nicer.

 

[notabot]

It's pretty much what it says. If a file is prevalent enough, or old enough, it will be allowed. I think that certain sigs are trusted right away, that's the "trusted status" category. This rule produces a very high amount of FPs, because it is actually a soft default/deny setup (when coupled with a decent AV, that is).

Thanks for this. A little more info from MS would had been nice and some configurability, ie a local keystore where I can place a public key and then if I sign executables with it's private counterpart this resulting in whitelisting the executable ( or some other method of manual override for this )

 

[Andy Ful]

Thanks Andy, I'll give it a few days then and try again, though the binary is already about a month old.

btw I disabled the ASR rule, not WD real time protection security is nice but being able to work is nicer.

This ASR rule will produce some false positives by design. But, it is strange that it could block the binary made one month ago. Could you post the link to the updater?

 

[Andy Ful]

@notabot,
If you have run (without blocking) the updater with active WD real-time protection, then this ASR rule should not block it anymore.

 

[Andy Ful]

My freshly compiled applications (before submitting to Microsoft) often trigger the WD ASR rule "Block executable files from running unless they meet a prevalence, age, or trusted list criteria". Sometimes they are also detected as trojans by WD Cloud delivered protection.
I can usually avoid the false positive alarms by running the executables offline, just after finishing the compilation. After this, the file is ignored both by this rule and also by the Cloud delivered protection.

The same can be done for application updaters with very low prevalence, after checking them by other methods to be sure that they are safe.
Otherwise, if the file was run online and was blocked by this ASR rule, I simply turn off the rule, reboot, run the file once, and turn the ASR rule again. The rule requires restarting Windows to work properly again, but the file is ignored afterward.

Normally, there is no need to bypass this ASR rule, just wait a day or two and most updaters will be allowed again.

 

[notabot]

In most cases, the file will be allowed to run offline and after running it once (without disabling WD real-time protection) this ASR rule will not check the file again. Disabling WD real-time protection is not a good idea, because after enabling it again many WD advanced features do not work properly until computer reboot.
If the software is popular then usually after one day or two it is allowed to run.
Disabling the ASR rule is not necessary.

it's Selenium Webdriver for Chrome, Downloads - ChromeDriver - WebDriver for Chrome , there's no installer, upgrading is just a matter of using a new exe. It's actually been half a month, not once month, the next-to-last version is the one that I used

https://chromedriver.storage.googleapis.com/index.html?path=78.0.3904.70/

 

[Andy Ful]

it's Selenium Webdriver for Chrome, Downloads - ChromeDriver - WebDriver for Chrome , there's no installer, upgrading is just a matter of using a new exe. It's actually been half a month, not once month, the next-to-last version is the one that I used

https://chromedriver.storage.googleapis.com/index.html?path=78.0.3904.70/

I tried the new version (published 30.10.2019) and it is currently accepted by this ASR rule. I also changed some bytes of the executable and after this, it was blocked by ASR. I hope that your issue with the previous version was an accident (maybe M$ guys overlooked it).

Edit.
The version published 12.09.2019 is still blocked by ASR. It seems that either some versions have very low prevalence and some not, or the developer submits some versions to Microsoft (from time to time). Another problem can follow from the frequently pushed new versions (two times a month, without submitting to MS) - the files are not signed and not popular, so they cannot get a sufficient prevalence at all.

 

[notabot]

I tried the new version (published 30.10.2019) and it is currently accepted by this ASR rule. I also changed some bytes of the executable and after this, it was blocked by ASR. I hope that your issue with the previous version was an accident (maybe M$ guys overlooked it).

Edit.
The version published 12.09.2019 is still blocked by ASR. It seems that either some versions have very low prevalence and some not, or the developer submits some versions to Microsoft (from time to time). Another problem can follow from the frequently pushed new versions (two times a month, without submitting to MS) - the files are not signed and not popular, so they cannot get a sufficient prevalence at all.

Thanks Andy, the exact version is a given, it needs to match the exact version of installed Chrome so if some versions are blocked by ASR, it becomes a pita.

Is there a way to add exclusions to this specific ASR rule ( eg by path or hash ) ? - that would be an ok solution

 

[Andy Ful]

You can add an exclusion via ConfigureDefender. But, any single exclusion is valid for all ASR rules that allow exclusions. I can recommend creating a special folder in C:\Program Files for executables which do not work well with this ASR rule and add this folder to ASR exclusions.