itman

A couple of things could be going on here. First, I don't use Outlook but instead use Thunderbird as my e-mail client. Below is a screen shot of Eset's default e-mail port settings: Note the default port settings for both IMAP and IMAPS. These must sync with your corresponding Outlook settings. If you are using IMAP which BTW does not support an encrypted SSL connection, then your Outlook same setting must be port 143. Also use of e-mail protocol is dictated by your ISP. For example, I can receive e-mail encrypted using IMAPS but have to send e-mail unencrypted using IMAP protocol. Additionally in Thunderbird, I need to set my email protocol to TLS/SSL for a IMAP connection. The SSL option is only supported for IMAPS. The Eset SSL protocol option determines whether or not your incoming encrypted e-mail i.e. IMAPS/POPS, will be unencrypted and scanned for malware. If SSL protocol scanning is turned on, the encrypted e-mail will be scanned; otherwise it will not be scanned. Using Thunderbird, this results in Eset inserting its root certificate in Thunderbird's root CA store. I believe Outlook might use Windows root CA store? If you received e-mail via IMAP, that e-mail will be automatically scanned by Eset w/o enabling Eset's SSL protocol scanning since it is unencrypted. Note enabling Eset's SSL protocol scanning will also result in all your Internet HTTPS connections being unencrypted and scanned for malware also. So be aware of that.

Those IP addressess trace back to China so I would be vigilant. Also if you don't have a router with NAT & SPI plus a firewall, I would consider investing in one.

Check out this posting: hxxp://www.sevenforums.com/windows-updates-activation/198811-windows-updates-windows-activation-error-code-80072efd.html Person did similar to you; reformat and OS reinstall. Below is what fixed it for him. Thank you Noel for your suggestions. Before I had a chance to try it though I was able to resolve the issue. I think I got one of those DNS changing viruses before my computer reformat. When I reset both the router and modem to factory settings, reset up my wireless network, and changed the usernames and passwords for both the modem and router I was able to access the windows update servers. I can't believe that after everything I tried I missed one of the easiest troubleshooting tasks! Thank you again for your help!

Pls hurry. Thank you.

As I stated previously in the "suggestions" thread, would like a tray option to disable/enable SSL protocol scanning on demand. Much more convenient would be a browser toolbar to do the same.

Bump! I really need this feature folks to block crypto malware downloads. I have WIN 7 Home so I can't use SRP. I have created a HIPS rule to prevent startups in susceptible directories but that doesn't protect me against scripts, .scr, and the latest variant payloads, .exx. Also, I am a bit old fashioned in that I believe in that old truism, "An ouch of prevention is worth a pound of cure." Hence, my desire to block target file writes in susceptible directories. And yes, I know what I am doing. All HIPS rules I create like this are "ask" mode.

Subnet? Like 255.255.255.0? Or the actual router 192.268.1.1 ? I turn off firewall, and I get Internet access… I turn it back on, and no internet.. What is the setting for NOT blocking my own router from in and outbound port 80??...seems to be a bug in the install process! Please advise Chas Try this: hxxp://support.eset.com/kb2888/

I know this has been asked before and I thought it was supposed to be incorporated into NOD32 and Smart Security by now? Appears the Endpoint versions support *.exe, etc. in target files and applications HIPS rules. I suspect Eset locked out this feature for the consumer versions. Is there anyway to unlocked this feature perhaps by XML directive command? Or, is it possible to get a copy of the Endpoint .bin file?

Emsisoft will be terminating Online Armor support in the near future since it no longer fits into their business development model. Would suggest Eset explore purchasing software licensing rites to it. Then incorporate it into NOD32 and Smart Security; at least the HIPS portion of it as replacement to the existing featureless HIPS Eset has in these two products. Or, offer it as an extra cost option.

Actually having Google web pages served unencrypted not that big of a deal since I assume it makes scanning page content easier since it doesn't have to decrypted them. It is a bit odd though that this is occurring.

Perhaps this has something to do with Google's move to using HSTS protocol?

Don't know if this has been commented on previously. When I search using Google, the first page displayed using IE10 is encrypted TLS 1.2. However, any subsequent searches including selecting a link on the initial web page and then returning, result in all pages being unencrypted? Yahoo search doesn't do this. The connection is still via port 443. It's as if Google is detecting the Eset cert. or something?

I have thousands of the below audit-success event log messages being generated whenever SSL protocol scanning is enabled. Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 8/2/2015 7:17:41 PM Event ID: 5058 Task Category: Other System Events Level: Information Keywords: Audit Success User: N/A Computer: Don-PC Description: Key file operation. Subject: Security ID: S-1-5-18 Account Name: XXX-PC$ Account Domain: WORKGROUP Logon ID: 0x3e7 Cryptographic Parameters: Provider Name: Microsoft Software Key Storage Provider Algorithm Name: Not Available. Key Name: 7DC-55BEA51545534880-NodSSL Key Type: Machine key. Key File Operation Information: File Path: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\b6c6c7213437feb6b8b9338292709a1f_107b96bd-56dd-464d-92cc-0a5dd752abc5 Operation: Read persisted key from file. Return Code: 0x0 Event Xml: <Event xmlns="hxxp://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> <EventID>5058</EventID> <Version>0</Version> <Level>0</Level> <Task>12292</Task> <Opcode>0</Opcode> <Keywords>0x8020000000000000</Keywords> <TimeCreated SystemTime="2015-08-02T23:17:41.543324200Z" /> <EventRecordID>348334</EventRecordID> <Correlation /> <Execution ProcessID="696" ThreadID="4120" /> <Channel>Security</Channel> <Computer>Don-PC</Computer> <Security /> </System> <EventData> <Data Name="SubjectUserSid">S-1-5-18</Data> <Data Name="SubjectUserName">XXX-PC$</Data> <Data Name="SubjectDomainName">WORKGROUP</Data> <Data Name="SubjectLogonId">0x3e7</Data> <Data Name="ProviderName">Microsoft Software Key Storage Provider</Data> <Data Name="AlgorithmName">%%2432</Data> <Data Name="KeyName">7DC-55BEA51545534880-NodSSL</Data> <Data Name="KeyType">%%2499</Data> <Data Name="KeyFilePath">C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\b6c6c7213437feb6b8b9338292709a1f_107b96bd-56dd-464d-92cc-0a5dd752abc5</Data> <Data Name="Operation">%%2458</Data> <Data Name="ReturnCode">0x0</Data> </EventData> </Event>

I will try to simplify as much as possible. On a recent NSS Labs test that was done ad hoc i.e. Eset did not sponsor or pay for the test, Eset's exploit protection against 32 bit exploits running on 32 bit WIN 7 was for all practical purposes 100%. You can read the details here: https://www.nsslabs.com/reports/consumer-endpoint-protection-test-report-eset-smart-security-exploits On another recent exploit test done by Malware Research Group against 32 and 64 bit exploits running on 64 bit WIN 7, Eset scored 80%. In comparison to other vendors tested, Eset ranked slightly below the middle. This test however was sponsored and paid for by Surfright for the purpose of specifically testing their HitmanPro Alert product. You can read details here: https://www.mrg-effitas.com/wp-content/uploads/2015/04/MRG_Effitas_Real_world_exploit_prevention_test.pdf Bottom line - I don't fully trust Eset's exploit blocker on a 64 bit OS running 64 bit software. Note that 64 bit exploits are rare but are increasing in frequency. Presently I personally am supplementing Eset with MBAE free since I run 64 bit WIN 7 and 64 bit IE10.

My experience with the this test tool is as follows. First and most important, only do browser tests with the Surfright test tool. Eset's exploit protection only works for apps that are being monitored by protocol filtering. Eset will not block tests from the test tool itself. Both ekrn.exe and egui.exe must be excluded from Eset's protocol filtering. That done, Eset will block the test exploit payload i.e. calc.exe from executing. You will receive no alert or log entry from Eset. Additionally, the shell of the browser being tested will still be running after Eset has blocked the test exploit payload and delivery process i.e. the exploit test tool. There will be multiples of these browser shells if you do all the tests in one session. You will have to manually terminate those processes using Task Manager or Process Explorer/Hacker. Note the above behavior is running the x64 version of the test tool on a x64 WIN 7 OS. When I did 32 bit browser testing, I believe the 32 bit test tool actually allowed IE 10 x86 to open and close. All calc.exe test exploit payloads were blocked however.

Does the exploit blocker protect x64 apps? Using SurfRight exploit test tool and x86 IE10, SS8 successfully blocks every x86 exploit test. Using x64 IE10 for x64 exploit test tool, SS fails every exploit test. I thought it might be a EPM issue, so turned that off and retested. SS 8 exploit blocker still failed every x64 exploit test.

Win 7 SP1 x64 Just got done reinstalling SS 8 for the 4th time since I believe this software is not running right. Noticed this in my event logs. Appears this might be a major issue? Description: The ESET Service service is marked as an interactive service. However, the system is configured to not allow interactive services. This service may not function properly. Event Xml: <Event xmlns="hxxp://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Service Control Manager" Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service Control Manager" /> <EventID Qualifiers="49152">7030</EventID> <Version>0</Version> <Level>2</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x8080000000000000</Keywords> <TimeCreated SystemTime="2015-07-03T19:25:15.284837500Z" /> <EventRecordID>564695</EventRecordID> <Correlation /> <Execution ProcessID="592" ThreadID="2408" /> <Channel>System</Channel> <Computer>Don-PC</Computer> <Security /> </System> <EventData> <Data Name="param1">ESET Service</Data> </EventData> </Event>

I checked App Mod Detection, and found this- ApplicatiomMidify.JPG 1. Should I Remove the 3 Programs in the box, and OK..., as ESS is still Slow getting browsers... Trusted (open/close 4 times)? 2. Maybe I'm not Trusting properly..., as after the next days cold startup. I have to Trust all over again...?- Especially after Win7 manual updates/Java/Adobe Flash Player/sandboxie/...!? Is it necessary to open Every module of updated programs (CCleaner/MS Word 2003/...? Something definitely is not right with your Eset installation. I have never received any alert from Eset SS 8 about trusting anything. Win Updates install without issue and so do other app updates. You definitely should not be getting trust alerts about IE at every startup after boot. That is unless something is indeed modifying IE and your other apps? I see you are running Zemana's Antilogger - free version. You running any other security software? Thought I saw a ref. to Sandboxie? You should exclude any other security software from Eset's real-time scanning at the minimum. Also post a screen shot of the alert from Eset you are receiving when you receive this "trust" alert. Also have you checked your logs to see if anything is recorded there? If so, please post a screen shot of the entries there. Do you have Eset's firewall set to "automatic" filtering mode and selected profile to "no profile?" Finally, you should uninstall any other security like software before installing Eset. If worse comes to worse, you will have to do that and then reinstall Eset. I have also seen mixed reviews on VIT Registry Fix. If you have run it after installing Eset, it may have very well "borked" part of your Eset installation settings in the registry. I have since uninstalled Zemana Antilogger as it played havoc with Windows Update changes..., but it was active when ESS was installed/online updated (both computers)- I will reinstall ESS later...- Any Special uninstall/install instructions? I have Never run VIT Registry Fix on Win7, as I'm scared by Any Reg cleaner (except CCleaner), and will stay away from it.... If you are using the "full" paid ver. of Zemana anti-logger, it does do real-time monitoring of app. changes. The free ver. does not do that. I stop using it because I don't trust Zemana. Windows uninstaller is usually adequate for Eset. Just install and leave default settings alone until there are no further "trust" issue that you spoke of. -Sounds good on the uninstall/reinstall, I won't import old settings..., and leave Default settings. -BTW?- I also had/have LastPass free Password Manager installed (security software of sorts...), and ESS is Slow to allow changes/updates- Should I also uninstall this, Before ESS reinstall? LastPass shouldn't affect Eset install as far as I am aware of. Note: The fact you were also having WIN update issues with Zemana AL leads me to believe you might have file permissions of some type of Group Policy issues. Did you ever set up Group Policy rules in WIN for file access, updating, or the like? You should have never received errors from Zemana AL about WIN updates; especially using the free version. Leads me to believe your issues might lie at the OS level.

