itman

I already commented on this here: https://forum.eset.com/topic/33302-liveguard-can-automatically-block-a-suspicious-file-but-cannot-upload-it-to-the-cloud/?do=findComment&comment=155033 .
Also for many LiveGuard submissions, you won't even know it was submitted unless you were constantly monitoring Eset Event log entries for it. As such, I guess the fact that a safe verdict desktop alert is not displayed is logical. The only time you will see an Eset popup notification is if the file is also submitted to Eset VirusLab for additional review and that setting is enabled in Eset Event settings.

This keeps coming up in the forum; over and over again.
If the file is deemed safe by LiveGuard, you will not get an Eset safe popup notification and the file will be silently unblocked.
The only time you will receive an Eset safe popup notification is if you attempted to access the file while it was in a LiveGuard blocked state.

Glad to see that Eset has joined AVLab test series. Since they are not an AMTSO member, they are not constrained by its testing methodology. As such, they can be more "creative" in testing of malware.
There does appear to be some confusion as to what the various test levels; L1 - L3 mean. So let's review those:
https://avlab.pl/en/modern-protection-without-signatures-comparison-test-on-real-threats/
To sum up the above, Level 3 ranking means malware detection based on behavior methods only. Also, behavior based detection implies that some system modification activities may have occurred prior to detection. Level 1 detection obviously offers the most system protection. However, almost all in the security industry will state that given the current and evolving state of malware development, it is an unrealistic malware detection standard. Rather, Level 3 malware behavior detection today is mandatory in conjunction with Level 1 and 2 methods.
As far as LiveGuard being a contributing factor to ESSP 100% Level 1 scoring, I see no evidence of this in the current test published details. One of many ways to determine LiveGuard effectiveness would be to have AVLab perform a controlled test of both EIS and ESSP. The test malware samples would include a large number of "true" 0-day samples. That is malware in-the-wild not currently being detected by any AV solution; not 0-day malware seen in the last 30 days. This test would also establish Eset's effectiveness using L3 behavior methods.

You can keep WD sigs. updated by setting WD to perform periodic scanning via Windows Security Center. The downside of this is the entire WD engine loads into memory at system startup time and basically sits there doing nothing until a periodic scan is run.
The alternative is to temporarily disable Eset real-time protection. After this done, WD real-time protection should auto enable via WSC monitoring. At this time, you can force an update of WD sigs. Then re-enable Eset real-time protection.

Verify the following highlighted setting is enabled in Eset GUI:

Also verify that Eset logging verbosity level is set to Informative:

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.

The download manager issue withstanding, my question is what about app based downloads; updates, etc.?
Most I believe are aware of every growing supply chain based tampering issue. Also, the connection could be hijacked en-route.

Interesting posting.
I will also add that both Kaspersky and BitDefender perform SSL/TLS protocol filtering. Hence the interception activity you observed using those products.
Also note that Eset will auto exclude from its SSL/TLS protocol filtering many vetted web sites using EV certificates such as banking web sites, etc.. If for some reason your bank web site is not auto excluded, you can create a URL exclusion for it in the Eset SSL/TLS protocol filtering settings section. This is the recommended way to perform SSL/TLS protocol filtering exclusions versus disabling SSL/TLS protocol filtering completely.

You don't need a fancy pc if all you want to do is test malware. You can pick up some cheap old computer off of places like eBay.
The problem with virtual machines and sandboxing is that some malware can be aware that it is running within them. So it won't expose its real real intentions if it thinks it is within one of those environments. Where as having a cheap disposable pc you can see the full effect of what the malware is doing with no risk. Then you can just wipe the system when you are done with testing.  

I will also note that this web site can be accessed fine when using Eset if a good adblocker browser extension such as uBlock Origin is deployed. This is because the adblocker is preventing the malicious ad source from rendering as shown in the below screen shot:

Also scumware.org detects malware on the web site which is the basis for Eset's detection I believe:

Quttera detected 31 malicious files scattered throughout web site references all having the same detection:
Detected reference to malicious blacklisted domain securepubads.g.doubleclick.net

If you can't remove the malware yourself, you can contact a website cleaning and monitoring service, such as www.sucuri.net.

You have bunch of .js files infected on the server. Like this one:
.../wp-includes/js/jquery/ui/core.min.js?ver=1.13.1
At the end of infected .js you can find malicious part. Manually cleaning those files wont probably help, there will be infected .php on your server that looks completely different (and its not visible from visitors POV).
Moreover err 5xx isnt directly connected to this infection. It was probably caused by some wannabe hacker who got access to your server for free and messed things up (ie via exploitable wp plugin). You need much more than help from this forum
 

