itman

Correct. I stated so incorrectly. It shows seconds; not thousands of a second.

My above posting of using thousands of a sec. in scheduled time field also did not work in starting of the scan upon resume from sleep mode. Appears the only immediate solution to this issue is to set scheduled time to a time when PC is always powered on. Or, just initiate the scan manually.

To get to the bottom of this, I went to the Apower web site here: https://www.apowersoft.com/phone-manager and downloaded apower-manager.exe. I then performed an Eset context-menu scan on apower-manager.exe in my Downloads folder. Results shown below: I then performed an Eset context-menu scan on the Downloads folder. Results shown below: The bottom line is apower-manager.exe shows no malware by either context-menu scan method; individual file or folder. Therefore, I can't duplicate the activity you posted about.

Thanks for the clarification. Based on your above context-menu folder scan screen shot, apower-manager.exe is an installer. Note the "INNO" reference shown. More detail on that here: https://en.wikipedia.org/wiki/Inno_Setup . When Eset scanned the installer for files contained within, it found an archived(ZIP) file containing apower-manager.apk which it classified as Trojan based malware. Why Eset did not the same detect Trojan when performing a context-menu scan on apower-manager.exe itself, my best guess is you did not clean the Trojan at the end of the previous folder scan? Eset internally recorded this decision for the file and did not redisplay the Trojan status. What I would do is delete apower-manager.exe in your Downloads folder. Then download it again from your original source web site. Now perform an Eset context-menu scan on the downloaded file and see if Eset detects the same Trojan as shown previously.

I reside in the U.S. and it occurred the very first time for me with a EIS 12.0.27 download. And again as posted, the option a while later did start appearing in the GUI.

The "Refer a friend" option missing from the Eset GUI. Perhaps this occurred in the ver. 12.0.31 installer @Moriseif downloaded because it was not fully activated as you posted above?

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.

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.

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.

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.

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.

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

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."

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.

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.

English translation is:

Was the folder you scanned an archive?

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.

The web site is not accessible; 404 error - page not found.

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.

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.

Post the screen shot in your reply. Only Eset mods now have access to attachments.

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.

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!

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.