itman

Have them check if the ISP router has a firewall and its enabled. Most ISP provided routers these days have a NAT firewall. Also, they are stateful. This means they won't allow unsolicited inbound TCP traffic; i.e. inbound traffic not in response to a prior outbound request, . If all the above apply, I would stand by my previous statement that un-patched vulnerable OS or app software exits on the device and an external hacker is trying to exploit it. Also per Eset posted log entries, the target IP address is 140.186.96.15 which is associated with Midcontinent Communications in Fargo, ND. That is a public IP address and not a private IP address which should be associated with the device. As such, something is definitely not right here. -EDIT- Let's say Midcontinent Communications; i.e. Midco, is the user's ISP. He requested and received a static IP address from them; i.e.140.186.96.15. Note the security issue with static IP assignment; https://www.techtarget.com/whatis/definition/static-IP-address

Is Huntress EDR software installed on this device?

Maybe. It all depends if Eset can detect the malware. If its 0-day malware, I would say you will probably be nailed.

That is a distinct possibility. Since the web site is infected, creating an exception for the detection is done at your own peril.

Based on prior forum postings on this topic, one possibility is vulnerable software exists on the device and these detection's are attempts to exploit those vulnerabilities. Review of the Eset logs on the device should yield details on the source of these detection's.

Refer to this posting for further assistance: https://www.bleepingcomputer.com/forums/t/788610/how-to-repair-encrypted-files-yyza-extension-stop-djvu/?p=5549768 . Note that unless someone else has paid the ransom and provided the decryption key to Emsisoft, it will not be possible to decrypt files using their decrypter tool.

This is a newer Djvu ransomware variant. As such, it is highly unlikely a decryption key exists for it. PCRisk has a detailed article on this ransomware here: https://www.pcrisk.com/removal-guides/27456-yyza-ransomware .

When you were infected with this ransomware, did you have an Eset product installed?

I can access whclab.com w/o issue using Eset. This includes the checkout area where magacart malware hides.

Per APIVoid, the domain is not parked;

I can connect to this domain w/o issue using Eset. It appears the issue lies with Myfxbook and how they have configured their Eset installation.

Did you try to activate Eset using your existing Eset license key? I have had HDD crashes in the past resulting in Win 10 being installed from scratch on new HDD. Then Eset being installed. I never had an issue activating Eset again using my existing license key.

Correct.

Note that the Windows Security Center validation is to verify if Eset is properly registered within it. Proper Eset registration yields an "on" status for Eset Security and firewall with Microsoft Defender and Windows firewall showing an "off." status. Ensure you post the result of this verification. Once this verification as to status is completed, we can proceed with other possible causes why the Microsoft Defender Engine process might be running.

Further analysis yields there is a way to provide to provide ACS support for Win 10 1903+ versions. Microsoft has removed all ACS support KB's for Win 10 versions prior to 1903 from the Win Catalog other than LTSB versions. If you refer to Micosoft's article on ACS support: https://support.microsoft.com/en-au/topic/kb5022661-windows-support-for-the-azure-code-signing-program-4b505a31-fa1e-4ea6-85dd-6630229e8ef4 , you will note there is no KB listed for Win 10 1903. Likewise if you try to install the KB listed for Win 10 1909, that won't work either because it is for LTSB version only. However if you access KB5005611 which is the ACS support KB listed for Win 10 2004, 20H2, and 21H1, it states the update applies to all Win 10 versions 1903 and later; Select the version 21H1 update applicable to your OS version. For additional reference you can refer to the Sophos ACS article: https://support.sophos.com/support/s/article/KB-000045019?language=en_US Finally and important, you need to verify that this certificate,Microsoft Identity Verification Root Certificate Authority 2020, exists in your Win root CA store using certmgr.exe. If it does not, you will need to download and install the certificate manually. Refer to the above linked Microsoft ACS article on how to do that.

I have a suspicion why Eset might be throwing a detection on this game. A couple of comments from Reddit; https://www.reddit.com/r/gaming/comments/11ef1ga/i_just_downloaded_riders_republic_and_its_making/

Are you receiving any Eset detection on RidersRepublic.exe?

I will also note that Eset detected a malware status of RidersRepublic.exe when the following occurred per your posted Eset Detection log entry; "Event occurred on a file modified by the application: C:\Program Files (x86)\Ubisoft\Ubisoft Game Launcher\upc.exe." So this upc.exe file should also be submitted to Eset for analysis via Submit sample for analysis option in the Eset GUI Tools section. You can also submit this upc.exe file to VirusTotal.com and see if detection's for it exist there.

With the low detection rate at VirusTotal, it could be an Eset false positive detection. You should submit RidersRepublic.exe to Eset for review as such. You do this by accessing the file in Eset GUI Quarantine section. Mouse right click on the file and select, Submit sample for analysis. Change the Reason for submitting the sample field to "False positive file."

Presently two detection's at VT on this one; Eset and Rising: https://www.virustotal.com/gui/file/6a948d7ee8796b35543075dec549956d84e3d7026c48657335f9d2fc6712a2c2/detection . Eset might be triggering on the presence of VMProtect.

Augur detection triggers in ESSP using Firefox; Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here 10/6/2023 3:14:54 PM;HTTP filter;file;https://smelel.icu/sm/redirect?landID=40&company=29374&uuid=e641a93e-8f14-40a7-9316-1d443f385b06&apiKey=b68c106c3df6f586f8cb1f48c5036112;ML/Augur.C trojan;connection terminated;xxxxxxx;Event occurred during an attempt to access the web by the application: C:\Program Files\Mozilla Firefox\firefox.exe (3AC154D0A0390E254E88F9BF89E7040B00ED02F3).;2C03C7B3B8AEAD5C16FB471F5760B54641AFE5E6;10/6/2023 3:14:51 PM https://www.virustotal.com/gui/file/05f1adce2d162fc881ccc2f633342dade521e92fa0a0d84f14ced9f8f436fa8c

Belaboring to the nth degree on this subject, the problem is how Win Server 2008 performs Win updating. Note that in Win 10, a cumulative update is actually installed after a system restart when Windows enters its isolated startup mode; i.e. blue screen with circle rotating mode. Such is not the case for Win Server 2008. It appears, the update is fully installed with only a system verification done as to its status after system restart. What happened with the KB5006728 update was upon required system startup after installation, Eset verified that ACS was installed and set the HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\ACSSupport key. Windows then completed the verification for the KB5006728 update by verifying if ESU existed since this update was only allowed in this status. Windows seeing that ESU was not in effect, then rolled back the KB5006728 update by uninstalling it. Eset did not recognize that KB5006728 was uninstalled removing ACS support. From this point on, Eset thinks ACS support is still installed because HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\ACSSupport key states it is. This issue doesn't exist in Win 10 EOL/EOS versions because Windows checks for ESU support prior to beginning the KB installation processing and terminates it at that point with appropriate lack of ESU support reason for installation failure.

At system restart, ACS support did exist via KB5006728 previous install. However, due to lack of MAK license; i.e. ESU, KB5006728 install was rolled back resulting in the device without ACS support.

The anomaly here is on Win 10, these KB updates won't even start installing. Therefore, HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\ACSSupport key never gets created. I attribute this to the age of Win Server 2008 R2 and that Win Updating was in a developing state then. Also and very much evident is Eset never tested that these Microsoft KB's actually worked on EOL and EOS OS versions. Same here. I am "throwing in the towel" on the ACS support baloney since there is no way to implement it on EOL and EOS OS versions w/o ESU.

Is that that a big deal? The whole point is to get ACS installed on the device. After that, you don't need ESU anymore.