0xDEADBEEF

I think ESET's lightweight is from dynamic binary translation and extensive caching and whitelisting. Generally in-product sandbox (and heuristics) can hardly be lightweight as there are pre-exec unpacking analysis. However, with some engineering effort, one can optimize for common cases. Most users will not generate tons of new binary/archive in a short period of time, therefore by skipping known good files, the performance impact can be reduced significantly. I noticed ESET recently has further optimization on this by caching the DBT-ed data of binary to further accelerate the scanning. https://support.eset.com/ca6626/ However, if you hit the "corner case", like doing huge compilation job, ESET is no longer the lightest weight product (perhaps this is the case in AV-TEST). The lightest weight solution is -- not to scan anything, so no extra instructions to execute

Nov 10 is the date I submitted to the forum. The initial day I spotted the file and right click submit to ESET was around Nov. 8. This implies the livegrid/background submission has very low priority or even be ignored sometimes. For malware spread in small-scale, yes, one generally cannot put hope on antivirus software to deal with them as vendors put more resources on "main stream" stuffs. However, during my test I also see some top-tier vendors blacklist so-called "rare" malware very rapidly upon first exposure on their cloud, or block the sample with behavior shield. This is much rarer in ESET. I have to keep email submitting the samples and get virus definition updated. I don't want to blame anything here, as I understand how hard it is to balance FPs and detection rate. However, I still would like to see that ESET can perform better.

I am opposed to the attitude of saying everything one doesn’t want to see as “not helpful” And I don’t think simply averaging different viruslab results is appropriate as they can have drastically different testing methodology. I believe that AVC real world test can better reflect the real world cyber attack and defense because the test is performed on a daily basis with fresh new samples. All products are tested throughly across all protection layers with cloud enabled. In contrast, I don’t think tests which perform on monthly basis and perhaps only does scanning of a large number of sample or offline detection is still helpful nowadays. In most cases, the life cycle of a particular sample has been severely shortened because of better reaction speed of security vendors. And to be honest, the eset ranking in this test is about right when cross compared with my own testing experience In addition, their detailed report indicates that most product’s fps are from url tests instead of local binaries. ESET sometimes also has FPs in URL blacklisting. Of course AVC’s local binary fp testing methodology is way too limited and perhaps overlap with the white training set of “nextgen” vendors

didn't know that they talked more in the cumulative report thanks.

OK, according to their more detailed setup mentioned in the cumulative result (see itman's link in this thread), I think their testing methodology is fair, which means ESET could do better.

hmm, alright I will submit it if I get a unzipped sample Plus I hope ESET can consider putting coinminer detection in potentially unwanted category. "Potentially unsafe" is sometimes too annoying but "potentially unwanted" is tolerable. There are a lot of users who don't want to have detection as strict as "potentially unsafe" but still want to block miner scripts.

I really hope zh-cn clients can detect flystudio.packed (or at least provide a switch if FP is a concern). Threat of this category is very popular in China but zh-cn and zh-tw version clients don't detect this category in PUA. Legitimate software using flystudio is so few that detecting all of them as PUA as english version does shouldn't be a big deal for ordinary users. BTW, another MBR locker ESET missed. SHA256: c050c6122d1ac7a59e0735b646a2543ebd13bbd8e2a602cafc13eaea0df341c8 I don't have this sample but I assume ESET might be able to get it. https://www.virustotal.com/#/file/c050c6122d1ac7a59e0735b646a2543ebd13bbd8e2a602cafc13eaea0df341c8/detection

cool. Two unrelated questions: 1) why currently ESET puts coinminer scripts in potentially unsafe application category that is by default to be off? 2) is there a way to enable PUA flystudio.packed detection on a zh-cn language endpoint client?

Sounds interesting

Alright, now I know how low the priority of GUI submission is. Thanks for the clarification. If the submitted sample through email is clean, will I get a feedback? How about very large samples that cannot be sent through email?

If you turn on the detection of "potentially unsafe application", ESET will detect the miner script. Not sure why this is in "potentially unsafe" but not "potentially unwanted"

