Jump to content

itman

Most Valued Members
  • Content Count

    3,280
  • Joined

  • Last visited

  • Days Won

    115

Everything posted by itman

  1. I will say this about this software, I would be leery of using it personally. Here is a sample named apower-manager.exe that was submitted to Hybrid-Analysis last year: https://www.reverse.it/sample/6db7d567d84c205ad90c3924e120acea2c73d3830f631be87de613f2d4e5f539?environmentId=100 . It determined that it was 100% malicious. However, every vendor listed at VirusTotal determined the sample was clean. I would submit your apower-manager.exe to Hybrid-Analysis for a scan and see what it finds.
  2. No. I did an in-program upgrade to 12.0.31 and the option remained in place after the upgrade completed. Strange .……. I thought by now Eset would have fixed the installer issue; at least on ver. 12.0.xx. I assume this is a matter of priorities with this issue being a non-operational one, assigned a low fix priority.
  3. As far as I am aware of this issue has been resolved. Eset a while back appears to have issued a module update for ver. 12.0.27 since I now see the option on my Eset GUI home page.
  4. I believe I know what is going on here although the Eset log entires are in German. You have both the original archive and a subsequent extracted .exe from it present in the Downloads folder. Assuming you have ThreatSense set to Normal scanning, it is detecting apower-manager.apk as the Trojan component. It could not clean the archived version of it for some reason and only will block the extraction of it. If Strict cleaning was deployed, I assume Eset would have just deleted the entire archive. It appears the extracted executable, apower-manager.exe is clean, hence no Eset scan alert for it. You can verify this by submitting the file to VirusTotal to see if any of the AV engines used there detect it as malware.
  5. This one has been bugging me for a while. Eset HIPS default behavior for ask rules that have not received a user response is allow. This is the only HIPS I have used where like default behavior is not block. Before I get into my suggested enhancement in this regard, overall I agree with Eset's approach. It is designed to prevent a user from creating an ask rule that due to; Eset GUI not fully initialized at boot time Non-response due to user physically not present at device that could inadvertently lead to critical system/app function being blocked leaving the system inoperable. However, the fact remains that the default allowed activity could have been malicious or suspicious in nature and needs user review. I therefore propose the following HIPS enhancement as far as default allow ask rule activity: 1. All such ask rules are logged in the HIPS log. 2. Eset display a non-expiring desktop alert that such default activity has occurred. At boot time, this could be done after the Eset GUI is fully initialized. The alert does not have to more than a notification that such default behavior occurred. This would alleviate one constantly reviewing the HIPS logs for such activity assuming he previously set logging to the correct level to capture such default activity.
  6. A security analyst a while back wrote a blog posting about Barkley's Stackhackr simulator . The blog is titled 'Security Through Absurdity'. I am posting excerpts below but you really should read the entire article. Overall, chalk this one up as more Next Gen marketing FUD: http://randy-abrams.blogspot.com/2017/07/stackhackr-useless-for-testing-good-for.html
  7. Try this. The below screen shot is for EIS. I believe there is a like setting in ESS. Disable; i.e. uncheck mark, "Notify about newly discovered network devices."
  8. itman

    ERR_SSL_PROTOCOL_ERROR

    I get an Eset PUA alert on that web site. This would indicate it is trying to download something nefarious to the user's device.
  9. Talk about a useless test. My Eset HIPS rule to monitor script execution easily detected it: Also of note is LiveGrid submission of launcher.exe to Eset's cloud servers upon its execution. -EDIT- Blocking criteria used. Unknown executable (to me) running from C:\Users\xxxx\Downloads\ directory is attempting to launch a script.
  10. I will say this. I had a similar browser based HTML detection using EIS last month. I posted on the forum about it because I had two questions. The first was why the log entry for it showed no action taken and the entry was shown in red color. As this: https://forum.eset.com/topic/17986-detected-threat-shows-in-red/?do=findComment&comment=88763 shows, Eset Web Protection which I have the ThreatSense setting set to Normal protection cleaned the threat with no user interaction required. As for no Eset quarantine event being recorded, I assumed this was correct since nothing ever hit the disk to be captured. I am still puzzled why the log event showed no action. As to the red color of the log entry, I never received a response.
  11. The web site is not accessible; 404 error - page not found.
  12. As far as I am aware of in regards to 1809, you should be seeing a Windows firewall setting as shown in the screen shot I previously posted. Refer to the below screen shot. Open Windows Security Center. Then select "Firewall & network protection" -> click on "Manage providers." In the Firewall section it should show that the Eset firewall is turned on and the Windows firewall is off. Also for reference, the Windows firewall is not completely disabled. Only the portion that controls monitoring actions by its rules are disabled. If the Eset firewall is used with default settings, Eset will also use the Windows firewall inbound rules but under the control of its firewall processing.
  13. The screen shot you posted is from the Windows Defender Firewall section of Control Panel. It also appears the ver. of Windows 10 you are running is not 1809. Earlier vers. of Win 10 had such a display. The screen shot I posted is from Win 10 1809. In any case, I don't see a problem with your installation. Eset is managing the Win firewall settings as should be.
  14. Post the screen shot in your reply. Only Eset mods now have access to attachments.
  15. You should see what is shown in the below screen shot when Eset has been successfully registered in the Windows Security Center. Suggest you uninstall Eset, reboot, and then reinstall it. Make sure you export your Eset settings prior to uninstall if you have created customized settings. You can then import these after Eset has been reinstalled. Hopefully, Eset will be successfully registered in Windows Security Center upon reinstall. -EDIT- Prior to doing the above, you can try this to see if it resolves the issue since it appears you are running Win 10 1809. In Windows Security Center, click on "Firewall & network protection." On the right hand of the shown screen, click on "Manage providers." In the shown Security Providers screen, go to Firewall section. There should be a option shown that will display the current Windows firewall status. Try to turn it off by clicking on the "Turn off" tab. If successful, then reboot and see if the below screen shot is shown in Control Panel -> Windows Defender Firewall.
  16. itman

    Phishing website test

    Here's a web site that lists live real phishing web sites: https://www.phishtank.com/phish_search.php?valid=y&active=All&Search=Search . I picked the first one which happens to be a HTTP web site and was just listed today. Eset IS 12.0.31 on Win 10 detected it!
  17. This publication: https://euroscug.org/wp-content/uploads/2017/11/Windows-10-Controlled-Folder-Access_1_3.pdf is worth a read in noting that WD's Controlled Folders feature is far from without out issues. These range from minimally missing desktop icons upon program installation processing completion to apps not being able to run subsequently.
  18. Let me give you an example of the problems one can run into if they don't have in depth OS operational knowledge. There are hidden OS used files in AppData directories. Desktop.ini is an example of one and it is constantly being updated. So as far as doing monitoring of controlled folders goes if you would have stuck to My Documents, Downloads, Photos, etc. folders, you probably wouldn't have run into issues.
  19. "The moral of this story" is if you don't understand how something works, you run the risk of severe damage if you fool around with it. As a rule, I don't create block rules with the HIPS but only ask rules. Also one should experiment with a few non-critical files/directories/etc. prior to attempting restrictive activities against critical system and an app executables and files. Also, Eset did not create the HIPS for user interaction with it. Its primary purpose is self-protection use and protection for a few critical system and registry areas. As such, you will not receive any official guidance in the creation of HIPS rules other than a few Eset KB articles on ransomware rules directed to users of the Endpoint product.
  20. Turned on logging on that rule for a while. Whatever I observed in the past in regards to it is not occurring in the current Eset ver.. So ignore my previous comments.
  21. I also don't understand why anyone would want to use MBAM in realtime mode. In any AV lab test of it I have reviewed, it always comes in last; example here: https://www.av-test.org/en/antivirus/home-windows/
  22. Does this not also block Eset proxy traffic? That was my experience in the past when I disabled the default rule.
  23. My best guess is Eset has "beefed up" its JavaScript scanner and MBAM's like protection is conflicting with it. As a test, try disabling Eset's advanced browser script protection and see it that resolves the CPU usage issue. Or alternatively, disable like protection in MBAM, if possible, while keeping Eset's like protection enabled and see if it resolves the CPU usage issue. Personally, I would disable MBAM's script protection since I feel Eset's is superior to it. Another possible point of conflict is MBAM's anti-exploit protection which is now included in the product. In the past, it was a stand-alone feature. Add Win 10's Windows Defender Exploit Guard that is constantly running and you have three anti-exploit products running at the same time …………..
×