Sp Ebil

Very dissatisfied with Eset

Recommended Posts

We are a company and we use Eset endpoint products for more than 8 years.Unfortunately,here and at least 1 year,every email we receive with an attached file, we have to look for it in Virus Total.

We have never seen Eset quickly find a file as trojan,walware e.t.c.This morning,10 / 59 other antivirus in Virus Total detect email attachment as Trojan.We are still waiting for Eset.......

We know that 6-10 hours from now,Eset will recognize it.We are already in search of a different product.

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

JamesR and Peter Randziak like this

Share this post


Link to post
Share on other sites
Posted (edited)
2 hours ago, Marcos said:

Among those 10/59 detections were none from a popular AV with a concrete detection name: all were generic detections.

If even Microsoft detects it as "Trojan:Win32/Fuery.B!cl"  , this raises big question marks about  ESET capabilities.

2 hours ago, Marcos said:

what matters is the reaction time of vendors when a malware is not detected heuristically / generically without update

I respectfully disagree. It is impossible to detect a "Zero day" as a malware with a name , so the key is to be detected  heuristically / generically without update; this is the generally accepted idea , and the trend today.

If ESET bases the detection only on signatures will always be behind....And that may explain the poor result in AVTest /AV Comparatives.

Edited by claudiu

Share this post


Link to post
Share on other sites
1 hour ago, claudiu said:

If even Microsoft detects it as "Trojan:Win32/Fuery.B!cl"  , this raises big question marks about  ESET capabilities.

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.

Quote

If ESET bases the detection only on signatures will always be behind....And that may explain the poor result in AVTest /AV Comparatives.

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/

Share this post


Link to post
Share on other sites
4 hours ago, Sp Ebil said:

How can i send you another file that came before 10 minutes ? .It's rar with name Swift.uue .Your forum system below,does not allow me to send it.

https://www.virustotal.com/#/file/d2509123dc6ebe0761cad617fd541d4941aa8710f4978bc579e4ac27722e9148/detection

This one shows 3/60 at VirusTotal which would put it in false positive territory.

Also, AV detection of prior .uue files which are executables has been low as shown at Hybrid-Analysis: https://www.hybrid-analysis.com/search?query=swift.uue

Share this post


Link to post
Share on other sites

VT is not using the most current engine. The sample is detected:

4646921ee4c0666a15a188dadbffd97632b245b9 » RAR5 » Swift.exe - a variant of Win32/Injector.DYKM trojan

 

Share this post


Link to post
Share on other sites
Posted (edited)
9 hours ago, Sp Ebil said:

This sample was only spotted 7 hours ago at VT:

Relevant dates related to the file being studied.
 
First Submission 2018-06-04 04:12:27
Last Submission 2018-06-04 04:12:27
Last Analysis 2018-06-04 11:13:43
 
-EDIT- Also this malware is exploiting MS Office vulnerabilities that were patched last year via CVE-2017-8570 and CVE-2017-11882. So the best way to eliminate "crud" like this is to always apply OS and app security updates ASAP.
 
Additionally, only two relatively obscure AV solutions originally correctly this malware as the exploit it is. Proof that there really is no better protection against exploits than by promptly applying patches when they become available. Per VT comments section:

Detected by THOR APT Scanner

Detection
============================
Rule: MAL_MS_Doc_Embedded_OLE_PE
Ruleset: Exploits
Description: Detects a suspicious string often used in PE files in a hex encoded object stream

Reference: https://github.com/rxwx/CVE-2018-0802/blob/master/packager_exec_CVE-2018-0802.py

Author: Florian Roth
Score: -

The above would be indicative that CVE-2018- 0802 was combine with one of the previous exploits in this attack; something it appears no one detected:

Quote

The security update addresses the vulnerability by removing Equation Editor functionality. For more information on this change, please refer to the following article: https://support.microsoft.com/en-us/help/4057882

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-0802

Edited by itman

Share this post


Link to post
Share on other sites
8 hours ago, itman said:

This sample was only spotted 7 hours ago at VT:

How is this relevant????

If there are mechanisms in place to detect it as a "zero day", then should be detected in first second. After is posted on VT , anyone can issue a signature based on MD5.

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, claudiu said:

How is this relevant????

If there are mechanisms in place to detect it as a "zero day", then should be detected in first second. After is posted on VT , anyone can issue a signature based on MD5.

To begin with, Microsoft detected by generic signature. That same signature has been associated with past false positives.

For this particular malware to have been detected by Eset, it would have to first been run on an unpatched device. If the device was patched against the referenced exploits employed, the malware wouldn't have succeeded and most likely would have never attempted execution. When run, the malware would have been captured and uploaded to LiveGrid for analysis.

As far as my 7 hour comment, AV Lab Realtime tests consider a detection with 24 hours to be acceptable and the AV solution is not penalized for initial non-detection at file creation time.

Finally, there are no true zero day security solutions in existence short of anti-executable software. Along the same line if Eset's HIPS was running in Interactive mode, malware execution would have been detected. However in each case, user interaction would be required with an allow or deny user decision required.

Edited by itman

Share this post


Link to post
Share on other sites
12 minutes ago, itman said:

Along the same line if Eset's HIPS was running in Interactive mode

By default HIPS doesn't run in interactive mode, so the malware execution would have been NOT detected.

13 minutes ago, itman said:

detected by Eset, it would have to first been run on an unpatched device

the mechanism involved in detection should be  transparent for the user ; explanations like "it would have to" ," if HIPS was running in Interactive mode", "would have been detected" prove once more time the infinitesimal probability that ESET would detect the particular malware in NORMAL CONDITIONS.

At the same time we had 10 from 50 antiviruses which detected (I do not care how) , the sample at first view. After 8 hours and a posting on the forum ESET added the detection.

The OP summarized very well the situation :

16 hours ago, Sp Ebil said:

Unfortunately,here and at least 1 year,every email we receive with an attached file, we have to look for it in Virus Total. We have never seen Eset quickly find a file as trojan,walware e.t.c

 

Share this post


Link to post
Share on other sites
Posted (edited)
3 hours ago, claudiu said:

The OP summarized very well the situation :

20 hours ago, Sp Ebil said:

Unfortunately,here and at least 1 year,every email we receive with an attached file, we have to look for it in Virus Total. We have never seen Eset quickly find a file as trojan,walware e.t.c

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

Edited by 0xDEADBEEF
Peter Randziak and itman like this

Share this post


Link to post
Share on other sites
Posted (edited)

As a follow up to @0xDEADBEEF VirusTotal comments, I am posting the following from their FAQ section. One can interpret such activity as "gaming the results." In any case, it illustrates that VT results should not be taken as "absolutes" when it comes to determining a given product's actual malware detection capability:
 

Quote

AV product on VirusTotal detects a file and its equivalent commercial version does not

VirusTotal antivirus solutions sometimes are not exactly the same as the public commercial versions. Very often, antivirus companies parametrize their engines specifically for VirusTotal (stronger heuristics, cloud interaction, inclusion of beta signatures, etc.). Therefore, sometimes the antivirus solution in VirusTotal will not behave exactly the same as the equivalent public commercial version of the given

https://support.virustotal.com/hc/en-us/articles/115002122285-AV-product-on-VirusTotal-detects-a-file-and-its-equivalent-commercial-version-does-not

Edited by itman
0xDEADBEEF likes this

Share this post


Link to post
Share on other sites
Posted (edited)

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.

detection.thumb.png.87b392c5f5ea82ad20633f3dac33fefc.png

Seems to be a tragic result for ESET right?

doc.png.adca6f6014287d44e8ed8d34ce40f583.png

Open it.. Well it is a very typical mal-doc, and ask one to enable macros.

2018-06-05_091853.thumb.png.10fc52245ed111ff7fe448ec16e2919a.png

Enable, then OK, first internal URL blacklist blocked some

2018-06-05_091905.thumb.png.b0696b27c83d699a8faef3ba2c4ec278.png

Then realtime filesystem monitoring kicked in

botnet.png.466b4993da69e4847f8a4ff7c1457f4d.png

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.

Edited by 0xDEADBEEF

Share this post


Link to post
Share on other sites

Also of note is none in this Office 365 example at VT positively identified the macro based malware which would not be possible until the macro was actually executed. Additionally, only two vendors were able to positively identify the VBA malware dropper.

Share this post


Link to post
Share on other sites
Posted (edited)

Also applicable to this discussion is a posting by @0xDEADBEEF made in another thread that I am copying below:
 

Quote

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:)

 

Edited by itman
Azure Phoenix likes this

Share this post


Link to post
Share on other sites
2 hours ago, 0xDEADBEEF said:

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.

This malware was released shortly after we started building the noon update so it made to update 17503 which was released 2 hours ago (at VT ESET isn't updated yet). We made sure that the payload was detected so that our users were protected from the very first moment even if the file was not detected by the on-demand scanner.

Share this post


Link to post
Share on other sites

Here's a nasty backdoor hitting the Indian sub-continent:

Analysis of MSIL.Backdoor.SocketPlayer.A - https://file.gdatasoftware.com/web/en/documents/whitepaper/G_DATA_SocketPlayer_Analysis.pdf

This downloader hash - 1fd13875bf3df273acc893c6a0fe0144a05d5534624471baaa48f014757301ef - is still not being detected by Microsoft although it was first submitted to Virustotal on 4/2/2018. Guess this one slipped through the Microsoft "detection crack.":o

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.