Does it mean the right click submission will not work???? I submitted the sample through right click menu with my email and description around Nov 8 11:00pm CST and it said the sample was submitted to eset.

There is a sampling bias here: the thing I have posted here is sort of uncommon case for ESET (<5% of the fresh new samples I collected personally) My personal experience is that, the more popular the threat is, the less likely it will slip through ESET's defense (assuming no glitches on their cloud backend ). Perhaps the LiveGrid and human analysis prioritize more popular threats first. For the sample in this thread, the reputation in LiveGrid is still unknown when I first got the sample, so I assume the exposure is still low to other endpoints. But of course, the reaction speed of this sample is way too slow from my personal view. In ordinary cases, the fresh samples I have encountered are usually at least blocked by LiveGrid. I have also seen cases that after ~20mins of my running of certain samples that bypassed the ESET, the LiveGrid started to blacklist the sample, which cannot be reflected on virustotal. But as you can see, no security solution is perfect. A false sense of being 100% secured will be disastrous when one encounter brand new samples which can quickly replicate to other machines (e.g. wannacry), unpopular samples (e.g. threats targeting countries where ESET has few endpoints deployed), custom made samples for specific targets (which are nearly impossible to exhibit malicious behavior in auto analysis pipeline), and other special cases which nearly no one can avoid (e.g. CCleaner incident) Since sometimes it is hard to know whether you are on the majority or minority side, the general guideline is to always be cautious when treating unknown files, mails, and websites, even with top tier antivirus products installed. And, my personal suggestion to ESET is that, I would like to see at least some feedback for the sample submission. I have never got feedback for my submission and sometimes felt frustrated. For the samples that are not flagged by ESET days after my submission, I was sometimes not sure if it is indeed clean, or simply didn't catch enough attention like the one in this thread.

Well at the same time BD and KIS reacted very rapidly after the initial exposure. ESET should be compared with top tier products. I would understand the slow response if there are some nuances in this sample though. Otherwise, two days after receiving the phishing mail is not very responsive anyway. It is even after the source of the malicious file, Mediafire, withdrawing the file from sharing due to malicious content.

Unfortunately no. I have tested the sample with ESET before submitting it, but it doesn't block anything during the whole execution. After submission I repeatedly scan the sample about every 8 hours but it is only after this afternoon does it start to detect this sample.

ah, generik detection, after two days of my submission

Hmm... If it is indeed malware, I'd be surprised that ESET still doesn't add detection days after the sample submission.

This originally comes from a potentially phishing mail (so social engineering wise, it is already suspicious enough) It is exhibiting some very suspicious behavior, like vbs drop, add autostart, query security products and UUID, and write files to sensitive paths... But I am not sure about if these are enough to be categorized as "malicious". Most detections of this file on VT are either machine learning/heur and generated by auto pipeline, no concrete signature detections so far though. On VT, the first detection is by Kaspersky, Bitdefender and Cyren, and then followed by avast and avira. I was waiting ESET's verdict for two days and we will see.

SHA1:19eee9336a4527eb76cd2ac69321727f159ad057 I submitted this to eset yesterday but it is not added to the detection so far. Meanwhile the detection on VT is increasing. It is exhibiting some suspicious behavior but I feel it is a bit strange. Is this file malicious?

Will HIPS wildcard be supported in v7?

Recently saw some news about Enterprise Inspector. Just wondering if this functionality will be absorbed to EEI, or it is still planned to return sometimes to the endpoint security product?

Just out of curiosity, when will the endpoint security v7 be released to business users?

My test experience showed that for some threats that can be block in early layers (like scanning or AMS), the later layers might not block it. The ransomware shield is restricted to certain families. In my tests, locky family is the one that is more likely to be blocked. Also, enabling livegrid might be necessary

I think the current design is good, but I like the enterprise GUI better, especially because the current v11 main window still cannot be maximized, which is really ugly on a tablet in tablet mode.

Yes I also saw this when reading ESET's blog post. Just not sure what the limitation will be using this technique