0xDEADBEEF

Agreed. But it is hard to reproduce exactly the same scenario of how it is originally delivered. Also, user initiated download and execute is still one major way of getting infected. I personally consider the protection against payload itself as equally important, even though it might be intercepted by other defense layers first.

Yes I am talking about executables. I don't consider those macro malware or script downloader that eset failed to detect initially as a "bypass", unless the downloaded payload execute successfully and do something bad without being detected. Generally, ESET is impressive in detecting most threats (it is much harder for me to capture a fresh malware before ESET does after all). One example is my post of that ransomware sample last time, there are some others (very few), and I'd be glad to notify ESET if I spot others in the future.

That's interesting also, seems my test samples are so special that I occasionally encounter ones that bypass all protection layers of ESET

hmm interesting.. Reminds me of this: https://www.eset.com/ca/about/newsroom/corporate-blog/esets-position-on-nss-labs-advanced-endpoint-protection-10-test/

Yes the sample size is small.. but if you look at past tests (starting this January), you will find that ESET is consistently low-ranked in these tests. What I want to know is that in their tests, if the "compromise" means the malwares are indeed effective (in other words, mimic the real world scenario) and penetrate the protection layers (e.g. somehow successfully executed without being detected). If both are true, then ESET indeed consistently missed something and needs improvements.

That's why I don't usually trust VT results (it is a poor indicator for saying if one product is bypassed or not)...

I remembered Microsoft's username in its engine was "JohnDoe". Not sure if they have fixed it or not.

ekrn 42,104k, egui 16,404k Attached screenshot sorts the mem consumption from highest to lowest. As you can see, the memory in use (green bar) exceeds 13GB. 10.1.210.2 and 10.1.204.1 have the same issue. ver390 is fine

64-bit win10

Not surprised at all. Did you try and see if it bypasses AMS?

Hmm, maybe I just have too many "rare" stuffs. Yes SS helps a bit sometimes. But it is user who finally decide whether to use it or not (SS usually doesn't flag something as malicious, but more of "IDK if it is benign or not"). If a user wants to use it, they will use it anyway unless something explicitly flag it as harmful.

Nope, I didn't get this sample directly from their distribution source. But from my experience, this one is likely to be exec-ed by the user through file explorer

thx for sharing.. hmm.. I once used similar way described in this doc to sniff the av sandbox

I am helping someone to report a potential memory issue. He is using ESET Smart Security 10.1.219. The problem was that the available memory kept decreasing after booting up the machine. He didn't find any process that was taking up such huge amount of memory. He couldn't even browse website properly in such scenario. His observation was as long as the web browser (firefox) was open, the available amount of memory kept decreasing, and finally made computer unusable. After turning off the "Enable application protocol content filtering" under "Web and Email", he could browse the website and the avail RAM didn't decrease any more. However, the available amount of physical memory is still pretty low with this setting (<3GB). After rolling back to 10.0.390, the problem is resolved. Environment: OS: Windows 10 Pro 1703 CPU: Ryzen 5 1600 RAM: 16GB

Although I hate to say this, I have a similar feeling. I think calling ESET custom HIPS rules for file access monitoring as anti-ransom module is more appropriate, but that's not what a normal user will do. And I believe ESET will not like the idea because it is user dependent and hard to distinguish good file accesses from bad. ESET is really powerful in detecting known ransomware families and their variants. I have observed that the old definition several months ago can still detect many of the new variants of known ransomware families (primarily through AMS, and some through anti-ransomware module) Maybe it is also because when hackers sell their products, the first proof-of-work is to bypass scan engines. But I have a feeling that ESET is a bit "delayed" when reacting to newly born ransomware. This is fine for most threats because you can assume that most user will encounter a "known" threat rather than a new one. You can even say that if the prevalence of a threat grows really quickly, it will definitely catch ESET's attention and lead to a faster response. But If the attack uses some ways to quickly propagate itself, then then situation could be much worse. I agree that in most cases, people need to primarily optimize for common cases (known threats), but letting so-called corner cases fail gracefully is equally important from my perspective.

I doubt the next gen ones deploy behavior analysis in VT. Most of them should be static detection only

If this is true, I'd say it is of zero robustness

I think anti-exe is very limited against a lot of attack vectors. Digging common software exploits (including something like DLL hijack) can easily bypass these software if the rule is not carefully created.

My sandbox is based on win7 x64. I personally don't consider SS as an effective advisory against malware because it simply generates too many FPs on legitimate programs. With such high FP rate, SS can be easily bypassed with a bit of social engineering. This sample is just one example which pretends to be an unpopular VPN client.

Lol yes. It is a complex one although its behaviors also touch multiple red lines compare to some more stealth ones. It took my poor sandbox over 5 minutes to process a 60sec running trace. Hmm, is ESET'S DBT useful when dealing with this kind of malware?

It is less than 10 PC's worldwide with ESET sensors, but it doesn't necessarily mean the prevalence of the sample is indeed that low. I don't know how large the user base of ESET is in China, but this might not be a good news to Chinese users I assume? Of course, it is unrealistic to hope that antivirus software can always block "rare" malware. But I cannot help wondering if there are some effective ways to help mitigate these corner cases. Paranoid users like me will use sandboxes or some other auto-processing pipelines to evaluate the sample before running, even when the antivirus flag it as benign (this is still very limited if the execution is triggered through exploit or reside purely in memory). Normal users trust what antivirus says instead. The paradox is that, when I see something marked as benign by ESET, how do I know if it is really benign, or it is actually because it has not been fully analyzed by their intelligent system? When I see the reputation is unknown, do I wait for days until the reputation becomes "safe"? It is not the first time I encounter this situation, and I really hope that ESET can strengthen its anti ransomware protection through some way. A false positive might be disastrous, encountering a ransomware like this is equally bad.

Of course I submitted . I just didn't put the link here because it is not appropriate. Even I didn't, LiveGrid should have collected the sample if it worked as claimed. Or it will be captured by VT sample sharing which already has 30 vendors reporting that sample as malicious at the time I spotted it. The point is: who protects me in such scenario?

Well, another of real-life experience with ransomware bypassing ESET protection layers. It is still "at large" even for now with ver15819 definition and has 3 days of reputation history... Other vendors have successfully block the encryption through their behavioral detection layer, how about ESET? The SHA256 is a3d939adaa73dc95cc29a43889b2f7b64ecceecd70ed490d6621656a3712f372

Well, this is just the ultimate undecidable problem proved in Cohen's work. The attacker can manipulate the control flow of the program and trigger it only under certain circumstances. This will even evade the automatic sandboxes (like Cuckoo), or auto sample processing pipelines on the vendor side if it is well crafted and have a specific set of targets. One solution is to constantly monitor the behaviors of untrusted programs even when it is in-flight. Many security software have this mechanism. ESET is heavily relying on AMS (it is also "constantly monitoring", but it is still pre-execution examination of the code). It is lack of constantly monitoring in HIPS automatic mode (or, very weak when also considering the antiransom module). The AVC's test you quoted also showed a similar result.

I have seen antiransomware module popups several times when I was testing a batch of locker/kovters which have bypassed AMS. I found that they are tuned to be rather conservative and only react to certain type of ransomware, perhaps due to the concern of false positives. That might be true in the end of the day. But MSE still has a long way to go... At least its engine is not as strong as you thought currently.