itman

Guess what? Eset now has a sig. for it; see below screen shot. So this puppy was in-the-wild  undetected by anyone for quite a while.

I was pondering this script later after posting in the forum. And came to two conclusions about it;
1. It is just a custom script written by someone to enable security mitigations in Windows and Chrome for his installations.
2. It was a "test run" by a malware developer to see if all the reg changes plus Chrome modifications would go undetected by the AV solutions.
I am leaning toward no. 2 as the reason for the script. Of note is all the reg changes were adds for security policy settings. They were all to enable the mitigations. On the other hand, the adds could also be deployed to disable those security policy settings.
Of note is AV's are poor at monitoring reg. add modifications. Eset HIPS for example doesn't even have an option to do so. You have to create a wildcard rule that monitors for modification to the associated higher level reg key to detect any add activity to its subordinate settings.

Agreed.
Ditch using MS Azure servers deploying Eset M/L algorithms and use Joe Sandbox instead:
https://www.joesecurity.org/contact-solutions#oem-integration .

I would qualify this by stating it is not good at detecting and preventing 0-day ransomware.
Yesterday morning I actually found a 0-day ransomware sample and it was a "doozy." 0-day context here is no one at VT detected it upon initial submission. The verdict is out on VT listed vendor behavior detection since those features for many vendors are not deployed on their VT versions.
Within a couple of hours, Eset along with two other vendors had a sig. for the bugger. So I consider that a good performance by Eset. Of course if this was a targeted attack and you were the initial target, your installation would be "dead meat."
By a "doozy" of a ransomware attack, I mean this bugger was designed to evade cloud sandbox analysis. The initial Joe's Cloud Sandbox scan came back clean. Joe must have detected something suspicious; like all sandbox files encrypted, and next time ran it under "fuzzy" command line criteria. Then, the bugger was detected.
Bottom line x 10, back up your files to off-line storage media!

Another source to consider when evaluating anti-virus software are trusted third party web sites.
One such site is PC Magazine that has been reviewing AV software for as long as I can remember. The plus in PC Magazine reviews is it does its own malware testing and also factors in AV lab results in the final determination of a AV product's effectiveness against against malware. Also, by performing it's own ad hoc testing, PC Magazine is not constrained by the AMTSO testing standard that applies to AV labs. On this regard, Rubenking knows what he is doing. He's been performing this type of testing for years.
So what does PC Magazine think of Eset consumer product effectiveness against malware?
https://www.pcmag.com/reviews/eset-nod32-antivirus
Unfortunately, the current review by PC Magazine parallels its past like reviews of Eset in regards to software protection capability. The bottom line is if you're in the "take AV lab reviews with a gain of salt" camp, you would run away screaming from Eset if PC Magazine reviews were your only evaluation category. However, I have seen enough other third party reviews like this to seriously question AV lab test reliability.

Refer to the PC Magazine article link I posted above - 'Phishing Protection Tests' section. Eset scores in the "middle of the pack" of AV products tested.
In an A-V Comparatives Anti-Phishing test commissioned by Avast, Eset scored about the same: https://www.av-comparatives.org/wp-content/uploads/2022/04/avast_phishing_04-2022.pdf

I would qualify this by stating it is not good at detecting and preventing 0-day ransomware.
Yesterday morning I actually found a 0-day ransomware sample and it was a "doozy." 0-day context here is no one at VT detected it upon initial submission. The verdict is out on VT listed vendor behavior detection since those features for many vendors are not deployed on their VT versions.
Within a couple of hours, Eset along with two other vendors had a sig. for the bugger. So I consider that a good performance by Eset. Of course if this was a targeted attack and you were the initial target, your installation would be "dead meat."
By a "doozy" of a ransomware attack, I mean this bugger was designed to evade cloud sandbox analysis. The initial Joe's Cloud Sandbox scan came back clean. Joe must have detected something suspicious; like all sandbox files encrypted, and next time ran it under "fuzzy" command line criteria. Then, the bugger was detected.
Bottom line x 10, back up your files to off-line storage media!

