LiveGuard can automatically block a suspicious file but cannot upload it to the cloud

[AnthonyQ 49]

1 hour ago, Marcos said:

That's most likely because the file is already detected. Make sure that you have aggressive detection set for "malware" category:

38816055042a3693ff846a391e8280f800d06a3c49ca0181ab0f99d99db48b09.exe - ML/Augur trojan

Also it's detected upon execution with real-time protection disabled:

No ML detection on my PC... Detection engine has been set to Aggressive for Malware. 

Also, after manual submission to LiveGuard, it seemed to tell my that this file is safe to open...

[itman 1,718]

3 hours ago, AnthonyQ said:

I just downloaded a sample from MalwareBazaar (MD5: dc55c31f417efc2fa4d421a16277e3b1) which is undetected by ESET's scanner, using Edge's bulit-in download function. 

No Eset detection consistency here!

When I downloaded and unzipped the archive, Eset detected locally with a suspicious detection:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
8/17/2022 9:18:39 AM;Real-time file system protection;file;C:\Users\xxxxxxx\Downloads\38816055042a3693ff846a391e8280f800d06a3c49ca0181ab0f99d99db48b09.exe;Suspicious Object;cleaned by deleting;xxxxxxxx;Event occurred on a new file created by the application: C:\Program Files\7-Zip\7zG.exe (DF22612647E9404A515D48EBAD490349685250DE).;2700583D7C38E75B1D37AF9B2EB02E5E71DA4E58;8/17/2022 9:18:24 AM

Also, there was no LiveGuard or LiveGrid submission on this one as evidenced by no Eset Event log entries created. All my Eset real-time settings are set to Aggressive.

Now an Eset suspicious detection is MSIL/xxxxxxxxxxx sig. based. Assumed here is this was a LiveGuard cloud blacklist detection.

Edited August 17, 2022 by itman

[itman 1,718]

I will also note that as far as sample from MalwareBazaar (MD5: dc55c31f417efc2fa4d421a16277e3b1) goes, Eset suspicious detection is "spot on" detection-wise. Only 4 vendor detection's for it at VT with CloudStrike's sandbox giving it a 60% confidence factor although it did rate it as malicious. As such, I am surprised Eset quarantined the file at all.

[itman 1,718]

1 hour ago, AnthonyQ said:

No ML detection on my PC... Detection engine has been set to Aggressive for Malware. 

Also set Suspicious detection's to Aggressive mode.

As I posted previously, I have all settings set to Aggressive mode and this has caused no problems on my Win installation.

[Marcos 5,158]

1 hour ago, itman said:

When I downloaded and unzipped the archive, Eset detected locally with a suspicious detection:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
8/17/2022 9:18:39 AM;Real-time file system protection;file;C:\Users\xxxxxxx\Downloads\38816055042a3693ff846a391e8280f800d06a3c49ca0181ab0f99d99db48b09.exe;Suspicious Object;cleaned by deleting;xxxxxxxx;Event occurred on a new file created by the application: C:\Program Files\7-Zip\7zG.exe (DF22612647E9404A515D48EBAD490349685250DE).;2700583D7C38E75B1D37AF9B2EB02E5E71DA4E58;8/17/2022 9:18:24 AM

It was detected by LiveGrid as Suspicious object. The system is dynamic, it wasn't previously detected this way but as ML/Augur.

1 hour ago, itman said:

Also, there was no LiveGuard or LiveGrid submission on this one as evidenced by no Eset Event log entries created. All my Eset real-time settings are set to Aggressive.

It wasn't submitted to LiveGuard because it was already detected as ML/Augur. It wasn't submitted to LiveGrid either because LG already received it from someone else and refused it.

If you temporarily disable the ESET LiveGrid reputation system for a test and re-scan the file, it should be detected as ML/Augur.

[itman 1,718]

11 minutes ago, Marcos said:

It was detected by LiveGrid as Suspicious object. The system is dynamic, it wasn't previously detected this way but as ML/Augur.

Yes, understood.

Although I believe the Suspicious detection is correct here, there is a risk to the average user. He might decide that the file is OK and remove the file from Eset quarantine and override Eset detection for it.

Since Eset has determined the file to be malicious, that is the detection that should be returned versus a suspicious verdict.

