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

[LaurentG]

No, I do think even 1 second that the script can be dangerous, the problem is not at all there...

You submitted the script to Microsoft, and they declared it was safe, and updated their detection rules to do not have the script detected.
But you forgot one (very important) point : Following Microsoft update, the script is actually no more detected as TrojanDownloader:HTML/Adodb.gen!A when loaded,
but continue to be detected as Trojan:VBS/Mountsi.A!ml at run !!
This means that even after been recognized as a false positive by Microsoft, it continue to be not usable !

So, let me sum up the situation.

1) I wrote myself a script, that is 100% safe without any possible discussion.
Nevertheless, Defender considers it as containing
- TrojanDownloader:HTML/Adodb.gen!A when it is loaded
- Trojan:VBS/Mountsi.A!ml when it runs.

This is typically a "false positive", which is per se acceptable : All antivirus have "false positive"

2) If we create an "Exception" on the script (or on the containing folder) in Defender's parameters, this removes the first detection (TrojanDownloader:HTML/Adodb.gen!A at load) but do not remove the second one (Trojan:VBS/Mountsi.A!ml at run).
Despite this "exception", script continue to be un-usable.

3) You proposed me (and I warmly accepted) to send the script to Microsoft as "false positive".
MS agreed with the fact that it is a false positive, and Defender's rules have been updated accordingly.
But (even after receiving and updated Defender to latest rules), if this update done by MS removes also the first detection (TrojanDownloader:HTML/Adodb.gen!A at load), it does not remove the second one (Trojan:VBS/Mountsi.A!ml at run).
Despite Microsoft agreement and update, script continue to be un-usable.

4) The ONLY solution to be able to use the script would be to accept, as you showed it 3 or 4 posts above, the threat Trojan:VBS/Mountsi.A!ml
But as I showed you (and you eventually agreed with me), such exception decreases the global scripting detection...

This was my initial assumption, in my 1st post, when I started this thread.... We are still at the same point

Hopefully, rewriting completely the script, and in particular splitting it in two scripts, I've been able to avoid Defender's detection, and if I still cannot run my initial script, I'm at least able to run another couple of scripts that do the same job. Thanks to this re-writing, I'm not blocked.