Another source to consider when evaluating anti-virus software are trusted third party web sites.
One such site is PC Magazine that has been reviewing AV software for as long as I can remember. The plus in PC Magazine reviews is it does its own malware testing and also factors in AV lab results in the final determination of a AV product's effectiveness against against malware. Also, by performing it's own ad hoc testing, PC Magazine is not constrained by the AMTSO testing standard that applies to AV labs. On this regard, Rubenking knows what he is doing. He's been performing this type of testing for years.
So what does PC Magazine think of Eset consumer product effectiveness against malware?
https://www.pcmag.com/reviews/eset-nod32-antivirus
Unfortunately, the current review by PC Magazine parallels its past like reviews of Eset in regards to software protection capability. The bottom line is if you're in the "take AV lab reviews with a gain of salt" camp, you would run away screaming from Eset if PC Magazine reviews were your only evaluation category. However, I have seen enough other third party reviews like this to seriously question AV lab test reliability.

Since we are the subject of A-V Comparatives, one test worth reviewing is the Advanced Threat Protection test for Consumer AV products: https://www.av-comparatives.org/tests/advanced-threat-protection-test-2021-consumer/ .
In this test, Eset and Kaspersky had identical scores; each missing two samples.
The important point to note in this test is BitDefender's score which was poor. Now BitDefender traditionally scores high in the AV lab's Real-time tests. The point here being that all AV lab tests available must be analyzed in accessing an AV product overall effectiveness.
Also, Microsoft was not listed in this test. This means they either declined to be tested, or Microsoft Defender's score was poor enough to have the results omitted in the public published report.

Since we are the subject of A-V Comparatives, one test worth reviewing is the Advanced Threat Protection test for Consumer AV products: https://www.av-comparatives.org/tests/advanced-threat-protection-test-2021-consumer/ .
In this test, Eset and Kaspersky had identical scores; each missing two samples.
The important point to note in this test is BitDefender's score which was poor. Now BitDefender traditionally scores high in the AV lab's Real-time tests. The point here being that all AV lab tests available must be analyzed in accessing an AV product overall effectiveness.
Also, Microsoft was not listed in this test. This means they either declined to be tested, or Microsoft Defender's score was poor enough to have the results omitted in the public published report.

I will state this about Microsoft Defender. It has two fundamental flaws.
The first is hackers ability to find ways around its self-protection despite Microsoft's best efforts otherwise.
The second is its exploit protection is dismal. MRG Effitas that performs exploit testing for its real-time test series, consistently shows MD "at the bottom of the heap" on exploit protection scores. This means if you're an average home user that does not keep their OS and app software updated as soon as one is available, you run the risk of being exploited. I assume there are large number of home users that fall into this category.
Finally, MD with default settings is not adequate. It needs to be "hardened" by applying all available ASR mitigations plus tweeting block-at-first-sight cloud scanning settings. Whereas this can be done easily via Group Policy in Win Pro+ versions, Win Home users will have to deploy registry modifications to do the same. This again is beyond the capabilities of most Windows Home version users.

Since we are the subject of A-V Comparatives, one test worth reviewing is the Advanced Threat Protection test for Consumer AV products: https://www.av-comparatives.org/tests/advanced-threat-protection-test-2021-consumer/ .
In this test, Eset and Kaspersky had identical scores; each missing two samples.
The important point to note in this test is BitDefender's score which was poor. Now BitDefender traditionally scores high in the AV lab's Real-time tests. The point here being that all AV lab tests available must be analyzed in accessing an AV product overall effectiveness.
Also, Microsoft was not listed in this test. This means they either declined to be tested, or Microsoft Defender's score was poor enough to have the results omitted in the public published report.

I can't get excited over this development.
AMD based motherboard users are excluded. Also, only Intel motherboard users using integrated graphics are the only ones this feature would apply to. This by large would be commercial users. Also, many Intel motherboard home desktop users have a third party graphics card installed. As such, this feature would be N/A for them.

Since this subject keeps appearing in the forum, let's review System Watcher and compare it to Eset protections.
First, what does System Watcher do:
https://media.kaspersky.com/pdf/Kaspersky_Lab_Whitepaper_System_Watcher_ENG.pdf
* - features not contained within Eset products.
Also, the System Watcher section in the Kaspersky GUI incorporates settings spread out all over the place in the Eset GUI.
I will also state this. If Kaspersky was not a Russian based product, I would be using it instead of Eset.

I can't get excited over this development.
AMD based motherboard users are excluded. Also, only Intel motherboard users using integrated graphics are the only ones this feature would apply to. This by large would be commercial users. Also, many Intel motherboard home desktop users have a third party graphics card installed. As such, this feature would be N/A for them.

