itman

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.

Suspect the POC wasn't publically disclosed. In any case, a CVE would not have been issued unless there was supporting data. As far as I am aware of, there haven't been any public disclosure on any exploiting. The main issue is both of these vulnerabilities only need low privledge status to exploit. https://nvd.nist.gov/vuln/detail/CVE-2019-5675 https://nvd.nist.gov/vuln/detail/CVE-2019-5677

For reference: I am posting this since I assume many Eset users are using older Nvidia chipset graphics cards. Nvidia pretty much treats older cards as legacy. As such, they are no longer offering driver updates for these cards; even for critical security vulnerabilities such as noted previously. For example, the last available driver for my card is R390 dated Mar., 2018. This vulnerability affects all drivers prior to R430. Since these are device driver vulnerabilities, I realize there is only so much Eset can do protection-wise against kernel mode vulnerabilities. If it can't protect against these, I guess its time to purchase a new graphics card.

If you click on the Eset Virusradar prevalence map, this malware is very much localized to Peru. This is one possible explanation for lack of detection by the other AV vendors listed at VirusTotal. The malware signature just hasn't been uploaded to the malware feed sources these other AV's use. Or since the malware is localized and incident occurances might be low, the other AV vendors consider its malware detection of low significance. Also this malware appears to be web site Javascript based. If the other AV solutions do not employ active browser based Javascript web filtering such as Eset does, it would be another explanation for lack of detection.

Kaspersky forum also has a posting on this: https://forum.kaspersky.com/index.php?/topic/398092-sarahruntc-blocked/&do=findComment&comment=2815790 . You really have to do a thorough "house cleaning" on your PC; especially in regards to any programs you have installed in the last few months from questionable sources and that you really don't need. Then proceed to doing likewise for temp directories and browser add-on and extensions. Whatever this bugger is, it appears to "fly under the detection radar" of most security software.

You did manually enter the the proxy server name and port? I believe that is what @Marcos did versus using the "Detect" option. Also the default setting in the Eset Proxy section is to "Use a direct connection" if proxy server is not available. As such, no necessary Eset server communication such as LiveGrid, sig. updates, etc. should have been blocked.

By any chance are you using FireFox? From the below screen shot, it appears it is also using a localhost proxy to filter traffic. Perhaps the uBlock Origin or Decentraleyes add ons do that. Don't know if that is a possible factor in this behavior. I've also disable WebRTC, RTCPeerConnection:

Here's another possibility, Your router has been hacked with DNSChanger malware. Go to this website: http://www.dcwg.org/detect/ and click on any of the links shown. I didn't see anything posted for Slovak. So you will have use an English based site or perhaps German, if you're fluent in that language. Actually, just use this site for a check: http://www.dns-ok.us/

Referring back to your log entries, they all appear to be redirects to Amazon servers in the U.S. associated with Massachusetts Institute of Technology. For example, selecting the first two entries yields this from Robtex site lookup: M.I.T. is one of the premier technical universities in the world. It also does a lot of computer research and does like activities for the U.S. government. If the Eset alerts for this only occur on certain web sites, I would stay away from those sites.

Note the following from the NOD32 knowledgebase article link I posted previously: However in Win 10, proxy settings can be set globally for all network adapters:

Try another browser for a while; IE11, Edge, or Firefox. If there no Eset log entries generated for Amanda runtnc, then this confirms the issue is most likely a malicious Chrome extension or the like. Uninstall Chrome and do as @Marcos just posted recently. -EDIT- Also reviewing your prior posting, I assume you reinstalled Chrome after you performed the Win 10 reset option. When a Win 10 reset is performed, all existing user accounts and their related files and registry entries are left intact. If you now get blocked Amanda runtnc activity when using other browsers than Chrome, we can assume the source is related to your local admin account directories or registry entries given that is how you log on to Win 10. Before proposing more radical solutions, I would give both Malwarebytes anti-malware and AdwCleaner a shot to see if they can remove this. Make sure to disable Malwarebytes realtime scanning so it doesn't conflict's with Eset's like protection. Then run a scan with both to see if they can find and remove this Amanda runtnc baloney. Also have you run an "in-depth" scan with Eset to see if it detects and removes this? This should have run automatically after Eset was reinstalled after you performed the Win 10 reset.

As note in step 1)., the original Eset detections should be shown in the Eset Filtered Web Sites log. If you performed the instructions given in step 2)., any resultant detections will be shown in entries contained in the Eset Network protection log.

I am wondering if you had previously set up a proxy setting in Windows, forgot about it, and it is overriding Eset's proxy settings?

I can confirm that it doesn't work. When I had a weekly scheduled scan configured and it was missed due to a PC sleep status, the scan did not start upon PC power up. Nor did it start at next PC boot time.

More details here: https://blog.malwarebytes.com/detections/riskware-dontstealoursoftware/

One Million Devices Open to Wormable Microsoft BlueKeep Flaw https://threatpost.com/one-million-devices-open-to-wormable-microsoft-bluekeep-flaw/145113/

Appears Eset is following Windows conventions here in that a weekly scan means once every 7 days. Also appears scheduled date is only applicable if PC is powered up always on the specified date/time to run the scheduled scan. The solution to me is for Eset to just create a Win Task Manager task for scheduled scans. Then users could edit that "to their heart's content."