But this re-writing is not always feasible (in particular if you haven't written the initial script yourself)

So, since you seem to have good and efficient relationship with Microsoft's teams, couldn't you explain them the problem, and ask them to create in Defender, a new kind of "Exception" in which absolutely no detection could not occur any more, neither at load, nor at run, when a script (or an exe) having this kind of "super exception" runs.
Of course, to declare such a "super exception" would remain 100% under user responsibility.
But if he/she is sure (and I'm sure in case of my script), why do not allow him/her to take such a responsibility ?

Like in Defender, in AVAST too, there are also two kinds (and maybe more...) of detection : static (at load) and behavioural (at run).
And I agree it's great to do not have only static detection, but also at run, based on what script or exe actualy does.
But contrary to Defender, in AVAST, if you have set an exception on your script (or program), it is completely excluded of any kind of detection : static AND behavioural.

With my proposal (if you send it to Microsoft and they accept ), Defender would become even better, with two levels of exception : one for static detections, and one for "at run" detections.... Would be great !

 

[Andy Ful]

But you forgot one (very important) point : Following Microsoft update, the script is actually no more detected as TrojanDownloader:HTML/Adodb.gen!A when loaded,
but continue to be detected as Trojan:VBS/Mountsi.A!ml at run !!

Not on my computer. I do not exclude this script in any way and I can run it without blocks, with one exception. Sporadically (usually when I run this script the second time) it is blocked for unknown reason as Trojan:VBS/Mountsi.A!ml. Did you remove the dynamic signatures as was suggested by Microsoft analyst (see the post https://malwaretips.com/threads/how...t-as-containing-a-threat.107234/post-935002)?

So, since you seem to have good and efficient relationship with Microsoft's teams, couldn't you explain them the problem, and ask them to create in Defender, a new kind of "Exception"

I do not have any relationship with Microsoft, except submitting my applications for whitelisting. You can easily have the same relationship.

With my proposal (if you send it to Microsoft and they accept ), Defender would become even better, with two levels of exception : one for static detections, and one for "at run" detections.... Would be great !

I am not sure if I would like to try improving Defender by supporting the ideas of other people. I am here because you had a problem and I was curious how it can be solved. Anyway, I do not have time for that (I am focused on improving my applications).

 

[Andy Ful]

@LaurentG,

I retested the script today and it is again blocked by AMSI-based detection Trojan:VBS/Mountsi.A!ml. This detection reappeared again when I resubmitted the script to remove another AMSI-based detection Trojan:O97M/Mountsi.D!.
It seems that Microsoft has a technical problem with the effective whitelisting of AMSI-based detections, even when they accept that the file is not malicious. For curiosity, I will resubmit the script last time.
Here is my question included in the submission:

"This file was already submitted 3 times Submission ID: 20b966a5-96e8-4b0e-8eed-81dff67d19ad, Submission ID: ac783499-ad48-42fe-8d8b-2a674ef0e13f and Submission ID: 9644028f-e75f-4f10-b26f-dabdcb60bb43. The first submission should remove the detection TrojanDownloader:HTML/Adodb.gen!A. The second and third submissions were claimed to successfully remove the post execution AMSI-based detections Trojan:VBS/Mountsi.A!ml and Trojan:O97M/Mountsi.D!. Unfortunately the script is still blocked by Trojan:VBS/Mountsi.A!ml even after removing the dynamic signatures and updating the signatures. Is there any technical reason which prevents effectively remove this false positives? "

 

[LaurentG]

Did you remove the dynamic signatures as was suggested by Microsoft analyst

No, I didn't catch it. But I just did it, and unfortunately, it doesn't change anything...

Sporadically (usually when I run this script the second time) it is blocked for unknown reason as Trojan:VBS/Mountsi.A!ml

For me it's a little bit more than "sporadically". I would say once every 3 to 5 run.
But if this could be acceptable for a manually launched script, it is not for a script launched in the background thanks to TaskScheduler.

I do not have any relationship with Microsoft

Too bad, I was hoping so.... It surely would have helped !

Anyway, I do not have time for that (I am focused on improving my applications)

I can understand !

I think we'll be obliged to stop there, unfortunately without satisfying solution.
Nevertheless, once again, tank you for your participation in this thread. It was really interesting to exchange with you !

 

[Andy Ful]

For me it's a little bit more than "sporadically". I would say once every 3 to 5 run.
But if this could be acceptable for a manually launched script, it is not for a script launched in the background thanks to TaskScheduler.

I think that such behavior is not acceptable. I resubmitted the script again for curiosity:
https://malwaretips.com/threads/how...ipt-as-containing-a-threat.107234/post-935454

 

[LaurentG]

I was not so wrong when I said you have good relationship with Microsoft

Your question to MS is clear.... and their answer will be very interesting !

 

[Andy Ful]

I made some tests. The initial script is undetected by AMSI-based models when using the below command:
Set XHR = CreateObject("WinHTTP.WinHTTPRequest.5.1")
instead of the original command:
Set XHR = CreateObject("Msxml2.ServerXMLHTTP")

 

[LaurentG]

Yes, you're right, I just did the test and I have the same.
This is very strange.... and make me even more doubtful than before on accuracy of AMSI-based detections of MSDefender....

I don't remember exactly why I'm using "Msxml2.ServerXMLHTTP" rather than "WinHTTP.WinHTTPRequest.5.1"
As far as I remember, in the past, my scripts that dowloaded files from Internet were using "Msxml2.XMLHTTP" (not serverXMLHTTP...) , and some other were using "WinHTTP.WinHTTPRequest.5.1". But I got some problems (I don't remember at all which ones). And it is on some forums that I found it was preferable to use "Msxml2.ServerXMLHTTP". Indeed, this solved al my issues..... until this script (but at this time, I was not using MSDefender, but AVAST, as antivirus).
And to be honest, I do not have any idea on the difference between these various solutions Msxml2.ServerXMLHTTP/ Msxml2.XMLHTTP / WinHTTP.WinHTTPRequest.5.1

Anyway, if I didn't have found a solution to have my script working, your test could be one. But since it's OK splitting the script in two sub-scripts...
Moreover, this kind of solution could help, but wouldn't be the answer to the initial question I ask with this thread : How to prevent efficiently Defender from considering a given VBS script as containing a threat ?

We've seen that there is no solution for threats detected by AMSI-based models... except maybe to send a request of "False positive" to MS.... provided MS give a really positive answer to the question you sent them yesterday....
I'm looking forward to getting MS answer....

 

[Andy Ful]

I made some tests and found some bugs in the way how Defender manages threats via Security Center. Some scripts are blocked by AMSI-based models without any alert, even from the scripting engine.
Now I use a simple test-script:

urlsource = "https://sample-videos.com/img/Sample-jpg-image-100kb.jpg"
Set WshShell = WScript.CreateObject("WScript.Shell")
targetfolder = WshShell.ExpandEnvironmentStrings("%userprofile%\\Downloads\\2021\\")
downloadpath = targetfolder & "temp.jpg"

Set fso = WScript.CreateObject("Scripting.FileSystemObject")
If not fso.FolderExists(targetfolder) Then
    fso.CreateFolder(targetfolder)
End If

Set XHR = CreateObject("Msxml2.ServerXMLHTTP")
On Error Resume Next
With XHR
'    .setTimeouts 15000, 15000, 15000, 15000
    .Open "GET", urlsource, False
    .Send
End With

Set Stream = CreateObject("ADODB.Stream")
With Stream
        .Type = 1
        .Open
        .Write XHR.ResponseBody
        .SaveToFile downloadpath, 2
        .Close
End With
Set Stream = Nothing
Set XHR = Nothing
Set fso = Nothing

WshShell.run """C:\Windows\notepad.exe"""
Set WshShell = Nothing

It simply downloads the JPG from URL (different from yours) to the folder %userprofile%\Downloads\2021\, and runs Notepad. If the JPG is downloaded but Notepad is not executed then it is the sign of AMSI-based post-execution detection.

After some tests, I can say that I do not like the way how Defender manages these detections. They were introduced in the year 2020 and will require many improvements.
Anyway, I did not see that Avast would use post-execution AMSI-based detections. If I correctly remember it only uses AMSI for pre-execution behavior detections. Defender script detection without AMSI-based post-execution detections is similar to Avast and can be stronger after enabling Defender ASR rules.

 

[LaurentG]

I can say that I do not like the way how Defender manages these detections

Me too... but maybe not for the same reasons than you ! (for me, it's the unability to bypass them)
If even you who are (a lot...) more "expert" in security than me (it's easy ) do not like it, more this time for the "good reason"... is is not reassuring for me !

Anyway, I did not see that Avast would use post-execution AMSI-based detections

No idea bout that. To be honest, I didn't ever heard about AMSI before this discussion.
The only thing I know about AVAST is that there are (at least) two kind of detections : one at loading the script, one "behavioural" at running it. And sometimes a kind of "Sandbox" in which it tests some programs it doesn't know before giving its "Go" (or not, sometimes....) after the test. And this is reassuring for users like me....

PS : FYI I've not been able to receive the e-mail with your post above : it has been detected an trap by Defender, as containing TrojanDownloader:HTML/Adodb.gen!A....
On the other hand, no issue when I go to your post directly on the forum, with Firefox.

 

[LaurentG]

BTW, it's also something I strongly disagree, the fact that Defender prevents loading of an e-Mail (in POP) only because it contains the text of something that could be, if the text was put in a script to be run, could be a Trojan Downloader.
It was NOT even a script in attachment, it was only plain text in the middle of an e-mail !
And in more, in this particular case, it was not even the text of a potential trojan downloader.... since it was your example.

I think that on all these examples, Defender is A LOT AND A LOT too much invasive.... and then not "trustful"

 

[Andy Ful]

BTW, it's also something I strongly disagree, the fact that Defender prevents loading of an e-Mail (in POP) only because it contains the text of something that could be, if the text was put in a script to be run, could be a Trojan Downloader.
It was NOT even a script in attachment, it was only plain text in the middle of an e-mail !
And in more, in this particular case, it was not even the text of a potential trojan downloader.... since it was your example.

I think that on all these examples, Defender is A LOT AND A LOT too much invasive.... and then not "trustful"

It seems that this detection tries to fight any scripting code that wants to download something and run anything. It is invasive but safe for most home users because many malware samples try to do it.
In enterprises, people use the Defender ATP paid version instead of Defender free and this version has an excellent Security Center, so managing such detections is not a problem for administrators.
Home users who use such scripts can remove the detection (TrojanDownloader:HTML/Adodb.gen!A) by submitting the file to Microsoft. The detection name is rather informative:
TrojanDownloader:HTML ---> download something from the Internet,
Adodb ----> download via ADODB.Stream object.

To this point, I like the way how Defender works. But, then the script is detected at the runtime by AMSI-based post-execution models. This detection is troublesome if cannot be whitelisted. It seems that Microsoft has a technical problem with it, so far.

 

[Andy Ful]

I think that we can close the thread. Although I submitted the script 4 times, the AMSI-based post-execution detection is still not whitelisted.

So my final answer to the OP question is as follows:

1. Submit the script to Microsoft for whitelisting.
2. If the script is still blocked, then split the script into 2 or more scripts.
3. If points 1 and 2 do not solve the problem then exclude the detection - remember that in the case of AMSI-based behavior detections this can have an impact on the script detection. So, it is recommended to enable Defender ASR rules for additional ani-script protection. If necessary, then make the ASR exclusion for this script.

Update
I had to stroke out the above info, because after additional emails and inquiry Microsoft finally solved the problem with whitelisting and excluding the AMSI-based detections.

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

No, I do think even 1 second that the script can be dangerous, the problem is not at all there... You submitted the script to Microsoft, and they declared it was safe, and updated their detection rules to do not have the script detected. But you forgot one (very important) point : Following...

malwaretips.com

 

[LaurentG]

OK with you to close the tread.
But just before closure,

It seems that this detection tries to fight any scripting code that wants to download something and run anything.

According to me, this is a lot too much.

I could agree if it was "fight any scripting code that wants to download something and run IT (what it just downloaded) just after"
Or maybe "fight any scripting code that wants to download something and run something, identified in such a way that Defender CANNOT KNOW what is launched to be run"

But surely NOT "fight any scripting code that wants to download something and run just after a completely different exe whose name is given in clear"
In particular when this exe is part of Windows, like Notepad in your case.

And also OK to "fight any scripting that...." but surely NOT to "fight any text file that is NOT a script and cannot run as is, even if this text looks like the source code of a script that...."
like it did, preventing me to get your e-mail.... BTW, an e-mail I cannot receive, by definition, I cannot submit it to Microsoft....

Maybe see you again in another discussion...
Regards

 

[Andy Ful]

OK with you to close the tread.
But just before closure,

According to me, this is a lot too much. ...

Yes. It should be improved, like many other things in Defender. It is not perfect, for sure.

And also OK to "fight any scripting that...." but surely NOT to "fight any text file that is NOT a script and cannot run as is, even if this text looks like the source code of a script that...."

TXT file with scripting code can be run by the scripting engine. For example, Wscript interpreter can run any TXT file with an additional switch. It is a common technique to download malicious code in TXT file (or file with another extension). Generally, non-invasive anti-script methods are not effective due to the diversity of scripting attacks. I usually recommend even more invasive anti-scripting methods, like blocking scripts by default and whitelisting only a few trusted scripts (SRP, AppLocker, Defender Application Control).
Be safe.

 

[Andy Ful]

The happy ending.

I was not impressed by the inability of whitelisting the script via standard submission. Furthermore, the exclusions of scripts were too general and after excluding one script other different scripts were also excluded (even when they used different URL in the script). So, I found another email address to Microsoft Defender Response which I used a few years ago to solve a problem with Hard_Configurator. I send the full information about a problem related both to whitelisting and exclusions. I was asked to do some diagnostics and upload the diagnostic file mpsupportfiles.cab.
After one day I was informed by Microsoft that the problem is finally solved with the new security intelligence update version 1.333.1190.0.
I checked it on my computer and both whitelisting and exclusions finally work as they supposed to work.

 

[LaurentG]

Hi Andy,

I just did the test, and I confirm it's OK now, at least for this script.

To be very specific :
- In the exact script you uploaded to Microsoft, MS Defender do not detect any more any threat (neither TrojanDownloader:HTML/Adodb.gen!A nor Trojan:VBS/Mountsi.A!ml.), and this without any exclusion / whitelisting defined.

- In "similar" scripts obtained by slight modifications of the "original" script
- MS Defender continue to detect TrojanDownloader:HTML/Adodb.gen!A, but, as it was already the case before, this detection can be bypassed with Folder (or file) exclusion.
- MS Defender do not detect any more Trojan:VBS/Mountsi.A!ml. even if there is no exclusion defined

This means that fix provided by MS with the new security intelligence update version 1.333.1190.0. (and above) enhances AMSI-based detections and avoids (at least) THIS specific "false positive" detection.

Nevertheless, the remaining question is : what would happen if AMSI-based threat was still detected ? And what will happen when such a detection will occur "erroneously" for a completely different script ? Will it be possible to "exclude it" for these scripts only ?
Let me remind you that this was the initial issue I raised with this thread : Ability to exclude A GIVEN SCRIPT from AMSI-based detection without excluding ALL AMSI-based detection.

And since these scripts are no more detected with AMSI-based detections, we still cannot answer definitely to this question.

Nevethless, there is at least one question we've been answered : It's now clear that you have very good relationship with Microsoft

 

[Andy Ful]

Hi Andy,
...
Nevertheless, the remaining question is : what would happen if AMSI-based threat was still detected ? And what will happen when such a detection will occur "erroneously" for a completely different script ? Will it be possible to "exclude it" for these scripts only ?
Let me remind you that this was the initial issue I raised with this thread : Ability to exclude A GIVEN SCRIPT from AMSI-based detection without excluding ALL AMSI-based detection.

And since these scripts are no more detected with AMSI-based detections, we still cannot answer definitely to this question.

Nevethless, there is at least one question we've been answered : It's now clear that you have very good relationship with Microsoft

It seems that the problem of exclusions was also solved. I tried it on similar scripts that are detected by AMSI-based modules. For example, after changing the URL the previously excluded script is blocked again.
Before the fix, the AMSI-based detections were rather experimental and did not use the full power of machine learning. That is a common problem with machine learning - it often uses "shortcuts" to achieve the goal.

 

[LaurentG]

I have not been able to create a script detected by AMSI-based module, and then to verify how to exclude it.
I started from the initial script, and changes both the URL to download, and he .exe to run after download, but if the TrojanDownloader:HTML/Adodb.gen!A continue to be detected, the Trojan:VBS/Mountsi.A!ml. is NOT. While, to be sure, I have removed the exception, and rather considered as "allowed threat" TrojanDownloader:HTML/Adodb.gen!A (It is not what I would do in real life, but for the tests)

I'll "cross the fingers" and hope that you're right when you are optimistic....

 

[Andy Ful]

I have not been able to create a script detected by AMSI-based module, and then to verify how to exclude it.
I started from the initial script, and changes both the URL to download, and he .exe to run after download, but if the TrojanDownloader:HTML/Adodb.gen!A continue to be detected, the Trojan:VBS/Mountsi.A!ml. is NOT. While, to be sure, I have removed the exception, and rather considered as "allowed threat" TrojanDownloader:HTML/Adodb.gen!A (It is not what I would do in real life, but for the tests)

I'll "cross the fingers" and hope that you're right when you are optimistic....

Even such "invasive" protection like in the Defender case, can be bypassed in many ways (but most malc0ders are too lazy to use them for now). Defender and other AVs simply detect the popular infection vectors, so the infection rate is low. I did not find any popular AV on default settings that had strong anti-script protection.