itman

The primary purpose of the AV-C Malware Protection test is to determine how AV solutions perform when malware tampers with the installation's network settings; primarily those dealing with Internet access. AV-C deploys a larger malware sample set but the malware is in the known prevalent category.

https://www.av-comparatives.org/tests/malware-protection-test-september-2021/
The problem with this test is it doesn't show offline protection capability. Therefore, no way to ascertain the cloud protection component impact.
-EDIT- Of note is EIS scored second from last place in this test; missing 18 out of 10,029 sample malware.
One could argue that is a respectable score. However, this was not 0-day malware. Rather, it was malware that had been in circulation for a while. Therefore, one could also argue Eset's signature detection ability is slipping of late. This is also strong justification that LiveGuard needs to be included in all Eset home versions.

Kaspersky is one example and it has proven quite effective against 0-day ransomware. By coupling ransomware behavior monitoring with system snapshot taking, Kaspersky is capable of restoring all files encrypted by ransomware.
Also, Kaspersky is not 100% bulletproof in this regard. I have seen a few ransomware that have bypassed its protections. However, they are a very rare occurrence.
It should be additionally noted that it appears Kaspersky has "worked out the kinks" in regards to previous versions system performance impact issues in regards to its system snapshot processing. System snapshot also gives Kaspersky the capability to "rollback" system modifications done by malware. Of note and in reference to postings in the forum Malware section, Eset might detect malware upon execution. However it is powerless to remove system changes performed by the malware prior to discovery. Those changes have to be manually removed.

Then why was it not detected as malicious from real-time protection via Web Access protection?

I have one! I will also comment on @Marcos prior statement on differences between EDTD and LiveGuard.
Besides Eset cloud scanning configuation capability and the optional creation and download of detailed scan analysis report, the main difference between LiveGuard and EDTD is the rendered scan verdict as shown below:
First, note that "Score" column is what is referred to in security analysis as the malware confidence percentage factor. The higher that factor is, the more the likelihood that submitted file is malware. The first thing I conclude from the above is Eset has set a "high bar" for malicious state rating; i.e. 100%. The currently accepted standard for malicious status is =>90%.
The main difference between EDTD and LiveGuard is one will never have a suspicious detection verdict returned by LiveGuard. This is keeping with industry standard practice that end users of consumer AV products do not have the skills to perform the required steps to evaluate a suspicious detection; e.g. above "Recommendations for users with suspicious samples." Also, Eset will get "dinged" on AV lab tests of consumer products for activity that requires user interaction.
Finally, my opinion why the ChromeSetup.exe sample was "missed" when originally scanned by LiveGuard. It's scan verdict was either safe or fell in the "suspicious" confidence range. Appears Eset will treat the "suspicious" category as safe for LiveGuard purposes. When @AZ Tech manually submitted the sample again to LiveGuard, the rating resulted in a "highly suspicious" confidence range verdict. This in turn resulted in the creation of a "suspicious" signature to allow Eset to block any subsequent downloads of the sample via real-time scanning.
As to why LiveGuard subsequently detected the sample, I strongly suspect the primary factor was the C&C servers wget connected to and downloaded the payload from. They were blacklisted by Eset sometime after the initial LiveGuard analysis.

I will also add that this ChromeSetup.exe is a significant malware for detailed analysis.
Elaborating, the malware developer created it specifically to bypass cloud based AV analysis. At the time of initial deployment, the remote download performed was a benign payload. After sufficient wide distribution of  ChromeSetup.exe , the developer switched the download to a malicious version.
Corrective action required to prevent a like re-occurrence. Cloud scanning needs to be performed repeatedly on any download originating from untrusted sources. This means code unsigned; not a trusted Publisher; etc.. And since signed malware has been deployed with valid code signed certificates, determining trust status is iffy at best.
I on the other hand adhere to blocking suspicious behavior whether benign or not; e.g. "cmd /c" use. 

OK. The manual re-scan by @AZ Techresulted in a malicious versus highly suspicious detection. At this point, I would have suspected Eset would have blacklisted it. However, when I ran the sample from its download source:
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;XXXXXXX;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
I received a suspicious detection?

Since I haven't commented on this point, I will now and "it's a no brainer."
In ESSP, there should be no LiveGrid submissions period. If Eset feels the file is suspicious enough to warrant a LiveGrid upload, it should be sending the executable to LiveGuard instead and blocking it until verdict rendered. This also would provide a backup mechanism for a missed LiveGuard submission upon initial file download.
-EDIT- Just read in Eset ETDT documentation that if one is receiving a LiveGrid submission versus LiveGuard submission, it means that the file was previously submitted to LiveGuard.
Looks like my test.exe is indeed a LiveGuard bypass.👍

