itman

Notice reference to feswa.exe in Process Explorer screen shot. Next refer to this very recent malware analysis of it by Joe's Cloud Sandbox: https://www.joesandbox.com/analysis/1431142/0/html#443628CBE77F47C6E613C90CF1B449051BF2 . What is running on your test device might be a new undetected variant.

Assumed what was left over was a reverse shell; etc. that downloaded the ransomware again with subsequent execution.

Are you running a VMware ESXi server?

Appears Minecraft uses UDP versus TCP protocol. Temporarily disable Eset HTTP/3 scanning per below screenshot and see if that resolves the issue. If it doesn't resolve the issue, re-enable HTTP/3 scanning;

Sucuri has a guide: https://sucuri.net/guides/how-to-clean-hacked-magento/ on how to clean a web site infected with magneto malware.

You will either have to wait until Internet protection module ver. 1475.1 is released for Eset commercial products: https://forum.eset.com/topic/40811-proper-solution-of-fixing-problem-with-invalid-certificate-chain-for-nodejs-apps/?do=findComment&comment=183333 or switch each endpoint device to pre-release updating which will install Internet protection module ver. 1475.1.

The "First scan" scheduled task option does not exist on my update ver. 17.1.11 ESSP installation. I am assuming it only appears on a new install of ver. 17.1.11 and possibly, thereafter. Once the automatic first scan completes, the First scan option is auto disabled by Eset.

As far as malware sourced LOL bin use observed on their honeypot (I assume) for March (?); what count cmd.exe 3609 svchost.exe 2154 sc.exe 765 rundll32.exe 747 iexplore.exe 735 tor.exe 718 consent.exe 630 schtasks.exe 563 wmiprvse.exe 363 PhoneExperienceHost.exe 357 powershell.exe 296 reg.exe 153 wscript.exe 129 taskkill.exe 103 msbuild.exe 80 ping.exe 56 control.exe 40 wmic.exe 40 csc.exe 26 regsvr32.exe 16 dism.exe 15 conhost.exe 13 taskhost.exe 13 net1.exe 8 attrib.exe 5 msiexec.exe 5 certutil.exe 4 mshta.exe 2 cscript.exe 1 No indication of how many of these samples, if any, were used in the March test. BTW - ESSP and Panda were the only tested products that missed a tested malware sample.

It depends on what you installed in regards to Ghostery. If it's the browser extension version, delete the extension from the browser you are using. If you installed its private browser version, remove it via Windows add/remove programs feature.

FYI -looks like Eset has released Internet protection module 1475.1 to production. I see it installed on my ESSP installation. Does this resolved the root cert. issues for everyone?

https://support.eset.com/en/kb3415-enable-pre-release-updates-in-eset-windows-home-products - also applicable to unmanaged Eset Endpoint installations. https://support.eset.com/en/kb7957-enable-pre-release-updates-in-eset-endpoint-products-in-eset-protect

Per the following, appears this is in-progress. However, it will require user intervention to implement; https://github.com/nodejs/node/issues/51537

Did you receive these errors when running Eset Endpoint pre-release ver. which includes the Internet module fix?

Em006_64.dll is Eset's anti-stealth; i.e. rootkit scanner, module. Makes sense this might be the source of Win blue screening. As a temporary workaround, disable Eset anti-stealth option and see if that stops the blue screens. -EDIT- Looks like Eset removed the ability to disable anti-stealth via GUI option in later versions.

And what is the fix? To not SSL/TLS scan node.js apps?

Do you have Win10/11 fast startup enabled?

It appears the HTTP/3 issue is with WireGuard per your prior posting: https://forum.eset.com/topic/40688-heavy-bug-in-version-17190-internet-security/?do=findComment&comment=182878 . Based on this; https://www.wireguard.com/known-limitations/ It appears WireGuard is exclusively UDP based as is HTTP/3 QUIC.

Has anyone tried this pointing to Eset root CA cert.? https://github.com/FiloSottile/mkcert/issues/563 I also believe the Eset cert. needs to be exported and converted to .pem format and then stored somewhere. Also, NODE_EXTRA_CA_CERTS can be deployed via environment variable as shown in this example: https://doc.sitecore.com/xp/en/developers/hd/19/sitecore-headless-development/walkthrough--configuring-sitecore-ca-certificates-for-node-js.html

Others having the same redirect issue: https://www.reddit.com/r/computerhelp/comments/1c15l3o/avg_antivirus_says_my_computer_has_been/ . Appears no one has been able to figure out what is causing the redirection.

Are you referring to disabling Eset Browser Script Scanner?

I really have no idea what you are referring to here? The fact that Eset alone on VT detects this Nowy folder.rar as malware? Previous versions of the file have contained ransomware: https://any.run/report/921f2ae14953e2f1d8b88296243fd35381cfacb714d39eb26cbc5e07639c0958/acd02b99-064b-4975-bcdf-556d44b109a0

No. The Eset forum is not the proper place to pursue this matter. Eset headquarters info shown below;

Github has opened a thread on this issue here: https://github.com/chocolatey/choco/issues/3423 . It appears the issue is the .ps1 script involved is unsigned and this is what is triggering the Eset detection;

You can get a copy of the script LiveGuard detects here: https://www.powershellgallery.com/packages/chocolatey/0.0.1/Content/public/Get-ChocolateyPackage.ps1 in addition to the Github web site.

Are you using the Win firewall at default settings? At default settings, the Win firewall allows all outbound network traffic and you should have no issues with Eset LiveGrid Internet connectivity.