itman

It is possible that two startup scans could be run at system boot or logon time. Such would be the case if the PC was idle long enough that Eset would push a module update after either of these events. The main startup scan will scan all files run after user logon at normal priority. The after module update startup scan will scan commonly used files; whatever those may be, at low priority. Since both these scans have the same name associated with them, it would be impossible to determine which scan was running by mouse hovering over the Eset taskbar icon. What might be observed by the OP is the running of the module update scan. Assuming a lower processing capacity PC and that the scan is running at low priority, it might run long enough to be observable via icon taskbar activity. In any case if this scan was running, it should have no impact on normal system activities since the scan is running at low priority.

FireFox just released ver. 68. This is the ver. that will use the Win root CA store if Eset's certificate is not added to FireFox's Authorities certificate store for some reason. If FireFox hasn't auto updated to ver. 68, do so manually. Now perform the AMTSO tests and see if Eset if still not detecting those.

I believe that is correct. But in this case, it appears the php server was not locked down; was hacked to deploy a malicious script; and that script is now attacking the internal network.

A few comments about php server use. It was designed for internal development usage and definitely should not be allowed access to the external network: https://www.php.net/manual/en/features.commandline.webserver.php

The only other culprit I can think of is the Advanced Machine Leaning module. This also was just introduced into Eset. Also, it appears there is no way to add exceptions to it or disable it short of completely disabling the HIPS.

These are all Fortinet IPS detections: https://fortiguard.com/encyclopedia/ips/26339 https://fortiguard.com/encyclopedia/ips/44580 https://fortiguard.com/encyclopedia/ips/12090 The possible malware is php.malicious.shell. Per the Fortinet description indicates a malicious php script running on a php server. Do you have a php/web server installed?

Make sure that "Enable Smart Optimization" is check marked in ThreatSense settings for the Startup Scan. Open Eset GUI. Then select Setup. Then select Advanced Setup. Under Detection Engine, select Malware Scans. Click on the "+" for STARTUP SCAN to expose the ThreatSense settings. As a test, I disabled it and then rebooted. I then observed same behavior with the scan taking approx. 3 mins. to run.

This suggestion was posted on the Sandboxie forum by Sophos: This coupled with excluding Sandboxie processes or entire directory as noted above, might do the trick. Personally, I suspect Eset might go "bonkers" if its access was denied to Sandboxie system use areas.

First, refer to this: https://help.eset.com/ees/7/en-US/idh_config_epfw_known_networks_group.html . Next, refer to EES online help in regards to Network Authentication which might be what you are looking for.

Try a manual download from here: https://www.sandboxie.com/AllVersions As shown on this site, there are many vers. of Sandboxie. So far, no one has mentioned what ver. they are running or if it's 32 or 64 bit.

As far as I am aware of, Sandboxie's driver is validly signed. Did you download it from here: https://www.sandboxie.com/DownloadSandboxie .

Don't know quite what you mean here. By default, Eset Network Protection will only connect to the Network's gateway device if using the Public profile. Or and additionally, other devices within the local network if using the Private profile. The gateway reference here is usually a router. Once communication reaches the router, it is 100% under its control from that point on.

Try this. 1. Open the Eset GUI and via Setup selection, navigate to the Network Protection section. 2. In the "Troubleshooting Wizard" section, determine if the "Recently blocked applications or devices" count is a non-zero value. If it is, open the wizard and search for blocked connection entries related to your VPN network access. Click on the "Allow" tab for those entries and the wizard will create the appropriate Eset firewall rule to allow the VPN network connection.

Believe I know what might be the "culprit" here. Eset recently implemented "Deep Behavior Inspection" in the HIPS. For anyone having this issue with Sandboxie, do the following: 1. Open the Eset GUI and navigate to the HIPS section. 2. Verify that a Deep Behavior Inspection section exists there. If so, add exceptions for all of Sandboxie's executables there. -EDIT- Or alternatively, just whitelist Sandboxie's entire directory using the "\*.*" notation. Hopefully, this will resolve the registry access issues with Sandboxie.

Continue monitoring to determine if the problem reoccurs.

Did you verify that firefox.exe is in the list of SSL filtered applications?

Go here: https://www.eset.com/us/activate/microcenter/ Appears you may have to first register with Eset using the provided Micro Center serial number. Eset will then register you and respond via e-mail to you with the license key.

I was going to suggest this. Appears in the upgrade to Win 10 1903, Windows Security Center internal settings in regards to use of a third party AV realtime solution got borked somehow. Externally, all appeared OK in that WSC showed Eset as realtime solution.

Following up on my prior posting, I switched the Eset firewall to Interactive and had no issue in creating an outbound firewall rule. Therefore, the "Notifications" reg. key is not needed or used in Win 10.

On my Win 10 1809 build running EIS 12.1.34, this reg. key is present: HKLM\Software\ESET\ESET Security\CurrentVersion\Config\gui\UI_CONFIG\ What is missing is "Notifications" which is assume is a subordinate reg. key of UI_CONFIG key.?

I am wondering if what is going on here is a classic "deadly embrace" situation. Eset detected something amiss in access to the Sandboxie registry key and/or data within and started monitoring it. Sandboxie in turn needs exclusive control of that registry key and can't get it. Normally, this should be resolved after a reboot and this appears not to be happening. You might try to disable Eset's HIPS which will require a reboot. Then delete the contents of Sandboxie's sandbox. Then re-enable Eset's HIPS and see if the issue reoccurs. If it does, then at least Eset's HIPS can be ruled out as the source.

Quttera shows two potentially suspicious files for the URL; both are JavaScript related: https://quttera.com/detailed_report/pandownload.com Perhaps Eset found something in code no one else feels worth flagging?

@BeanSlappers SSL/TLS protocol scanning issues are with FireFox; not with Edge. Did you mean that FireFox is not in the list of SSL-filtered applications?

This one has me baffled. Eset still doesn't detect the ps.txt malicous script in the .zip file when scanned locally via context scan. However when the .zip file was submitted to Virus Total, the malicious script was detected by NOD32. I am also running EIS. Could there be an issue with the default SmartScan ThreatSense parameters which I believe context scanning uses? -EDIT- It's Smart Optimization. Disable that in Context-Scan profile and Eset now detects it. Here's the story. After Eset detected the renamed .ps1 script via AMSI, appears it created a local detection for it. Afterwards, when I scanned the folder containing the .ps1 script, Eset detected it. So as far as I am concerned, my assumption about once scanned never scanned again non-.ps1 files is correct. BTW - with all this "fooling around" with this malicious .txt PowerShell script, only 13/56 detect it at VT; of the major AV players - G-Data, Avira, Qihoo-360, Rising, Kapersky, Ikarus, and Dr. Web. This further reinforces the difficulty of finding hidden malicious code in a .txt file.

Yes. Python scripts are not scanned by AMSI. Nor AutoIt; WMI scripts that use their own script engine; etc.. Given malware developers roaring success in abusing legit Win binaries in "living of the land" attacks, "the sky is the limit" when it comes to malware these days.