itman

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:

MalwareBytes has an article that elaborates on what happens when two security apps try to use WFP at the same time:
https://support.malwarebytes.com/hc/en-us/articles/360051090194-Issues-running-other-security-applications-and-Malwarebytes-for-Windows

I will also state that with Emsisoft real-time protection disabled, there could be possible conflicts between it and Eset.
Eset has a HIPS that controls deep behavior inspection plus anti-ransomware protection. Emsisoft also has behavior protection mechanisms. The likelihood that these could conflict with each other is higher in my opinion than real-time protection conflicts.

Since you use the firewall in Interactive mode, make sure you don't have a rule that is blocking inbound and outbound traffic for ekrn.exe. You can also check for connectivity; i.e. ping, to the following IP addresses:
https://support.eset.com/en/kb332-ports-and-addresses-required-to-use-your-eset-product-with-a-third-party-firewall#esetlivegrid

Note that Eset's official web site in Indonesia is :https://www.eset.com/id/ .

The answer is no per Emsisoft's recommendation: https://help.emsisoft.com/en/1728/are-emsisoft-products-fully-compatible-with-other-security-products/

The answer is no per Emsisoft's recommendation: https://help.emsisoft.com/en/1728/are-emsisoft-products-fully-compatible-with-other-security-products/

As far as I am concerned, Eset should have developed a signature detection for this software long ago.
Despite WV-X popularity in the security forums such as wilderssecurity.com and malwaretips.com, there are multiple issues with this product many are not aware of. For starters, its kernel mode drivers are not WHQL certified. The software is written in Python. Then there is the issue with the internal certificate modifications this software performs. There are multiple detections on anyrun.com about this activity such as this one: https://app.any.run/tasks/e5f4c11b-c2c0-4651-9bd8-dbf26182dce1/ . Ditto for malicious detection's on other web cloud sandbox analysis sites.

Time to patch again!
https://www.theregister.com/2021/12/14/apache_log4j_2_16_jndi_disabled/

I wonder if this has something to do with Eset's Application Modification Detection feature: https://help.eset.com/eis/15/en-US/idh_config_epfw_app_content_checking.html . This feature is active when the Firewall is in Interactive mode.
Possibly when this option is at default value:
You won't get a notification and new rules are auto created regardless of if identical rules exist. If the option is disabled, you will get a notification about existing "permissive" rules with an option to keep them.