I was able to find a previous article on one instance of a hacked attestation signed driver: https://www.neowin.net/news/microsoft-whql-signed-fivesys-driver-was-actually-malware-in-disguise/ .
I specifically selected this article to show the "confusion" that exists in regards to attestation signed drivers. Neowin.net made a point to state this instance was a hacked Microsoft WHQL certified driver. In reality, the driver was not WHQL tested by Microsoft. However, reviewing the driver certificate it does state it is? This is because Microsoft wants to give the "illusion" that attestation signed drivers are actually tested by Microsoft when in reality, they were not.

That doesn't mean it is not capable of dropping malicious files later.
https://www.hybrid-analysis.com/sample/09430fa20aac3815ba456f4644f41b41073d4994e538797c172c10a19f825b35?environmentId=120
MITRE ATT&CK™ Techniques Detection: This report has 10 indicators that were mapped to 11 attack techniques and 3 tactics

It must be malicious. Kaspersky wasn't detecting it. Then I submitted to them an hour ago and got a reply with 20 minutes stating that it's a malware and detection will be added. 
Hello, New malicious software was found in the requested file. Its detection with verdict Trojan.Win64.Agentb.ktqd will be included in the next update. Thank you for your help. Best regards, Alexander Kryazhev, Malware Analyst So, if you still want to use this file even after detections from all these top AV vendors, then that's your choice. Use at own risk.

Note that the "Number of users" process status indicates the number of Eset users that have run the software.
It appears Edge is not used as frequently as Firefox or Chrome among Eset users.
I have always viewed this "reputation" feature of Eset as useless since it is solely base on feedback from Eset installations.

I had uninstalled Eset on 7/5 and re-installed on the same date using an off-line download of ESSP ver. 15.2.11.0.
I just checked in Eset GUI what date is shown for Eset cert.. It is 7/5.
Next, I opened certmgr.msc. Then checked Eset cert. date for Eset cert. in Trusted Roots store. The Eset cert. date there is also 7/5.
I repeated what you did:
Again, Eset GUI Eset cert. display shows a date of 7/5.
Using certmgr.msc, check if Eset cert. in Trusted Roots store shows a date of 6/29. It is possible that when you reinstalled Eset, the Eset cert. from the prior Eset installation was not replaced for some unknown reason.

Note that the "Number of users" process status indicates the number of Eset users that have run the software.
It appears Edge is not used as frequently as Firefox or Chrome among Eset users.
I have always viewed this "reputation" feature of Eset as useless since it is solely base on feedback from Eset installations.

BTW - the log entry translated yields:
Time;Scanner;ObjectType;Object;Detection;Action;User;Information;Hash;First seen here 6/29-2022 7:59:27;Advanced memory scanner;file;Memory memory » spoolsv.exe(1544);a variant of Win64/CoinMiner.AFZ trojan horse;contains infected files (after next reboot);;; B6D31B120E905B753109CB0985C1F7818D10A40E;

https://www.bleepingcomputer.com/news/security/microsoft-exchange-servers-worldwide-backdoored-with-new-malware/

https://www.bleepingcomputer.com/news/security/microsoft-exchange-servers-worldwide-backdoored-with-new-malware/

Damn!
Both drivers are using Microsoft attestation kernel mode code signed drivers. I guess its time I write a posting on the "clear and present danger" Microsoft attestation code signed drivers present in Win 10/11.
BTW - this is not the first time attestation signed drivers have been deployed maliciously.
I also strongly recommend to Eset that they at least throw a warning alert on attempted installation of attestation signed drivers.

Guess what? Eset now has a sig. for it; see below screen shot. So this puppy was in-the-wild  undetected by anyone for quite a while.

I was pondering this script later after posting in the forum. And came to two conclusions about it;
1. It is just a custom script written by someone to enable security mitigations in Windows and Chrome for his installations.
2. It was a "test run" by a malware developer to see if all the reg changes plus Chrome modifications would go undetected by the AV solutions.
I am leaning toward no. 2 as the reason for the script. Of note is all the reg changes were adds for security policy settings. They were all to enable the mitigations. On the other hand, the adds could also be deployed to disable those security policy settings.
Of note is AV's are poor at monitoring reg. add modifications. Eset HIPS for example doesn't even have an option to do so. You have to create a wildcard rule that monitors for modification to the associated higher level reg key to detect any add activity to its subordinate settings.