Advice Request How to prevent efficiently Defender from considering a given VBS script as containing a threat

[Andy Ful]

The script is also blocked by Defender ASR rules. After splitting the script into two scripts, these scripts are allowed both by AMSI and ASR rules.

 

[Andy Ful]

Final determination - not malware:

I followed the instructions to remove dynamic signatures and update:

Finally, run the script. This time it was allowed to run (no TrojanDownloader:HTML/Adodb.gen!A detection). Unfortunately, after downloading the photo, the script has been blocked by Defender, although Defender did not show the alert this time. The below alert is from Windows Script Host:

Translation from Polish: "This script contains malicious content and has been blocked by the antivirus program".

I checked the detection: Trojan:VBS/Mountsi.A!ml
I will test it tomorrow because the update of AMSI-paired ML signatures/rules can be updated by Microsoft later.

 

[LaurentG]

Thanks for all your tests !

It will be very interesting also to see what happens if the script remains "functionally" the same, but is "technically" modified. Eg. by moving the order of some lines, modifying the name of some variables, etc..., in order to know HOW Microsoft has removed the detection : Is it ONLY for this EXACT script, or is it more "general"

 

[LaurentG]

Hi Andy,

I just did a quick test this morning with VirusTotal.
I have submitted THREE versions of the same script.
The ONLY difference between the 3 versions is that
- I have moved the order of some variable initializations in the top first 10 lines in second version,
- and in more changed the name of the objects : XHR -> XHttpReg, WshShell -> WSHRun in the 3rd one.

As a result, the three scripts are the same, but since they do not have the same SHA256, they are analysed 3 times separately.
And what is fantastic is that we do not have the same result !!!!!

Here are the three VirusTotal URL :

VirusTotal

VirusTotal

www.virustotal.com

VirusTotal

VirusTotal

www.virustotal.com

VirusTotal

VirusTotal

www.virustotal.com

In particular, Microsoft Defender sees again the TrojanDownloader:HTML/Adodb.gen!A except in the first version, the one you submitted as "false positive".

