LiveGuard Concerns

[itman 1,542]

ESSP ver. 15.0.21

I created a .exe locally. I then uploaded to a file sharing web site. I then downloaded the file and it ran w/o issue.

The problem is Eset felt the file suspicious enough to send to LiveGrid for further analysis:

Time;Component;Event;User
1/16/2022 2:31:01 PM;ESET Kernel;File 'test(1).exe' was sent to ESET Virus Lab for analysis.;SYSTEM

Time;Hash;File;Size;Category;Reason;Sent to;User
1/16/2022 2:31:01 PM;2E9E7CC7A6D5CD2B0FFFA93A4AE783C68A4C1D6E;C:\Users\XXXXX\Downloads\test(1).exe;157696;Executable;Automatic;LiveGrid®;

The question is why wasn't this file sent initially to LiveGuard and blocked execution until verdict rendered?

Edited January 16, 2022 by itman

[Marcos 4,713]

I assume you didn't download the file from the Internet.

[itman 1,542]

36 minutes ago, Marcos said:

I assume you didn't download the file from the Internet.

Quote

I then uploaded to a file sharing web site. I then downloaded the file and it ran w/o issue.

Also, it is my understanding that LiveGuard scanning is not conditioned upon "mark-of-the-web" status. For example, a .exe could be copied from a USB drive. Or in this case, downloaded as a:

Edited January 16, 2022 by itman

[itman 1,542]

This issue is also occuring on legit app downloads.

Just received a LiveGrid submission on Thunderbird update download:

Time;Component;Event;User
1/16/2022 4:33:07 PM;ESET Kernel;File 'MVA7Yd5A.exe.part' was sent to ESET Virus Lab for analysis.;SYSTEM

Of note is this is a sfx archive and does have the "mark-of-the-web" associated with it:

Edited January 16, 2022 by itman

[New_Style_xd 64]

Here on my pc was also blocked and removed a program that I used ten years ago, and this week ESET removed it. I was thinking, why now?

[AZ Tech 32]

5 hours ago, itman said:

The question is why wasn't this file sent initially to LiveGuard and blocked execution until verdict rendered?

On January 8, 2022 I asked @Marcos the same question when I downloaded this sample through a phishing link, then it was the first time that eset saw this file and it was not detected by Web access protection and the download completed, the problem is that the same thing happened here, it wasn't sent initially to LiveGuard and blocked execution until verdict rendered ,
exactly as what happened with you, but the only difference is that I downloaded the file from its original source as it is designed to deceive the user “and as I usually download the rest of the samples” and the file should inevitably be sent for analysis automatically, of course this did not happen and after several minutes of downloading the file I send it to LiveGuard manually, only then the file was detected .

Unfortunately Marcos ignored my question and didn't investigate it, and I didn't publish it because I know I will be accused by somebody of doing amateur malware testing, so I also ignored it because I didn't find it helpful to share something with a community that would ignore you trying to help everyone and instead From that he will blame you and describe you as doing amateur malware testing even without knowing how you get the samples !! .

[itman 1,542]

13 hours ago, AZ Tech said:

Unfortunately Marcos ignored my question and didn't investigate it, and I didn't publish it because I know I will be accused by somebody of doing amateur malware testing

I see you're still "smarting" from my comment in another thread. So, I apologize. Now let's move on.

[New_Style_xd 64]

Really, this version has a lot of problems with this LiveGuard it's not doing its job right. one hour it does not detect as threat, after few days it detects as threat, and when it detects it takes few minutes.
For example, I went to download a program, then LiveGuard detected it and sent it to the ESET server, but it took a few minutes. why does this take so long? I had to wait and look at the pc. other competitor products do not and that way, things are faster.

[Marcos 4,713]

5 minutes ago, New_Style_xd said:

Really, this version has a lot of problems with this LiveGuard it's not doing its job right. one hour it does not detect as threat, after few days it detects as threat, and when it detects it takes few minutes.
For example, I went to download a program, then LiveGuard detected it and sent it to the ESET server, but it took a few minutes. why does this take so long? I had to wait and look at the pc. other competitor products do not and that way, things are faster.

Please provide more details about this case. Of course, the result of LiveGuard evaluation may change in time since it's a dynamic system and if a new threat is evaluated as clean, it may be evaluated as malware in a few minutes if more data has become available in the mean time.

Quote

For example, I went to download a program, then LiveGuard detected it and sent it to the ESET server, but it took a few minutes. why does this take so long?

Again, I don't understand. A cloud analysis takes 2-5 minutes on average. Did it take 30 minutes? Hours?

[itman 1,542]

15 hours ago, AZ Tech said:

