itman

OK. We can rule out MITM activity. I just noticed something. Firefox Quantum 68 is no longer going to FireFox's Authorities root certificate store in regards to Eset's root CA certificate. Appears it is directly accessing it from the Win 10 root CA certificate store. This in spite of the fact that Eset's root certificate is presently stored in Firefox's Authorities store. Did you verify that Eset's root certificate is present in the Win 10 root CA certificate store? If not, do the following: 1. Enter certmgr.msc in the Win 10 desktop taskbar search area. 2. Open certmgr.msc. 3. Under "Logical Store Name" section, open the "Trusted Root Certificate Authorities" folder. 4. Open the Certificates folder. 5. Navigate down to the beginning of certs. that begin with "E." 6. Verify that a certificate named "Eset SSL Filter CA" exists. 7. Double click on the cert. to open it. Click on the Certificate Path tab. Certificate status should show it is OK. 8. Close certmgr.msc. Report back on your findings.

Someone will have to run it on a lab test device or in a VM and see what happens.

There is one last thing you can try for detection of external MITM activity. There is a small developer, well known at wilderssecurity.com, that has developed a small utility program specifically designed to check for external MITM activity. The product is currently in beta testing but works fine; I just previously ran it. Go here: https://www.trustprobe.com/fs1/apps.html . Click on the "NoSnoop" link to download the utility. Unzip it. Open the unzipped NoSnoop folder. Double click on nosnoop.exe to run the utility. All the web sites shown on the resulting output from the utility should show OK. Note: Windows SmartScreen will alert on this since it was not a Win Store download. So you will have to override it to run the utility. Also, Eset might immediately submit it to LiveGrid; it did for me. Again to be expected, since it appears Eset has no reputation on the utility. What this utility does is make external and independent connections to the web sites listed to verify the root CA certificates associated with them. It does this without using a browser; only using the device where run from existing network connections to verify that no MITM certificate interception has occured.

That is not correct. See the below screen shot for Win 10 x(64) 1809. There are only three cases when these services would be running: 1. Windows Defender is the default realtime scanner. 2. Windows Defender periodic scanning option has been manually enabled. 3. Effective with Win 10 1809 if the third party AV solution installed does not use the Windows Early Launch Anti-malware driver, Windows will additionally activate WD's realtime protection. It will run concurrent with the third party AV realtime solution. In any other instance when WD's realtime protection is running concurrent third party AV realtime protection, it would be indicative of either a malfunction within Windows itself or the third party AV solution installation processing malfunctioned.

I believe the only solution for this would be to disable Eset's scan alert for removable medium. This could pose a security risk.

No. As far as Eset is concerned, the default installation settings assuming PUA protection is enabled at that time provide the maximum protection.

Switch to pre-release updating in Eset. After that processing completes, check if current version is 12.2.23. If it is not, then perform a manual update check which should download version 12.2.23.

What browser is this behavior being observed for? Have you tried different browsers and the same behavior manifests?

The only other thing I can think of at this point is some type of man-in-the-middle is occurring. When this happens, HTTPS traffic is intercepted en-route and decrypted using the attacker's root certificate. In most cases but not always, this breaks "the chain of trust" in the browser resulting in a warning from the browser this activity has taken place. One possibility is the MITM activity is occurring externally with the Eset root certificate being replaced with the site's original chained root certificate. Go to this web site which will validate SSL/TLS communication: https://badssl.com/dashboard/ In FireFox Quantum 68 and EIS 12.1.34, the only tests shown in light red indicating a minor concern are SHA-1 Intermediate and dh1024 Crypto cypher issues. The test area to be noted is the Interception Certificates area.

Did you try @Sammo suggestion of setting firefox.exe in Eset's SSL/TLS filtered applications to "Scan" versus the default setting of "Auto?" While in that section, make sure that there are not multiple firefox.exe applications listed. You should have only one entry for Firefox and its path specification is C:\Program Files\Mozilla Firefox\firefox.exe assuming your using Win 10 x(64). Next in the Web Access protection section, open the Web Protocols section and verify that only port 443 is shown in the HTTPS Scanner Setup section.

Ahh........... It's the obvious stuff that can "trick you up." Totally ignored that parameter under the assumption logs are created in all scanner modes.

@Marcos this might be the reason for the Win 7 driver errors when attempting to install Sandboxie:

Detection was had when I was signed off from Win 10. Cleaning mode is "Strict." File was indeed quarantined but I would expect Eset to also write a Detection log entry. If one never referred to Eset Quarantine, they would never know a malware was detected and mitigated.

https://fileinfo.com/extension/com In other words, malware runs via a batch script. https://en.wikipedia.org/wiki/COM_file

No reason to wait a week. If the Eset DBI Sandboxie exclusions are working, it would be apparent immediately by no conflict with clearing the sandbox after browser termination.

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.