itman

This one has been bugging me for a while. Eset HIPS default behavior for ask rules that have not received a user response is allow. This is the only HIPS I have used where like default behavior is not block. Before I get into my suggested enhancement in this regard, overall I agree with Eset's approach. It is designed to prevent a user from creating an ask rule that due to; Eset GUI not fully initialized at boot time Non-response due to user physically not present at device that could inadvertently lead to critical system/app function being blocked leaving the system inoperable. However, the fact remains that the default allowed activity could have been malicious or suspicious in nature and needs user review. I therefore propose the following HIPS enhancement as far as default allow ask rule activity: 1. All such ask rules are logged in the HIPS log. 2. Eset display a non-expiring desktop alert that such default activity has occurred. At boot time, this could be done after the Eset GUI is fully initialized. The alert does not have to more than a notification that such default behavior occurred. This would alleviate one constantly reviewing the HIPS logs for such activity assuming he previously set logging to the correct level to capture such default activity.

A security analyst a while back wrote a blog posting about Barkley's Stackhackr simulator . The blog is titled 'Security Through Absurdity'. I am posting excerpts below but you really should read the entire article. Overall, chalk this one up as more Next Gen marketing FUD: http://randy-abrams.blogspot.com/2017/07/stackhackr-useless-for-testing-good-for.html

Try this. The below screen shot is for EIS. I believe there is a like setting in ESS. Disable; i.e. uncheck mark, "Notify about newly discovered network devices."

I get an Eset PUA alert on that web site. This would indicate it is trying to download something nefarious to the user's device.

Talk about a useless test. My Eset HIPS rule to monitor script execution easily detected it: Also of note is LiveGrid submission of launcher.exe to Eset's cloud servers upon its execution. -EDIT- Blocking criteria used. Unknown executable (to me) running from C:\Users\xxxx\Downloads\ directory is attempting to launch a script.

English translation is:

Was the folder you scanned an archive?

I will say this. I had a similar browser based HTML detection using EIS last month. I posted on the forum about it because I had two questions. The first was why the log entry for it showed no action taken and the entry was shown in red color. As this: https://forum.eset.com/topic/17986-detected-threat-shows-in-red/?do=findComment&comment=88763 shows, Eset Web Protection which I have the ThreatSense setting set to Normal protection cleaned the threat with no user interaction required. As for no Eset quarantine event being recorded, I assumed this was correct since nothing ever hit the disk to be captured. I am still puzzled why the log event showed no action. As to the red color of the log entry, I never received a response.

The web site is not accessible; 404 error - page not found.

As far as I am aware of in regards to 1809, you should be seeing a Windows firewall setting as shown in the screen shot I previously posted. Refer to the below screen shot. Open Windows Security Center. Then select "Firewall & network protection" -> click on "Manage providers." In the Firewall section it should show that the Eset firewall is turned on and the Windows firewall is off. Also for reference, the Windows firewall is not completely disabled. Only the portion that controls monitoring actions by its rules are disabled. If the Eset firewall is used with default settings, Eset will also use the Windows firewall inbound rules but under the control of its firewall processing.

The screen shot you posted is from the Windows Defender Firewall section of Control Panel. It also appears the ver. of Windows 10 you are running is not 1809. Earlier vers. of Win 10 had such a display. The screen shot I posted is from Win 10 1809. In any case, I don't see a problem with your installation. Eset is managing the Win firewall settings as should be.

Post the screen shot in your reply. Only Eset mods now have access to attachments.

You should see what is shown in the below screen shot when Eset has been successfully registered in the Windows Security Center. Suggest you uninstall Eset, reboot, and then reinstall it. Make sure you export your Eset settings prior to uninstall if you have created customized settings. You can then import these after Eset has been reinstalled. Hopefully, Eset will be successfully registered in Windows Security Center upon reinstall. -EDIT- Prior to doing the above, you can try this to see if it resolves the issue since it appears you are running Win 10 1809. In Windows Security Center, click on "Firewall & network protection." On the right hand of the shown screen, click on "Manage providers." In the shown Security Providers screen, go to Firewall section. There should be a option shown that will display the current Windows firewall status. Try to turn it off by clicking on the "Turn off" tab. If successful, then reboot and see if the below screen shot is shown in Control Panel -> Windows Defender Firewall.

Here's a web site that lists live real phishing web sites: https://www.phishtank.com/phish_search.php?valid=y&active=All&Search=Search . I picked the first one which happens to be a HTTP web site and was just listed today. Eset IS 12.0.31 on Win 10 detected it!

This publication: https://euroscug.org/wp-content/uploads/2017/11/Windows-10-Controlled-Folder-Access_1_3.pdf is worth a read in noting that WD's Controlled Folders feature is far from without out issues. These range from minimally missing desktop icons upon program installation processing completion to apps not being able to run subsequently.

Let me give you an example of the problems one can run into if they don't have in depth OS operational knowledge. There are hidden OS used files in AppData directories. Desktop.ini is an example of one and it is constantly being updated. So as far as doing monitoring of controlled folders goes if you would have stuck to My Documents, Downloads, Photos, etc. folders, you probably wouldn't have run into issues.

"The moral of this story" is if you don't understand how something works, you run the risk of severe damage if you fool around with it. As a rule, I don't create block rules with the HIPS but only ask rules. Also one should experiment with a few non-critical files/directories/etc. prior to attempting restrictive activities against critical system and an app executables and files. Also, Eset did not create the HIPS for user interaction with it. Its primary purpose is self-protection use and protection for a few critical system and registry areas. As such, you will not receive any official guidance in the creation of HIPS rules other than a few Eset KB articles on ransomware rules directed to users of the Endpoint product.

Turned on logging on that rule for a while. Whatever I observed in the past in regards to it is not occurring in the current Eset ver.. So ignore my previous comments.

I also don't understand why anyone would want to use MBAM in realtime mode. In any AV lab test of it I have reviewed, it always comes in last; example here: https://www.av-test.org/en/antivirus/home-windows/

Does this not also block Eset proxy traffic? That was my experience in the past when I disabled the default rule.

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.