On January 8, 2022 I asked @Marcos the same question when I downloaded this sample through a phishing link, then it was the first time that eset saw this file and it was not detected by Web access protection and the download completed, the problem is that the same thing happened here, it wasn't sent initially to LiveGuard and blocked execution until verdict rendered ,
exactly as what happened with you, but the only difference is that I downloaded the file from its original source as it is designed to deceive the user “and as I usually download the rest of the samples” and the file should inevitably be sent for analysis automatically, of course this did not happen and after several minutes of downloading the file I send it to LiveGuard manually, only then the file was detected .

I just duplicated this by attempting to download from the Github web site and it's of interest on how Eset is presently handing this.

First, the download was detected by Eset Web Access protection;

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
1/17/2022 11:41:45 AM;HTTP filter;file;https://objects.githubusercontent.com/github-production-release-asset-2e65be/415741799/0d35497c-5e47-459d-a8f7-7037a6e7ae52?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A/20220117/us-east-1/s3/aws4_request&X-Amz-Date=20220117T164144Z&X-Amz-Expires=300&X-Amz-Signature=155eccd0e17bc5a9256c58bcf7a5c561f0e0f7ab3bd3829a52c103e654ece7f2&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=415741799&response-content-disposition=attachment; filename=ChromeSetup.exe&response-content-type=application/octet-stream;Suspicious Object;connection terminated;XXXXX;Event occurred during an attempt to access the web by the application: C:\Program Files\Mozilla Firefox\firefox.exe (A56FB4525DA249A093D84260BE60C110D1235204).;C5E1883FC2D3E23BC4D81F1A94F5A58A6F85FA7A;1/17/2022 11:41:45 AM

However, it appears the download was submitted to LiveGuard:

Time;Hash;File;Size;Category;Reason;Sent to;User
1/17/2022 11:42:24 AM;1EC527EAF3F18CBAFFFA637A64CC1B98389B415C;C:\Users\XXXXX\AppData\Local\Temp\mrq7oePo.exe.part;3444590;Executable;Automatic;ESET LiveGuard;XXXXXX

My question is why submit a file to LiveGuard that was previously blocked from being downloaded? Or in this case, the download was not in reality blocked by Web Access protection and this is what was submitted to LiveGuard? Note that this was a silent LiveGuard submission with no "block until scan completed" option.

Edited January 17, 2022 by itman

[Marcos 4,713]

I assume it's because of different hashes, C5E1883FC2D3E23BC4D81F1A94F5A58A6F85FA7A vs 1EC527EAF3F18CBAFFFA637A64CC1B98389B415C

[itman 1,542]

16 minutes ago, Marcos said:

I assume it's because of different hashes, C5E1883FC2D3E23BC4D81F1A94F5A58A6F85FA7A vs 1EC527EAF3F18CBAFFFA637A64CC1B98389B415C

I also noticed that. I also assume that the .part file is exactly that; part of the in-process download.

Assumed is HTTP filtering caught the suspicious code after part of the download occurred. In this case, it would have deleted the in-process .part file. So why submit it again to LiveGuard?

Edited January 17, 2022 by itman

[NewbyUser 71]

https://fileinfo.com/extension/part

.part stands for partially downloaded file

Edited January 17, 2022 by NewbyUser

[itman 1,542]

2 hours ago, itman said:

Assumed is HTTP filtering caught the suspicious code after part of the download occurred. In this case, it would have deleted the in-process .part file. So why submit it again to LiveGuard?

Pondering a bit, I suspect what was submitted to LiveGuard was the rest of the download after the Web Access suspicious code detection. Once that code was detected, real-time scanning of the rest of the download was a moot point. However, the remainder of the code might be contain additional "nasties." Hence, the LiveGuard upload of that code for further analysis. This also points to a distinction between LiveGrid and LiveGuard code upload processing.

BTW - I have never seen a "suspicious" detection originating from real-time scanning. So that is something new.

Edited January 17, 2022 by itman

[AZ Tech 32]

11 hours ago, itman said:

I see you're still "smarting" from my comment in another thread

I apologize for that but I was "upset" not "smarting" .

 

11 hours ago, itman said:

So, I apologize. Now let's move on.

Not a problem, it's fine.

[AZ Tech 32]

9 hours ago, itman said:

First, the download was detected by Eset Web Access protection

Yes, this is the only positive thing about it. The file became detected in ESET LiveGrid after a few minutes and thus became detected by eset Web Access protection and Real-time protection/scanning as "suspicious" ,as shown in the attached screenshot .

Cons :
- The file was not sent to LiveGuard automatically and so far I can't find a logical reason for this to happen and there is no clarification from eset.
- The file was only detected in ESET LiveGrid from January 8, 2022 until January 17, 2022 and now the detection is "BAT/TrojanDownloader.Agent.OMI", and I think that if it wasn't for public discussion, it would have taken more than that .

[Marcos 4,713]

If a file downloaded from the Internet is not sent for analysis in the LiveGuard cloud sandbox and is not whitelisted, most likely it's because the file is already known to ESET (was already scanned locally). Likewise already detected files are not sent either.

[itman 1,542]

12 hours ago, AZ Tech said:

The file was only detected in ESET LiveGrid from January 8, 2022 until January 17, 2022 and now the detection is "BAT/TrojanDownloader.Agent.OMI", and I think that if it wasn't for public discussion, it would have taken more than that .

I agree that keeping a detection in suspicious status for 9 days is unacceptable. A safe or malicious verdict should be rendered by Eset AV Labs within 24 hours at most. Appears this one "fell through the cracks." Does make one question the processing of manually submitted suspect files.

As far as LiveGrid use in the Web Access suspicious detection, it is non-applicable. All LiveGrid is used for is determining running processes reputation status via Context menu option or from the like tool present in the Eset GUI. Also if one of the various Eset detection mechanisms detects suspect activity, then the file is uploaded to LiveGrid servers and forwarded to Eset AV Lab for further detailed analysis. The Web Access suspicious detection originated from a like detection signature Eset created after you manually submitted the sample.

[Marcos 4,713]

1 hour ago, itman said:

I agree that keeping a detection in suspicious status for 9 days is unacceptable. A safe or malicious verdict should be rendered by Eset AV Labs within 24 hours at most. Appears this one "fell through the cracks." Does make one question the processing of manually submitted suspect files.

It was a simple batch file that executed wget followed by a malicious url that had already been blocked before. That also means users could not download the payload with WAP enabled.

I assume that the triviality of the batch file might have contributed to the fact that an automated detection was not generated. We manually analyzed and created the detection yesterday.

[itman 1,542]

54 minutes ago, Marcos said:

That also means users could not download the payload with WAP enabled.

The service only exists in Win 10/11. Most important, it is only running if a wireless connection is used:

[Marcos 4,713]

I meant Web Access Protection which we've had since Windows 95 (IMON).

This was the only malicious file in the package for which a detection has been added. The urls were blocked in November already:

[Marcos 4,713]

I've just checked the sample and found out that LiveGuard blocked it in LiveGrid on
2022-01-08, 03:05 CEST

[itman 1,542]

1 hour ago, Marcos said:

I've just checked the sample and found out that LiveGuard blocked it in LiveGrid on
2022-01-08, 03:05 CEST

I assume this was the result of the the manual submission noted previously:

Quote

On January 8, 2022 I asked @Marcos the same question when I downloaded this sample through a phishing link, then it was the first time that eset saw this file and it was not detected by Web access protection and the download completed, the problem is that the same thing happened here, it wasn't sent initially to LiveGuard and blocked execution until verdict rendered ,
exactly as what happened with you, but the only difference is that I downloaded the file from its original source as it is designed to deceive the user “and as I usually download the rest of the samples” and the file should inevitably be sent for analysis automatically, of course this did not happen and after several minutes of downloading the file I send it to LiveGuard manually, only then the file was detected .

Resulting in the suspicious sig. being generated. At this point, any future download's would have been detected by Eset Web Access protection as I observed.

1 hour ago, Marcos said:

This was the only malicious file in the package for which a detection has been added. The urls were blocked in November already:

This is OK as far as it goes. The download could have been modified since then to use different C&C download servers.

[itman 1,542]

We've got off on a tangent BTW and @AZ Tech original question remains unanswered. That is:

Quote

On January 8, 2022 I asked @Marcos the same question when I downloaded this sample through a phishing link, then it was the first time that eset saw this file and it was not detected by Web access protection and the download completed, the problem is that the same thing happened here, it wasn't sent initially to LiveGuard and blocked execution until verdict rendered ,

@Marcos briefly answered this previously:

7 hours ago, Marcos said:

If a file downloaded from the Internet is not sent for analysis in the LiveGuard cloud sandbox and is not whitelisted, most likely it's because the file is already known to ESET (was already scanned locally).

Translation - this download had been scanned by Eset previously somewhere; deemed safe; and subsequently whitelisted. This also means LiveGuard is not going to protect you from an Eset borked non-detection.

[Marcos 4,713]

So you confirm that the file you tested existed on the disk, ie. it was scanned by ESET before you uploaded it to the file sharing service and then you downloaded it?