itman

I just started getting an inbound network alert on this at boot time: Time;Event;Source;Target;Protocol;Rule/worm name;Application;User 10/26/2015 2:03:12 PM; Decision on allowing communication delegated to user; Source 137.135.12.16:443; Destination 192.168.1.XX:49158; TCP; Allow communication for svchost.exe/Dhcp;C:\Windows\System32\svchost.exe;NT AUTHORITY\LOCAL SERVICE First, I know of any known instance why DHCP would use port 443. Is this possibly a bug by Eset? IP 137.135.12.16 resolves to either Microsoft or Eset. Also, this appears not to be a stateful connection since I assume I would not have received an inbound alert to a previously sent outbound request. Presently I am blocking this communication.

I have been running ver. 9 HIPS in learning mode for two days. Thought I would do that and then switch to interactive mode after a while since I can no longer create meaningful custom rules with this version. Guess what? In learning mode, the HIPS has started creating duplicate rules! And yes, I did verify that they were indeed duplicates. So eventually switching to interactive mode after the learning period is worthless since I will be getting constant alerts for processes that were already defined. So it is obvious no one at Eset has every tested all the features of the HIPS prior to this release.

Yes, the SSL protocol scanning issue is intermittent. One time when starting IE11, my home page, att.yahoo.com, will show the Eset root cert.. On most occasions it will not. Ditto for other HTTPS web site; no Eset root cert.. Also tried changing scan setting for IE from auto to scan with no change in behavior. Eset root cert. is properly installed in IE's root CA store.

You might want to create a separate topic for this issue.

When I installed ver. 9, Eset asked me to logon to the Anti-Theft site . Since I have an existing Eset logon and password that was created from the ver. 8 install, I used that. After the ver. 9 installation completed, I have no issues with an Anti-Theft warning. It is disabled in Eset and the warning message is indeed enabled. So the best I can speculate is perhaps this feature somehow requires an Eset logon and password although it is disabled? Go figure?

Update - I have decided to "play" with ver. 9 since I had already installed it. Exported my old settings for reference. Uninstalled the ver. 9 over ver.8 install and reinstalled ver. 9 fresh. Presently running HIPS in learning mode and will switch to interactive mode in a few days. Then I will see if I can try to incorporate some of my old custom rules. Doubt that will be possible since it appears that all rules are added at the bottom of existing rules ignoring their allow or block status. A real bummer for me since I had some real tight rules in ver. 9. Also this "fresh" install did nothing to correct the SSL protocol scanning issues I mentioned in another post.

I found the problem and it's pretty ugly. Also proves to me Eset hasn't thoroughly tested this version. Under ver. 8, allow rules executed before blocked rules. I don't know if that was because the rules were arranged in alphabetical order and executed top to bottom, etc.. In version 9, blocked rules appear interspersed with allow rules in what appears to be some random order? This issue coupled with SSL protocol scanning not working properly is the last straw for me. I will be restoring the image I took prior to ver. 9 install and plan on staying on that ver. until Eset gets their act together with the ver. 9 release. I also don't appreciate wasting my time on an untested product!

I don't think a reinstall would help. Later yesterday, the HIPS was creating duplicate/multiple rules for the same process and activity. If it doesn't settle down today, I am going back to ver. 8. I really hate the ver. 9 interface anyway. Like others have said, modification of rules and the like in this version appear to have been made intentionally hidden and difficult. I really don't need that kind of grief and aggravation in a security product.

Appears this is definitely an issue with VeriSign certificates. For example, Google search uses Eset's root cert. Also when I was using ver. 8, I would experience periodic IE 11 lock ups which I could never nail down. Now, I strongly suspect the issue was SSL protocol scanning conflicting with Versign's validation of root certificates. Presently, any site with a Versign root certificate is overriding use of Eset root cert.

No, still SSL Protocol scanning issues it appears. VeriSign is my DNS provider and it appears they are overriding Eset's cert. on sites where they issued the cert. Issue manifests for instance when returning back to my home page which is att.yahoo.net for example.

No way I am doing a clean install and have to recreate all my firewall and HIPS rules from scratch. I would go back to ver. 8 first. So far, no more HIPS alerts so I am hoping these initial ones were a fluke.

Under ver. 8 .319, I set HIPS to Smart mode and created my own rules. Since I installed ver. 9, I am getting HIPS alerts for actions that already have existing rules. I suspect it may be related to when multiple program source application entries exist for a single target program. Or Smart mode no longer works like it did under ver. 8 with user rules added?

Win 7 x64 SP1, IE11 Here's the situation. I had IE 11 Internet zone set to highest security settings. I included sites I trusted in the Trusted zone which was set at the Medium-High level. Under Eset ver. 8 .319 everything worked fine as far as SSL protocol scanning goes. After I installed ver. 9, I tried out the online banking protection for my bank's web site and could not log on. Went I hit the logon button after entering my user id and password nothing happened. Tried again, same thing. Next I openned IE11 in normal mode and I noticed no HTTPS sites were using the Eset cert.; they were all using their own certs.. So I reset IE's Internet zone settings to Medium-High level and all of a sudden SSL protocol scanning was functioning as it did under Eset ver, 8. Also ver. 9 online banking protection was working properly in that I could log onto my bank site in that mode. Looks like disabling all active content which IE's highest level security settings do, screwed up Eset's SSL protocol scanning.