I checked App Mod Detection, and found this- ApplicatiomMidify.JPG 1. Should I Remove the 3 Programs in the box, and OK..., as ESS is still Slow getting browsers... Trusted (open/close 4 times)? 2. Maybe I'm not Trusting properly..., as after the next days cold startup. I have to Trust all over again...?- Especially after Win7 manual updates/Java/Adobe Flash Player/sandboxie/...!? Is it necessary to open Every module of updated programs (CCleaner/MS Word 2003/...? Something definitely is not right with your Eset installation. I have never received any alert from Eset SS 8 about trusting anything. Win Updates install without issue and so do other app updates. You definitely should not be getting trust alerts about IE at every startup after boot. That is unless something is indeed modifying IE and your other apps? I see you are running Zemana's Antilogger - free version. You running any other security software? Thought I saw a ref. to Sandboxie? You should exclude any other security software from Eset's real-time scanning at the minimum. Also post a screen shot of the alert from Eset you are receiving when you receive this "trust" alert. Also have you checked your logs to see if anything is recorded there? If so, please post a screen shot of the entries there. Do you have Eset's firewall set to "automatic" filtering mode and selected profile to "no profile?" Finally, you should uninstall any other security like software before installing Eset. If worse comes to worse, you will have to do that and then reinstall Eset. I have also seen mixed reviews on VIT Registry Fix. If you have run it after installing Eset, it may have very well "borked" part of your Eset installation settings in the registry. I have since uninstalled Zemana Antilogger as it played havoc with Windows Update changes..., but it was active when ESS was installed/online updated (both computers)- I will reinstall ESS later...- Any Special uninstall/install instructions? I have Never run VIT Registry Fix on Win7, as I'm scared by Any Reg cleaner (except CCleaner), and will stay away from it.... If you are using the "full" paid ver. of Zemana anti-logger, it does do real-time monitoring of app. changes. The free ver. does not do that. I stop using it because I don't trust Zemana. Windows uninstaller is usually adequate for Eset. Just install and leave default settings alone until there are no further "trust" issue that you spoke of.

I checked App Mod Detection, and found this- ApplicatiomMidify.JPG 1. Should I Remove the 3 Programs in the box, and OK..., as ESS is still Slow getting browsers... Trusted (open/close 4 times)? 2. Maybe I'm not Trusting properly..., as after the next days cold startup. I have to Trust all over again...?- Especially after Win7 manual updates/Java/Adobe Flash Player/sandboxie/...!? Is it necessary to open Every module of updated programs (CCleaner/MS Word 2003/...? Something definitely is not right with your Eset installation. I have never received any alert from Eset SS 8 about trusting anything. Win Updates install without issue and so do other app updates. You definitely should not be getting trust alerts about IE at every startup after boot. That is unless something is indeed modifying IE and your other apps? I see you are running Zemana's Antilogger - free version. You running any other security software? Thought I saw a ref. to Sandboxie? You should exclude any other security software from Eset's real-time scanning at the minimum. Also post a screen shot of the alert from Eset you are receiving when you receive this "trust" alert. Also have you checked your logs to see if anything is recorded there? If so, please post a screen shot of the entries there. Do you have Eset's firewall set to "automatic" filtering mode and selected profile to "no profile?" Finally, you should uninstall any other security like software before installing Eset. If worse comes to worse, you will have to do that and then reinstall Eset. I have also seen mixed reviews on VIT Registry Fix. If you have run it after installing Eset, it may have very well "borked" part of your Eset installation settings in the registry. -EDIT- You keep referring to "Trust" alerts and your browser. Are these alerts in ref. to the trusted zone? Again screen shots of the alerts are a must.

