itman

Looks like it's not sleep mode after all.
This morning after system startup, Eset Service was using less than 40 MB. After openning Firefox, Eset Service now using 200+ MB.
I don't care about the increased memory use when FF is active. What I don't like is Eset is not releasing the memory after FF is closed.

I did a system restart. Eset service started up at 22 MB and gradually rose to 28 MB.
Opened Firefox and some other apps and memory usage is currently at 30 MB.
As I recollect, I saw Eset Service memory usage spike to the 200+ MB range after a recent MS Office update and it never went down afterwards. I will keep monitoring to see if its leaking memory.

Let's check the obvious. Is LiveGrid Feedback enabled?

I will note that maximum download speed varies dramatically depending on network adapter, connection type used, and computer manufacturing date. As far as computer age goes, this is referencing the motherboard network adapter chip used and the BIOS/UEFI interaction to it. Some motherboards have an internal speed test accessible via the BIOS/UEFI that measures network Ethernet bandwidth between the router and motherboard. This should always be the first test performed to verify that the router is actually serving up 1Gb speed.
The below screen shots are from Google 1 Gb fiber service in regards to their speed test:

https://support.google.com/fiber/answer/6250056#zippy=%2Cmobile-devices-wi-fi%2Ccomputers-ethernet-or-usb-adapter-to-ethernet%2Ccomputers-wi-fi

Looks like the problem has been resolved, folks!
Since the screen shots posted in my last posting were for illustrative purposes only and not chronologically synced to a specific test instance, I decided to repeat the test and post new screen shots.
When I started to retest, Firefox updated to ver. 96.0.3. After that update, I can no longer duplicate what was happening previously.
From everything I am observing when testing after this latest update, Firefox was the "culprit." Prior to the update when Google Safe Browsing blocked a download, Firefox was downloading a .part version of the file to the Downloads folder. LiveGuard then attempted to process this .part file and "everything went downhill" Firefox and LiveGuard wise thereafter. After the Firefox update, no .part file is being downloaded to the Downloads folder when Google Safe Browsing blocks a download and no subsequent LiveGuard processing occurs.
A note of interest here is Firefox still is downloading a .part file to the %Temp% directory. If you manually in FireFox don't remove the Google Safe Browsing blocked download or navigate immediately to another web site, that .part file remains in the %Temp% directory:

Appears LiveGuard is "oblivious" to the existence of this file.

BTW - I did verify at VT the the above .part file is just a renamed version of VbsToExePortable_3.2_Dev_Test_1.paf.exe.
Since it appears LiveGuard is triggering off the download to the %Temp% directory, this brings up LiveGuard bypass possibilities. Something along the lines of a simultaneous payload download to both the Downloads and %Temp% directories?

BTW - I did verify at VT the the above .part file is just a renamed version of VbsToExePortable_3.2_Dev_Test_1.paf.exe.
Since it appears LiveGuard is triggering off the download to the %Temp% directory, this brings up LiveGuard bypass possibilities. Something along the lines of a simultaneous payload download to both the Downloads and %Temp% directories?

Looks like the problem has been resolved, folks!
Since the screen shots posted in my last posting were for illustrative purposes only and not chronologically synced to a specific test instance, I decided to repeat the test and post new screen shots.
When I started to retest, Firefox updated to ver. 96.0.3. After that update, I can no longer duplicate what was happening previously.
From everything I am observing when testing after this latest update, Firefox was the "culprit." Prior to the update when Google Safe Browsing blocked a download, Firefox was downloading a .part version of the file to the Downloads folder. LiveGuard then attempted to process this .part file and "everything went downhill" Firefox and LiveGuard wise thereafter. After the Firefox update, no .part file is being downloaded to the Downloads folder when Google Safe Browsing blocks a download and no subsequent LiveGuard processing occurs.
A note of interest here is Firefox still is downloading a .part file to the %Temp% directory. If you manually in FireFox don't remove the Google Safe Browsing blocked download or navigate immediately to another web site, that .part file remains in the %Temp% directory:

Appears LiveGuard is "oblivious" to the existence of this file.

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.

I did some additional testing using this download: https://raw.githubusercontent.com/Makazzz/VbsToExePortable/master/VbsToExePortable and it was multiple tests. I have also definitely identified what is the LiveGuard issue.
First, I updated my prior posting in this thread that both Safe Browsing download settings need to be disabled till this issue is resolved by Eset.
The issue is Safe Browsing will first download a "metadata" version of the file for initial analysis in the Google cloud. It then deletes that file and subsequently will download the full version of the file. What LiveGuard is capturing is the metadata version of the file for Eset cloud analysis. The problem is the metadata version of the file doesn't contain all file data and no longer exists in the user's Downloads folder resulting in both the download being borked along with LiveGuard's subsequent processing of it.

