Eset Internet Security 14.1.20.0 just started quaratining a .VBS file that I created months ago.

[Ted Harris 0]

Hello,

Eset Internet Security has just started to quarantine a .VBS file that I created months ago.  It says that the virus in the file is VBS/Runner.NOX Trojan.  I excluded the file from detection.  When I run a File Explorer context menu scan, the file is left alone.  When I run a scan on the hard drive itself, the file is quarantined.

This behavior started with detection engine 23295P installed on 5/14.  I am running the latest version of Windows 10 Pro 64 bit.

Your help is appreciated

[Marcos 5,274]

The detection covers VB scripts that load another script from a folder typical for malware, e.g. a subfolder in c:\users plus there are some other conditions for detection. I assume the best course of action would be creating a detection exclusion for the file. You can also report it as per https://support.eset.com/en/kb141 but I'm not sure if we we'll be able to something about it if we don't want to stop detecting actual malware that your file resembles.

[Ted Harris 0]

Hello,

I manually put the file back in the original folder.  After replacing the file several times, I discovered that Eset is deleting the file every time I reboot.

[Marcos 5,274]

You can create a detection exclusion for the file to prevent it from being detected.

[Ted Harris 0]

Hello,

As I said earlier, I created a detection exclusion rule for the file.  On system boot Eset deletes the file.  On full hard drive scan the file is quarantined.

[Marcos 5,274]

Please provide logs collected with ESET Log Collector for a check.

[Ted Harris 0]

Hello,

The .VBS file was in the Users folder.  I created a new folder in the root of my C:\ drive and copied the file there.  I created a new detection rule.  Eset is no longer deleting the file.

 

[itman 1,748]

4 hours ago, Ted Harris said:

I created a new folder in the root of my C:\ drive and copied the file there.  I created a new detection rule.  Eset is no longer deleting the file.

Which means that if malware did the same, it would bypass Eset detection. @Marcostake note.

I am also surprised Eset would throw an alert based on behavior in the original file location scenario. I would think additional file characteristics such as being packed, obfuscated, or encrypted would be secondary characteristics that would factor into the malicious determination. On the other hand if .vbs file execution originated from a MS Office executable; e.g. macro base malware payload, then absolute file blocked and quarantining would be appropriate.

Edited May 14, 2021 by itman