Getting back on topic, it should be noted that Kaspersky at VT also did not detect this RagarLocker ransomware sample discussed. 
At this point, I will give Kaspersky a pass on this baring proof otherwise. This sample only "sets the stage" for the ransomware to run at next system restart time. At that time, System Watcher anti-ransomware behavior methods would have detected the files being encrypted.

Windows based backdoor's are a very broad category. In their simplest form, they a can be nothing more than a reverse shell.
The problem with backdoor's is there is nothing initially inherently malicious about them. All they do in essence is establish a remote connection. Also a backdoor can remain dormant for days, weeks, and even years.
The only way a backdoor can be detected is by either having a signature for it or by IP address blocking  whatever it is try to connect to. Anyone that states otherwise is "blowing smoke." 

A quick Joe's Cloud Sandbox analysis review of this ransomware shows what's going on:

Here's a description of RagnarLocker ransonware: https://www.acronis.com/en-us/blog/posts/ragnar-locker/
Of note:
Further described as:
Also the ransomware is not new; dating to April , 2020.
As far as this specific RagmarLocker sample, I suspect this might have been deployed:
https://chipscs.com/3-significant-developments-in-ransomware-campaigns-2/

Since this subject keeps appearing in the forum, let's review System Watcher and compare it to Eset protections.
First, what does System Watcher do:
https://media.kaspersky.com/pdf/Kaspersky_Lab_Whitepaper_System_Watcher_ENG.pdf
* - features not contained within Eset products.
Also, the System Watcher section in the Kaspersky GUI incorporates settings spread out all over the place in the Eset GUI.
I will also state this. If Kaspersky was not a Russian based product, I would be using it instead of Eset.

Based on my testing of recent Follina malware samples, Eset has you covered in regards to this specific msdt.exe exploit. All samples were detected upon download; either by signature detection of payload or via Eset exploit protection by CVE.
However, there's another exploit technique that has been discovered that I posted about over at wilderssecurity.com and described here: https://www.bleepingcomputer.com/news/security/new-dogwalk-windows-zero-day-bug-gets-free-unofficial-patches/ . This one appears to be a Microsoft Defender bypass since opening of the malware dropper, a .cab file, bypassed Mark-of-the-Web checking. Until shown otherwise, I would say Eset should cover this one also.
-EDIT- Looks like Eset has issues with Qbot malware deployment of Follina exploit: https://forum.eset.com/topic/32642-eset-not-detecting-qbot-deploying-follina-exploit/

You're best bet for resolution on this is to contact Eset - Hong Kong and have them contact Eset North America to request a purchase refund on your behalf. You will have to provide all original purchase details such as that you posted in this thread.
I all else fails, you can contact MasterCard and dispute the purchase charge made by Eset N. A.. Note this must be done within 30 days from the date of the statement date showing the disputed charge.

BTW - this ms-msdt use isn't the only exploit that currently exists in MS Office:
https://www.bleepingcomputer.com/news/security/new-windows-search-zero-day-added-to-microsoft-protocol-nightmare/
This leads me to believe that it might be advisable to take the Microsoft Defender ASLR rule approach in regards to MS Office executable's and block all child process startup from them. Of course, this might bork something legit.

I will note that for anyone using Eset recommended anti-ransomware HIPS rules, this attack can be mitigated by adding C:\Windows\System32\msdt.exe -EDIT- and C:\Windows\SysWOW64\msdt.exe to the list of specific startup applications for the rule named "Deny child processes from Office 20xx processes."
Ref.: https://www.huntress.com/blog/microsoft-office-remote-code-execution-follina-msdt-bug
 

I am running ESSP and just performed an Internet based speed test. I have not seen any speed degradation with ESSP from those recorded when I was using EIS.
The only way to prove that ESSP on your Windows installation is the source of the speed degradation is to first export your existing Eset settings if you have made changes to Eset default ones. Uninstall ESSP. Run your speed test with only Microsoft Defender and the Win firewall active. If your speed tests don't improve significantly, ESSP is not the source of your speed degradation.
Finally, reinstall ESSP and import your previously saved Eset settings.

You first need to create an Eset Home account. Refer to this to do so: https://help.eset.com/home_eset/en-US/new_account.html .
Once you create the Eset Home account, you can log in to it and remove your existing license associated with the damaged PC. Refer to this one how to do so: https://help.eset.com/home_eset/en-US/new_account.html?remove_device.html .
Now you can install Eset on your new PC by entering your license key at installation time.