itman

Let's theorize a bit. Your malware sample contained a 0-day version of Redline Stealer malware which ran when you executed "the other stuff" in your malware sample. Redline Stealer steals device credentials. Attacker accesses your VM using the stolen credentials and executes a remote ransomware attack: https://www.scmagazine.com/resource/remote-ransomware-what-is-and-how-to-stop-it . Bottom line - your files are not being encrypted locally but on the attacker's server with the local device files being replaced with the remotely encrypted files.

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.