itman

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.

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

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.

Eset Anti-phishing protection is URL based as noted in this knowledge base article: https://support.eset.com/en/how-anti-phishing-works-in-your-eset-product .
In regards to web based e-mail opened in a browser, it appears that only a known phishing web site which was physically accessed via opening an e-mail link would be blocked.

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.

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?

That's correct. Eicar is detected only if it meets its definition:
https://www.eicar.org/?page_id=3950
Any anti-virus product that supports the EICAR test file should detect it in any file providing that the file starts with the following 68 characters, and is exactly 68 bytes long.
The above file is longer and contains additional characters, breaking the definition of eicar.

I need to correct the UAC prompt reference in my above statements. What is being displayed is the Win file access prompt to escalate access to current logged on user access permission level. There is also no reason this prompt should be displayed since I have full access rights to any files I manually created.
There appears to be a "timing" issue in regards to the HIPS processing of file modification rules in regards to rename or delete actions. It appears the HIPS is blocking file access prior to Win 10 completing its file access verification processing. Since the OS can't access the file, it doesn't know what to do. It instead displays the file access prompt to escalate to the required current user access permission level.
Since I am running ESSP, I wonder if there is a LiveGuard file processing factor that is the source of this behavior?

Manual Win service startup means the service won't start unless another service/process starts it. Assume Eset Service; i.e. ekrn.exe is starting Eset Firewall Service.

I have a theory as to why these UAC alerts are appearing.
Appears Eset is attempting to use dllhost.exe to inject a .dll into explorer.exe. The strange part is both processes run at medium integrity level. As such, no elevation of privileges is required for dllhost.exe. This would indicate something has changed OS-wise in regards to explorer.exe internal protection mechanisms.

As I posted, an Eset re-install fixed the issue. As such, assume there was some type of internal corruption with the original installation.

Manual Win service startup means the service won't start unless another service/process starts it. Assume Eset Service; i.e. ekrn.exe is starting Eset Firewall Service.

Looks like this is indeed a serious problem. I thought I could get around the block action not working by changing the rule to ask. Then selecting deny when the alert appeared. A no go on that idea. The file still got deleted.

Here's the problem the OP is showing as I am interpreting it.
When a directory/folder or file is renamed using Win Explorer, Eset HIPS modification rule does detect it and alerts. However, the renaming remains in effect. This might have something to do with Win Explorer performing the rename activity. I suggest creating a .bat script with the following command for example:
rename c:\computer\test.txt test.exe Run the .bat script by double mouse clicking it and see if the renaming activity is prevented.
-EDIT- I ran this test myself and there is a problem with the HIPS. It recognizes file renaming as file modification activity, but does not prevent the file from being renamed. This parallels a long known issue with Eset real-time scanning in regards to file renaming activities.
Also, it appears none of the file modification mitigations are working. I can delete a file as well. Again, the HIPS alerts it blocked the delete, but the delete occurred.

Actually, this might be a better work around. Temporarily disable scanning of network drives until the copying completes?

Refer to this: https://forum.eset.com/topic/30842-apache-http-proxy-version-2452/ if applicable to your installation.
Also, it is not just Apache server that is affected by this vulnerability, but many other products: https://github.com/NCSC-NL/log4shell/blob/main/software/README.md . Here is the Github web page with comprehensive information on this vulnerability including scripts that can scan devices for vulnerable software: https://github.com/NCSC-NL/log4shell .
It is possible that IE11 accessed a compromised web site and was redirected to a known attacker server trying to exploit the Log4Shell vulnerability. In other words, this was an initial exploratory attempt against the source device. Since Eset blocked this access, there is nothing to be concerned about at the current time in regards to this particular incident.

Yes.
Since this was outbound communication which Eset allows all by default, I assume this IP address, 117.2.3.4, is on the Eset IP address blacklist. Have you applied all Log4Shell Apache server and related software vulnerability patches?

Log4Shell-like Critical RCE Flaw Discovered in H2 Database Console
https://thehackernews.com/2022/01/log4shell-like-critical-rce-flaw.html

https://www.picussecurity.com/resource/blog/simulating-and-preventing-cve-2021-44228-apache-log4j-rce-exploits

An Eset moderator will have to confirm 100% if firewall is required.
Based on what is shown here:
https://help.eset.com/ees/9/en-US/idh_config_epfw_ids_rules.html?idh_page_epfw_settings.html
My opinion based on the above is the firewall is required. Note what I underlined. That protection is based on Network Inspection processing which is part of the Eset firewall protection.

Eset's KB article on pre-release updating: https://support.eset.com/en/kb3415-enable-pre-release-updates-in-eset-windows-home-products . Of note:

Eset's KB article on pre-release updating: https://support.eset.com/en/kb3415-enable-pre-release-updates-in-eset-windows-home-products . Of note:

The interesting part of the tracert output is we are both traversing through the same Deutsche Telekom AG server from the U.S..
Given is we are using different ISPs. This leads me to speculate that for those in the U.S. having LiveGrid connectivity issue, the source of the issue lies with their Internet provider or the DNS servers they are using.

I did come across the Google ProjectZero article that recommended that winhttpautoproxysvc  service be disabled: https://googleprojectzero.blogspot.com/2017/12/apacolypse-now-exploiting-windows-10-in_18.html . BTW - this was patched by Microsoft.
At the same time I found this later dated router vulnerability advisory that also might be worth exploring:
https://www.kb.cert.org/vuls/id/598349
Of note is the recommended mitigation for this is:

Probably the best advice to LastPass users is the last paragraph of the bleepingcomputer.com article: