Leaderboard

As additional info, today I got another such document sample which is not detected by ESET scan using latest virus db First look at VT result: Note the first submission of this sample to VT is 12:12 UTC, and I am testing at around 14:00 UTC, around 2 hrs difference in time. Seems to be a tragic result for ESET right? Open it.. Well it is a very typical mal-doc, and ask one to enable macros. Enable, then OK, first internal URL blacklist blocked some Then realtime filesystem monitoring kicked in And finally the botnet protection blocked trojan downloader behavior. And the system is clean with these stuffs successfully blocked. This is a common case in nearly all document samples I've tested As you can see ESET has layered approach against such threat, not just through scanning.

We have prepared a new version 4.0.88 which addresses the issue. It hasn't been thoroughly tested by QA yet but we've installed it on Ubuntu 18.04 x64 and didn't notice any issues with browsers. It will undergo QA testing soon and then will be released for the public. In the mean time, you can download a 64-bit installer from here.

I have always recommended in my forum postings that AV Lab tests should be averaged over time to get a "clear picture" as to a given product's capability. I found such a web site that automates this here: https://fatsecurity.com/tools/test-results-calculator?companyId=16&compareCompanyId=10 The feature I found most interesting is the trend analysis graph. Comparing Eset to Windows Defender over the last two years with all ranking categories: Protection, Performance, and False Alerts rated equally, I observed the following: 1. Eset has a significant overall higher ranking. 2. Both products show a significant increase in test scores during Q1 - 2018 testing. 3. Eset's overall test scoring during the two year period was consistent and uniform. Windows Defender test scoring during this period showed multiple "peaks and valleys" in test scores indicating overall inconsistent capability.

Some more testing reveals that some vendors closely monitor and quickly blacklist VT samples. They can get very bad detection rate when the samples fall outside VT collections This forms a severely biased result: for people who test these products for fun, the samples are likely to be collected from VT or at least been scanned in VT (note that a lot of online sandbox also upload sample to VT as a static verdict). Vendors which closely monitor and blacklist VT samples might get pretty good result because they always get the sample before one can get it due to such sampling bias, so it creates an illusion that these vendors always detect malware samples (ahead of time). In reality, this is not the case, because wide-spread samples might not be on VT and rare samples might be on VT. A recent non-VT sample collection I got had pretty bad result in those high-scored vendors but ESET still performs well. Further tests reveals some simple MD5 modify techniques can easily bypass those VT vendors blacklist signatures (including detection names like GenericKD, UDS, Gen... all are common ones from vendors with good scores on AVC), while ESET's signature and cloud signature have good robustness against such basic technique. So great job ESET

Since you have opted for detection of potentially unsafe applications - PUsA (detection is disabled by default), no wonder that a pot. unsafe application was detected. You can either disable PUsA detection completely (not recommended) or upon detection expand Advanced options, select "Exclude signature from detection" and select No action.

https://www.wilderssecurity.com/threads/avlab-three-tests-against-bashware-ransomware-and-cryptominer-threats.404915/ Of note in this AV Lab test was that Eset was only one of two products for ransomware and one of three products for cryptominers to stop all threats in the early detection stage. -EDIT- Eset missed one cryptominer. Still a very good performance overall.

To dispel any "allusions" that Windows Defender is ready for enterprise level protection is the AV- Comparatives enterprise solutions comparative test for Mar. - Apr., 2019 here: https://www.av-comparatives.org/tests/business-security-test-march-april-2018-factsheet/ For this testing, WD's file-level blocking was set to "high" which would correspond to its default Win 10 Enterprise setting. Out of 620 malware samples, WD detected them all but 31 of them required user interaction to block/allow with also 4 false positive detections recorded. This level of use interaction would clearly be unacceptable in most corporate environments. Eset on the other hand scored 99.4% in this test with zero user interactions and false positives. Eset was also tested at default settings.

