itman

I suspect something is amiss with your device BIOS power management settings. In the Power Management section of the BIOS, look for a setting titled PME Event Wake Up or the like. This allows for the PCI or PCIe bus to monitor and control sleep activity at the hardware level. Make sure the setting is enabled. Note: the feature only works on my device for example, if ATX power supply provides at least 1amp on the +5VSB lead. Most modern power supplies conform to this requirement.

It appears you are manually starting up B&PP via desktop icon or within the Eset GUI itself. Enter the URL for your bank within an open FireFox browser session. Eset should auto open a separate B&PP browse session and directly connect to your bank web site.

It appears at this point, the only scan that is running at its true scheduled time is one coded with the missed scan option of ASAP. Also, it has yet to verified if the ASAP missed scan option is working properly. It was not in vers. 12.0. I have a scheduled weekly scan due to run tomorrow at noon. It has the 1 hour missed scan option. I will post tomorrow if the scan ran at it schedule noon run time.

Post a screen shot of the actual Eset alert please. The first thing that needs to be determined is what application is trying to import a root CA certificate. From the message posted, it appears something is trying to update Eset's root CA certificate in the Windows root CA certificate store.

A good example of sc.exe malicious use is the "Honeybee" malware that has attacked S.E. Asia humanitarian aid organizations in the past. Honeybee is delivered via malicious macro in a Word document. Note: if you open the McAfee article reference, Eset HTTPS filter will throw an alert. Appears it is detecting some example code on the web page as malware -EDIT- the below .bat scripts is what Eset is detecting. I had to repost them as a .png attachment: https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-uncovers-operation-honeybee-malicious-document-campaign-targeting-humanitarian-aid-groups/

Another way the attacker could have created the service is using reg.exe which will allow for direct modification of the registry. It can also be run remotely if the remote registry service is running on the target device. Ref.: https://attack.mitre.org/techniques/T1112/ .

Looks like I was right in my assumption. I would still perform forensics in hope of discovering what was able to create the Win service. Look for traces of script execution; most likely PowerShell, using sc.exe. Ref.: https://support.microsoft.com/en-us/help/251192/how-to-create-a-windows-service-by-using-sc-exe .

FYI - advise you delete that log from web sharing site you uploaded it to. Or, alternatively password protect it or secure it by some other means. For future reference, post all future log requests to the forum; only Eset mods have access to these. Or, PM them to the requestor as an attachment.

Appears to me, the clients got nailed by a true 0-day malware. Also, it appears Eset created a new signature for this bugger, Win64/Vools.P. It is encouraging that Eset was still able to detect it via AMS using a prior variant DNA signature. BTW - what was the source of the svchost.exe injection?

I am not sure SysRescue will scan the UEFI. According to this: https://support.eset.com/kb3509/?locale=en_US&viewlocale=en_US , it only scans boot sectors. Appears to me you will have to use an Eset installed product to scan UEFI. -EDIT- You can give Eset's Online Scanner- installed version, a shot and see it has a setting to scan the UEFI: https://support.eset.com/kb2921/?locale=en_US&viewlocale=en_US

Your screen shot shows you have no Internet connectivity. Reboot your PC and see Internet connectivity now exists.

Since the malware is being detected in svchost.exe, my best guess the malware has created a service in the registry and set it to start at boot time. If you can find the service, it most likely have an .exe associated with it. When you find the malicious service besides deleting it, the .exe should also be removed. Another possibility is the malware is injecting one of the running svchost.exe processes since Eset is detecting the malware via AMS. The older OS versions are vulnerable to svchost.exe injection methods. This type of attack would require another .exe or script running at boot time to perform the activity. So registry autorun keys and Win program startup directories will need to be reviewed for any suspicious entries.

Yeah, forgot about that. There are a few third party software utilities that basically "fake out" Windows activity monitoring and employ their own timers to control sleep activity. Can't vouch for any since I never used them. Appears best solution for evening scanning as the OP is doing is just disable sleep mode prior to running the on-demand scan since PC will shutdown after scan completion. Then reenabling sleep mode at boot time.

Your device should only be entering sleep mode when there has been no system activity for a specified period of time. The default Window setting is one hour. As such, the device should not be entering sleep mode until the Eset scan is completed. Since you have specified that Eset shutdown the device after the scan has been completed, sleep mode activation is not applicable. To verify if your Win sleep mode is properly functioning, temporarily set the Win sleep mode time interval to 5 mins.. Then start your on demand scan w/shutdown option. After 5 to 10 mins. or so if the scan is still running, we can rule out sleep mode beginning a factor. You can cancel the on demand scan and reset Win sleep mode time back to its initial setting.

If none of the network devices have been patched against the SMBv1 vulnerability, the first mitigation step must be to apply the appropriate patch to all devices. It appears the source of the attack is unknown at this point. Without the source being identified, the attacker will in all likelihood perform a subsequent attack against the network nullifying all previous virus infection removal efforts.

Thanks for the feedback. Would suggest Eset post an announcement when a change to GUI related components are made. Especially in regards to B&PP since many are sensitive to any changes in that area possibly due to the malware.

Are you referring to MS17-010: https://support.microsoft.com/en-us/help/4012598/title which was patch for SMBv1 on Win Server 2008 OS?

Will Eset scan if the limited admin user is signed out but the computer is still powered up?

I did a little experiment and connected to my router via https and experienced the same behavior. As far as I am aware of, all connections to the router's admin GUI have to be made via http except in your case it appears. Try this. Refer to the below screen shot and add the IP address for your router, 192.168.1.1, to the excluded address for Eset's Protocol Filtering. This should eliminate any interference by Eset in your connection the router.

Screen shot of the what you are observing please.

Appears to me that perhaps the beta update ended up in a production pico update. So I guess we need another pico update to restore things back to they were previously?

Log sent.

In that posting I was referring to the default Log Maintenance scan. And it is running correctly now at its scheduled scan time. Note that the missed scan option for this event is ASAP. Try this. Set your missed scan time to 1 hour. See if the scan runs at boot time if your PC is powered off at the scheduled scan time.

Rebooted. Everything remains as I previously described including the release version. BTW - I am not an Eset insider unless someone enrolled me as such w/o my consent.

To clarify, this was a production update and not a pre-release update? I don't have pre-release updates enabled. Also my BP&P module is 1146 dated 3/1/2019.