I did some additional testing using this download: https://raw.githubusercontent.com/Makazzz/VbsToExePortable/master/VbsToExePortable and it was multiple tests. I have also definitely identified what is the LiveGuard issue.
First, I updated my prior posting in this thread that both Safe Browsing download settings need to be disabled till this issue is resolved by Eset.
The issue is Safe Browsing will first download a "metadata" version of the file for initial analysis in the Google cloud. It then deletes that file and subsequently will download the full version of the file. What LiveGuard is capturing is the metadata version of the file for Eset cloud analysis. The problem is the metadata version of the file doesn't contain all file data and no longer exists in the user's Downloads folder resulting in both the download being borked along with LiveGuard's subsequent processing of it.

https://help.eset.com/essp/15/en-US/idh_hips_editor_main.html?idh_hips_editor_single_rule.html

Not any more since latest version is a basically clone of Chrome. Then there is the "Microsoft" factor which by definition is not synonymous with privacy.

Wildcards are allowed in HIPS rules with the following restrictions:

Note that the last three above sentences are the only way a wildcard can be used within a file path specification.

Wildcards are allowed in HIPS rules with the following restrictions:

Note that the last three above sentences are the only way a wildcard can be used within a file path specification.

I use Firefox due to privacy concerns with Chrome.

I came across this article: https://security.googleblog.com/2021/06/new-protections-for-enhanced-safe.html on how enhanced Safe Browser protection works in Chrome.
Eset needs to test if a LiveGuard conflict exists with Safe Browsing in Chrome.

Your web site is also currently blacklisted by McAfee; appears due to volume of spam it is generating.
Refer to this Sucuri analysis: https://sitecheck.sucuri.net/results/https/b-set.co.il .

This explains a bit more what FireFox is doing in regards to file downloads:
https://support.mozilla.org/en-US/kb/how-does-phishing-and-malware-protection-work?as=u&utm_source=inproduct   The conflict with LiveGuard to me is obvious from what I underlined.   I have disabled both Safe Browsing file download checks until Eset finds a resolution which I assume will take some time. This issue also might manifest in Chrome since I assume it is also using Google’s Safe Browsing service.

Rather than edit my prior posting, I will make another one. This illustrates another possible scenerio in regards to ChromeSetup.exe. This scenario also "wraps up" malware concepts I have previously posted in this thread. We'll assume that all Eset detection mechanisms were deployed and this .exe is sandbox aware.
At Eset "first sight" of  ChromeSetup.exe, Eset local hueristics did detect the injection activity to WMIADEP.exe. This detection in turn resulted in a block and upload by LiveGuard to the cloud sandbox. The .exe detected that it was being scanned in the sandbox and set a "switch" in memory to this effect. Upon connection to the remote C&C servers, they first queried if the sandbox switch was set. If set, the download was done minus the malware payload. 
Eset LiveGrid scanning of the .exe completed and the following "suspicious" indicators were evaluated:
1. Process injection - very suspicious.
2. Download of a non-native Windows download utility not frequently used - suspicious.
3. Execution of the above downloaded utility to download additional software - highly suspicious.
Since LiveGuard won't return a suspicious verdict, it rendered a "safe" one. Eset local based processing received the safe verdict, whitelisted the process -OMG!, and unblocked the .exe.
Thereafter whenever an Eset installation encountered ChromeSetup.exe, it ran unimpeded. This only stopped when Eset in an unrelated detection incident, flagged the C&C servers used by .exe and blacklisted them.
Given the above two scenarios, I would prefer to believe that ChromeSetup.exe was not detected by Eset local heuristic scanning ........................

If you post the web site URL as @Marcos requested, he could pinpoint the malicious code for you.

If you post the web site URL as @Marcos requested, he could pinpoint the malicious code for you.

This is because you logged on as Guest. Create a forum account and and post your queries in the appropriate forum section and you won't see the Captcha again.

It gets weirder.
Deleted the two files in my download folder. Then did another download from the Github web site. Now I have the above 0 byte .exe in my downloads directory. No alert or log entry for this download in regards to a LiveGuard upload.
-EDIT- Appears for some strange reason, FireFox (assume it's Google Safe Browsing) is now blocking the download. Overriding that, the download completed sucessfully. Not a beep from Eset on the download or upload to LiveGuard. Appears LiveGuard did give a safe verdict to it.

It gets weirder.
Deleted the two files in my download folder. Then did another download from the Github web site. Now I have the above 0 byte .exe in my downloads directory. No alert or log entry for this download in regards to a LiveGuard upload.
-EDIT- Appears for some strange reason, FireFox (assume it's Google Safe Browsing) is now blocking the download. Overriding that, the download completed sucessfully. Not a beep from Eset on the download or upload to LiveGuard. Appears LiveGuard did give a safe verdict to it.