Marcos

If you look up a description of the detection, you'd found out that it's a kind of a cloud-based machine learning detection. If it raises a question about ESET's detection capabilities, doesn't it rise the very same question when the mentioned vendor misses thousands of malicious samples that ESET detects? There's no security solution that would proactively protect from 100% of threats, especially if malware authors focus on specific vendors and modify the malware until it becomes undetected. And if they also test it also upon execution in real conditions and perform modifications until it becomes undetected, they will eventually evade detection. Security vendors make it harder for attackers to infect systems but making it 100% impossible is unreal. Nope. ESET uses multiple protection layers to make it difficult for malware to get in even if attackers take measures to evade traditional detection: https://www.eset.com/int/about/technology/

It's an rtf document with a NSIS/Injector inside. Among those 10/59 detections were none from a popular AV with a concrete detection name; all were generic detections. It is a fact that no AV detects 100% of all threats; what matters is the reaction time of vendors when a malware is not detected heuristically / generically without update. There have been numerous cases when ESET was the only vendor to detect certain new threats. The detection will be added in the next update as DOC/TrojanDropper.Agent.EN and the dll inside as Win32/Injector.DYKG. As of Endpoint v7, you will be able to take advantage of the new technology ESET Dynamic Threat Defense which will allow for running any suspicious files in ESET's sandbox and apply also machine learning in order to asses the dangerousness of a file. The client will then be informed about the result and block or allow the file accordingly.

Please provide me with a link to the VT results so that we can comment on it. Without knowing what wasn't detected and how your ESET product is configured no conclusions should be made.

This is really weird because Microsoft says on the mentioned website: Prerequisites To apply this hotfix, you must be running one of the following operating systems: Windows Server 2008 R2 Service Pack 1 (SP1) The 64-bit version of Windows 7 Service Pack 1 (SP1) Please try creating a Procmon log from the time you attempt to install the update, maybe it will show incorrect detection of the OS. Also I'm going to drop you a personal message shortly.

Most likely you have enabled logging of all scanned files: Please disable it and delete the big dat files in safe mode.

Please provide me with the ticket number for identification of your ticket. The best would be to know the ID of the ticket that your local customer care used in communication with ESET HQ. In the mean time, make sure that this update is installed: https://support.microsoft.com/en-us/help/2883492/sec-e-internal-error-error-when-a-32-bit-application-calls-the-schanne

ESET never uninstalls itself automatically. It sounds like an issue while upgrading from an older version. Do you know by chance if you had a legacy version (up to v8) installed or you had v10 or v11 before you chose to upgrade to the latest version? You should be able to uninstall / reinstall ESET from scratch. In case of issues, try running the ESET Uninstall tool in safe mode first.

I'd say very soon. It will require a special license for activation since it will be provided as an extra paid service.

No, it's not possible since the tool gathers logs from the system as well as ESET's logs, configuration, etc.

Do you use the latest EIS v11.1.54? Would using the numeric keys above letter keys work as a workaround in the mean time ?

I'm sorry but the archive is password protected. Without knowing the password, neither humans nor AV scanners can scan inside password protected archives. If we were to brute force the password, it could take more than a day for a 6-char. password provided that 500,000 passwords were tried per second.

Most likely your license is not valid or there was a problem exporting your credentials to LiveGrid servers. Please gather logs with ELC and provide me with the generated archive in a personal message.

Hello, basically you should exclude: 1, The ESET install folder: C:\Program Files\ESET 2, The ESET program data folder: C:\ProgramData\ESET 3, Quarantine folders (optional): C:\Users\%UserName%\AppData\Local\ESET\ESET Security, C:\Windows\System32\config\systemprofile\AppData\Local\ESET 4, HKEY_LOCAL_MACHINE\SOFTWARE\ESET 5, HKEY_USERS\%SID%\Software\ESET (per-user settings, optional)

Task orchestration is planned to be implemented into future versions of ESET Management Center (ERA v7+) as MichalJ mentioned here: https://forum.eset.com/topic/14271-future-changes-to-eset-remote-administrator/?do=findComment&comment=71686:

If a submitted file becomes detected, e.g.due to being blacklisted in LiveGrid or because a detection was added, it will be cleaned like any other malware. Unlike the LiveGrid feedback system, in case of ESET Dynamic Threat Defense technology the client will receive a response with scan results from ESET minutes after samples were submitted, run in ESET's sandboxed environment and their dangerousness was evaluated also using machine learning techniques. EDTD will be provided as an additional service and will be included in Endpoint and server products v7+. As for the sample that wasn't detected and you submitted it, please provide me with its hash.

Tencent has been detected as PUA since 2015. Since it was not me who analyzed it, I don't know what's exactly wrong with it. However, the detection was created by an experienced PUA engineer so there was definitely something that makes it PUA.

I've filed a bug ticket for developers since the issue is easily reproducible.

Please contact customer care and provide step-by-step instructions how to reproduce the issue as well as logs gathered by ESET Log Collector. Also share the steps with us here so that we can try to reproduce it and look into it as well.

Please make sure that the policy with the changed password is actually applied. I'd enforce this setting to ensure that it's not overridden by another policy:

Files evaluated by ESET products as suspicious for whatever reason (e.g. they look similar to known malware) are replicated automatically after they are submitted. If they turn out to be malicious, a detection is added either automatically or manually by detection engineers. Such file is also blacklisted in LiveGrid if possible so that all users with LiveGrid enabled can benefit from it and be protected within a few minutes. As for manual submissions, if we spot a suspicious file submitted manually via the built-in form, we check it. However, since there are too many irrelevant files submitted (clean files, media files, etc.), we don't recommend using this way for submitting suspicious files. Instead, please follow the instructions at https://support.eset.com/kb141.

Should the issue persist, please configure Windows to generate complete memory dump as per the instructions at https://support.eset.com/kb380/. After the system crashes and the system restarts, compress the dump and supply it to ESET for analysis.

"Unable to clean" is reported also in cases with insufficient privileges or if the file has been moved before ESET could clean it which could be this case given the folder name C:\Users\dcombs\Downloads. We'd need to get a Procmon log with advanced output enabled from the time when ESET is attempting to clean it as well as logs gathered by ELC as advised above by JamesR. "Archive damaged" messages are reported on archives that are either damaged or they are extremely large. Check if the size of the archives is in GB.

Wildcards can be used only in file names at the end of the path, ie. not to substitute folder names unless a specific threat you want not to be detected is specified. Why is it a problem if /home/*/.ssh is scanned? How many folders are under the /home folder? If you don't use a wildcard, does the exclusion work alright?

Those records are likely logged only if you have logging of all blocked operations enabled. It serves for troubleshooting HIPS-related issues and should remain otherwise disabled. Enabling it may cause performance issues and may unnecessarily waste disk space.

First of all, since this is an English forum we kindly ask you to post in English so that moderators and other users understand you and can respond accurately. As for your question, VPN is not a standard feature provided by antivirus programs. As I have seen, it's mainly provided as a stand-alone product approximately for the same price as antivirus itself. Currently there are no plans to sell a separate VPN solution.