I would give this a shot although I don't know if it would work with ver. 9. Eset Web and E-mail setup -> Protocol Filtering-> SSL -> Certificates "OK I went into ESET and unchecked "Add security certificate to known browsers", exited, re-entered ESET and rechecked the box and viola! It appears to be working again."

I got it to update after I rebooted. I have been playing with my DNS settings in the firewall. Created an outbound rule just to connect to my DNS servers and disabled the default DNS rule. Appears Eset didn't care for that since it wouldn't connect to DNS servers and threw an outbound alert at first boot. I allowed it but appears by this time it had blocked the Eset update connection. Don't know why my DNS created firewall didn't work however.

WIN 7 x64, SP1 - Eset Smart Security 8.0.319.0 Two auto updates have run so far today; the one after boot and the scheduled hourly update with no signature updating occurring. Never saw this happen before?

You sure what your using is not the "cracked" version? hxxp://xozen.blogspot.com/2015/04/leaked-full-version-of-nanocore-rat.html hxxp://www.herdprotect.com/nanocore.exe-e6c4bc39dd65fe8b41bb52823f06c4a2fefa26c5.aspx

Problem here is if it's cloaked malware some of which are sandbox aware, it could escape detection. The implication here is it is passes cloud and back-end scanning, the software will be whitelisted on your PC?

I assume this means firewall and hips rules, etc.? Definitely a no-go for me if true.

If I have a HIPS rule that protects a target process against "Modify state of another application", will it protect against these memory injection methods: VirtualAllocEx/VirtualFreeEx WriteProcessMemory CreateRemoteThread I believe it does but just want to verify.

Yes, Eset cert. is installed in Thunderbird. However, that is not the issue since that cert. is only used for web site validation. In default installation mode, Thunderbird will install the Mozilla Maintenance service and use that to perform silent background updating. In other words, it is using svchost.exe to connect to the Mozilla update servers. Since Eset's SSL protocol scanning is enabled for all port 443 communication, I assume the cert. being sent to those servers to establish a TLS session is the Eset root certificate from the Windows root CA store? I assume the Mozilla update servers would reject that cert. just like it does for a Firefox update? One solution is to just disable svchost.exe from all SSL protocol scanning. I just might do that since I believe there is also an issue with Adobe's ARM service and God knows what else. On the other hand if a malware service was to get installed, it could send encrypted ###### un-scanned and undetected. As far as Thunderbird goes, I now realize that using Mozilla's Maintenance service and allowing silent updating is a big security risk. In this mode, all UAC elevated prompting is bypassed. I have changed the update option in Thunderbird to "notify about updates." This method allows for updating via the thunderbird.exe process with elevated UAC prompt and the Mozilla Maintenance service is never started or used. Again I assume that thunderbird.exe will initiate the update server TLS handshake using the Eset root CA OS certificate and it will in turn be rejected. I have therefore excluded the following Mozilla certificates from SSL protocol scanning. The test will be when Mozilla serves up its next Thunderbird update. -EDIT- Further risks associated with using Mozilla Maintenance service noted here: https://wizzley.com/mozilla-maintenance-service-a-security-issue/ . Note that according to this article you have to either disable the service or uninstall it to actually prevent update downloads from the service.

::1 is IPv6 address for localhost. Also MS could be using IPv6 addresses if your router and ISP support IPv6.

Ref. https://forum.eset.com/topic/5556-new-malware-got-past-nod32/ Interesting. I had something similar happen but with a different twist. I use Thunderbird as my e-mail client. Recently I had Thunderbird open reading my e-mail and I received a pop-up about Thunderbird having blocked an invalid update. Posted this on the Mozilla TBird forum and mods there had no clue as to what that error message was or where it originated. And it gets stranger .......... I just recently discovered there is an issue with Mozilla updates for Firefox, Thunderbird, etc. if Eset SSL protocol filtering is enabled. Appears Mozilla rejects Eset's root certificate and no connection is allowed for updating and the like. Checking my Thunderbird update logs indeed showed I had not had an update since Eset had been installed. Fix is to exclude Mozilla certificates from Eset SSL protocol filtering which I have subsequently done. So either this failed update message was bogus; or an attempt had been made to actually update Thunderbird, the update was bogus, and thankfully Thunderbird rejected it. The referenced thread and my experience makes me wonder if perhaps a man-in-the-middle attack can occur when Eset's SSL protocol filtering does not work properly? Also of concern is that no diagnostic message from Eset is displayed when there is an issue with a web site accepting Eset's root certificate.

Eset Advanced setup -> Tools -> System updates -> No updates

Well, this explains why I haven't been receiving any Thunderbird updates since I installed Eset. Below is what I excluded when accessing update functions within Thunderbird. Only one I didn't exclude was for Google analytics since I assumed that was for tracking by Google. Is this enough to now start getting update notifications from Mozilla?