itman

Translating, it presently falls into the category of "educational" ransomware. There are others in this category. These types of ransomware are used for lab demonstration and forensic purposes. However as the ID- Ransomware previously linked article notes, these type of ransomware are often used maliciously: As such, there is absolutely no excuse Eset should not be detecting this sample. At the very least, it should be detected as a PUA. Oh, I forgot. Eset, God forbid, might possibly be "dinged" for a FP detection on it.

I really don't know what you are trying to do. This web site maintains a list of malicous domains used by uBlock's corresponding Malware Domains extension. I assume you are using uBlock with FireFox. Eset doesn't like this domain for some reason. I really believe its a FP detection. Anyway how I handle it to avoid getting Eset alerts is shown in the below screen shot. This will give me a popup alert that the connection occurred. Also I set it to log the activity. I can then check in uBlock that an update occurred for the extension at the same time.

No need for the ASR mitigation. Assumed is WD's cloud sandbox has Controlled Folders enabled. Unknown process performing repeated file modification activities to same is enough to flag the unknown process. This is why MS had a sig. for it so quickly.

This is far from the first ransomware employing XOR techniques. Here are a few other examples: https://www.rsa.com/en-us/blog/2017-05/how-ransomware-uses-tmp-files-and-the-temp-folder https://www.cybereason.com/blog/the-sodinokibi-ransomware-attack https://blog.malwarebytes.com/threat-analysis/2018/04/lockcrypt-ransomware/ So my guess is how it was deployed is new and this is why it wasn't detected by a number of solutions. This is a perfect example of why everyone needs to backup their User files and keep them off-line; or the online backup location locked down access-wise. Also another strong case for use of the anti-ransomware solutions like AppCheck or Checkpoint's solution. These use "bait" files to detect file modification and therefore are not dependant upon detecting ransomware behavior methods.

Of note is none of the Next Gen solutions on VT are detecting this. This would be a clear indication that behavior employed by this ransomware is new and their ML engines haven't been tuned to detect it.

Individuals having this issue need to supply other pertinent system details such as Win OS ver. and release used. For example, it could be only Win 7 uses are having this issue. As I recollect, I was always having Win 7 sound issues non-withstanding this Eset sound issue.

More details on this ransomware is here: https://translate.google.ru/translate?hl=ru&tab=wT&sl=ru&tl=en&u=https%3A%2F%2Fid-ransomware.blogspot.com%2F2019%2F09%2Fgoransom-poc-ransomware.html It is using XOR for encryption activities. Suspect this is why it is "flying under the radar" of security solutions monitoring for specific crypto API's.

Still no detection by Eset or Kaspersky. But Microsoft; i.e. Windows Defender, detects it. Also, BitDefender detects it.

You need a malwaretips.com logon to see the POC. I suggest you post it here so all can view.

The normal and default node for SSL/TLS protocol filtering is Automatic mode. The only reason Interactive mode should be used if one wants to specifically create a web site certificate exception. For example, a web site where privacy considerations apply like a healthcare provider.

It's a hidden "master plan" by Microsoft to get everyone to use Windows Defender ........................

BTW - I went through the hassle of uninstalling 12.2.29 and then reinstalling it. I am still getting the Security Center event log entries at boot time. So I don't know what these clean install of 12.2.29 statements are about in regards to preventing this issue.

