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

[LaurentG]

I have a problem with Defender : it considers a safe script (I know it's safe, I wrote it myself !) as a threat, and I cannot efficiently bypass its "protection" !

This script is downloading a jpeg file from a Web site (this jpeg file is updated once a minute on the web site, it's a WebCam), and launches an external command (jhead.exe) on the resulting file (thanks to WshShell.run command) to set it some EXIF parameters.

First of all, I'm obliged to create a "Defender exception" to the script itself (or to its containing folder), otherwise the script do not even start, because Defender blocks its loading, considering a TrojanDownloader:HTML/Adodb.gen!A threat.
I could also mark this threat as "authorized", but even without doing so, if an exception is defined, the script is not analysed at its loading, and starts.

But at run time, despite the fact that the script is set as an exception, when it comes to the line WshShell.run to launch the jhead.exe command, Defender detects this time the threat Trojan:VBS/Mountsi.A!ml
And I'm obliged to mark this threat as authorized if I want to have this line of the script running (and EXIF data set on the jpeg file).
But I DO NOT WANT to accept this threat in "any circumstances". I ONLY want to that Defender DO NOT consider (falsely) that it is present in my script (where it is NOT).
If I mark it as "Authorized", it won't be any more catched by defender in case another script (I wouldn't have written myself) would actually contain it... and then I wouldn't be any more protected against this threat in a malicious script !

To have defined an exception on this specific script should be enough (and safe).... but it is not enough, and the only solution is NOT safe !

Of course, I can guarantee that the problem is NOT in the jhead.exe, that is 100% safe (and never detected by Defender, nor any other Antivirus), and that I'm using for years without any problem. (Jhead homeage: Exif Jpeg header manipulation tool )
Moreover, I can add also that I have several other scripts I wrote in the past, that are on the same way launching the same jhead.exe command, and that are not considered neither as containing the TrojanDownloader:HTML/Adodb.gen!A when they are loaded, nor running the Trojan:VBS/Mountsi.A!ml when they are run...
I tried also to reorganize a little bit my code, but this didn't solve the issue.

So my question is : Is there a mean to tell Defender : "this script, I'm sure, is safe, let it run", without being obliged to open risk in authorizing a given threat evrywhere ad everytime.

I recently switched from Avast to Defender, on the advice of several other forums that explained it was a lot better, and that Avast was at the origin of a lot of issues...
But I never had such an issue with Avast : when it raises a "false positive", it's enough to create an exception on the .exe or the .vbs and eveything goes well....

Except if there is a solution in Defender to my problem, I think I'll go back soon to Avast....

 

[Andy Ful]

There is nothing wrong with going back to Avast.
The detection Trojan:VBS/Mountsi.A!ml is related to AMSI-paired machine models. It blocks some dangerous code inside the VBS script without blocking the rest of the script. If you allow execution of this dangerous code then it will be also allowed for other scripts (also for malicious scripts).
I do not know the AV which could allow the dangerous code for some selected scripts and would block it for the rest, except maybe the scripts specially whitelisted by the AV vendor.
If you want to use Defender and this script, then you can try to modify the script to avoid AMSI detection.

Post Update.
The final recommended solution:

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]

My problem is that my script do not launch any dangerous code

Here is the part of the script that generate the issue :

LocalFile = subDirPSP & nomPSP & ".jpg"
JHeadcmd = """C:\PortableApps\JHead\jhead.exe"" -mkexif "
Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.run JHeadcmd & LocalFile

The threat is raised while on the WshShell.run

So clearly, I'm not looking for

the AV which could allow the dangerous code for some selected scripts and would block it for the rest

I'm only looking for a way to inform Defender that there is no dangerous code in THIS script.

FYI, here is another (also "home made") script that has NEVER been blocked by Defender, neither at loading, nor at run

Set wshshell = CreateObject("WScript.Shell")
wshshell.Run """C:\PortableApps\jhead\jhead.exe""" & " -q -ft -exonly """ & WScript.Arguments(0) & """", 0, true

Very similar, isn't t ?

So why the first script and not this one ?
I already tried to replace JHeadcmd by its value in WshShell.run, as it is in the 2nd script, but without any success

So I still need community's help !

PS : What I just read about AMSI-paired machine models (I never heard about before) make me even less favourable to make Trojan:VBS/Mountsi.A!ml an "authorized threat" !!!
But I nevertheless need to be able to run my script....

 

[Andy Ful]

I have just run this code on my computer (Defender + advanced settings activated by ConfigureDefender).

LocalFile = subDirPSP & nomPSP & ".jpg"
JHeadcmd = """C:\PortableApps\JHead\jhead.exe"" -mkexif "
Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.run JHeadcmd & LocalFile