[Marcos 5,158]

"Suspicious object" is a detection of blacklisted files or files with a blacklisted DNA hash.

 

 

[itman 1,718]

2 minutes ago, Marcos said:

"Suspicious object" is a detection of blacklisted files or files with a blacklisted DNA hash.

Again, I realize that as I previously posted.

I recommend Eset change the detection to what it actually is - "file malicious - blacklisted."

[New_Style_xd 69]

I agree, this makes it better for ordinary users to understand that it is safer.

[itman 1,718]

Eset would "do itself a big favor" if it added "consistency" to LiveGuard processing. This in itself would alleviate the majority of the forum's never ending postings on LiveGuard operational status and functionality.

Let's take for example this sample from MalwareBazaar (MD5: dc55c31f417efc2fa4d421a16277e3b1). Eset did initially submit this file hash to its cloud for current whitelist/blacklist status. For the average user, it doesn't matter how this was done. Eset should just alert and log the file was submitted to LiveGuard. If the file has been whitelisted, Eset shows the Safe verdict popup (optional) and creates a corresponding Event log entry to that effect. Tip - if the current LiveGuard processing submission alert clearly stated that you will not be notified if the file is safe would eliminate a lot of confusion.

Now these ML/Augur cloud blacklist detection's are a bit more difficult. But nonetheless since the origin of detection (blacklist) is cloud based, Eset should show the detection alert and subsequent log entry creation in the LiveGuard context and not local based real-time scanning.

Or, since the whitelist/blacklist cloud lookup is also applicable to other Eset products, just show the submission as a LiveGrid one.

Bottom line - what we currently have here is a clear example of an interface designed by security developers w/o any end user feedback and input as to its usability.

Edited August 17, 2022 by itman

[AnthonyQ 49]

15 hours ago, itman said:

No Eset detection consistency here!

When I downloaded and unzipped the archive, Eset detected locally with a suspicious detection:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
8/17/2022 9:18:39 AM;Real-time file system protection;file;C:\Users\xxxxxxx\Downloads\38816055042a3693ff846a391e8280f800d06a3c49ca0181ab0f99d99db48b09.exe;Suspicious Object;cleaned by deleting;xxxxxxxx;Event occurred on a new file created by the application: C:\Program Files\7-Zip\7zG.exe (DF22612647E9404A515D48EBAD490349685250DE).;2700583D7C38E75B1D37AF9B2EB02E5E71DA4E58;8/17/2022 9:18:24 AM

Also, there was no LiveGuard or LiveGrid submission on this one as evidenced by no Eset Event log entries created. All my Eset real-time settings are set to Aggressive.

Now an Eset suspicious detection is MSIL/xxxxxxxxxxx sig. based. Assumed here is this was a LiveGuard cloud blacklist detection.

Yeah. An analyst has added a detection for the file in question. Maybe I should set detection engine to Aggressive for other kinds of threats to ensure ML-based detection can be properly triggered next time.

[New_Style_xd 69]

9 hours ago, itman said:

Eset would "do itself a big favor" if it added "consistency" to LiveGuard processing. This in itself would alleviate the majority of the forum's never ending postings on LiveGuard operational status and functionality.

Let's take for example this sample from MalwareBazaar (MD5: dc55c31f417efc2fa4d421a16277e3b1). Eset did initially submit this file hash to its cloud for current whitelist/blacklist status. For the average user, it doesn't matter how this was done. Eset should just alert and log the file was submitted to LiveGuard. If the file has been whitelisted, Eset shows the Safe verdict popup (optional) and creates a corresponding Event log entry to that effect. Tip - if the current LiveGuard processing submission alert clearly stated that you will not be notified if the file is safe would eliminate a lot of confusion.

Now these ML/Augur cloud blacklist detection's are a bit more difficult. But nonetheless since the origin of detection (blacklist) is cloud based, Eset should show the detection alert and subsequent log entry creation in the LiveGuard context and not local based real-time scanning.

Or, since the whitelist/blacklist cloud lookup is also applicable to other Eset products, just show the submission as a LiveGrid one.

Bottom line - what we currently have here is a clear example of an interface designed by security developers w/o any end user feedback and input as to its usability.

I agree with you when you talk about this: I agree with you when you talk about this: