itman

I second this. I believe this current Eset HIPS behavior stated in ver. 9 when the Metro GUI was introduced much to many dislike of it. In ver. 8 as I recollect, the HIPS did remember what the last selected directory was in rule creation and auto navigated to it when adding a new application.

Downloading software "cracker's" BTW is always a bad idea as noted in this Microsoft write up: https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=HackTool:Win32/Patch Also in the event you do get hacked by such a download, many security forums will refuse to help you in mitigation efforts.

One other comment about this hd.sentinel.pro.4.x-patch.exe file you downloaded. Appears you wanted to download the portable version of HD Sentinel Pro? Portable versions are downloaded in a compressed file format e.g. .zip, .rar, etc. and the file "extracted" to a new folder in the download directory. The extracted folder contents contain all the files need to run the application without making any system area modifications. The file you downloaded was a .exe which was a clear indication that something was not right with your download.

In regards to this, the Eset router scan feature is only applicable to when your network connection is set to "Home/Office" profile. You should have received a warning from Eset to this effect when you attempted to perform the scan. As such, I believe the above message you received is not applicable. In other words, the router scanning feature can not diagnose router issues or vulnerabilities when in public profile mode. Next time you receive a redirection or like alert from Eset, post a screen shot of the alert received and we'll take it from there.

This is for general information. The .exe in question can best be described as a "proprietary" installer. What developers do is pack all their installation files along with an extractor .exe into a single executable. When this file runs it in turn runs the extractor program which first unpacks all the files and then stores them in the proper directories on your system. Because all the source files are packed in a proprietary format, AV scanners on download cannot unpack those files to scan them via signature detection as they can do against files created by public domain archiving programs create like .zip, .rar, etc.. Therefore, AV scanners have to wait until the installer is run to scan the files as they are unpacked. Eset employs its heuristic scanner for this processing which sandboxes anything the installer is extracting preventing any installation and execution of those files until they have been signature scanned. What NOD32 detected on VT was one of .exe's within the application as a potentially unsafe application I believe. VoodooShield on the other hand does not use signatures but machine learned rules and the like. When a file is downloaded, it immediately executes it in its sandbox and makes a "good ,maybe OK, or bad" determination on the application overall. -EDIT- This determination is also conditioned by submitting the file to VirusTotal for a manual scan by all the AV product engines listed there. This is in all likelihood how the .exe file was determined to be malicious. Eset on the other hand and as previously noted can differentiate between the good and bad processes within the application and only allow the good processes to be installed. This in effect allows the user to use the application but exclude its undesirable features such as adware and the like.

The way Eset works in regards to a PUA is to remove and quarantine the "offending" parts of installation and leave the rest proceed thereby allowing for the app to be used if possible. VoodooShield used the "hatchet approach" and just blocked the entire installation.

A few comments about the issue of hd.sentinel.pro.4.x-patch.exe detection. The VT analysis shows that NOD32 detects it as a potentially unsafe application(PUA). As such, neither NOD32 or Smart Security would have detected this status until the .exe was actually executed. Did you actually try to execute it with Smart Security? If you did execute it and it was not detected, did you verify in the Eset GUI Antivirus Scanner settings that all the following settings are check marked? Enable detection of : potentially unwanted applications potentially unsafe applications suspicious applications

You should never use more than one realtime AV scanner. Both will invariably conflict and you could actually reduce your malware detection capabilities. This has been the recommended procedure for many years. Additionally, some AV products in the past were designed to be compatible with other like products either out-of-the box or with minor configuration changes. Such is not the case today with almost all AV vendors recommending use of only one realtime scanner. Most will flat out state if asked that they do not guaranty compatibility with other realtime AV scanners. Also, I believe the later releases of Win 10 will not allow more than one realtime AV scanner and will auto disable any realtime scanning in same upon product installation. If anyone wants to use an excellent free on-demand scanner, use Kaspersky anti-virus(KAV).

Is this a stand-alone PC or is it part of a HomeGroup or other type of network? Make sure your router has not be hacked. What is your Eset firewall network profile - public or home/office network? What ver. of Windows are you using and what type; Home, Pro, etc..

More likely, they would instead try to bypass the AV protection; either by not running the malware itself or disabling the AV protection. On the later point, Eset has that well covered on Win 10. We'll have to see how this recent Windows Defender feature plays out. There is already active discussion on the various security forums that based on recent AV lab tests alone, many are seriously considering or are "dumping" their paid third party AV solutions for WD. This "plays nicely" strategy-wise for them since many of those folks are presently using a paid anti-exec solution such as AppGuard.

Unfortunately, "that the rub." No one has to convince me that Eset has the best generic signature detection in the business. However, there are malware that are coded from scratch and the only way those can be monitored for suspicious activities is via execution; not just initially but continuously until sufficient reputational data can be gained to deem the process safe. As far as next gen/AI monitoring as the sole anti-malware mechanism, it is not recommended today and will not be so until enough empirical data over time has proven its effectiveness. However other AV vendors; Symantec, Bitdefender, and Kaspersky to name a few, are using it currently as supplemental detection against unknown processes in exactly the same as Windows Defender is on Win 10 CE.

Yes, I realize that. The difference is MS is using the latest AI/Next Gen probabilistic algorithims to arrive at a "safe" decision. Again like I said, "time will tell" on its effectiveness.

Today Microsoft announced that for WIn 10 CE, all unknown processes will be scanned in Windows Defender via behavior analysis on their cloud servers . An interesting option is scan duration is configurable to allow for more thorough scanning. Ref.: https://blogs.technet.microsoft.com/mmpc/2017/07/18/windows-defender-antivirus-cloud-protection-service-advanced-real-time-defense-against-never-before-seen-malware/?platform=hootsuite "Time will tell" on its overall effectiveness. But this does "up the bar" for third party AV vendors including Eset to do so the same in their reputational scanners. One problem I do see is "sleeper" malware that for example delays its execution of malicious activities for a set interval of time. Case in point is recent ransomware strains that perform like activities.

I still get "an occasional" hang in IE11. When this happens, I just delete all temp files, etc. via IE11 Tools -> delete browser history and things fine after that. Seems to happen when accessing non-U.S. based web sites. For example prior to switching DNS provider, I was having repeated issues with this forum web site. Perhaps cloudfront frontend server checking is the culprit?

Was also having same behavior using IE11 on Win 10. Try as I might, could not resolve the issue. Switched to a third party DNS provider and the problem is gone. I would be suspicious of one's ISP in light of the recent U.S. reversal of data harvesting by the current administration.