itman

I explained this once to you. Eset has internal default rules and those rules take precedence to any user created rules. Also if an alert response is not received within a short period of time, Eset will auto allow the action. This comes into play for example with any ask rule that might be triggered during the boot process. Those will be allowed by the time the PC initializes, the desktop appears, and finally the Eset GUI is started.

Nvidia in their "infinite security wisdom" created two .bat scripts they dumped in C:\Windows directory. Their startup service can run these .bat scripts if errors are encountered in their software as recovery procedures. So basically, you have to allow svchost.exe to run cmd.exe. Not the most secure thing to do if malware creates a malicious service. Hence my recommendation that file wildcard support is needed. There is also the issue of why the HIPS hasn't been updated to reflect Win 10's current ability to uniquely identify an individual svchost.exe service by process id.

You need to be more specific on what you are trying to do. Give an example. One issue I have in regards to the cmd.exe is that there is no way to restrict what .bat files it can execute. A "target" in a HIPS rule has to be an application - period. This could be accomplished if the HIPS provided a read restriction in the Files section. I really don't know why read restriction capability was never added. Every other HIPS I have used in the past had the capability. I will also add that file wildcard capability which I have repeated asked for needs to be added to make this capability functional. The following is example rules. 1. Allow cmd.exe to read xyz.bat. 2. Block/ask cmd.exe to read C:\*\*.bat; where C:\* would mean the drive root directory and all subdirectories.

Yeah, I know about this. Just be careful with GitHub software. Being open source, it can be hacked. One of the major sources of nasty backdoors has been GitHub software.

As far as anti-exec processing, there is a one built into Win 10 - native SmartScreen. I have tested with a couple of unknown reputation files and each time got an alert from it when they tried to run. Eset let the files run w/o issue. Neither file was malicious but I prefer an option to disallow execution in this instance. The downside is native SmartScreen relies on "The Mark of the Web" remaining associated with the downloaded file. There are ways to "strip that off" of a download.

I did some of my own testing in regards to this business about the HIPS not detecting Farber activity. For starters, I set the HIPS to Interactive mode and then ran Farbar. To begin with, Farbar will load and begin execution because you started it manually. However, the first attempt by Farbar to perform any activity the HIPS monitors for will cause an alert as shown by the below screen shot. Now if you create a .bat script and run Farbar by execution of the script, you will receive a HIPS alert about the startup of Farbar. Likewise, malware doesn't magically run by itself. Something has to execute it.

I have run Farbar in the past and Eset HIPS in Auto or Safe mode will not alert because its a safe app. Are you saying that the HIPS in Interactive or Policy mode is not throwing an alert at Farber startup time?

You will need to show an example of an .exe that Eset HIPS did not detect running in Interactive mode. The only way I know that could occur is if you inadvertently created an allow rule while running in Training mode or by manual creation. One possibility for example is that an allow rule was created for a process to start another process. If the allow rule did not specifically state what process start up was allowed, then Eset will allow any child process startup from the parent process.

In the example of lets say a command shell executing powershell, cmd.exe starts up conhost.exe. Conhost.exe is the process that actually starts up powershell.exe. So creating a HIPS rule to monitor what conhost.exe starts up will give you the information your seeking.

You never posted the screen shot. Needed to further diagnose the issue.

Check that Window's clock shows the correct time. Also if the backup battery on your motherboard goes back, time settings in the BIOS are not maintained causing Windows to reset it which may not be done automatically on Win 7. I assume the repair tech did check the battery? To be sure, ask him.

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.

Go into each sub-section. For example, real-time protection. The "curved arrow" default setting option is there for it in Smart Security.

It is not enabled for Eset browser adds-ons/plug-ins; at least for IE11. I am on ver. 10.1.210. Suspect same applies to Outlook. Will check other areas and report back if I find more. -EDIT- None of Eset program module .dlls i.e. em0xxx_64.dll are compiled with CFG. Granted they only exist in equi.exe I believe, but that is not a protected process like ekrn.exe. Additionally, none if Eset's drivers are complied with CFG.

Please compile Eset .dlls with CFG support ASAP so that they can't be exploited by a ROP bypass as noted here: https://improsec.com/blog//bypassing-control-flow-guard-on-windows-10-part-ii

