itman

It's activation "baloney" created by one of Eset's partners. Most likely in this case, MicroCenter: https://www.microcenter.com/tech_center/article/7909/how-to-activate-a-pre-installed-eset-trial-when-the-prompt-does-not-show .
If you purchased a PC from MicroCenter that came with a pre-installed trial version of Eset, contact their tech support for further assistance.

It's activation "baloney" created by one of Eset's partners. Most likely in this case, MicroCenter: https://www.microcenter.com/tech_center/article/7909/how-to-activate-a-pre-installed-eset-trial-when-the-prompt-does-not-show .
If you purchased a PC from MicroCenter that came with a pre-installed trial version of Eset, contact their tech support for further assistance.

Quttera found malware located per below screen shot. However, it also found 28 files listed in the suspicious category.

If you're not capable of cleaning malware from your web site, Quttera will do it for you for a fee. It is not Eset's responsibility to clean malware from your web site.

Eset detects the payload download:

Again and obviously, the script is not being executed in Eset's cloud sandbox.

Eset detects the payload download:

Again and obviously, the script is not being executed in Eset's cloud sandbox.

Eset detects the payload download:

Again and obviously, the script is not being executed in Eset's cloud sandbox.

Currently, theme can be changed in FireFox on my Win 10 build whether logged onto forum or not. Just set it to "Eset (default)" per below screen shot and see if that works.

Most of the LiveGuard misses I am seeing is when the script payload is being downloaded from attacker's C&C server. Assumed is these attacker's aren't stupid and are refusing to download the payload when they detect a sandbox server connection. Without the payload, LiveGuard won't observe any actual malicious activity occurring.
However from a YARA behavior detection aspect, there certainly is enough suspicious activity with this script to flag it. However, ESSP default LiveGuard malware confidence factor of 90% is at a level that it is only going to trigger on observed known malicious activity.

This also needs to be noted about LiveGuard processing in ESSP.
It is using a malware confidence factor of 90%. Whereas, this level is great for eliminating false positive detection's, a lot of new stealthy malware is not going to be detected by it.
LiveGuard in ESSP needs to have the same configuration options that exist in LiveGuard Advanced; aka EDTD. That is the ability to set malware confidence factor and the ability to return suspicious detection's. These could be provided in an "Advanced" section of existing LiveGuard settings similar to that which exists for the HIPS. This would make it harder for non-technical Eset users from modifying them.

Here's a list of Win LOL binaries that Microsoft itself recommends be blocked from execution: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules .

Here's a .vbs script that Eset LiveGuard gave a safe rating for after a 8 min. analysis.
On VT, only McAfee detects it: https://www.virustotal.com/gui/file/35d11d86e996833469ee713fce6ba52dbcdcf3211e36985182f47040c2166ac9/detection .
Joe's Cloud Sandbox analysis yielded a 100/100 malicious verdict for it: https://www.joesandbox.com/analysis/995223 . Highlighted are Win trusted LOL binaries used:

Appears Eset cloud doesn't even use its own recommended HIPS anti-ransomware rules which would have stopped PowerShell spawned child processes.

Its likely that the external URL for OAB has a WebShell one-liner in its URL.  To check for and to remediate this, please do the following.
JS/Exploit.CVE-2021-26855.Webshell.H is an IOC detection which simply means your Exchange server was exploited in the past by this CVE.  Ensure you your Exchange server is fully patched, and then perform the following to remove the remnants of attack.
 
 
Check the following on the Exchange Server:
1.      Use a web browser to access: https://127.0.0.1/ecp
a.       Login with an admin that has enough rights (might require exchange admin)
2.      Click on "Servers" on the left
3.      Click on "Virtual Directories" tab thing in top middle area
4.      double click on "OAB Default Website" (OAB = Offline Address Book)
5.      Check what is in the 2 URL fields
a.       Internal URL
b.      External URL
6.      Copy and paste any suspicious URL fields into Notepad (with word wrap enabled) and then save a screenshot and discard the Notepad
a.       Saving the raw text will cause a detection by ESET.
7.      Save your changes and then move on to either rebooting the exchange server or restarting IIS.
a.       Without restarting IIS, then the IIS server will continue to host the AutoDiscovery settings which cause detections on endpoints with outlook.
Here is what this looks like on my non-compromised test environment:

Restarting IIS (or just reboot the server)
Open "Internet Information Services (IIS) Manager" (Windows + R > inetmgr.exe) Click on your server name in the list (mine test environment showed: SVRSANDEXCH (DEMO\Administrator)) On the far right under actions, click "Restart" (or you can right click on the server name and choose "stop" then "start") This made outlook on my test workstation go offline for about 30 seconds (likely longer in a production environment) and I no longer got any of the cached OAB URLs which caused detections. After this, all endpoints may get one, or more, final detection as they clean up any remaining copies of AutoD/AutoDisovery XML files, but the total count of detections of webshells per day, should go decrease until you no longer have any of these detections.