My conclusion : All the AV that give the same result for the three are maybe good analysts (and maybe not), but those that do not even give the same result cannot be trustful !
Only McAfee, Nano and Rising, plus of course the 50+ AV that say (and it's the reality...) that there is no threat in the script, are then "credible"
In particular, for this reason, I'm now very reluctant to keep Microsoft Defender.... How to be confident ?

 

[Andy Ful]

@LaurentG,​

My conclusions are totally different.

1. AV can detect these scripts as malicious and most AVs cannot.
2. AV does not detect the whitelisted script as malicious and still detects the modified scripts as malicious.

The above points are welcome when protecting against malicious scripts. If VirusTotal detections were correct (and confirmed for many samples) then Defender would be more secure than most AVs. Of course, the VirusTotal detections are not the same as on the client machines, so we cannot say on the basis of such a test that Defender can protect better than most AVs.

Defender is known for strong and restrictive protection against scripting, so there can be some problems not from the security point of view but for usability. Some legal scripts (like yours) can be false positives. Most AVs are not so restrictive, so they do not block your scripts. Some of them use very restrictive methods only for obfuscated scripts.

Edit.
The differences in the protection of popular AVs are negligible in the home environment. Any test made by the home user (despite the result) cannot prove anything interesting due to a small number of samples. If you would like to see something interesting then you should test several thousands of samples per week.
So, do no focus on Defender, you can choose any popular AV that you like.

The best Home AV protection 2019-2020

Real-World tests include fresh web-originated samples. Malware Protection tests include older samples (several days old) usually delivered via USB drives or network drives. Real-World 2019-2020: SE Labs, AV-Comparatives, AV-Test (7659 samples in 24 tests) -------------------Missed samples...

malwaretips.com

 

[Andy Ful]

Because, the AMSI-paired ML still blocks the script I resubmitted it to Microsoft and asked to remove the Trojan:VBS/Mountsi.A!ml (AMSI-paired ML) detection. After several hours this detection was removed, but the script is now blocked by Trojan:O97M/Mountsi.D! (another AMSI-paired ML detection).

Anyway, some interesting conclusions can be made:

1. Submitting the script to Microsoft can rather quickly remove the Defender antimalware detection. The same can be done locally by excluding the script via Security Center.
2. The procedure from point 1 cannot automatically remove the detections made by AMSI-paired ML and ASR rules.
3. In some cases removing one of AMSI-paired ML detections does not remove other AMSI-paired ML detections.
4. ASR exclusions do not remove non-ASR detections.

 

[LaurentG]

Defender is known for strong and restrictive protection against scripting

Another point that makes me doubtful with Defender (and is about scripts) is the following : The Anti-ransomware protection of Defender prevents scripts to modify files in protected folders, that is OK.
But if you want to create an exception (because you have a script you want to allow).... with Defender you are obliged to create an exception on wscript.exe.... which means that ANY script becomes allowed.... which means that there is no more any anti-ransomware protection, as soon as ransomware uses script technology.

While with Avast, you have to put an exception script per script, and then to allow a specific script do not become a full breach.

So, I can agree with your analysis (at least some parts of it). Nevertheless, a big concern with Defender (IMHO) is that it is not "specific enough" when you create exceptions :
- it was my initial problem : I wouldn't care that Defender "detects" Trojan:VBS/Mountsi.A!ml in my script, if I were able to put an exception ONLY for my script, and not be obliged to put a global exception on any Trojan:VBS/Mountsi.A!ml
- and this second point with Anti-Ransomware protection against malicious scripts

For me, the main problem with Avast which makes me still a little bit hesitant to use it again is the fact they have been told recently to be SELLING privacy data of their users.
Do you know if this is still the case, or did they go back on this point ?

PS : Thank you for your link , I'll have a look on it.

 

[harlan4096]

Here are the three VirusTotal URL :

VirusTotal

VirusTotal

www.virustotal.com

VirusTotal

VirusTotal

www.virustotal.com

VirusTotal

VirusTotal

www.virustotal.com

I have sent 2 of those 3 scripts to Kaspersky, and in both cases, the final verdict from the analyst was "No malicious..."

 

[Andy Ful]

Another point that makes me doubtful with Defender (and is about scripts) is the following : The Anti-ransomware protection of Defender prevents scripts to modify files in protected folders, that is OK.
But if you want to create an exception (because you have a script you want to allow).... with Defender you are obliged to create an exception on wscript.exe.... which means that ANY script becomes allowed.... which means that there is no more any anti-ransomware protection, as soon as ransomware uses script technology.

While with Avast, you have to put an exception script per script, and then to allow a specific script do not become a full breach.

You are not obliged to use scripting when managing files in the protected folders. If you cannot skip scripts for that then you can use Windows built-in solutions like ASR rules or SRP-based (Applocker or Defender Application Control) solutions to block/whitelist scripts. Of course, you can also use another AV or dedicated 3-rd party anti-ransomware solution.

So, I can agree with your analysis (at least some parts of it). Nevertheless, a big concern with Defender (IMHO) is that it is not "specific enough" when you create exceptions :
- it was my initial problem : I wouldn't care that Defender "detects" Trojan:VBS/Mountsi.A!ml in my script, if I were able to put an exception ONLY for my script, and not be obliged to put a global exception on any Trojan:VBS/Mountsi.A!ml
- and this second point with Anti-Ransomware protection against malicious scripts

It seems that AMSI-paired ML detections are just like other behavior-based detections. Excluding one script should not exclude the modified script. I will try to test it to be sure.

For me, the main problem with Avast which makes me still a little bit hesitant to use it again is the fact they have been told recently to be SELLING privacy data of their users.
Do you know if this is still the case, or did they go back on this point ?

I do not know. For me, it would not be a problem.

 

[LaurentG]

I have sent 2 of those 3 scripts to Kaspersky, and in both cases, the final verdict from the analyst was "No malicious..."

I know they are not malicious. I wrote them myself....

But the topic we discuss on this thread is not : is this script malicious or not, but rather : How to do with Defender when it considers it (erroneously) as malicious, and this without creating a large breach that would put the Pc at risk.

Clearly, the answer is : There is no solution in Defender other than
- to get a "False Positive" verdict from Microsoft, and removing the script from Defender's detection (quite "huge" process...)
- reorganize the script (inc. splitting it in several scripts).... when it is possible....

This is for me a strong limitation to Defender...

 

[Andy Ful]

...

But the topic we discuss on this thread is not : is this script malicious or not, but rather : How to do with Defender when it considers it (erroneously) as malicious, and this without creating a large breach that would put the Pc at risk.

Clearly, the answer is : There is no solution in Defender other than
- to get a "False Positive" verdict from Microsoft, and removing the script from Defender's detection (quite "huge" process...)
- reorganize the script (inc. splitting it in several scripts).... when it is possible....

This is for me a strong limitation to Defender...

The whitelisting made by the Microsoft analyst strongly suggests that AMSI-paired ML detections are just like other behavior-based detections, as @struppigel suggested (I will make an additional test to confirm this). From your own test, it follows that whitelisting one script (antimalware detection) does not whitelist the modified scripts. From my tests, it follows that whitelisting one of AMSI-paired ML detections for the same script does not automatically whitelist another possible AMSI-paired ML detection.
Furthermore, your scripts are also blocked by ASR rules. ASR exclusions also do not automatically whitelist modified scripts.

Anyway.
It is true that many commercial (paid) AVs can provide a more flexible way of anti-ransomware protection than Defender on default settings + Controlled Folder Access. So, if you need more flexibility you can use one of them or learn to use Windows built-in security.

 

[LaurentG]

It is true that many commercial (paid) AVs can provide a more flexible way of anti-ransomware protection than Defender

What I mention about AVAST for anti-ransomware is in the free verssion, not in the paid...

BTW, I've been a little bit surprise that you consider as a "no-problem" the fact that Avast could sell privacy data of its users.... For me it's a HUGE problem.
I would say that nowadays, this kind of behaviour (to sell user's privacy data) is one of the MAJOR problem of software industry. It is for me a blocking point against Chrome vs Firefox, in the field of browsers... (In the case of chrome, and thus Google, I think they don't sell them, but they use them for their own profit : the problem is not the selling in itself, but the fact to collect and use these data in a profit perspective)

 

[Andy Ful]

What I mention about AVAST for anti-ransomware is in the free verssion, not in the paid...

So, choose Avast. You know well its pros and cons.

BTW, I've been a little bit surprise that you consider as a "no-problem" the fact that Avast could sell privacy data of its users.... For me it's a HUGE problem.

I did not say that it should not be a problem for you.
I did not also say that I accepted what Avast did.
You can look at this thread:

Advice Request - AVAST/AVG trustworthy again or not?

Do you consider it ok to install and trust AVAST and or AVG again at this point or not and why? Thanks!

malwaretips.com

 

[LaurentG]

Thank you for all your advices.
Right now, I'll stay with Defender, since my main "operational" problem is solved, thanks to script splitting... and since I'm a little bit lazy....

And in case I have another problem, ... I'll see ....

In the mean time, I'lll read the documentation you send me

Bye, and have fun !

 

[Andy Ful]

In my case Defender often does not show the alert on AMSI based detections, but such an alert shows the scripting engine like in the post:

Advice Request - How to prevent efficiently Defender from considering a given VBS script as containing a threat

The script is also blocked by Defender ASR rules. After splitting the script into two scripts, these scripts are allowed both by AMSI and ASR rules.

malwaretips.com

Anyway, the AMSI-based detections are still visible in Security Center (Threat history). One can reach the Threat history like in the below article:

View Protection History of Windows Defender in Windows 10

Recent versions of Windows 10 come with an app called Windows Security. Formerly known as "Windows Defender Security Center", this application is intended

winaero.com

In the case of the script in OP the actual detection on my computer looks like:

 

[LaurentG]

OK, thanks for your answer.
Like in your own testing, in my case also Defender often did not show the alert on AMSI based detections, only sometimes (I'd say once out of 3 or 4)

And when it's the case, I got the same messages (except they're in french ).

If you allow (as shown in your screen copy), what I understand and what I experimented is that after excluding this detection, this threat will be allowed for other scripts.
While you write (in the other thread) : it does not mean that after excluding this detection, the blocked script code (like "Wshshell.run") will be allowed for other scripts. It is an important feature because otherwise, such exclusions would decrease the protection.

I fully agree with your conclusion about decrease of protection that could generate....

So the (very important) question is :
If we exclude the threat (as you show it just above, and as I did it), will this threat Trojan:VBS/Mountsi.A!ml be allowed for other scripts ?

As I write above, my personal experience is that the answer is Yes (after allowing it, I never got it anymore, not only running the original script, but even in slightly modified copies of the original script, that BOTH raised this detection before allowing the threat, until I remove the allowance/Exclusion).
And if I'm right, as you say "such exclusions would decrease the protection."

But maybe I'm wrong ? Are you sure that this exclusion do not have such consequence ?

Thanks in advanced for your advice !

 

[Andy Ful]

Are you sure that this exclusion do not have such consequence ?

Yes, I am sure. AMSI-based detection does not make an exclusion for the command "Wshshell.run" in your script. It does not block this command but simply interrupts the script execution at that moment, because this command increases the suspiciousness above the detection threshold (like the last straw that breaks the camel's back). The interruption is also caused by the sum of all suspicious features that happened before "Wshshell.run" command.

If you split the script into two scripts (in a smart way) then the suspiciousness is divided between these scripts. So, the suspiciousness of each script is far below the detection threshold, and "Wshshell.run" command can be executed (also the commands after it) - the script execution is not interrupted.

After making AMSI-based exclusion, the script is still monitored and evaluated. But, the Defender machine models use different evaluation criteria (as compared to the non-exclusion case) and can recognize that your modified script is not malicious. You should not be surprised because your brain is able to do it, too.

The AMSI-driven detection includes features extracted from the script content by machine learning, partial fuzzy hashes, etc. Additionally, it can use metadata and other signals like file age, prevalence, or behavior-based script logs. At the runtime, the behavior monitoring can also extract the set of libraries, COM objects, and function names used by the script.
All of this and more can be used to classify the script as malicious or not.
Of course, it would not be wise to exclude detections of dangerous scripts used in the wild. This could decrease the detection of other malicious scripts.

Post was edited a few times to make it more informative.

 

[LaurentG]

Thanks a lot for very detailed explanation.... but I'm still not convinced.

Sorry to be so insistent, but please let me explain once more my fear. Maybe with these latest explanations, you'll be able to reassure me better.

I never imagine that the "Wshshell.run" in itself would be excluded. It's NOT my purpose.
But if I do what you show it in your post above, afterwards, if I click on
Windows Security / Virus & Threat protection on "Allowed threats"...

...I can see that the Trojan:VBS/Mountsi.A!ml is now "identified as threat which [you] I allowed to run on [your] my device".
Not in the script where it has been detected last time, but "generally speaking".

The best "proof" is that it is no more detected in NONE of the two scripts that were blocked before.

And if, in this screen, I click on "Don't allow", then both scripts become again blocked....

It's the reason why I remain convinced that excluding such threat decreases the detection of other malicious scripts.

 

[Andy Ful]

I never imagine that the "Wshshell.run" in itself would be excluded. It's NOT my purpose.
But if I do what you show it in your post above, afterwards, if I click on
Windows Security / Virus & Threat protection on "Allowed threats"...

It's the reason why I remain convinced that excluding such threat decreases the detection of other malicious scripts.

Understand. Yes, such exclusion can decrease the scripting detection if it was done for the dangerous script, especially when used in the wild. That is why I suggested you rather split the script to avoid detection. But, as you concluded by yourself you do not think that this particular script is dangerous and it was not used in the wild (it is your own script). I submitted this script to Microsoft and the analyst also thinks so.
If you do not believe the Microsoft analyst and think that your script can be dangerous anyway, then do not exclude it.

Edit.
It is probable that the cumulative effect of excluding many different scripts could make an impact on post-execution script detection. To avoid this, one should try to submit all excluded scripts to Microsoft. After submitting, they are often used to learn Defender models to improve the detection (minimize the false-positive rate without decreasing malware detection).

 

[Andy Ful]

@LaurentG,

Please note, that any test with modified scripts (string modifications) will be irrelevant. Such modifications are a kind of script obfuscation and AMSI-based models are used to ignore such modifications. But, if you will obfuscate the script by the method used in the wild then other behavior-based models can classify it as highly suspicious.