Since there were some questions about Eset local real-time processing scanning my test.exe in regards to my original posting I started this thread with, I retested using the following procedure:
1. I disabled Eset real-time scanning for my test.exe file by adding an exclusion for it.
2. I modified my test.exe using PowerShell to add some code to the end of the file resulting in the file hash being changed.
3. I uploaded the test.exe to a file sharing web site.
4. I removed the prior created Eset real-time scanning exclusion for the test.exe file along with deleting the file from my hard disk.
5. I downloaded the test.exe file from the file sharing web site. No LiveGuard submission occurred.
6. When I ran the downloaded test.exe, I received notification the file had been submitted by LiveGrid for Eset AV lab analysis and the process executed successfully.
Therefore, I conclude that something else within Eset is triggering an upload to LiveGuard and unknown files are not being submitted as stated by Eset. Or, my .exe as created bypassed LiveGuard processing.

Yes, it is possible ChromeSetup.exe had been previously scanned by LiveGuard. @Marcos already stated that the outbound connections used by it were already blacklisted. However, detection of those malicious C&C servers should have been enough to flag ChromeSetup.exe as malicious. On the other hand, they might not have been detected as malicious at the time ChromeSetup.exe was LiveGuard scannned and LiveGuard gave the process a safe rating.
Taking @Marcos statement at face  value that LiveGuard doesn't condition file uploading on MotW status which I presently don't, do you see wget.exe as a supported LiveGuard/EDTD app?

-EDIT- BTW I downloaded latest ver. of wget from here: https://eternallybored.org/misc/wget/. The sucker is code signed! Created my global OSA block rule. Tested it. Good to go now on this bugger.

Are you using the latest ver. of Antitest?
I downloaded it and on ESSP, it was first caught by LiveGuard,; scanned in the cloud; and deemed safe. The latest ver. is dated 9/16/2021. The fact the .exe was scanned by LiveGuard is indicative of Eset never seeing it previously.
Running Antitest on Win 10 using Firefox and B&PP in ESSP, all keystrokes were scrambled.
What I am suspecting is the version of AntiTest you are using is not compatible with Win 11.

That is not case initially as @AZ Tech posted here: https://forum.eset.com/topic/31086-liveguard-concerns/?do=findComment&comment=145452 .

Refer to the following per VT behavior analysis:

Wget.exe was spawned from a trusted WMI based process. Notice the "-O" command line parameter. The update.exe malware payload was downloaded from attackers C&C server and immediately executed.
Bottom line is LiveGuard missed the file download by wget.exe.

My test.exe is nothing more than a .bat to .exe created file. The difference is how it was created.
It was created not by any web available program to do so, but by a .bat script. The script deployed a little known but quite effective, for bypass purposes, "living off the land" Win trusted binary to create a .exe that contained a self-executing .cab file containing test.bat. These types of files are used by Windows internally to extract the content in memory and immediately execute what was extracted. Of note is my test.exe Properties show details for a trusted Win executable that exists in every Windows version.

Since I haven't commented on this point, I will now and "it's a no brainer."
In ESSP, there should be no LiveGrid submissions period. If Eset feels the file is suspicious enough to warrant a LiveGrid upload, it should be sending the executable to LiveGuard instead and blocking it until verdict rendered. This also would provide a backup mechanism for a missed LiveGuard submission upon initial file download.
-EDIT- Just read in Eset ETDT documentation that if one is receiving a LiveGrid submission versus LiveGuard submission, it means that the file was previously submitted to LiveGuard.
Looks like my test.exe is indeed a LiveGuard bypass.👍

I have a theory as to why LiveGuard is not detecting my test.exe and other missed downloads I have observed; that is they were only detected after download and submitted to LiveGrid. As much as I would like to believe it was my "stealthy" coding, that is not the reason.
To date, all LiveGuard submissions on my Eset installation have been detected during the in-process file creation phase. For Firefox browser based downloads, it was submission of the .part file in my User account temp directory. For the prior posted archive file attachment example, it was in the User Account temp created sub-directory by 7zip processing.
But what happens if the file downloaded/created locally doesn't involved any intermediate processing during file creation? My suspicion is FireFox for example, only will create a .part place holder file in the User account temp directory for larger file downloads. Otherwise, it will just directly create the download in the user's default download directory.
-EDIT- Also from the fileinfo.com link posted previously is:
As such, it is possible Eset is moving the .part file to the User account temp directory during LiveGuard analysis. In any case, it would appear LiveGuard processing would be dependent upon a .part file being created.

Since there were some questions about Eset local real-time processing scanning my test.exe in regards to my original posting I started this thread with, I retested using the following procedure:
1. I disabled Eset real-time scanning for my test.exe file by adding an exclusion for it.
2. I modified my test.exe using PowerShell to add some code to the end of the file resulting in the file hash being changed.
3. I uploaded the test.exe to a file sharing web site.
4. I removed the prior created Eset real-time scanning exclusion for the test.exe file along with deleting the file from my hard disk.
5. I downloaded the test.exe file from the file sharing web site. No LiveGuard submission occurred.
6. When I ran the downloaded test.exe, I received notification the file had been submitted by LiveGrid for Eset AV lab analysis and the process executed successfully.
Therefore, I conclude that something else within Eset is triggering an upload to LiveGuard and unknown files are not being submitted as stated by Eset. Or, my .exe as created bypassed LiveGuard processing.