Excluding the sandbox evasion possibility posted about previously, I had a similar episode when testing a PowerShell script. It too came back with a safe verdict. The interesting part is as follows.
This script actually dialed-out to download a Github script. The interesting part is when I independently attempted to download the Github script via browser download, Eset detected by in memory signature:
Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
5/10/2022 10:42:52 AM;HTTP filter;file;https://codeload.github.com/gist/f646cb07f2708b2b3eabea21e05a2639/zip/4137019e70ab93c1f993ce16ecc7d7d07aa2463f;MSIL/Rozena.I trojan;connection terminated;xxxxxx;Event occurred during an attempt to access the web by the application: C:\Program Files\Mozilla Firefox\firefox.exe (021FF4E98DFC0305D80136D97F5DB3B0A8B6F3D9).;6DC4E1A593E2716F9364205876910059CA7471EF;
This result implies two possibilities:
1. Eset LiveGuard is submitting files to the cloud but not actually running them in the cloud.
2. Eset LiveGuard cloud scanning is entirely behavior based and Eset is not employing its existing protection mechanisms in the cloud sandbox to detect malware status.
-EDIT- This detection, MSIL/Rozena.I, indicates the download was Meterpreter. It may very well be that the Github server will refuse to download to a sandboxed sourced connection. In this case, label it as another example of anti-sandbox evasion.

This also needs to be noted about LiveGuard processing in ESSP.
It is using a malware confidence factor of 90%. Whereas, this level is great for eliminating false positive detection's, a lot of new stealthy malware is not going to be detected by it.
LiveGuard in ESSP needs to have the same configuration options that exist in LiveGuard Advanced; aka EDTD. That is the ability to set malware confidence factor and the ability to return suspicious detection's. These could be provided in an "Advanced" section of existing LiveGuard settings similar to that which exists for the HIPS. This would make it harder for non-technical Eset users from modifying them.

There is no issue with .exe downloads. Those are being blocked upon download after LiveGuard submission occurs. The issue is with script downloads not being blocked.
To date, LiveGuard behavior in regards to receiving a safe verdict response for a prior submission is the following.
You will only receive this response if you physically try to access a LiveGuard submitted file that is currently blocked. Otherwise when the LiveGuard analysis is completed and a safe verdict rendered, the file will be silently unlocked and no user notification in any form will be provided to the user as to the safe verdict status.

First, your Win 7 version is 32 bit. Out-of-the-box, it makes you more vulnerable to malware since it doesn't have kernel patch protection.
Next is this fact:
https://support.eset.com/en/kb7292-microsoft-windows-support-policy-and-eset-products
In other words, you are and will continue to be vulnerable to OS exploiting.

Is that a typo? The Eset cert. in my Win root CA store has an expiration date of 5/2/2032.
As far as thumbprint verification goes, Eset when installed creates a unique cert. for each installation.
I suspect what NordVPN is objecting to is the cert. is self-signed. Use certmgr.msc and verify that the Eset cert. stored in the Win root CA store thumbprint matches what you posted.
I suspect NordVPN presented this warning: https://support.nordvpn.com/Connectivity/1047409912/Nordvpn-com-is-telling-me-Invalid-security-certificate.htm ? Eset SSL/TLS protocol scanning feature uses its Win root CA store certificate to intercept HTTPS traffic, unencrypt it, and examine it for malware activity. Bottom line - You have to set NordVPN to trust Eset's certificate.

I have been running with Aggressive settings for sometime and have had no issues with Eset real-time false positive detections. On the other hand, I don't download and install "dodgy" apps.
Again, its up to you to decide what is best for you.

It's your decision as to what level you wish to use.

Refer to the below screen shot. Note that default settings for Suspicious applications is "Balanced" and for Potentially Unsafe applications is "Off."

As far as I am concerned there is a timing issue in regards to LiveGuard uploads.
This morning I went to the Kaspersky Virus Removal Tool web site using Firefox. Upon access to the web site and in anticipation of me performing an actual download, Firefox did a partial download of the KVRT.exe file. LiveGuard immediately sent this to the cloud and generated a desktop alert:
Time;Hash;File;Size;Category;Reason;Sent to;User
5/7/2022 9:31:19 AM;2A589D5ED79B97DDF45432A24650ACF81ABA2F1E;C:\Users\xxxxxx\Downloads\KTLQMcZI.exe.part;45088768;Executable;Automatic;ESET LiveGuard;xxxxxxx
Time;Component;Event;User
5/7/2022 9:31:19 AM;ESET Kernel;File 'KTLQMcZI.exe.part' was sent to ESET Virus Lab for analysis.;SYSTEM
Of note is I did not actually download the app and exited the web site. That was it for any other LiveGuard alerting or logging activity
Shortly thereafter, I did actually return to the web site and perform an actual download:

Note that the actual size of the KVRT.exe download is 114 MB.

Something weird was going on in the forum today in this regard.
After signing in from a previous Win 10 sleep session, I accessed the forum using Firefox. I was presented with the dark theme which I most definitely did not manually select. Playing around trying to get Eset back to it original aqua color background would only yielded a blue color background. Later, it shortly reverted to the aqua background to later revert to blue background theme again. Finally later, it reverted back to the default aqua background when set to Eset (default) and I no longer see the black theme option. Great! Keep it this way.

I also received module update and did a full system restart.
Same result. Looks like the problem has been resolved. But, I believe continue monitoring will be required for a while to make sure Eset doesn't bork it again.

I also received module update and did a full system restart.
Same result. Looks like the problem has been resolved. But, I believe continue monitoring will be required for a while to make sure Eset doesn't bork it again.

Interesting.
GPU is not showing in task manager on my Win 10 build. I never noticed it was missing since I don't use task manager to monitor this way.