itman

I will also add that it would be very helpful if Eset would display in the HIPS what the HIPS default rules are under the auto and smart modes. Or alternatively, publish same in a help document or the like. Eset stores those default rules in a .bin file which makes it impossible to see what rules are being executed by default. I know of no other security vendor that employs a HIPS that doesn't not display its default rules. It makes it impossible to prevent duplicate user rules from being created for which Eset default rules already exist.

Yes, that is exactly what I am saying. First, I am not going to post my detail HIPS rules via attachment of the .xml backup file publicly for obvious reasons. Below is a screen shot of the way HIPS rules are ordered in ver. 8. Note they are sorted alphabetically. Also as best as I can determine, they are executed in top to bottom order. At the minimum, allow rules are executed before block rules. After the conversion to ver. 9, all the HIPS rules are reordered in a jumbled fashion with allow and block rules appearing in some unknown order. This makes maintenance extremely difficult. Initially, I also believed this was also affecting the order in which the rules were executing. However, most of the rules were behaving the same in ver. 9 but I was still receiving alerts on activity that was previously allowed in ver. 8. Worse, the alerts were unrelated to the activity being performed. For example as stated previously and belaboring the point, I have two browser related rules that control its startup. The first rule allows which processes are allowed to start the browser. The second rule is an ask rule that monitors the startup of browser by any other process. The ask rule for some reason in ver. 9 was being triggered by unrelated activity e.g. svchost.exe startup of wmiprvse.exe. Worse the triggering was random and not being done upon every execution of svchost.exe startup of wmiprvse.exe. This is only one example of much more erratic and inconsistent behavior I observed in the ver. 9 HIPS.

Against my better judgment, I decided to try the latest ver. of SS 9 again .............. under the assumption the HIPS issues were resolved. Well, they are not and I am definitely not a "happy Eset camper!" For starters, the existing ver. 8 rules end up a jumbled mess of allow and block rules instead of being sorted alphabetically as done in ver. 8. Far worse, many of my existing ver. 8 rules did not function properly in ver. 9. For starters, I monitor a few selected processes startup. One is my browser, IE11. For some unknown reason and most notable that rule was being triggered for a number of system processes startups e.g. svchost.exe startup of wmiprvse.exe, etc., etc.. And the list of "borked" rule executions goes on and on. My existing HIPS rules ver. 8 work flawlessly and I expect the same from ver. 9. It is bad enough that the metro interface used by ver. 9 makes HIPS rule creation more burdensome to say the least. Obviously, whoever designed the ver. 9 GUI was not a technician and definitely not a power user. And not providing a way to at least to sort or reorder HIPS rules is inexcusable. It appears that Eset may not be aware of the fact that a number of its customers specifically use NOD32 or Smart Security for its HIPS feature?

I did. It stated something to the effect that unsolicited inbound TCP packets were blocked which to me means that these were not a result of any outbound initiated communication i.e. they were not statefull responses. Makes me wonder if a firewall rule is needed to allow all inbound traffic for ekrn.exe. And still doesn't explain why the traffic is occurring? Doesn't matter now since I reverted back again ............... to ver. 8 due to numerous ver. 9 HIPS issues that still exist.

Win 7 SP1, x64 and Eset Smart Security 9.0.377.0 Reinstalled ver. 9 last night to see if issues fixed from the initial release. Having HIPS issues but will post those in a separate reply one I shake down things for a while. One thing that caught my eye immediately is the number of dropped incoming connections from Eset's U.S. server. See the below screen shot. I suspect this is related to Eset's SSL protocol scanning for cert. pinning? Question is why are these un-statefull inbound connections from Eset occurring and is this normal behavior? I am sure these connections are from browsing activity since the number increases whenever a browsing session is initiated. Also, Eset sig. updating so far appears to be fine.

Yes, that is normal behavior. Eset doesn't support Thunderbird's latter versions as far as browser integration goes.

Appears the web site you are viewing is not https://weather.com:

NOD32 has no firewall as stated but it does install a NDIS mini-port filter on the network connection that is used by the web protocol filtering feature. My gut tells me that is the issue somehow in this case.

Came across this posting on the Win 7 forums: hxxp://www.sevenforums.com/general-discussion/201140-unravelling-csrss-exe-new-process-architecture-windows-7-a-2.html?s=b503c5aeabda69daa47dc871b7d70e44 Appears it is not uncommon for some games to want to load themselves as a subprocess under csrss.exe. This is probably the explanation for the Eset HIPS log messages about csrss.exe process modification attempts. This is definitely not normal or safe behavior but games do all kinds of stuff that is not normal system behavior.

More on Steam malware here: https://threatpost.com/steam-stealer-malware-booming-business-for-attackers-targeting-gaming-service/116792/

I will also add that when you enable the HIPS log blocked activity option, you will see a lot of entries for legit system activities being blocked for Eset self-defense protection. I enabled that logging option and observed a "slew" of "partial access allowed" log entries originating from svchost.exe against every file in every directory associated with Eset including every Eset driver file. I had a hunch what this was about. Subsequent analysis of my Win 7 event logs confirmed my hunch. If you haven't guessed yet what svchost.exe was doing, defrag was running. Kind of neat though to see Eset's self-protection in action.

