itman

My best guess is Eset has "beefed up" its JavaScript scanner and MBAM's like protection is conflicting with it. As a test, try disabling Eset's advanced browser script protection and see it that resolves the CPU usage issue. Or alternatively, disable like protection in MBAM, if possible, while keeping Eset's like protection enabled and see if it resolves the CPU usage issue. Personally, I would disable MBAM's script protection since I feel Eset's is superior to it. Another possible point of conflict is MBAM's anti-exploit protection which is now included in the product. In the past, it was a stand-alone feature. Add Win 10's Windows Defender Exploit Guard that is constantly running and you have three anti-exploit products running at the same time …………..

This is one clever ransomware. Appears the attacker created his initial files as hidden desktop items. Then executed them from a .Net program using something like this: Process.Start(@"C:\Users\xxxxx\Desktop\Translator.exe.lnk"); Also execution could be done via shell.

Appears this is BlackRouter ransomware. Originally it was being distributed via a RDP tool: https://gbhackers.com/blackrouter-ransomware-attack/ . This leads me to believe me that a legit app is dropped on the device. However, its installer is hacked and runs the ransomware .exe; i.e. blackrouter.exe. TrendMicro has a more detailed analysis here: https://blog.trendmicro.com/trendlabs-security-intelligence/legitimate-application-anydesk-bundled-with-new-ransomware-variant/ . Of note is Eset does detect this variant. So this must be a new variant that is bypassing Eset DNA signatures. More justification to this assumption since Trend is also not detecting the new variant.

Appears the attacker is infecting your PC at will with new coin miner variants. Suggest you contact your in-country Eset support contact for malware removal assistance.

Same here on the Win 10 build I am running. In theory, the Eset scheduled scan timing parameters should be controlled by following variables: 1. The last date/time a scheduled scan was run. 2. The date/time a scan is scheduled to run. 3. The Windows clock date/time. As far as Eset's KB3207 missed scan recommended setting of Immediately with a 24 hour interval specified, that is because: What the above implies to me is Eset by default will try to run the scan if missed. I did notice something interesting for the only Eset provided scheduled scan that is time dependent; log maintenance. The time coded on my Eset EIS 12.0.31 installation is 6:00:15 PM. I find it a bid odd that thousandth of seconds is specified. Perhaps the issue is the coding of immediately if scan is missed is dependent upon such time specification? This time format coding along with an interval of "0" is what I am coding to try in my user created scheduled scan to see if it resolves the issue.

Ref.: https://support.microsoft.com/en-us/help/3189806/a-program-is-trying-to-send-an-e-mail-message-on-your-behalf-warning-i

Also per Virus Total: https://www.virustotal.com/en/file/1d6965edad78dbaa59f02a24b98e4bb6ad3fafbd8b51aaaeee43c1dd8f8c7315/analysis/1534723852/ , this appears to be XRIG Monero coin miner based on the Eset malware detection. This coin miner is known to exploit vulnerable Win OS versions. Is your system fully up to date OS update wise?

Suspect the other file shown in your alert that begins in Russian? and ends in Microsoft Passport is also bogus and part of the coin miner attack. If the file physically exists on your hard drive, you can submit to Virus Total and see what the scanners their detect. For the time being until @Marcos gets back to you, you can create a HIPS rule to block startup of anything in "C:\Users\user\AppData\Roaming\*.*". When you create the rule, eliminate the previously shown quote marks. Make you set the logging level to warning, so a log entry is created. If the HIPS log entries created become excessive, you can subsequently set logging level to none. Make sure to post a screen shot of at least one HIPS log page of entries created by the rule. You can then clear the HIPS log if you wish. As far as I am aware of, there are no executables in C:\Users\user\AppData\Roaming\ sub-directories than run on a normal basis. If in fact you do use Microsoft Passport, make sure there is not a sub-directory created for it in C:\Users\user\AppData\Roaming\. If so and it contains executable files, then don't create the above HIPS rule mentioned

What file is Eset detecting the coin miner in? Click on the "file" word shown in blue in the Eset alert to determine this.

Interesting assumption. Also to be factored in to this is how wake up from sleep mode is handled in Win 10. By default you are required to sign-on again after resuming from sleep. Also the subsequent activity that Windows performs is quite similar to that of done when signing in after a full boot; e.g. Win Update check, etc.. This could very well be the problem in that Eset's missed schedule scan internal clock is reset at log-on time. It has been posted that the missed scheduled scan options also do not work on Win 7. So the issue might very well be that Eset's internal scheduler monitoring clock in regards to missed scans is reset after resume from sleep.

I don't understand this posting either. Eset detected the base malware, Win32/Floxif, way back in 2012. Win32/Floxif .H is just a variant which regardless of a positive signature for it which Eset has (created 9-4-2015), would have been detected via DNA signature analysis. Ref.: https://www.virusradar.com/en/Win32_Floxif/detail

I believe the OP's question is if he can use URL's instead of IP addresses in a firewall rule. The answer as far as I am aware of is no. The problem is Microsoft constantly changes the IP addresses associated with its URLs. Therefore, using IP addresses is an effort in futility.

