itman

You can, but not recommended. Also, they run at low priority and only scan commonly used files:

Here's your choices: 1. Keep adding IP address to block with your existing Eset firewall rule whenever an Eset popup alert appear with a new IP address. 2. "Live with" the existing Eset alerts. 3. Remove the Chrome extension.

No problem here with latest Firefox ver.:

"My take" on this runtc.net issue is that it is some type of redirect tracker interception. Who is "infamous" for tracking activities - Google.

https://www.petri.com/microsofts-upcoming-chromuim-based-edge-browser-has-few-features-for-the-enterprise In other words, the new Edge browers will employ the same security features as the old Edge browser.

To begin with, Eset HIPS doesn't official support "\\" notation in a path name. If it works, it would only apply to the immediate path specified. In other words in your example for the C:\Users directory, but not for any subordinate directories specified within the C:\Users directory.

Forum attachments can only be read by Eset moderators. If that that doesn't suffice, upload logs to a file share of your choice and PM both the link to the logs on the file share service.

Guess I am not following you on this one. Each time you export your settings, a new .xml file is created. Just import the latest .xml file you created.

Interesting. That was my number one suspect initially.

My "two cents" observation in regards to PUA Chrome extensions and the like is Eset is excellent at detecting and eliminating then at attempted installation time. If however they get installed through either lack of detection, user allowing the install, etc, then it's an entirely different matter removing them when subsequently later detected via Realtime scanning. Even Eset's own KB articles on the same indicate that manual removal of the extension/s is required.

Looks like I was right about my suspicions about getclicky.com: https://www.threatcrowd.org/domain.php?domain=getclicky.com

Yes, since it appears the alerts are being generated by one of those add-ons.

My best guess at this point is the issue is on the user's end. Ask if he/she is from Peru. This Eset detection has so far been largely related to connections originating from that country. Very possible is the user has DNS hijack issues, whatever. They try to connect to your site but are being redirected to a site containing Javascript that Eset detects as JS/Agent.OCJ. As @Marcos just replied, we need a screen shot from the user's Eset Filtered Websites log that shows the URL/IP address associated with the alert.

I disabled uBlock for your site and FireFox itself blocked getclicky.com. So my money is still on that as the source. Find out what browse/app the person was using when he received the Eset alert. Also, Eset might be throwing this detection in response to this issue: https://www.bleepingcomputer.com/news/security/windows-10-apps-hit-by-malicious-ads-that-blockers-wont-stop/

I am not getting any Eset alerts for this web site using Firefox. I am however using uBlock Origin and it is blocking at least 7 things on your web site. This leads me to believe the issue might the ads, trackers, etc. being displayed/used on the site. -EDIT- Primary suspect is getclicky.com. Other suspects are metrics.api.drift.com and event.api.drift.com. And it goes w/o saying that google-analytics is being used.

As far as preventing installation of malicious chrome extensions, they and add-on installations need to be managed via policy methods. Here's an article on how to do so: http://woshub.com/how-to-configure-google-chrome-via-group-policies/ . As far as Eset goes, do you have for Real-time file system protection -> Detection Engine -> Scanner Options all the following enabled on the endpoints? Detection of potentially unwanted applications Detection of potentially unsafe applications Detection of suspicious applications If the above are all enabled, you can set Real-time protection ThreatSense -> Parameters -> Cleaning level to "Strict clearing." Doing so will eliminate any PUA pop-ups from Eset on the endpoints requiring user action and automatically delete and quarantine the file.

Some "free press" courtesy of bleepingcomputer.com: Windows 10 Apps Hit by Malicious Ads that Blockers Won't Stop https://www.bleepingcomputer.com/news/security/windows-10-apps-hit-by-malicious-ads-that-blockers-wont-stop/

As far as blocking telnet, see this thread: https://forum.eset.com/topic/19638-unsual-open-network-services-notification/?tab=comments#comment-95738 To begin with, most routers with IDS capabiity will block telnet inbound traffic by default. As far as Eset firewall goes, you have two choices: 1. Block all inbound/oubound port 23 communication. This will stop most but not all telnet traffic. 2. Create 15 Eset firewall rules; one for each of the 15 protocol numbers, 240 - 255, associated with telnet , blocking all inbound/oubound traffic from same.

See this thread: https://forum.eset.com/topic/19081-jsspigotb/ . Also refer to the Eset knowledgebase article link I posted in the thread.

It is a "smart" signature detection. Rather than relying on a 100% signature malicious code match, DNA signatures will triggering on code "snippets" known to be malicious. This way polymorphic malware, that is malware that alters its code to avoid hash detection methods, can be detected. Additionally, DNA signatures also employ "YARA" like behavior rules that can detect known malicious process activities.

What is your endpoint version? Ver. 7 has Ransomware Shield protection: https://support.eset.com/en_EN/kb6803/?locale=en_EN&viewlocale=en_US

Why this would even be remotely related to adding Eset's root CA certificate to non-Microsoft browsers really needs to elaborated upon. As far as Edge and I also assume IE11, I can't see how it's related at all. Both those browsers use Windows root CA certifcate store. The Eset root CA certificate is added to that when Eset is installed.

As far as CVE-2019- 5675 goes, I believe it is fair to assume it is similar in nature to other DxgkDdiEscape vulnerabilities previously disclosed by Google's Project Zero: https://googleprojectzero.blogspot.com/2017/02/attacking-windows-nvidia-driver.html

Do this. Temporarily, disable all the add-ons in Chrome. If you no longer receive any blocked Eset Network log entries related to runtnc.net, you have found the source. Then one by one enable each add-on monitoring for any blocked Network log entries until you find the exact source of the activity.

It's enabled by default. Look under Internet Protection section in the Eset GUI to verify that it is.