Looks like Steam is the culprit: https://support.steampowered.com/kb_article.php?ref=9828-SFLZ-9289 . They basically want you to allow Steam to do whatever it wants by creating exceptions for it in your security software. After witnessing first hand what is does, I wouldn't have it on my PC.

With Microsoft's announcement of this .dll "patching" malware: https://blogs.technet.microsoft.com/mmpc/2016/04/26/digging-deep-for-platinum/ , I strongly suggest Eset add global root modification detection against knowndlls and knowndlls32 tables ASAP. When I did testing using the old Comodo Leak Test, ver. 8 failed the knowndlls modification test.

I would say this would be the only legit access activity to modify equi.exe and ekrn.exe. And only with limited activity. For example in ver. 8, equi.exe runs under explorer.exe. I use Emsisoft's Anti-malware which injects its monitoring hook into explorer.exe. As a result when equi.exe is started by explorer.exe, EAM's hook is injected into equi.exe. This is allowed since I created a specific user HIPS exclusion rule to allow all activity from EAM's processes to avoid conflict between EAM and Eset. On the other hand, ekrn.exe runs as separate service. As such, there is no attempted hook injection by EAM.

Is squad.exe your game? I am not a gamer but I would not let any application modify csrss.exe. Squad.exe is trying to modify csrss.exe. Also it is csrss.exe that is trying to modify equi.exe and ekrn.exe. That is not normal behavior. Maybe a gamer can shed some light on if this is normal behavior? I know I would never allow it. You might want an Eset malware specialist to review this HIPS log.

To my best knowledge, no system process should be modifying equi.exe or ekrn.exe for that matter. I have a specific HIPS rule for both to prevent global hooking, event interception, and state modification and have never received any alerts. Most definitely, csrss.exe should not be modifying equi.exe. Also your video games should not be modifying system or Eset processes. Best you copy the entries in the HIPS log that apply to the above and post in this thread. That way verification can be made if it is actually modification activity that is occurring.

There have been past instances with Chrome and it opening by itself as mentioned previous: hxxp://www.techrepublic.com/blog/google-in-the-enterprise/the-google-chrome-startup-mystery-troubleshooting-the-ghost-in-the-machine/ . I believe this instance was caused by a "borked" Chrome update. So I would strongly suspect the issue to be Chrome related. I would look at your Chrome logs for anything abnormal. If all else fails, you can always reinstall Chrome.

Last entry in the url log file looks "hosed" to me: h t t p : / / w w w . g o o g l e . c o m / u r l ? s a = t & r c t = j & q = & e s r c = s & s o u r c e = w e b & c d = 7 4 & v e d = 0 a h U K E w i N 9 t X L 8 K L M A h V M F z 4 K H T J A A c 4 4 R h A W C C 8 w A w & u r l = h t t p : / / w w w . n s a n e d o w n . c o m / ? n e w s = 2 5 2 5 4 6 4 2 6 & u s g = A F Q j C N H V P 8 h B b V _ F 3 q s q L c 8 C 4 s V K _ N b 9 m w C : \ P r o g r a m F i l e s \ I n t e r n e t E x p l o r e r \ i e x p l o r e . e x e

Did you remove all traces of Norton Internet Security before installing Eset? That would include running its "cleaner tool" after uninstalling via the Windows method.

This appears to have started recently. When accessing the "Filtered Web Sites" log file via Smart Security GUI view log files option, Eset's GUI freezes on my desktop and cannot be shutdown. Only way to get rid of the Eset GUI window is to reboot the PC. What is really strange is access to all the other log files is fine w/o GUI issues. Should I just delete that log file manually? What is its file name and directory location? -EDIT- The Filtered Web Site log was updated yesterday with an IP blacklist detection. Might be a problem with the way that module writes to the log file?

Eset's Web Protocol Filtering feature by default checks incoming port 80 traffic for malware. The only way to stop this is to exclude the application from like scanning. Doing so puts you at risk since the purpose of Web Protocol Filtering is to scan download traffic at the network level prior to its arrival and storage on your hard drive. So you will have to evaluate whether the elimination of the "annoyance" you mention is worth the risk. BTW - You do not want to "Temporarily Disable Protection" to speed up your downloads!

I came across an interesting posting over at bleepingcomputer.com who is running point on the fight against ransomware malware. Note that only two mainstream AV/anti-malware products were recommended for ransomware protection and Eset was one of them: hxxp://www.bleepingcomputer.com/forums/t/611096/has-ransomware-become-uncatchable-with-todays-av/?p=3979209

Check if Eset set up your firewall protection mode as "Home/work network" as shown in the below screen shot. Note: picture shows ver. 8 settings; will be slightly different in ver. 9. If not set as "Home/work network," change it to that, reboot, and see if that solves the problem:

Appears OP is having a problem getting a valid IP address assigned via DHCP from his ISP. The high number of an APIPA range IP address assignments, i.e. 169.254.1.99, points to that. Don't know why the inbound UDP port is 21302 though. ARRIS Group appears to be his ISP. I believe 192.168.1.1 is the DHCP server IP address on the router. Might also be an issue with the Actiontec router firewall if it has one. Please post a screen shot of your zones settings in the zone and rule setup section of Eset Network setup area.

Agree 100%.