Per Eset Help feature: https://help.eset.com/eis/12/en-US/idh_dialog_epfw_zones_page.html Of note is when the Eset firewall is set to "Public," nothing exists in the Trusted Zone.

Proofpoint published an article titled, LCG Kit: Sophisticated builder for Malicious Microsoft Office Documents, which highlights two main points: 1. MS Office malware attacks are becoming increasingly sophisticated. 2. These attacks are now being sold on the dark web as kits enabled those without advanced programming skills to create advanced malware attacks that difficult to detect. https://www.proofpoint.com/us/threat-insight/post/lcg-kit-sophisticated-builder-malicious-microsoft-office-documents It is therefore imperative that organizations employ mitigations to defeat the above attack methods. I posted previously about OLE mitigations. JavaScript should be disabled via in-product Adobe Reader setting, RTF objects should likewise be blocked via MS Office in-product settings. Etc,, etc.

https://support.eset.com/kb5657/?locale=en_US&viewlocale=en_US Also noted in the article is for best compatibility with BP&P, it is recommended that you set your default browser to IE11.

Also, Rapid 3.0 Ransomware uses the .nano extension. So it is imperative the ransomware be positively identified which can be done here: https://id-ransomware.malwarehunterteam.com/

If this is Scarab ransomware, this is a very recent variant: https://twitter.com/demonslay335?lang=en

Microsoft has an article on firewall ports and connections used by Visual Studio: https://docs.microsoft.com/en-us/visualstudio/install/install-and-use-visual-studio-behind-a-firewall-or-proxy-server?view=vs-2017 . One easy solution might be to just switch the Eset firewall to its default allow all outbound connections when performing your debugging activities.

This is a long shot suggestion but the process crashing activity might be related to a known 1809 bug in which desktop notifications are not working after the 1809 upgrade. This would be more the case if you are no longer receiving any Win notifications after the 1809 upgrade. If this is the case, you could try this fix: https://pureinfotech.com/fix-action-center-notifications-not-working-windows-10-1809/ or Google search for other fix suggestions. The missing desktop notifications was really the only issue I encountered after upgrading to 1809, and the above posted link fix worked for me.

Interestingly today when I went to pause Eset protection, I received the normal alert with specification on how long to pause for. So it appears, my posted screen shot is a one-time thing. Anyway, I paused Eset w/o issue. No ShellExperienceHost.exe crash or anything else for that matter. So I can't duplicate the issue on my Win 10 x(64) 1809 build w/EIS 12.0.61 installed. Again, this ver. of Eset was installed on 1803 when I upgraded to 1809. What is a fact is I had multiple failures trying to upgrade to 1809 via Win Updates download. What I finally did was disable Virtualization in my BIOS settings which in turn disabled Core Isolation in 1803. I then did an in-place upgrade to 1809 as previously described. What I can state is as a result of this in-place upgrade, 1809 has been running w/o issue. In fact, it has been the most problem free Win 10 upgrade I have done to date.

In theory, KIS 2019 should have performed better than EIS 12.0.31 in this test because it already has behavioral monitoring; i.e. System Watcher, in place. Note that EIS/NOD32 doesn't have behavioral monitoring until ver. 12.1. As far as no Internet connection, it would have no effect on detection in this test since neither product goes to the Cloud to perform to decision making activities to block or allow the malware process from running.

Just tried to duplicate this on Win 10 x(64) 1809 w/EIS 12.0.31 installed. When I tried to disable Eset, I get what is shown in the below screen shot: Never ever saw anything remotely similar to this on any prior version of Eset I have installed. Also, the date of last threat detection in my Eset corresponding log file is 12/21.

To satisfy "our friend" uninstall KIS 19 so that only WD is running. Make sure its signatures are updated. Leave Controlled Folders and other settings at default. Rerun the same samples and see if anything is encrypted or if Emotet was detected.

This issue is a mystery to me since I am running Win 10 x(64) and EIS 12.0.31 w/o such problem. I suspect this might be related to how the Win 10 1809 upgrade was performed? I performed the upgrade by doing an in-place upgrade from 1803 using a prior 1809 .iso file downloaded using the MediaCreator tool. I would suggest opening an admin level command prompt window and run this command: DISM.exe /Online /Cleanup-image /Restorehealth This will run for a while and will fix any system issues it finds with your 1809 build.

As far as AV lab malware sample selection goes, I believe it is logical to assume some qualification of samples is used. Besides the obvious selection by malware category; e.g. Trojan, ransomware, etc., it can be assumed that prevalence is also a factor. If a lab always used the most prevalent samples, the tests would show almost always show 100% detection by most of the major AV vendors. Obviously, a widely used malware is one that needs immediate detection and mitigation. Additionally if lab test reports showed always 100% detection by all test participants, no one would pay attention to the tests since they already know the outcome. AV vendors would no longer pay to have their products tested and the labs would go out of business. So if is fair to assume that the labs will include a few malware samples that are not widely in use or are isolated geographically. The odds of one being infected by one of these malwares is statistically very low. Assumed is Eset is concentrating on malware with the greatest risk to its customers versus trying to "bag" a lab test with a 100% score. Finally do note that AV labs do not disclose such sample selection criteria as above which really needs to be done.