itman

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.

If this was the case, it would have been true when Eset scanned the downloaded .ps1 version of the malware. Eset had no trouble detecting that when initially scanned. This means that Eset processes .ps1 files differently upon initially scanning them.

A few more discussion points to "tidy up" The first is about Eset being able to detect the malware script when it is created on the local device in .ps1 format. Appears that advanced hueristics will actual run the script via Powershell in its sandbox. This will allow for examination via AMSI. In this case, Eset will detect the malware and can delete and quarantine it. Next up is this malware script's code. I looked at it again. Appears it is not obfuscated. All that voluminous code at the end of the script appears to be either packed or encrypted. Unfortunately, my skill set in either of those two areas is deficient. So I can't analyze it further. This then leads to the ability of any security solution being able to detect in a .txt file: 1. That packed or encrypted code actually exists. 2. If the solution did detect the code, could it actual decipher it? Definitely the answer is no if its encrypted with a strong cypher. From what I can tell from this analysis to date, there appears to be a deficiency in the Eset file scanning whitelist processing. One solution would be for the HIPS to monitor for existing file renaming where the extension was changed to .ps1. When this occurs, the original whitelist status would be removed. It appears that Eset presently special cases .ps1 files overall in that these files are indeed always re scanned . But it appears so only if they were originally scanned as .ps1 files.

In regards to the PowerShell .txt malware sample, it is a heavily obfuscated .Net based PowerShell script. Setting PowerShell to Constrained Language mode would have stopped it from executing regardless of the Eset element. My test procedure for this malware script as follows: 1. Unzipped it and renamed it from .txt to .ps1. 2. Started Process Explorer for monitoring purposes. 3. Opened Run window in Win 10 x(64) 1809. 4. Entered into Run window; powershell -ep bypass malware.ps1. PowerShell never started execution and Eset detected the malicious script via AMSI scanning: Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here 7/5/2019 10:30:23 AM;AMSI scanner;file;C:\Users\xxx-xxxx\Downloads\powershell\ps.ps1;PowerShell/TrojanDropper.Agent.S trojan;blocked;xxx-xx\xxx-xxxx;;169A92DADC65118C905957FB081493087B422140;7/5/2019 10:30:23 AM -EDIT- Of note and important! Eset did not delete and quarantine the malware. It only blocked its execution. So it appears, AMSI detections will require manual cleaning. -EDIT- Appears after AMSI detection, upon next access to the file, Eset's realtime engine will detect, delete, and quarantine the file.

Do you have access to another PC with Win 10 1809 on to this? One possibly answer here is there is an issue with Eset on 1903 with AMSI. Also PM me the PowerShell .txt example you were testing with that Eset detects in .ps1 form. Attach it as a non-password protected .zip file.

Please do as you theorized; rename in another script the .txt script to a .js script and execute it. Does Eset now detect it?

As I stated in a previous post, this is due to the fact the .txt file contains obfuscated code. Additionally if the script was packed or encrypted, Eset would not detect it on download or subsequent scanning. This is because the script will only decloke when loaded into memory at execution time. This is what Microsoft created the AMSI interface for. It is a memory sandbox where the script code can be examined by AV solutions after it has been decloked, but prior to actual execution.