ESET LiveGrid problem for non premium products

[AZ Tech 32]

For users who do not have a premium product (Products that do not have LiveGuard feature), I have noticed the following:

Some malicious files that are detected and blocked by LiveGuard are not detected either by LiveGrid or by database updates even after a few days of discovery.
Example : Attached sample - password 123

Note: Even for users with LiveGuard, these samples are still treated as new samples (they are sent to LiveGuard for analysis and then detected), As shown in the screenshots, the date the sample was first detected by LiveGuard, and an example from another device a few days later.

It is also noticeable that some samples take a very large time (days) and may not move from the stage of detection through ESET LiveGrid to being detected through databases (unfortunately I do not have an example at the moment, but I am working on it and as soon as possible I will update this topic with an example)

sample.rar

[itman 1,659]

The question is was the file sent to Eset Virus Lab originally? Check your Event log for a like entry:

Time;Component;Event;User
12/30/2021 11:37:40 AM;ESET Kernel;File 'YfTsIBnQ.exe.part' was sent to ESET Virus Lab for analysis.;SYSTEM

[Marcos 5,070]

I guess this is because the sfx archive detonates in the LiveGuard sandbox which, of course, does not happen when scanned locally, e.g. by the on-demand scanner. Malicious files inside the archive should be detected upon extraction.

[AZ Tech 32]

1 hour ago, itman said:

The question is was the file sent to Eset Virus Lab originally?

surely

[AZ Tech 32]

1 hour ago, Marcos said:

Malicious files inside the archive should be detected upon extraction.

Yes, this is true, but the sfx archive itself is a file that can be detected by Hash for example!
There are many sfx archive files detected by eset, so what is the problem here ? Especially since the sfx archive itself is known by eset file reputation system.

[Marcos 5,070]

Threats in the sfx archive are actually detected during an on-demand scan:

keygen-step-4.exe » WINRARSFX » Crack.exe - a variant of Win32/TrojanDownloader.Agent_AGen.M trojan - retained
keygen-step-4.exe » WINRARSFX » RobCleanerSetupie22113.exe - a variant of MSIL/TrojanDownloader.Agent.JVN trojan - retained
keygen-step-4.exe » WINRARSFX » md1_1eaf.exe - a variant of Win32/Packed.NoobyProtect.G suspicious application - retained
keygen-step-4.exe » WINRARSFX » KiffAppE2.exe - a variant of MSIL/Spy.Agent.DNT trojan - retained
keygen-step-4.exe » WINRARSFX » low.exe - a variant of Win32/Kryptik.HNVQ trojan - retained
keygen-step-4.exe » WINRARSFX » pub1.exe - a variant of Win32/Kryptik.HNVQ trojan - retained
keygen-step-4.exe » WINRARSFX » rtst1043.exe - a variant of Win64/Agent.ATS trojan - retained

 

[itman 1,659]

Pondering a bit, I believe the issue here is one that has surfaced numerous times in regards to amateur malware testing.

Upload the sfx archive to a file sharing site. Now download that archive and Eset should detect the malware samples within upon download via its real-time protection.

[Marcos 5,070]

I assume the sfx was downloaded within another password-protected archive which prevented Web access protection from scanning it internally.

[AZ Tech 32]

24 minutes ago, itman said:

regards to amateur malware testing.

What ? amateur malware testing ?
Well guys though I didn't say that it only happens with files of the sfx archive type only, although I did mention that this is just an example and not limited to sfx archive files, even though I was about to give another example The same thing happened to him and this time it's not sfx archive but that's enough, since it's amateur malware tests and since I'm wrong (always) well I'm quitting and I promise that this is the last time I'm online in this forum (I'll leave things to the experts), I apologize for wasting your time with my amateur malware testing .

 

 

2 hours ago, Marcos said:

Threats in the sfx archive are actually detected during an on-demand scan:

