itman

My best guess at this point is it arrived as part of another app installer.

This puppy has been flying under the radar for some time. The Reddit article is 10 months old. Out of curiosity, check Win add/remove programs and see if there is an entry for WindowsMalwareProtection or MicrosoftMalwareProtection

Another important detail from the Reddit article I forgot to post. It is conhost.exe that is performing the remote communication; Makes sense since conhost is what contains the malware code. So I will add an Eset firewall rule to block conhost.exe communication.

As noted previously, this fails because Windows checks for ESU support. Without it, Windows won't allow the KB update to remain installed. Eset must be checking for something other than if this reg key value exists; HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\AcsSupport exist and is set to 1. Of note is this reg key value does not exist on my Win 10 22H2 build.

Another posting about this bugger on Reddit; https://www.reddit.com/r/techsupport/comments/zaqigb/is_this_a_maleware/ The interesting part is most of its binaries are Microsoft signed. It also appears the payload is embedded within conhost.exe. Based on what was recently posted in this thread, it appears cmd.exe was started or conhost.exe standalone; most likely in suspended mode, then process hollowing and/or command line modification was done on conhost.exe, and conhost.exe was started. Perhaps its time Eset start setting deep behavior inspection hooks into conhost.exe as it does for cmd.exe.

Let's "take it from the top." First, we are talking about AV WSC initialization processing only as I see it. Could this whole issue be simply resolved by installing the Microsoft Identity Verification Root Certificate Authority 2020 certificate? Or, is what these KB patches do is modify existing INTEGRITYCHECK processing? Let's check that out; https://learn.microsoft.com/en-us/cpp/build/reference/integritycheck-require-signature-check?view=msvc-170&viewFallbackFrom=vs-2019 Based on the above, I don't see any changes in INTEGRITYCHECK processing other than the ACS signing requirement. So I assume these required KB's modified INTEGRITYCHECK to do this. Putting it all together, Windows requires this INTEGRITYCHECK modification for AV's to register in WSC. Without the KB's being applied, Eset won't be able register in WSC. I assume this means Eset will run concurrently with Microsoft Defender. Is this really a problem?

Was this certificate added: https://forum.eset.com/topic/38212-install-failing-on-2008r2-servers-with-acs-support/?do=findComment&comment=173230 ? I assume Eset ACS signed binaries need that Win root CA cert.?

As far as Autoruns goes of note is this from the Malwarebytes posting; Run Autoruns64.exe. Once it fully initializes, search for MicrosoftMalwareProtection and systemreset. Take a screenshot of the section where they are located. Don't modify anything yet.

Here's Malwarebytes remediation of the bugger: https://forums.malwarebytes.com/topic/297568-program-fileswindowsmalwareprotection-systemresetexe-malware-removal/ . Problem is the fixlist isn't available.

You might want to check out this posting: https://forum.eset.com/topic/36845-eset-endpoint-products-compatibility-issue-with-azure-code-signing-acs-program/?do=findComment&comment=173276 . OP indicates ESET Server Security 9.0.12017 works w/o KB update.

Prior incidents of PowerShell/Agent.AEW trojan in the forum usually involved the creation of a Win service: https://forum.eset.com/topic/32255-powershellagentaew-trojan-keeps-coming-back-after-cleaning-and-reboot/?do=findComment&comment=150342 ; the service running SyncAppvPublishingServer.vbs; with the service being started via scheduled task. This current instance is different. It appears explorer.exe connects to the domain in question to either download the PowerShell malware or to run it remotely. In a remote PowerShell attack, the script being deployed must exist on the target device. So it is possible what is attempting to download from this domain is the script. SysInternal's Autoruns migh be of assistance here looking for suspect explorer.exe task running at system startup time.

Pondering and then theorizing, it appears Windows installed KB5006728 and subsequently uninstalled it when it realized the device didn't have ESU support. Eset upon recognizing KB5006728 was installed, deactivated the ACS warning and very possibly now believes all is well in regards to this issue. Appears Eset is cluelesss as to the subsequent uninstall of KB5006728 . The "clear and present danger" is if Eset will attempt to update these servers assuming ACS support is installed and what might be the impact of this on the OS and the existing Eset installation.

Bad ending for out friend trying to update his Win 2008 R2 servers. He didn't realize he had to be on ESU support for this KB fix to work. More the reason for everyone to get on this pronto; lest you have to purchase and install new Win OS licenses.

I assumed you had a LTSC license.

One thing to be pointed out is the detection's posted in this thread are originating from explorer.exe. This is highly suspect and "smells" of malware activity.

I will also add that people "better get cracking" on applying these KB updates. Based on this recent posting: https://forum.eset.com/topic/38212-install-failing-on-2008r2-servers-with-acs-support/ , updating is far from smooth.

Obviously, you will be able to apply the applicable KB for the referenced OS version. The problem is there is no reference to Win 10 1903 in https://support.microsoft.com/en-au/topic/kb5022661-windows-support-for-the-azure-code-signing-program-4b505a31-fa1e-4ea6-85dd-6630229e8ef4 . As such, it can be assumed it can't be updated via KB method.

The IP address is associated with Zemlyaniy Dmitro Leonidovich; https://scamalytics.com/ip/isp/zemlyaniy-dmitro-leonidovich -EDIT- Although Zemlyaniy Dmitro Leonidovich overall is suspect, this particular IP address looks OK: https://scamalytics.com/ip/139.28.38.154

Did you verify this Win root CA cert. is installed?

Per Microsoft: https://support.microsoft.com/en-us/topic/kb5022661-windows-support-for-the-azure-code-signing-program-4b505a31-fa1e-4ea6-85dd-6630229e8ef4 , KB5006728 must be installed on Win Server 2008 R2. Also refer to this Eset article: https://support-eol.eset.com/en/trending_weol2023_10_2022.html .

The important point is this. If your VPN works w/o issue using the Win firewall exclusively, we have definitive proof that Eset ver. 16.2 network processing is the issue. Also after installing Private Internet Access VPN, closely exam Win Firewall inbound/outbound rules for any new rules created in regards to it. Those rules can be used later for reference when Eset is reinstalled.

If you tired to contact Eset North America support, their business hours are Mon. - Fri. between 6AM and 5PM PST. You should be able to contact them now via LiveChat: https://helpus.eset.com/?chat=support&intcmp=btn-chat-home

Also, refer to this recent comment from Eset N.A. in regards to use of Eset consumer products in commercial environments: https://forum.eset.com/topic/1169-future-changes-to-eset-nod32-antivirus/?do=findComment&comment=173136 . It appears Eset considers a single consumer product license for 10 seats or less not a consumer EULA violation. However, subsequent consumer license purchases and product installation on the same commercial network would be a EULA violation. This is also why it is critical to contact your Eset distributor in Germany to fully clarify what is allowed in regards to this issue.

I never had an issue using my existing Eset license key to activate Eset. Last year, my boot drive crashed causing a full install of Win 10 on the replacement drive. I installed Eset on the replacement drive using my existing license key w/o issue. Of note was this was a single seat license. Also, my Eset license was purchased from the Eset U.S. eStore web site. Appears you will have to resolve this existing license issue with the third party reseller from where you purchased the license from.

Microsoft Defender/Win firewall will be your real-time protection until Eset is installed again. BTW - what do you mean by Eset OEM license key? Was Eset installed by the computer manufacturer?