Question Mullvad VPN & Defender ASR question

Please provide comments and solutions that are helpful to the author of this topic.
@simmerskool and @Andy Ful

I have observed Windows Security ASR rules behave "wonky" in virtual machines. As if they live a Microsoft-unintended life of their own.

Just try to use ASR within enterprise or government server VMs. Oh. The. Horror.

One would not expect problems, but there are isolated ones.

If one has to disable certain ASR rules, then it removes a significant benefit of the rules in the first place.

All one can do is report to Microsoft.
 
Often a tmp file will be a package, the package will then be processed and who knows what will be extracted. Or it could be renamed as well. Tmp file can be anything and everything.
Vendors, publishers, have forgotten the art of ensuring that Authenticode is applied and propagated through the entire run sequence - even to *.tmp files.

Even then, all bets are off - properly Authenticoded or not - with a couple ASR rules - especially the one about file reputation less than 30 days and exploitable vulnerable signed drivers.

Vendors, publishers are lazy and don't submit stuff to Microsoft for whitelisting. Who would have guessed? Even if the did, Microsoft can still reply "No. Your junk ain't safe because it can be absued and we consider any abuse an exploit."
 
The answer to your "problem" (solution) is provided in the Windows Security Protection History. Disable this ASR rule.

View attachment 290677


But still, what is being blocked does not happen to 99.999% of other users that have the same rule enabled using Mullvad and Protonmail. To address that issue, you have to decide how you will report to Microsoft - or decide you'll not go through that effort.
sorry if one of my above posts was unclear, I try for clarity but I'm nearly blind in one eye and have fat fingers or too narrow keyboard. Actually -- you say 99.999% do not see this which is why I posted it here in the first place, as I only starting seeing this recently seemed odd at the time. (unclear exactly when I activated that Rule). But several sources say this is correct when that rule is set to "warn" (which I think is default in DefenderUI). (The one time I contacted MS support about 2.5 years ago, they were actually very helpful! ie, helpful with win10 in-place repair) (perhaps the issue is mullvad driver being categorized as a vulnerable signed driver...?? :unsure: )
 
  • Like
Reactions: Trident
Yes, it is that rule for drivers. Did you try the below?
Disable the rule >> Restart Windows >> Run Mullvad VPN >> Enable the rule >> Restart Windows

This ASR rule does not block already installed drivers. But still, installing a vulnerable driver extends the attack surface area. However, it is not as dangerous as in Enterprises.
I will try what you suggest, Disable the rule >> Restart Windows >> Run Mullvad VPN >> Enable the rule >> Restart Windows > I think I had recently install Mullvad, so making more sense (to me)
 
@simmerskool and @Andy Ful

I have observed Windows Security ASR rules behave "wonky" in virtual machines. As if they live a Microsoft-unintended life of their own.

Just try to use ASR within enterprise or government server VMs. Oh. The. Horror.

One would not expect problems, but there are isolated ones.

If one has to disable certain ASR rules, then it removes a significant benefit of the rules in the first place.

All one can do is report to Microsoft.
This was on hardware win10 host, but I think I had recently installed mullvad and that Rule was already set to Warn, and then it persisted. All good info, appreciate the all the replies.
 
sorry if one of my above posts was unclear, I try for clarity but I'm nearly blind in one eye and have fat fingers or too narrow keyboard. Actually -- you say 99.999% do not see this which is why I posted it here in the first place, as I only starting seeing this recently seemed odd at the time. (unclear exactly when I activated that Rule). But several sources say this is correct when that rule is set to "warn" (which I think is default in DefenderUI). (The one time I contacted MS support about 2.5 years ago, they were actually very helpful! ie, helpful with win10 in-place repair) (perhaps the issue is mullvad driver being categorized as a vulnerable signed driver...?? :unsure: )
The issue is an attacker was seen abusing the Mullvad driver to gain high kernel privileges. The rule is designed to block perfectly benign, but abused drivers. So Microsoft is taking measures to block these drivers. The problem with ASR rules is that they are just super generic blocks designed with zero care and zero dwelling on the context (for example a Mullvad-signed application wants to install this Mullvad abused driver). This is how ASR works and it’s why it’s effective because it eliminates loads of ifs and buts that the attackers can step on, to evade detection.

The downside is, it will require poking around and you will be getting these alerts. If you wanna be an ASR user, you gotta get used to that, this will be your ABC. Reporting here and there won’t result in anything, the rule is designed to block abused driver, this driver was abused and is blocked. The rule is working as intended. Even if you manage to get through to someone at Microsoft, they will ask for the setup, they will check the digital signature and once they verify, they will advise you to disable the rule, install and enable again. Other than that, nothing else will happen.

You will have to assess the context yourself (e.g how this driver arrived), did you download something questionable, or is this the Mullvad setup. Instead of the security software doing this assessment, it will now be you.
 
Last edited:
Did you try the below?
Disable the rule >> Restart Windows >> Run Mullvad VPN >> Enable the rule >> Restart Windows
This ASR rule does not block already installed drivers. .
@Andy Ful , YES, this "fixed" it - now opening and connecting Mullvad is NOT triggering this Rule now reset again to Warn after the reboot.
 
@Andy Ful , YES, this "fixed" it - now opening and connecting Mullvad is NOT triggering this Rule now reset again to Warn after the reboot.
If you use SAC you can disable this rule because it includes MS's Vulnerable Driver blocklist as part of its protection. And maybe some other rule(s)? 🤔
 
  • +Reputation
Reactions: simmerskool
sorry if one of my above posts was unclear, I try for clarity but I'm nearly blind in one eye and have fat fingers or too narrow keyboard. Actually -- you say 99.999% do not see this which is why I posted it here in the first place, as I only starting seeing this recently seemed odd at the time. (unclear exactly when I activated that Rule). But several sources say this is correct when that rule is set to "warn" (which I think is default in DefenderUI). (The one time I contacted MS support about 2.5 years ago, they were actually very helpful! ie, helpful with win10 in-place repair) (perhaps the issue is mullvad driver being categorized as a vulnerable signed driver...?? :unsure: )
I assumed that you already saw it, but decided to point it out just to be thorough.