itman
-
Posts
12,244 -
Joined
-
Last visited
-
Days Won
322
Posts posted by itman
-
-
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> -
Appears this is the problem? Appears to be activated when anything other than the default mode of allowing all outbound traffic is selected? In any case, any updates that are signed should not be triggering an alert. I would check your settings in this area.
I checked App Mod Detection, and found this-
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.
-
Appears this is the problem? Appears to be activated when anything other than the default mode of allowing all outbound traffic is selected? In any case, any updates that are signed should not be triggering an alert. I would check your settings in this area.
I checked App Mod Detection, and found this-
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.
-
Appears this is the problem? Appears to be activated when anything other than the default mode of allowing all outbound traffic is selected? In any case, any updates that are signed should not be triggering an alert. I would check your settings in this area.
I checked App Mod Detection, and found this-
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.
-
I suspect Gigabyte is pushing WIN 10 updates.
I also have a GigaByte MB and have had zip problems w/ESET. I also don't have App Center installed.
I did install a WIN 7 update yesterday for AMD SMBus driver. Turns out a lot of these WIN 7 hardware drivers are just "null" drivers. Also suspect this driver update originated with AMD and not Gigabyte.
My advice is turn off any auto updating of motherboard drivers until you install/upgrade to WIN 10.
-
Appears this is the problem? Appears to be activated when anything other than the default mode of allowing all outbound traffic is selected? In any case, any updates that are signed should not be triggering an alert. I would check your settings in this area.
-
Here's a description of the features from SS 8 Help:
Automatic startup file check
When creating a System startup file check scheduled task, you have several options to adjust the following parameters:
The Scan level drop-down menu specifies the scan depth for files run at system startup. Files are arranged in ascending order according to the following criteria:
· Only the most frequently used files (least files scanned)· Frequently used files· Commonly used files· Rarely used files· All registered files (most files scanned)Two specific Scan level groups are also included:
· Files run before user logon – Contains files from locations that may be accessed without the user being logged in (includes almost all startup locations such as services, browser helper objects, winlogon notify, Windows scheduler entries, known dll's, etc.).· Files run after user logon – Contains files from locations that may only be accessed after a user has logged in (includes files that are only run by a specific user, typically files in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run).Lists of files to be scanned are fixed for each aforementioned group.
Scan priority – The level of priority used to determine when a scan will start:
· Normal – at an average system load· Lower – at a low system load· Lowest – when the system load is the lowest possible· When idle – the task will be performed only when the system is idle -
Glad I saw this posting. I didn't realize this option existed.
As far as the OP's original inquiry, hope you realize that the "registered files" option means scan all files mostly.
My startup file check options is what I am questioning. I have two that were set up by default.
1. Scan after user logon. Files run after user logon
2. Scan after updating. Commonly used files.
Well and fine on those two. But what about files accessibly without user logon? Are files scanned in this option also being scanned in the "Files run after user logon" option?
Seems to me a system startup scan needs to be added with the option "Files run before user logon?"
-
Update 2.
Just completed testing SS 8 exploit protection using Surfright's Exploit Test Tool. SS 8's protection about equal to that provided by EMET 5.2 as far as IE10 browser protection goes. This confirmed by recent AV lab tests showing both in the 80% range as far as exploit detection goes. Both failed heapspray tests miserably. So it appears SS 8 memory protection more akin to vaporware. So, .dll injection not utilized or needed by SS 8 exploit protection.
Only thing I did not like about SS 8 exploit protection is zip alerts or logging occurred when it stopped an exploit. At least some recording of the activity should be given to the user.
-
My opinion is the following:
You can add port 443 in the http-port list, then http-traffic will be scanned on port 443.
In standard configuration only ports 80, 8080, 3128 are scanned for http-traffic. So this has nothing to do with the second https-port list.
So if you don't add 443 to the http-port list, http-traffic on port 443 will not be scanned even if https-scanning for port 443 is activated.
Maybe someone from ESET can post here if that's correct.
My opinion is the following:
You can add port 443 in the http-port list, then http-traffic will be scanned on port 443.
In standard configuration only ports 80, 8080, 3128 are scanned for http-traffic. So this has nothing to do with the second https-port list.
So if you don't add 443 to the http-port list, http-traffic on port 443 will not be scanned even if https-scanning for port 443 is activated.
Maybe someone from ESET can post here if that's correct.
Found a copy of pre-release ver. 9 user manual on the web yesterday. Just describes features w/o specific settings and the like. From what was stated there, ver. 9 will include an option to selectively turn on/off SSL protocol scanning by application. So I will just have to wait until it's released to determine if this issue is a moot point.
-
I created a HIPS rule to protect it from modification. Using Process Explorer checked to see if any Eset .dlls injected indicating that it is indeed protected. Zip, Nada, nothing present. Eset .dlls have been injected into everything else where I created a HIPS rule for them. Ieplorer, explorer, etc. have Eset .dlls injected. Emsisoft Anti-malware and EMET have their .dlls injected into Adobe Reader.
Just how is Eset protecting Abode Reader?
Update.
I have been doing some intensive testing since I last posted. The good news is the HIPS works great. Feature wise it is something out of the stone age but it is very responsive and accurate as far as created rules.
As far as the exploit protection, the only thing I saw where Eset .dll injection is occurring is upon the start up of a new explorer.exe instance. It was not like this at Eset installation; I saw Eset .dlls being injected into IE10 up until recently. I also did reset the HIPS to it's default setting; no help. The best I can determine is the recent IE 10 and Adobe reader updates have broke it.
-
If you do that, then no port 443 scanning will be done.
There is no information in the help files or context menu that says so, also it would be illogical.
From the Smart Security ver. 8 user manual:
Use HTTPS protocol checking for selected ports – The program will only check those applications that are specified in
the Web and email clients section and that use ports defined in Ports used by HTTPS protocol. Port 443 is set by
default.
Encrypted communication will be not scanned. To enable the scanning of encrypted communication and view the
scanner setup, navigate to SSL protocol checking in Advanced setup section, click Web and email > Protocol filtering
> SSL and enable the Always scan SSL protocol option.
To me this means disable that option and HTTPS traffic will not be scanned. What is unclear is if port 443 was added to the HTTP port list, would it be scanned?
-
I would also like to see SSL protocol scanning decoupled from e-mail scanning. I very much need this feature to scan my Thunderbird encrypted e-mail received from my e-mail ISP. I don't want to turn it on for browser use however.
It's already implemented:
First activate SSL scanning, after that you can deactivate https-scanning under
Web and E-Mail -> Web protection -> HTTP, HTTPS
If you do that, then no port 443 scanning will be done. Note that there can be web traffic that uses port 443 that is not encrypted. That is why by default, Eset scans port 443 with SSL protocol scanning disabled; it just ignores encrypted traffic. Also the Eset cert. remains in the Windows root CA using your suggestion which I consider a security risk. Eset should only use the like cert. installed in Thunderbird's root CA.
The e-mail SSL protocol scanning options should override globally setting off SSL protocol scanning for everything which currently is the case.
-
I created a HIPS rule to protect it from modification. Using Process Explorer checked to see if any Eset .dlls injected indicating that it is indeed protected. Zip, Nada, nothing present. Eset .dlls have been injected into everything else where I created a HIPS rule for them. Ieplorer, explorer, etc. have Eset .dlls injected. Emsisoft Anti-malware and EMET have their .dlls injected into Adobe Reader.
Just how is Eset protecting Abode Reader?
-
@itman
Nice idea. But if I'm remembering correctly in v8 you can include and exclude applications for SSL scanning, so this may solve your problem.
The "excluded applications" option turns off all protocol scanning for the selected app. I do want my browser HTTP traffic scanned; just not the HTTPS traffic.
-
ahhh itman, i've been using grc.com for years and only just the other day did i do a stealth report and found 4 'closed' with the rest stealth. what a pretty green stealth is. you get kudos for bringing it up
looking at grc.com again, i've realised while performing some tests that the 4.79.142.206 alert [as above] is grc's ping!
anyhoo, does anyone know how to stealth those 4 ports? they are 25 [smpt], 80 [http], 137 [netbios-ns] and 138 [netbios-dgm]
i'm still on grc.com to see whether there's any suggestions or recommendations of how to stealth those 4 ports but if some already knows, please, let me know.
ta much
You can eliminate the port 137 and 138 issue by disabling NetBIOS for the IPv4 or IPv6 connection for your modem. No reason for NetBIOS to be enabled these days.
-
I would also like to see SSL protocol scanning decoupled from e-mail scanning. I very much need this feature to scan my Thunderbird encrypted e-mail received from my e-mail ISP. I don't want to turn it on for browser use however.
-
My advice is go to this web site: https://www.grc.com/x/ne.dll?bh0bkyd2 . Click on "Proceed." Then click on the "Common Ports" tab. It will run a scan to determine if any of the commonly used ports are open and therefore visible to the outside world. All your ports after the scan is complete should show "Stealth."
It would be helpful however if at least a HIPS log entry was generated when an exploit is blocked.
Antiexploit, how to test
in ESET NOD32 Antivirus
Posted · Edited by itman
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.