It was better today; connected right away. Also ekrn.exe connections were less but numbered around 20. Why all the ekrn.exe connections? That is what is strange to me.

I have been plagued with this issue for some time. Whenever I connect to the Eset forum the first time after a cold boot using IE11, the forum takes a long time to display its web page. Like 30 secs. or so. I took a screen shot using TCPView of what is going on. What are all these ekrn.exe connections to a Cloudfront server I assume is hosting Eset forum content about?

How about adding a HIPS profile option? One thing that I dislike about the HIPS is it lacks features like Comodo's Defense+ where options like Windows Update and Trusted Installer modes are provided. One can easily switch to those modes when doing like activities thereby preventing existing user HIPS rules from interfering with these processes activities. It dawned on me that the same could be accomplished in Eset, I believe fairly easily, by allowing for like profiles for the HIPS to be created. A profile in its simplest form could be just to specify Eset default HIPS rules. The user could then just switch to this profile via HIPS GUI option prior to performing Win updating and then switch back to his existing HIPS rules profile upon completion of Win updating activities. Ideally, the HIPS profile option could be specified on the Eset desktop icon GUI selection options.

In regards to the recent publicized Cybellum bypass of AV vendors self-protection mechanisms, I will state this won't be the last attempt by Next Gen AI startups to discredit the establishment AV vendors. What I suggest is Eset add a new detection category along the lines of the existing PUA/PUP detection. The category will be for potentially unwanted system utility applications i.e. PUS. This should cover all Windows system utilities that are not installed by default and not applicable to retail versions of Windows. This includes not only Application Verifier but apps like PsExec, etc.. I envision this as an optional GUI setting like the existing PUA setting is. Operation would also be identical in that if the system utility was detected by hash, an alert would be generated where the user could allow or deny its execution. If denied, the utility would be removed from the system. Since these system utilities might be employed in commercial environments, I see this option applying to retail versions of Eset only.

No problem on my PC. You having problems with password entry on any other web sites?

In IE11, there really are no direct settings to control font usage other than to permit font downloads which is enabled. However in Win 10, fontdrvhost.exe does run in AppContainer which might not be 100% compatible w/IE11 since again, there is no issue when using Edge.

You don't. You can get a new license directly from Eset or any one of its authorized distributors.

My comment in regards to Adguard is do you really want it intercepting and decrypting SSL traffic? Eset's SSL protocol scanning is already doing that and examining such traffic for malware. Adguard in the past has not properly performed SSL scanning as noted here: Different certificate, same key The first thing I did was to install Adguard two times in different VMs and look at the root certificate that got installed into the browser. The fingerprint of the certificates was different. However a closer look revealed something interesting: The RSA modulus was the same. It turned out that Adguard created a new root certificate with a changing serial number for every installation, but it didn't generate a new key. Therefore it is vulnerable to the same attacks as Superfish. I reported this issue to Adguard. Adguard has fixed this issue, however they still intercept HTTPS traffic. I learned that Adguard did not always use the same key, instead it chose one out of ten different keys based on the CPU. All ten keys could easily be extracted from a file called ProtocolFilters.dll that was shipped with Adguard. Older versions of Adguard only used one key shared amongst all installations. There also was a very outdated copy of the nss library. It suffers from various vulnerabilities, however it seems they are not exploitable. The library is not used for TLS connections, its only job is to install certificates into the Firefox root store. Ref.: https://blog.hboeck.de/archives/874-More-TLS-Man-in-the-Middle-failures-Adguard,-Privdog-again-and-ProtocolFilters.dll.html

Please post a "sticky" in this forum and the NOD32 one that Eset's SSL Protocol scanning feature is not compatible with any other security software that does the same and list examples of such software e.g. Ad-Aware Web Filtering Adguard install version NetNanny etc.. The wording should state that either the software must be uninstalled or the HTTPS scanning option in the software disabled. Also add such verbage to Eset's help documentation. This will help in resolved issues with SSL protocol scanning in the Forums.

Plus the pin and lock symbols are missing ..................... I just fired up Edge and all these "exotic" features are present. Perhaps these graphics have something to do with DCOM storage which I have set 0 btyes or saving encrypted web pages to disk which I have disabled in IE11? If someone can ID what method these graphics are using, I could explore what settings in IE11 affect those.