Marcos

The topic was unhidden so that other users seeking an answer to your question in the future can find it here.

Files uploaded in our forum are accessible only by ESET staff.

ESET NOD32 for Linux Desktop is a legacy product that doesn't support activation. If it's not included in the registration email that you can retrieve through the web form https://www.eset.com/int/support/lost-license/, you can contact customer care who will provide it.

Please carry on as follows: - enable advanced logging under Help and support -> Details for customer care - reproduce the problem by trying to use your VoIP phone - stop logging - collect logs with ESET Log Collector and upload the generated archive here.

I have no clue what I did differently but I was unable to reproduce it on Windows 10. Does temporarily disabling self-defense make a difference? Please enable logging of blocked operations in the advanced HIPS setup, reproduce the issue, disable logging, then collect logs with ESET Log Collector and upload the generated archive here.

Is it happening when no on-demand scan is being run? Do you have idle-state scanning disabled in the advanced setup? Please generate a complete memory dump of ekrn when the issue is manifesting. Open the advanced setup -> tools -> diagnostics, set the dump type to "Full" and click ok. Then click "Generate" (dump) in the same window. When done, collect logs with ESET Log Collector, upload the archive to a safe location and drop me a personal message with a download link.

I've tried to reproduce it to no avail. Chrome is set as default browser, the sandbox is configured to delete the content when the application quits. I open Chrome through the "Sandboxed Web Browser" icon, close Chrome after a while but no error occurs and everything seems to be fine.

That is my understanding as well; with AMSI-enabled OS's the file should be detected on execution of the interpreter (haven't tested it though but in theory it should work). Also if such file is included in an archive, it would be scanned by web protection and would be detected regardless of the extension. There are actually 3 ways how to solve it: always scan txt files (could make certain system slow down when an application is logging to big txt files extensively), keep the optimization as is, utilize HIPS to scan such files at the right point (like AMSI on not AMSI-enabled systems). The last one would be probably best but I'm not sure if it would be 100% effective and could not be circumvented with some effort. At any rate, it would be a long-term solution that cannot be implemented immediately.

Clicking "hw report" on the top of this topic will show you another topic with a similar question. If that is what you are after, then creating such report is not currently possible but we track it and possibly it will be implemented in one of future versions.

Please check in the advanced setup if you have Idle-state scanning enabled. Try disabling it. Since you didn't mention what operating system you use, if you have Windows 8.1 or Windows 10, make sure that Windows Defender is not running and that periodic scans are disabled. Please collect logs with ESET Log Collector and post the generated archive here (only ESET staff will have access to it).

Please provide logs collected with ESET Log Collector as well as "C:\ProgramData\ESET\ESET Security\HipsRules.bin" . It can happen if you have a process exclusion entered incorrectly, e.g. without a full path to the file.

Not really. There would be always ways to bypass detection. Imagine an AV would have to parse, e.g. 100 MB txt file on access each time. The machine would be unusable. You can disable Smart optimization to make sure that files are scanned each time they are accessed, however, it will most likely have adverse effect on performance as well.

Please provide me with the file for internal debugging. Do you mean that it was not detected neither by real-time protection nor on-demand scanner after renaming the extension?

With regard to Windows 10 1903 update, please refer to https://forum.eset.com/topic/19829-upgrade-to-windows-10-version-1903-may-cause-boot-error-on-windows-10-with-eset-endpoint-encryption/. Please continue with the discussion on the 1903 issue in the topic above.

Potentially unwanted and unsafe applications are not malicious in any way. According to https://support.eset.com/kb2629/: A potentially unwanted application (PUA) is a program that contains adware, installs toolbars or has other unclear objectives. There are some situations where a user may feel that the benefits of a potentially unwanted application outweigh the risks. Potentially unsafe applications are legitimate applications that may be misused in the wrong hands (e.g. a process killer tool misused to kill AV). The detection also covers certain toolbars. It is disabled by default which is probably why the app hadn't been detected until recently.

Unfortunately, you didn't mention what host or IP address was found on a blacklist. I'd recommend contacting your local customer care who should report it to the developers of antispam.

It seems you have already contacted samples[at]eset.com as well where you've received a response. The detection is correct. The reason why EOS couldn't delete the file could be that you have another AV installed which is protecting files in its folders.

I now have 443-600 there. I reset to defaults a 2-3 hours ago as I thought that could be the culprit, however, when I reopened advanced setup, there was 443 only. Not sure what happened in the mean time besides a module update. Looks like a bug but it's not yet clear when it occurs.

JS/Adware.AA is a correct detection. If you want to contact ESET's security research lab, email samples[at]eset.com if you would like to get a response. However, in this case it's not needed since a reply would be same.

I've switched to interactive mode, ran Edge, chose to create blocking rules when prompted and finally switched to automatic mode: The problem here would be that the path to Edge's executable will change when it updates to a newer version and the rule will become invalid.

I have no clue. I have various ESET products installed and everywhere is port 443: Also I'm not sure if a range of ports will work; it's accepted by the validator, however, the tooltip says that ports must be delimited by a comma. Even if it worked, ESET supports only HTTP(S), POP3(S) and IMAP(S) protocols so other communication would not be scanned anyways.

Do you have the same ESET product installed on both machines? What error is activation ending with? What is your public license ID?

To prevent multiple topics on a subject, we'll draw this one to a close.

Microsoft is going to block upgrade if ESET Endpoint Encryption is detected as a preventive measure until thet address an issue in the update caused by CleanMgr which accidentally deletes the FDE driver after upgrade but leaving it registered in the Upper Filter storage stack. The bug started to manifest in build 18343 and any newer builds are currently affected as well.

You can also set Firefox to use the system trusted root CA certificate store by setting security.enterprise_roots.enabled to true in about:config.