My experience is ESET tends to block malware-carrying documents at later stage instead of at scanning stage. VirusTotal only shows scan results. I partially agree that there are more cases that ESET didn't detect the document or other archives that are commonly seen in malware-spreading spams at early exposure stage through scanning (i.e. other scanners in VT already detect it but ESET doesn't). But after opening/executing these files I usually found the actual payload were blocked either by internal URL blacklists or AMS or later defense layers. These experiences include "realworld" ones that the samples at the time I got were not even exposed in VT. So solely judging through VirusTotal doesn't fully reflect a product's detection ability. Many documents of this type for example, are merely downloaders and don't contain the actual malicious code. Blocking the actual payload at later stage should also be counted as successful. Also, blocking some types of threats at later stage is, from my perspective, a way do decrease false positives, especially if you have the experience that some vendors in VT have aggressive detection against downloaders and occasionally also misclassify legitimate files as such family

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.

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

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

Greetings from Australia. My name is Chris, retired Electronics Engineer. I have been using ESET products for many years and am well satisfied with the protection they give me. I am a bit of a "tinkerer" and have 4 installations Windows 7-32, Windows 8-32 , Windows 10-32 and 64 on the one machine. being able to boot into an old version of Windows for recovery procedures has "saved my bacon" a few time when things went awry or got too scrambled in W10 which I use most of the time. An interesting fact about me ?? Nothing exciting ! I am a traveller, haveing visited over 70 countries on fact finding vacations. I am an AVID chatter using SKYPE and other forums with acquaintances in mainly sanish speaking countries.

If they are getting an error "Scanner initialization failed", it's related to upgrade to Windows 10 April 2018 Update (v1803). We have published an alert for this: https://support.eset.com/alert6798/. Disabling Protected service in the HIPS setup and rebooting the machine might mitigate the error. Microsoft is looking into it, however, the result is uncertain at the moment. Wherever possible, I'd recommend upgrading Windows 10 x86 to x64 version.

We have confirmed this to be a bug in the latest ESET Endpoint Antivirus 6.6.2078.5. It will be fixed in the next version of EEA. ESET Endpoint Security is not affected which is why I was initially unable to reproduce it.

Unfortunately, Eset slipped in rankings from previous 2017 Q4 test ranking of level 1 (99.7%) to Level 2 (98.5%) certification. Only test malware detection category Eset improved in was PUA/Adaware in which it scored 100%. Since both 2017 Q4 and 2018 Q1 tests were performed using Win 10 x(64) and Internet Security 11.0.159, it is assumed MRG test samples were the reason for the difference in test performance. https://www.mrg-effitas.com/wp-content/uploads/2018/05/MRG-Effitas-2018Q1-360-Assessment.pdf

If you delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{3DD675F0-E4EB-4CCD-A57E-2C47B8C86675} manually, install Agent from scratch and then uninstall it, does this key remain in the registry?

That's how it works in ESMC (ERA v7) which is currently in the phase of beta testing and will be released soon.

There are 2 automatic startup scan tasks that would detect any malware in memory or autorun locations.

"Are you running Windows 10" and "Is Fast Boot on?" should be way higher up the list of questions. Turning FB off has sorted a wave of issues in my shop.

If the computers are completely offline (ie. connection to ESET's servers is not possible even via an http proxy with connections restricted to ESET's servers), activate them using an offline license file. For information how to generate an offline license file, please refer to https://help.eset.com/ela/en-US/downloading_offline_legacy_licenses.html. On a computer with Internet connection, use the Mirror tool to create a local mirror (https://help.eset.com/era_install/65/en-US/mirror_tool_linux.html?mirror_tool_windows.html). You can transfer its content to a computer that is accessible from the offline computers and point them to update either from a share or use a simple http server to provide the mirror content via http.

Some of it may be speculation....some of it may be fact. It all goes through official channels. It is against forum rules to announce releases...see #17 https://forum.eset.com/topic/76-rules-of-the-eset-security-forum/ ESET will release information when it is ready (no sooner...no later). Granted we are talking about beta testing here, if you've signed up to participate in that, you should see it here (or perhaps get an e-mail). I'm not sure as I do not do A or B testing anymore.