The file C:\PortableApps\JHead\jhead.exe has been executed without any problem. I created the folder C:\PortableApps\JHead\ and used a renamed alternativestremview.exe --> jhead.exe .

Edit.
Also, no problem when using the original application jhead.exe.

LocalFile = "C:\PortableApps\JHead\*.jpg"
JHeadcmd = """C:\PortableApps\JHead\jhead.exe"" -mkexif "
Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.run JHeadcmd & LocalFile

I had to change the path to JPG file.

 

[struppigel]

Hello. Please turn to Windows Defender support.
You can submit your script as False Positive here: Submit a file for malware analysis - Microsoft Security Intelligence
They have to take care that the script is excempted from their detection while also protecting from the actual malware scripts.

 

[Andy Ful]

This could help for the first Defender detection TrojanDownloader:HTML/Adodb.gen!A, but whitelisting AMSI detection is another thing. Anyway, it is worth trying.

Edit.
AMSI and AMSI-paired machine models are different things. AMSI is a Windows interface that is available for all AVs. On the contrary, AMSI-paired machine models are specific to the concrete AV which can use AMSI.

 

[LaurentG]

Thank you both for your answers.

I agree with Andy that even if my request of "false positive" was accepted, this would have only effect on TrojanDownloader:HTML/Adodb.gen!A, not on AMSI detection which is, as far as I have understood, a "live detection" based on behaviour.
Moreover, raising such a request needs a Microsoft account, and for different reason, I do not have, and prefer to do not create one.
So I give up wit this "solution".

About the "mini script" I showed, on my Pc also, a script limited to these 4 lines works fine, and is not detected by Defender.
It's actually consistent with the fact that the second script I mention (and that is limited to launching jhead) is OK

But these four lines are inside a more complete script that is running fine without them (except the fact it do not make the full job, not creating the EXIF).
It is only when I add these lines to the main script that Defender raises in it :
- as a Trojan downloader
- and a AMSI threat at run....

I think I'll try to reorganize completely once again my script. Maybe I'll be lucky...
Otherwise, except if some other proposal are done on this forum (or some other where I post the same issue), I'll finish in giving up wiith Defender and returning to Avast or similar...
Too bad, since I was convinced that to add extra softs (like Avast) when (almost) the same in available in Windows is always a bad idea and should be avoided (as far as we can....)

 

[Andy Ful]

Thank you both for your answers.

I agree with Andy that even if my request of "false positive" was accepted, this would have only effect on TrojanDownloader:HTML/Adodb.gen!A, not on AMSI detection which is, as far as I have understood, a "live detection" based on behaviour.
Moreover, raising such a request needs a Microsoft account, and for different reason, I do not have, and prefer to do not create one.
So I give up wit this "solution".

About the "mini script" I showed, on my Pc also, a script limited to these 4 lines works fine, and is not detected by Defender.
It's actually consistent with the fact that the second script I mention (and that is limited to launching jhead) is OK

But these four lines are inside a more complete script that is running fine without them (except the fact it do not make the full job, not creating the EXIF).
It is only when I add these lines to the main script that Defender raises in it :
- as a Trojan downloader
- and a AMSI threat at run....

I think I'll try to reorganize completely once again my script. Maybe I'll be lucky...
Otherwise, except if some other proposal are done on this forum (or some other where I post the same issue), I'll finish in giving up wiith Defender and returning to Avast or similar...
Too bad, since I was convinced that to add extra softs (like Avast) when (almost) the same in available in Windows is always a bad idea and should be avoided (as far as we can....)

You can post the full script here or PM to me. I may test it on my computer and make the corrections.
I will also send it to Microsoft - it would be interesting to see the final effect.

 

[Andy Ful]

...
Too bad, since I was convinced that to add extra softs (like Avast) when (almost) the same in available in Windows is always a bad idea and should be avoided (as far as we can....)

For compatibility reasons, it is better to stick with Defender. But, there can be several reasons to skip Defender for another AV. Avast is a very good solution, too. Did you have any problem with Avast?

 

[struppigel]

I agree with Andy that even if my request of "false positive" was accepted, this would have only effect on TrojanDownloader:HTML/Adodb.gen!A, not on AMSI detection which is, as far as I have understood, a "live detection" based on behaviour.

AMSI is not based on behaviour. It provides the scripts in unpacked form to the antimalware product, so that the usual signature scanning can be applied to it.

However, even if it was behaviour based, a false positive submission still has to be processed and, if verified, remediated. Whether this is done by putting something on an allowlist or modifying the signature or behaviour rules is up to Defender's analysts. Allowlists are usually the last resort.

Moreover, raising such a request needs a Microsoft account, and for different reason, I do not have, and prefer to do not create one.
So I give up wit this "solution".

In that case I don't have any other suggestion. You'd need to be guessing what their signatures detect and change it by trial and error.

 

[TairikuOkami]

AMSI is not based on behaviour. It provides the scripts in unpacked form to the antimalware product, so that the usual signature scanning can be applied to it.

Defender kept asking for every single line of the code in a single file, after about 20 allow, I gave up, and as the result I ended up with unbootable Windows.

 

[LaurentG]

Hi Andy,

here is the full script. There is nothing "private" in it, you can play with it as much as you want. Sorry, but comments are in french...
You can seee also in the script the run of "sticky.exe" : It's a (very good IMHO) program of Sticky Notes, you can find here : Stickies

Keep me informed of your tests, either succesful... or not.

And about your question : No, I have never got any problem with Avast

PS : To avoid any issue when downloading it, I put my script in a .txt file (rather than .vbs)
PPS : I just saw it doesn't prevent Defender to "cry" when downloading it.... Be careful ;-)

 

[LaurentG]

I post you also the previous version of the script : The ONLY difference : this version didn't call jhead, and then didn't put EXIF data
But the MAJOR difference is that this old version has NEVER been detected as a threat by Defender....

 

[Andy Ful]

In many cases, AMSI is a part of behavior detections:

How AMSI helps you defend against malware - Win32 apps

As an application developer, you can actively participate in malware defense. Specifically, you can help protect your customers from dynamic script-based malware, and from non-traditional avenues of cyber attack.

docs.microsoft.com

AMSI can scan the contents of the circular buffer which is different from the content of the script. So it is not clear if whitelisting the script as a file will whitelist AMSI detection too. But, @struppigel is right that it is worth submitting the sample to Microsoft and wait for their answer.

 

[Andy Ful]

I have just had a look at that script. It can be easily used as a trojan downloader. I will try to modify it in the evening. But, it seems that splitting the script into 2 different scripts could help. The first script should download the pictures. The second should execute Jhead and Sticky.

 

[LaurentG]

It was also my idea (to split in two or three scripts)
But I'm afraid that what you propose doesn't solve the problem, since in your splitting, global structure of the 1st script would remain : a download and a run (the run of the second script)

It's the reason why I'll probably have a main script that
1) run a subscript (that only downloads)
2) then run jhead or sticky depending on the fact that the file supposed to be downloaded exist or not (or maybe based on a return code of second script)
With this structure, there is no more any script that includes both a download and a run.

If this not enough, the only remaining solution would to have two completely separate scripts, and to schedule the second a few seconds or minutes after the 1st. But this becomes a bit complex... and a little bit tricky to manage efficiently (in particular to manage all possible error cases)

On the other hand I don't understand when you write :

It can be easily used as a trojan downloader.

To be a Trojan downloader, a script would
1) download a file (the trojan)
2) run the Trojan, ie. the file just downloaded
while this script
1) downloads a file
2) run a completely different executable already present on the Pc before script run : The file downloaded is not the one that is run.

 

[struppigel]

LaurentG I can submit the sample to Defender if you agree.

In many cases, AMSI is a part of behavior detections:

How AMSI helps you defend against malware - Win32 apps

As an application developer, you can actively participate in malware defense. Specifically, you can help protect your customers from dynamic script-based malware, and from non-traditional avenues of cyber attack.

docs.microsoft.com

I think we both mean the same but have different understanding on terminology.

A behaviour based detection for me is one, whose rules are based on behaviour of the sample. E.g., the rule will say: If something downloads a file, puts it to autorun and executes it, this behaviour is defined as malicious. In order for this to work all of these steps until execution will also be done by the sample. This may lead to, e.g., anti-ransomware protection rule only detecting a malware after it has already encrypted some files.

What you probably refer to is that the sample needs to be executed in order for AMSI to work. We call this part dynamic (static is the counterpart with no execution involved). The sample is executed but the detection signatures on them are not behaviour based because they don't care what the sample does. All they care about is the deobfuscated content in memory. These are usually just patterns and they are applied the same to AMSI streams as static signature patterns.

AMSI can scan the contents of the circular buffer which is different from the content of the script. So it is not clear if whitelisting the script as a file will whitelist AMSI detection too.

It won't work for hash based allowlisting. There are different ways to allowlist a file, though. Among others, signatures can be applied. They work just as any other signature on the deobfuscated content, but detect a clean file instead of malicious ones.

 

[LaurentG]

Hi struppigel

if you want (and have time to do so....), pls feel free to submit the script to Defender.
Their answer will be interesting to read....

Or do whatever you want with the script.
As already said, even if it is a script I wrote, there is absolutely nothing "private" in it (only my first name in the D:\Users\Laurent\.... paths)
And the programs that the script call (jhead and sticky) are free softs, open source for jhead (and not for Sticky) but both usage is open and free.

On my side, I have just finished to split my script in two scripts : I have now a subscript that is ONLY in charge to download the file.
It accepts two parameters : the URL, and the filepath to create, and sends a not null Rc in case of any error.

Now the "main" script do not anymore download itself anything, but only
- define the different parameters
- runs the sub-script
- depending on the Rc runs jhead or sticky and log file creation

With this architecture, Defender doesn't see any more any threat, neither at load of the scripts, not at their run time.... while what is run is EXACTLY the same than in previous situation !

So for me, the problem is now closed.

Nevertheless, I'll have a look on the forum, in case you post answers provided by Defender to your "false positive" request.

Thank you to all people who participate in this thread for your participation, your advices, etc...

 

[Andy Ful]

For now:

 

[Andy Ful]

...
It won't work for hash based allowlisting. There are different ways to allowlist a file, though. Among others, signatures can be applied. They work just as any other signature on the deobfuscated content, but detect a clean file instead of malicious ones.

That is the part I am not sure of. That is why I wrote that such files can be specially whitelisted by the AV vendor (standard submission may fail). For example, I submitted one of my executables to Emsisoft and Bitdefender. The executable is whitelisted, so it can be run. But still, some actions are blocked by the Emsisoft behavior blocker and by BitDefender ATP. It seems that in some cases the AV vendor does not want to whitelist globally (for all users) the file and all its actions, but allows the user to exclude unwanted blocks locally.
That is why I am curious what decision will be made by Microsoft in the case of this particular script.

Edit.
The term "AMSI detections" can be misguiding, because AMSI is a monitoring feature (does not detect malicious behavior). I had in mind the behavior-based blocks that use the AMSI-paired machine models. Malicious scripts blocked by AMSI-paired machine models are reported in Microsoft Defender Security Center as follows:

• Trojan:JS/Mountsi.A!ml
• Trojan:Script/Mountsi.A!ml
• Trojan:O97M/Mountsi.A!ml
• Trojan:VBS/Mountsi.A!ml
• Trojan: PowerShell/Mountsi.A!ml