I have a theory as to why LiveGuard is not detecting my test.exe and other missed downloads I have observed; that is they were only detected after download and submitted to LiveGrid. As much as I would like to believe it was my "stealthy" coding, that is not the reason.
To date, all LiveGuard submissions on my Eset installation have been detected during the in-process file creation phase. For Firefox browser based downloads, it was submission of the .part file in my User account temp directory. For the prior posted archive file attachment example, it was in the User Account temp created sub-directory by 7zip processing.
But what happens if the file downloaded/created locally doesn't involved any intermediate processing during file creation? My suspicion is FireFox for example, only will create a .part place holder file in the User account temp directory for larger file downloads. Otherwise, it will just directly create the download in the user's default download directory.
-EDIT- Also from the fileinfo.com link posted previously is:
As such, it is possible Eset is moving the .part file to the User account temp directory during LiveGuard analysis. In any case, it would appear LiveGuard processing would be dependent upon a .part file being created.

Since there were some questions about Eset local real-time processing scanning my test.exe in regards to my original posting I started this thread with, I retested using the following procedure:
1. I disabled Eset real-time scanning for my test.exe file by adding an exclusion for it.
2. I modified my test.exe using PowerShell to add some code to the end of the file resulting in the file hash being changed.
3. I uploaded the test.exe to a file sharing web site.
4. I removed the prior created Eset real-time scanning exclusion for the test.exe file along with deleting the file from my hard disk.
5. I downloaded the test.exe file from the file sharing web site. No LiveGuard submission occurred.
6. When I ran the downloaded test.exe, I received notification the file had been submitted by LiveGrid for Eset AV lab analysis and the process executed successfully.
Therefore, I conclude that something else within Eset is triggering an upload to LiveGuard and unknown files are not being submitted as stated by Eset. Or, my .exe as created bypassed LiveGuard processing.

Let's talk about my IMAPS AOL based Thunderbird e-mail that for some unknown reason ( I suspect OAuth2 security) Eset doesn't scan at all via client e-mail processing. This issue BTW to this day still remains unresolved.
Because of this, I only accept text based e-mail with attachments listed separately. I never open attachments in Thunderbird but instead have it set to open with its default associated program. For example, a .docx attachment would be open by MS Office Word. Since the file already exists on my disk, it appears that it would never be submitted to LiveGuard.
-EDIT- I stand corrected and thankfully so.
E-mailed myself a password protected archive I knew would trigger LiveGuard when opened. In Thunderbird, selected 7zip to extract the file. T-Bird dropped the compressed file to my User account temp directory. Note: the compressed file did not have the "Mark-of-the-Web" associated with it. Upon extraction, the .exe contained within was immediately sent to LiveGuard and its associated temp file deleted.

This doesn't sync with prior forum postings stating old files resident on the user's device are being submitted to LiveGuard.
I can only infer from our current discussion, that these files must have existed on the local device prior to Eset installation and, both the Eset initial scan was terminated and no subsequent Eset scan; either scheduled or on demand, was ever performed. Plus, the file has never been accessed since the Eset installation. This is possible but " a bit of a stretch."

For clarification, are you stating:
1. Eset locally detected suspicious detection's are submitted to LiveGrid.
2. All newly created files not trusted and/or whitelisted are blocked and submitted to LiveGuard for cloud scanning. This assumes an Eset local malicious detection did not occur previously via real-time scanning.
Is the above correct?
 

Thanks for pointing this out.
Most of the complaints about LiveGrid uploads of safe files appear to originate from "old" scanned files. It appears that LiveGuard upload criteria is also conditioned by age of the file. Namely, the elapsed time from present when Eset originally whitelisted the file. This kind of makes sense to me in that Eset detection methods in the past do not equal those at the present time. In other words, Eset is doing a re-verification of the file in the cloud sandbox.

Well, in this case I have a question :
Why is a file automatically sent to LiveGuard when it is already known by eset two years ago "as shown in the attached screenshots" and of course has already been scanned locally "somewhere", and at the same time not sent a completely new file?

Even if we say that this file has already been scanned locally "somewhere" and if we assume that it happened, it happened a very few hours or minutes ago, so which of them do you think has priority to send to LiveGuard ?

I assume this was the result of the the manual submission noted previously:
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.
This is OK as far as it goes. The download could have been modified since then to use different C&C download servers.

If Eset scans locally created .exe's, then that is the explanation for the non-submission to LiveGrid upon download. The file hash for the downloaded file would be the same as the original uploaded file on disk.
However, the .exe was a self-executing CAB file. Of note is the file is extracted from the CAB archive and immediately run. Does Eset scan those upon file creation? Of note is Eset's reference to only .SFX files that are scanned:
https://help.eset.com/eis/15/en-US/idh_config_threat_sense.html