They won't be overridden but could conflict with or negate the user rules you created manually. The most important thing to remember is allow rules always take precedence over ask or block rules. For example, you created a rule manually to block some process activity. However a rule was created in learning mode to allow the same activity. The learning mode rule will always take precedence over your manually created block rule and your block rule will never be executed. My own opinion is if the HIPS was set to learning mode initially, it should be switched to interactive mode thereafter with all new rules created from that mode. If you need to run a program installer thereafter, you have two choices: 1. Switch to learning mode again and run the program installer. This is really not secure since the installer may do whatever it wants in regards to system modification activities. 2. Stay in interactive mode and answer HIPS alerts as they appear. Again, you would need advanced system knowledge to be able to determine what is or is not acceptable system modification activity. My own opinion is the best HIPS option is when Eset is installed is to switch to Smart mode. Then manually create your HIPS rules from that point on. The most important point to remember is the Eset HIPS is not a "full featured" HIPS along the lines of Comodo's Defense+, the now defunct Outpost HIPS, etc.. These HIPS's provided features such as "Installer" mode one could easily switch to when performing program installations. This installer mode could be conditioned for example by specifying "Trusted Publishers" to prevent installations from untrusted sources.

I saw these test results the other day. Actually Eset is fairly consistent in this test series; scoring in the 98.x% range. What has happened is everyone else is scoring better lately. I also would like to know this. A while back, Eset was missing some PUA's. Don't believe that is the case anymore since they are currently quite aggressive in their PUA detection. Another thing I am suspicious about is WD's settings on this test. With that number of FPs, it has to be running with aggressive settings which is not the default.

@Marcos already answered this. The answer is yes!

For those likewise "experimenting" with WD real-time, here is an article to how to configure block-at-first sight for the maximum time period of 60 secs. cloud scanning; i.e. 10 secs. default plus additional 50 secs.: https://www.ghacks.net/2017/05/26/set-windows-defender-antivirus-blocking-to-high-on-windows-10/ . Without a doubt, GPO is the way to do stuff like this but you need Win 10 Pro+ to do so. Note: this article is two years old, so perform web due diligence and verify the registry mods. given are still applicable if going that route on Win 10 Home. Also assume those reg. mods will definitely be wiped out by applying the next Feature Upgrade and possibly so by a cumulative update. There is also a possibility these high block-at-first sight will increase the likelihood of false positives so be prepared for that.

Personally, I believe Smart mode is nothing more than a HIPS "placebo" setting. I and many others have never seen a HIPS alert in either Auto or Safe mode assuming no user rules have been created.

The fact that you're on Win 10 1803 should have no bearing on why NOD32 can't install. When you ran the Eset Uninstaller Tool did you do so in Win Safe mode? It needs to be run in Safe mode.

Not that I noticed. Note that WD will whitelist a process after the initial block-at-first-sight scan so it is not repeated.

Good to know AMS is not dependent upon RTP. As far as ransomware additional HIPS rules, I use Eset's recommended ones plus many more of my own. My understanding of WD's advanced ransomware ASR mitigation is it is doing similar to what you noted in regards to Eset file level operations monitoring. If it detects during heuristic analysis at process startup like activities, those operations and/or processes are blocked. Assumed there could be conflicts with legit encryption software due to this. So exceptions to the ASR mitigation would have to be added. N/A for me since I don't use any like software. Again, I am still in the experimentation phase as to using WD as real-time protection but as noted, it does look promising.

You are the second person who recently posted they found NOD32 not running. What ver. of Windows are you using; e.g. Win 10 1903. Also have you applied recent Win Updates?

That's impossible to do unless we know what virus you are referring to. I have asked multiple times for you to display the virus information that Malwarebytes found.

As far as AMS goes, per the below Eset online help description that it works in conjunction with exploit protection leads me to believe it only applies to Web Access protection; the real-time function I have validated still is in effect if WD real-time protection is enabled: As far as ransomware shield protection, it also is a HIPS setting. If there is an Eset's real-time component to it, recent AV lab tests have shown WD's out-of-the-box ransomware detection is equal that of Eset's. An additional advanced anti-ransomware ASR mitigation can also be deployed. I assume that mitigation will block all non-Windows process based use of the crypto API's.

It is best you open a support ticket with Eset Middle East to assist you in removal of this.

Forgot to mention how I am disabling Eset's real-time protection is via Advanced Settings option. I am not disabling it via "Protections" opinions that show various pause duration settings.