Did you restart the computer after upgrade to v11.1? I mean a true restart (e.g. by clicking "Restart computer" in ESET's gui), not a hybrid one via the Start menu. Try restarting the computer via "shutdown -r -t0" and let us know if the issue goes away. Does uninstalling v11.1 and installing it from scratch resolve the issue?

Hello Rod. See https://support.eset.com/kb3466/ as per Marcos's instructions, then send him the ELC logs via PM (Private Message...you can do so by hovering over his name and then select "message"). Be sure to open a case with your local customer care.

I fixed the link reference.

Hello guys, the issue is fixed in HIPS module 1321+, the module will be distributed automatically. Thank you for reporting this to us. Regards, P.R.

That's interesting. There have been reported issues with Win 10 x(86) 1803 and Eset ver. 11.1.54; mostly on NOD32. I haven't heard of any with Win 7 however.

Hello @Tyler Reilly , we noticed this error as well, usually it happens when Windows indexing service touches our files during the update process, which does not happen on each update, but just on some of them. This issues is addressed in new builds 11.2.15.0+ (not yet publicly available) Edit: A colleague told me, that you are a business user, what I didn't realize, sorry for that. I will try to update this thread, when I will find out the version of EES where, it should be fixed. The easiest workaround is probably to exclude ESET folders from indexing, or just to wait for the service release. Regards, P.R.

That is most likely because every http connection goes through esets_proxy.

Could you specify version of MySQL database you are using? Is this clean installation? MySQL 8.0 introduced changes in communication/authentication protocol which we do not support - if this is the case, MySQL 5.7 will be required to run ERA.

The problem here is with seccomp sandbox which has never been supported by pac and which limits the allowed syscalls for a whole process. We use such syscall and the OS kills the process then. There is no workaround but recompiling the kernel with seccomp disabled. To prevent this from happening, we'll have to detect that seccomp is used by a protected process and behave accordingly. This detection will be added soon and will be included most likely in version 4.0.89.

@slarkins Although I am a bit biased, from the point of view of being the PM responsible for ERA, I would like to assure you, that ERA version 6.5 is a stable, reliable product, that we are getting a lot of positive feedback for. But of course, I encourage other users, to provide feedback to you. Also, if you are not a big company, I would maybe recommend you to wait for a couple of months, as in September we will globally release ESET Cloud Administrator, which is cloud-based version of ERA, focused on the needs of smaller companies (up to 250 managed computers). You will not have to take care of the server, its maintenance, and the entire operation would be much simpler.

Drag and move it wherever you want the notifications to pop up.

After you get ESET REMOTE Admin version 6.x installed and agent pushed out to a Version 5.x endpoint you can "request configuration" and "convert to policy" to bring over policies for Version 5.x. If you were just using the defaults in ERA 5.x you can just use the default Version 6.x Endpoint for Windows policy. In ERA 6.5 console you will create a client uninstall task to remove V5 Endpoints and 4.5 File Security. I highly recommend unhooking self defense on 4.5 EFS before uninstall as some uninstalls have been known to hang and self defense was causing it. After you have push uninstall and rebooted (client install task of V6 product will fail if you don't reboot first) then do client install task and push 6.6 out to endpoints. I have not heard of any issue with current build causing slow file access. If all endpoints are protected you may want to turn off network scanning for real time file system protection.

Make sure "Disable notification about successful update" is unchecked as shown in the below screenshot:

EFSW 6.5 doesn't create mirror files for Endpoint 6.6. This will be first supported in EFSW v7. We strongly recommend using HTTP Proxy instead of a mirror to save bandwidth and to ensure that only files that are really needed by clients are downloaded. If you need to use a mirror, use the command line Mirror tool or create it using Endpoint 6.6.

Developers have reproduced the issue and are working on finding the root cause with highest priority. We'll keep you updated.

Hi team! Description: Save reports to a shared folder / network directory. Detail: Currently, it's just possible to save reports in ERA 6 to the default Windows/ Linux path. This is a bit difficulty to get results faster. Thank you.

I had a similar incident a while back. I was installing a different ver. of Eset Internet Security over an existing version. The installation terminated midway through with an error. The installer rather than rolling back to the previous version, left the new ver. partially installed but non-functional. In other words, no operational version of Eset Internet Security was installed as far as the OS was concerned. This should never happen.

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.

I can confirm this behavior. It started on my Eset installation, 11.1.54, on 5/29. In my case, I have a HIPS rule that allows svchost.exe to startup cmd.exe that I log. Prior to 5/29, the log always showed for operation - startup application. The log now shows unknown operation. The main question is if existing user HIPS rules are functioning properly? -EDIT- The only Eset module updated on 5/29 was the router vulnerability scanner.

In your specific case,my guess is that specific configuration caused that sending of email resulted in "deadlock", where both client and server were waiting for remote peer activity. This might happen especially in case connection security type is not properly configured. I guess that restarting ERA service (triggered by system update) with proper configuration actually resolved this. Just for future reference, following hostname/port/security configurations should work with smtp.gmail.com: smtp.gmail.com, 587, STARTTLS, Login, Plain or Automatic authentication smtp.gmail.com, 465, TLS, Login, Plain or Automatic authentication Also be aware, that it might be required to enable less secure apps access your account which is caused by fact that ERA does not support OAUTH authentication method which is the only considered as security for this server.

Great. Thank you.

Hello, In order to remove an account, expand it (so that the token shows) and then swipe it to the left. A red trash icon will be revealed and you will be prompted by a pop up dialog to confirm whether you want to keep or delete the account. Regards, T.

@VIP Problem is not with Apache in particular or with the proxy. Problem is with invalid data being cached. They have set expiration for 7 days, so the solution would be to clear the proxy cache, not to disable caching / proxy at all. MartinK requested the data, to verify this suspicion, that seems to be the most likely reason for the problems.

Showing the interactive window to the end-user is not very good idea, because users often click "allow" and then get "infected". The decision should be in hands of administrator (e.g. through ERA console) who should add exclusions for potentially harmful tools he wants to use. Additionally when users clicked "allow" without adding an exclusion, the tool was detected again and again (by on-demand or on-access scanners). More information here: https://forum.eset.com/topic/14743-request-for-feedback-on-a-plan-to-change-handling-of-potentially-unwanted-unsafe-applications/

@davidenco Thankyou.. I have followed your suggestion and cleared out the cache folder (\ProgramData\Apache HTTP Proxy\cache) and but restarted the ApacheHttpProxy service. All is good now and the packages are being installed from the ERA Server.

Do the new updates deal with this threat? See: https://www.zdnet.com/article/this-malware-is-harvesting-saved-credentials-in-chrome-firefox-browsers/?ftag=TRE-03-10aaa6b&bhid=21977969419277629210563629293254

Description: Nested OR and AND in Dynamic Groups / Virtual Machines Detail: Nested OR and AND in Dynamic Groups creation, so you can have two or more sets of OR under an AND, or two or more sets of OR under an AND, or any combination. Example Virtual Machine or not (Physical) so we can split these two types apart, some advice here for how to determine it, will likely require nested criteria:https://blogs.technet.microsoft.com/kevinholman/2014/10/16/faq-how-can-i-tell-which-servers-are-physical-or-virtual-in-scom/ PS. What's the rough expected release date for ESMC V7 at the moment?

It appears that the Kali Linux download from Offensive Security also includes links to pen testing tools such as Metasploit which includes Mimikatz. Since these tools can and are used maliciously, this is what Eset is detecting.

Unfortunately without a proof we cannot comment on it. Of course, no antivirus detects 100% of all threats, especially when it comes to scripts. And blocking all powershell scripts just because they could be misused is not a good solution either.