Dear Marcos, Thank you for your continuous support, you have all the respect and appreciation, but I'm not stupid for not trying all these things before I talk about them, 
I know that well and I did not limit the problem with this file specifically or even sfx archive files in general. 
It's just a coincidence that the sample I used as an example is a sfx archive, and again I did not say that the problem is exclusively for that file or that type of file. 
what I was saying is that there are files that are detected by LiveGuard (regardless of their type) and are not detected by LiveGrid or database updates and this has happened more than Once for more than one file type. 
and also sometimes some files remain detected by LiveGrid and are not detected by databases after days. This is what I was saying from the beginning.
But instead of us investigating, maybe the guy doing amateur malware testing might have been right (like in the beginning when i reported the LiveGuard delay, you didn't believe me and when you investigated it yourself You found me right), instead we judge people as It's amateurs and inexperienced and we ignore the main topic, well guys again I apologize for wasting your time, I'm leaving here.
Thanks.

[Marcos 5,070]

@itman meant amateurish testers in general. They do not download samples from the original web location but instead download or copy them from a removable medium and thus skip Web access protection, an important protection layer.

However, you download samples from the original locations, typically where malware disguised as cracks is available so Web access protection as well as other protection modules come into play.

We appreciate your efforts in helping. Please do not take the above personally, I'm sure it was not meant like you understood it. We highly appreciate if you report anything suspicious with regard to detection or whatever and we will always be happy to look into it and either clarify why it is so, or we'll try to improve things.

[itman 1,659]

Here's something related.

Thunderbird for some reason was having issues internally updating. Not trusting the internal download option since I have never seen it before, I manually download from the Mozilla web site.

Of interest is this download was a sfx archive:

LiveGuard submitted the download:

Quote

Time;Hash;File;Size;Category;Reason;Sent to;User
1/6/2022 10:51:01 AM;FE2935C9450ED1C4A319CC0D4C28E4D63F1641C9;C:\Users\xxxx\AppData\Local\Temp\ZnYanBiy.exe.part;41494640;Executable;Automatic;ESET LiveGuard;xxx-xxx

But did not block its execution? Also the file size of what was submitted doesn't match the downloaded file size?

Edited January 6, 2022 by itman

[AZ Tech 32]

3 hours ago, Marcos said:

We appreciate your efforts in helping. Please do not take the above personally

Thanks Marcos, I appreciate it.

Regarding the sfx archive , first of all, looking at the attached screenshots, the same sfx archive, once extracted from the zip file, is detected by Kaspersky. It is noted that the reason is cloud protection (a counterpart to ESET LiveGrid),
This is exactly what I demand that all files that are detected by LiveGuard or any other component, 
regardless of the file type, whether it is sfx archive or whatever (what matters that the file is detected as malicious and known by eset file reputation system) should be included in the files that are detected by ESET LiveGrid to other users, then detected by database updates as quickly as possible.
 

5 hours ago, itman said:

Upload the sfx archive to a file sharing site. Now download that archive and Eset should detect the malware samples within upon download via its real-time protection.

What a genius idea !!
I think that someone should tell those responsible for the spread of these malicious files not to publish them as a password-protected archive !!
 

3 hours ago, Marcos said:

you download samples from the original locations, typically where malware disguised as cracks is available so Web access protection as well as other protection modules come into play.

By the way, this is exactly what happened with that sample .

and By the way, this is not malware testing at all !
On the contrary, it's just something I've noticed in normal conditions of use and I hope my request will be of interest to eset because it is in the interest of everyone (expert geniuses and amateurish).

Thanks .

[Marcos 5,070]

While users were protected in this case, I could imagine how this could be misused to evade detection. I've created an improvement proposal for developers who deal with automated detections and blocks so that such files are blocked in LiveGrid.

[itman 1,659]

43 minutes ago, AZ Tech said:

and By the way, this is not malware testing at all !
On the contrary, it's just something I've noticed in normal conditions of use and I hope my request will be of interest to eset because it is in the interest of everyone (expert geniuses and amateurish).

Yes.

Malware can and have been delivered via a password protected archive. The best example would be an e-mail attachment employing a macro or phishing. In either case, user intervention is required via enabling macros in an Office app or by manually entering the password. Excluding e-mail attacks, malware employing use of a password protected download are rare.

[AZ Tech 32]

33 minutes ago, itman said:

Excluding e-mail attacks, malware employing use of a password protected download are rare.

I do not agree with that, for example, but not limited to, most of the ransomware that targets the home users and the most famous and most prevalent is STOP-Djvu ransomware. 
We can say that all infections occur through a fake software or crack, all of them are downloaded in the form of password-protected archive from Malicious sites or advertisement links It redirects visitors of those sites to malware download links.
Thus, it is not correct to say that malware employing use of a password protected download are rare .