Would be helpful if Eset posted that the exploit blocker and advanced memory protection are not effective until the first cold boot the day after installation i.e. when the registry is fully available and updated. Also there is a major conflict running EMET with Eset exploit blocker together. The problem is not readily apparent in that both run fine. However, my testing shows that EMET will override all activity by Eset's exploit blocker. My testing shows that Eset's exploit blocker is fair superior in coverage to that of EMET's in the apps that Eset's behavior blocker covers. Eset's BB passes all the SurfRight HPMA exploit tests on WIN 7 x64 SP1. It would be helpful however if at least a HIPS log entry was generated when an exploit is blocked. Finally, would also be nice to know what loads eplghooks.dll since it appears this has nothing to do with the exploit blocking protection. Is it the advanced heuristics feature of real-time scanning? I currently have that turned off and see that eplghooks.dll is not injected into any processes.

The below screen shot is for WIN 7. If you use WIN 8, find the equivalent area. Do the following sequence. Click Control Panel -> System and Security -> System -> Remote Settings. Then ensure that Remote Assistance is not checked. It is possible that someone is getting control of your PC through that feature.

For sometime I felt that the HIPS module was not working properly. Examples were I would only once in a blue moon see eplghooks.dll injected into explorer.exe, iexplorer.exe, etc. Also never was any injection occurring after a cold boot. A while back, I enabled startup checking in the advanced HIPS setting and never received any alerts or log event entries from it. No indication from Eset that any issues existing with the HIPS. Yesterday, I reset the HIPS setting to "Smart" mode and rebooted. I had done this previously without issue. However this time, it caused my PC to go into WIN 7 startup recovery mode. Turns out something had corrupted the WIN 7 spldr.sys driver file; the security loader driver. Fair to assume it was Eset. Also mysteriously Eset HIPS was reset to "Automatic" mode. Additionally, I started finally seeing alerts and log entries from startup entries initiating. Finally the best part was I did see that eplghooks.dll was being injected after today's cold boot. Bottom line - the system crash appears to have reset Eset HIPS and everything appears to be working properly. Presently very leery of resetting the HIPS to "Smart" mode again. What is sorely needed is some diagnostics to ensure the HIPS is working properly and also a way to reset it to initial install default mode. The current reset to default settings option does not do this. -EDIT- Also as far as I am concerned and through testing, Eset's behavior blocker is not protecting the standalone(non plug-in) versions of Adobe Reader, all MS Office 2010 apps(Word, Excel, etc.), or Thunderbird e-mail. None of these were injected by eplghooks.dll upon start-up. So Eset's claims of protection must only support the browser plug-in versions of same. Interestingly, it did inject notepad.exe on start-up.

Here is something to check out on this issue. Windows Updates for June offered an Intel microcode optional update: https://support.microsoft.com/en-us/kb/3064209 . It was dated 6/19/2015. Most of the posts on these BSODs started after that date. Would be curious to see if people having issues with Eset SS or NOD32 have installed this update. -EDIT- Known problems with this update: hxxp://www.sevenforums.com/windows-updates-activation/373250-recent-windows-update-kb3064209-causes-windows-7-not-boot.html

Looks like I was initially right all along. Eset does indeed not inject its hook .dll, eplgHooks.dll, into Adobe Reader. Appears I might have been preventing the loading of eplgHooks.dll into IE10 and explorer.exe; most likely by one of the HIPS rules I have created. In any case, the Eset hook injection is now working properly; at least for everything except Adobe Reader. Strongly suspect that Eset hasn't been able to find away around Reader's sandboxing option. This doesn't appear to be a problem for EMET or Emsisoft though; both inject their hook .dlls without issue.