0xDEADBEEF
-
Posts
361 -
Joined
-
Days Won
3
Posts posted by 0xDEADBEEF
-
-
3 hours ago, itman said:
Finally one will ask why products like Bitdefender, Kaspersky, and others had high test scores. The reason is those products use both a HIPS plus local and cloud based behavior analysis with sandboxing in their detection processing.
Thanks for the info. I understand that one should always balance between detection and FPs, and sometimes sacrificing detection rate a bit is unavoidable for usability. However, I also see that some products like Bitdefender or Kaspersky achieved good detection rate while also maintaining decent FP rate in AVC (Kaspersky's FP is on par with ESET, and Bitdefender is slightly higher). Doesn't this imply that sacrificing less detection to achieve the similar FP is doable? Especially if the FP testing samples are cherry picked towards the gray zone, it implies their ways of suppressing the FP also work pretty well.
They have something that ESET currently doesn't. K has cloud-based HIPS and rollback mechanism. B has a complex weight-based process and inter-process scoring algorithm to deal with post-execution scenario. Although AMS is a similar technique, it still suffers in some cases while other behavior blockers may well handle these corner cases. I know it is much easier to say than actually implementing additional protection layers without introducing more FPs, but I just hope ESET can become better. It has decent HIPS modules, it has a good reputation system. Maybe it is a good idea to exploit more from these infrastructures.
oh, but I really love ESET's low perf impact and good compatibility with sandboxes
-
13 minutes ago, TomFace said:
"Personal experience is never representative.".........but it's the biggest factor in making a decision as to what service to use.
Some folks require repeated validation of known (past) experiences. Those folks most likely subscribe to magazines that tell them what to buy (like cars).
Other folks just go buy the car they want (after a test drive).
I choose not to suffer from analysis paralysis.
Personal experience can be helpful, but not all the times. When you do a short-term test drive, you never know if there are some hidden engine problem that might outbreak and lead to disasters sometimes later. For a layman, finding a dealer with good reputation might be a safer option.
Similarly, encountering cyber-threats might be rare and the threats are usually in stealth. Trying is definitely necessary, but the loss induced by these attacks might be too much to afford. Relying on trustable reviews with a systematic testing approach is a natural way to help make decisions.
We see similar things in testing processor performance: product A could outperform B in metric 1, but could also be beaten in metric B. This is natural and is because many things are just too complex to be measured by a single standard. I don't think security product is an exception. I'd prefer to gradually learn and interpret these results and metrics (which might contradict each other if only looking at numbers) in an objective way and fits my need, instead of simply saying a no to these stuffs.
-
2 hours ago, cyberhash said:
I think "real world experiences" paint a better picture than any tests can ever achieve. From my own personal experience i have never been infected by anything major since using ESET's products, which i have done since their first version of NOD32.
Then again the weak point in any security app is more likely to be the user. From opening an email with a pdf/word document attached or trying to download pirated products, or visiting bad sites/links.
Back when everyone was a member of Wilders Security Forums it was easier to draw a conclusion as to what performed better as you had users of every security product giving opinions and feedback to a wider audience in one place.
Then on top of detection, you have to look at other matters that affect each product. Like false positives , system impact, borked updates, bad definitions including flagging of windows files as bad.
ESET has done consistently well in these area's too and should always be taken into consideration when making a choice/purchase.
I don't doubt that Microsoft is improving as you now have forced telemetry built into your o/s that was never there before. In addition to them now trying to draw more attention to their own security products.
But i still get a feeling that you won't beat a company who's sole business is in security and have been in that business for a long time.
Personal experience is never representative. As some articles pointed out, no test can directly guide certain user's choice of AV products especially when correlating with his/her usage pattern. I have several experiences of my computer got infected by web trojan when using NOD32 full protection (when it was at ver3.0), but it doesn't mean anything to other people, nor do other individual's personal experience.
That's why we need some 3rd party test. Generally it is assuming a single person facing all possible (sampled) threats and obtain the probability of infection. I personally view it as the evaluation in "the worst possible case".
Well, ESET indeed does exceptionally well in balancing FPs and detection rate. But when a certified 3rd party test is consistently showing that it ranks relatively low in detection rate compared to other products, there should be some explanation. On tester's side, this could be due to bad samples, biased samples, inappropriate testing methodology, etc. But it might also be due to the real missing pieces on the vendor's side. I personally tend to suspect the sample quality first before I question the security product. But since I can get no more info from their reports (especially for the system performance impact evaluation), I can only post here and hope someone can give a more convincing explanation.
My view is: if any test raises an issue, there should be some explanation. It could be the issue with the test itself, it could be the issue with the product, or it could be both.
P.S. I've personally played with Microsoft's heur engine, and I know how funnily it performs
-
4 hours ago, cyberhash said:
I thought av-comparatives was the only one that was impartial with its reviews.
@0xDEADBEEFLikewise i don't think that o/s version should really dictate the outcome of the test, If the same sample sets are being used on all the products tested.
I don't either. Actually I care more about what kind of samples did ESET miss every time. Even though it is a very small portion of the whole sample set AVC uses each time, the consistent miss ratio makes me curious about if they are of the same type or not.
I personally don't care too much about the AMTSO org results unless they look too bad. But I indeed heard some people posting negative comments about ESET saying "it performs even worse than the free Windows Defender"... So I think some reasonable explanations are good to have
-
20 minutes ago, itman said:
Could be AV-Comparatives use of Win 7 in these latest tests.
Eset employs all the latest security enhancements - ELAM, AMSI, etc. - build into Win 10. Therefore, AV-Test and Virus Bulletin tests on Win 10 show better scores. Additionally, ESET is a top performer consistently in SE Labs(UK) and AVLab(Poland) tests.
OS might be a factor. But if this is the case, since there is still a decent amount of people using Win7, it does not make sense to provide a compromised protection in one system but not the other.
Region (sampling bias) might also be a factor... But if this is the case, it is not a good explanation to north America users..
VB employs quite different testing methodology (# sample is small, only tests static detection, while AVC real-world test seems to test all protection layers, that's why ESET has dynamic detection). I am not familiar about other EU tests, will take a look.
As for performance impact score, ESET has very bad score in AV-TEST but very good score in AVC... This is really funny. My experience is that ESET is very light weight (proved by its very low power consumption by looking at energy meter in a windows tablet), but apparently some tests disagree with this.
-
I have noticed that ESET has been placed in relatively low ranks in AVC's real world tests (from Feb. to Jun.). I am just wondering if this is due to ESET's relatively conservative detection strategy.
Of course, the number of samples they use in real world test is pretty low (~400), and many times the detection rate of different products are pretty close (so the # of missed samples is actually very few). I have read David Harley's article about AV tests and understand that sampling bias and many other factors might affect a product's detection results in a test. But several months of similar rankings still make me wondering if ESET missed more than other vendors (of course the FP rate is always very decent compared to others). Another thing I noticed is that ESET seems to be a bit conservative in detecting macro malwares. Is it because ESET prefer to deal with this at later defense level? (like when payload is actually downloaded?)
Another mysterious thing is that the performance test in AV-TEST and AV-Comparatives are utterly opposite. Is it because of the difference in their testing strategy?
-
1 hour ago, Marcos said:
There are currently no plans to use it in home products as administrators are usually technically savvy enough to be able to handle increased number of false positives which cannot be said about majority of home users.
Cool, thanks. Looking forward to seeing the new detection feature in the future endpoint releases.
-
8 hours ago, Marcos said:
It's a feature that is being fine tuned to reduce false positives and was not supposed to be seen by users yet.
Thanks. It means it will be available again sometimes in the future endpoint release? Will it also be available in personal products?
-
22 hours ago, Marcos said:
The setting should not be visible to users. Please tell us in which product and version do you see this setting? Is the product fully updated? Does it update from pre-release or regular update servers? Also post information about installed modules from the About window.
I once saw this option in the ESET Remote Administrator (in an old version). I am currently using ERA 6.5.522 with EES 6.4, but cannot find this option anymore.
I remembered the option was here in the policy tab of windows product. Is it an abandoned feature?
-
I've noticed that some people's endpoint security has an optional high sensitivity heuristic in the threatsense parameter. However, I cannot find this option in my v6.5 endpoint security installation. Is this option only open to some companies or controlled by the administrator?
-
On 6/25/2017 at 3:07 PM, itman said:
Only applies to Windows 10 CU Enterprise versions:
Mitigation with virtualization-based security
Virtualization-based security (VBS) provided with Device Guard on Windows 10 and kCFG enhancements with Creators Update stop common exploitation techniques, including those utilized by ETERNALROMANCE and ETERNALBLUE.
Stopping shellcode execution with W^X enforcement
On systems that have Device Guard VBS enabled, writing and then executing shellcode—such as the ETERNALROMANCE backdoor—in the kernel is not possible due to W^X enforcement policies in the hypervisor. These policies ensure that a kernel memory page is never both writable and executable at any given time.
Even if an attacker tries to attack page tables, the hypervisor is still able to force the execute-disable bit through extended page tables (EPT). This in turn forces attackers to rely on code-reuse methods, such as return-orientation programming (ROP). As a consequence, the shellcode implant library in the Shadow Brokers release is fundamentally incompatible with VBS-protected systems.
Preventing use of corrupt function pointers with kCFG
In Windows 10 Creators Update, we introduced a new security mitigation in the kernel space for VBS-enabled systems. The kernel is now compiled with Control Flow Guard (CFG)—a control flow integrity solution designed to prevent common stack-pivoting techniques that rely on corrupt function pointers or C++ virtual method tables.
Control Flow Guard in the compiled kernel (also known as kCFG) aims to verify all indirect call targets before invoking them. This makes it harder for an attacker to execute code by abusing function pointers or other indirect calls.
In the case of the ETERNALROMANCE exploit, the subverted function pointer would lead to a security fault when invoked, making the exploit non-functional in its current form. The same applies for ETERNALBLUE, which also relies on a corrupted function pointer to achieve code execution.
On early Windows 10 systems before Creators Update and without Device Guard, it is possible to attack the page tables of the HAL region to turn it executable and gain code execution using the ETERNALBLUE exploit technique.
Thanks!
-
On 6/15/2017 at 1:32 AM, Marcos said:
I have a different experience. AMS and anti-ransomware protection seem to be very effective and detect malware in memory even if authors re-pack it to evade detection. While it works to evade detection by most of other AVs, ESET would still detect it by HIPS (AMS). As far as I know, only Microsoft uses a similar technology.
So Microsoft also has some in-memory detection mechanism? Is there a name for it?
-
On 6/20/2017 at 4:39 AM, J.D. said:
We check all the new products in the market to find out if there are some groundbreaking startups/ideas and so far we haven't seen anything like this. We could find a way to bypass their protection methods usually in matter of hours. ESET policy however is not to publish offensive research results against competitive products - we prefer to live in a friendly security industry.
Somewhat expected...
BTW, I enjoyed reading the last part of the machine learning discussion from ESET
-
18 hours ago, J.D. said:
All of them have serious issues from effectiveness to performance impact. Modern ransomware inject into multiple process where some processes create new files and the other delete or rewrite. For a good solution, you would have to track every change in the operating system which is very performance heavy. Ransomware Shield is triggered usually after a few changes done so we still have such feature on a to-do list, but we prefer to invest into other layers to block the attack. One of them is AMS. The idea for AMS is to prevent malicious activities before they happen, like in the “Minority Report” movie :-) It is not a single point of analysis but real-time monitoring of newly appearing executable pages. Whenever a process is accessing file system, processes, registry or network we extract the DNA from new memory and check it. This happens synchronously, before the CPU executes this new code. It's greatly helping with packers/protectors or non-deterministic code like downloaders or condition-triggered malware.
Really appreciate your response. I remembered ESET has introduced rule-based HIPS since V4, but till now, the HIPS's auto mode still does little in malware's post-execution scenarios (although there is a smart mode and a ransomware protection). Is it due to the concern of FPs so that ESET only leave this function to advanced users?
I agree that it is a paradox to claim a product can know the threat before it appears. But some statements you gave seems to be based on the fact that malware makers can always fool the AVs. Will it be the case that a product is so hard to be fooled so that malware creators can hardly/are discouraged to bypass a certain product? For example, in the old days when AVs use traditional signatures (strings, API sequences) to detect threats, it might be intuitive to hide these signatures. But if the signature is less intuitive (some inherent file properties like entropy or something else), it is less intuitive for malware makers to realize what is triggering the detection. Will this ever be the case?
A question about possibility to bypass AMS: from the description, it seems to me that AMS statically scans the new executable page. So how about self-modifying code? How about writing an emulator-like execution engine to execute the encrypted code with-in a small memory window so that AMS cannot gather enough features to do scoring? (I am not pro so please bear with me if these questions are dumb)
-
Seems to be so.
I have set a local folder to be visible in the LAN (like "\\server\Runtime"), and added a rule to protect the local path of the folder (like "C:\Users\Username\Runtime"). And apply on all applications.
When explorer.exe tries to create a new folder through the local path, the HIPS will prompt the window; but accessing from Network using explorer.exe doesn't prompt any window. Adding the network path to the protection doesn't help
-
Another question related to the product: when a malware bypasses the scan and detected by AMS, it is already at the execution stage. The executed malware will sometimes have some side-effect on the machine (registry, files, etc.) I have seen some vendors employ rollback mechanism, and some use standard repair procedures. In some cases, wild ransomware might successfully encrypt some files and then be detected through behavior detection, the rollback mechanism of those products will recover encrypted file (currently ESET is not). Is there a reason why ESET doesn't introduce such roll-back mechanism?
-
7 hours ago, J.D. said:
Hi,
It is a pleasure to get questions from someone with understanding of computer security and related problems :-)
Machine Learning is used in ESET and we were using it for years. For this reason, we have opinion on the topic less biased by Deep Learning hype. ESET is a privately held company and we know that the truth is very far from marketing claims of security startups trying to attract investors. Machine Learning is a strong tool but not a perfect solution nor silver bullet.
If you are wondering when ESET started to use e.g. neural networks look at this article.
There are multiple problems related to machine learning for security. It is for a long discussion but I’ll try to gather the main points in one post.
1. Supervised vs unsupervised machine learning
There are two types of machine learning – supervised and unsupervised. Unsupervised is great for finding anomalies but it won’t tell you if the sample is malicious or not. With the number of constantly updating “clean” applications in the world, you cannot make a product that base on anomaly detection only. Well, you can do “application whitelisting” but maintenance is so problematic for admins that relatively small number of companies may use it. Such companies also get problems with being exploited by not deploying software updates fast enough. In addition, you can perform attacks using proper executables – interpreters for scripted languages even embedded in OS (e.g. Powershell).
When labels are assigned, you get supervised machine learning which has a basic limitation: it cannot detect things that are new, that do not have properties seen in other malware. Therefore, targeted attacks like Stuxnet (too dissimilar) cannot be detected using supervised machine learning.
The labelling of new samples, not similar to anything seen in the past or too similar to clean files is the biggest challenge. That’s why startup companies care that much to have access to labelled samples e.g. by VirusTotal – from point of view of vendors that have human experts in Malware Lab it’s like parasitizing on the hard work of the others.
2. False positives vs generalization
Generalization in machine learning classifier means false positives. To avoid FPs you need to operate with high-dimensional spaces where generalization is limited by curse of dimensionality.
It is a purely business decision to have product with low number of false positives. Our detection using multiple layers of protection (basing on different principles) is so good that e.g. number of successful ransomware attacks on our customers is very small. Having more FPs would cause more issues for the customers than detection misses. FPs are extremely important because they guarantee disruption (even global) of business continuity while chance of infection e.g. by ransomware is still just a chance.
The other problem with machine learning is that M.L. does not guarantee to cover in 100% even the training set (known samples). Outliers (too dissimilar samples) are being treated as a noise and ignored by machine learning, then must be covered by “signature-like” methods.
3. Deep Learning hype
Deep Learning is great for tasks that have hierarchical structure (e.g. in classification of images single pixel means nothing but when combined into edges, parts, objects, scenes it gives great results). In structured problems, where each extracted feature has meaning (like mentioned entropy, features from file header, use of specific APIs, opcodes, description of flow, strings) there are just better algorithms than Deep Learning that we use in ESET like Gradient Boosting, SVM or Random Forest.
Deep Learning has some terrible properties related to modification of samples – it is very vulnerable to it and can be easily fooled. We use therefore Deep Learning only for very specific tasks at the end of the automated sample-processing pipeline.
4. Bypassing of machine learning
Modification of samples is of course the first way to bypass machine learning. Malware authors modify the samples until they bypass detection and for them it does not matter if the modification bypasses heuristics, human-made descriptions or machine learning model.
Modification of samples can be done in many ways but the easiest one is to just “hide features” from extraction. It can be done by obfuscation, compression, encryption, embedding or separation (like downloading of external code for execution). Machine learning is blind when it has no features to process. If a product has no base technologies for unpacking/deobfuscation then machine learning cannot decide if e.g. compressed file is clean or not. The strengths of ESET products lays in ability to extract features in form of DNA vector which is simply great for machine learning. And yes, we use in machine learning classification. In fact, ESET products never based on binary patterns as self-called “next-gen” security vendors present “traditional vendors”.
Why not to block all obfuscation, compression or encryption? We do it when they are clearly malicious but such methods are standardly used for good purposes e.g. compression of executables, prevention of .NET code reversing, minification of JavaScript…
Malware authors are creative and know that if file has not enough features then it trigger anomaly detection. They modify then clean applications or open source software and add there malicious components. For machine learning, such files look generally fine, like a new variant of clean application.
5. Need of updates
The next problem with machine learning is need of updates. In case of security, you have to do it very quickly. When you have a miss in detection, you need to update fast to cover the miss, when you have an FP you have to remove it instantly. Claims of some startups that they do not need updates are pure marketing that will sustain until product get popular enough to be directly targeted by malware authors. To react fast updates must be incremental that’s why even companies that claim to be “machine learning based” provide regular updates.
6. WannaCry and multiple layers of protection
ESET was one of just a few products that proactively protected from WannaCry. It happened due to multiple layers of protection that our products have implemented (based on files, network, behavior, anomalies, memory, reputation) – in this case network level detection of exploit. We believe that having more layers of protection is like having multiple products. One technology can be easily bypassed but adjusting attack against multiple technologies is getting expensive and complex for the attacker.
Really glad to see such detailed response from ESET. I am with ESET's view that static ML detection alone, which treat executables as data, is not that reliable against malware because it doesn't really look into the things happening under the hood. These methods are somewhat similar to anomaly detection and should not have been deployed to ordinary clients from my view, due to many potential FPs (ESET's low FP is one of the primary reason for me to stick to this product indeed).
But does it mean that in order to control FPs, products should be mostly relying on the response speed of the vendor (in that sense there will always be some unfortunate first-time victims). One claim those startups made is their products are capable of detecting unknown threat even with very infrequent update. Of course these statements are hyped, but still makes me wondering if a reliable AV product can somewhat stay ahead of the newly born threats. I knew some vendors have provided sandbox as a mitigation measure for this scenario, has ESET ever considered this issue?
-
30 minutes ago, Marcos said:
I have a different experience. AMS and anti-ransomware protection seem to be very effective and detect malware in memory even if authors re-pack it to evade detection. While it works to evade detection by most of other AVs, ESET would still detect it by HIPS (AMS). As far as I know, only Microsoft uses a similar technology.
Yes, I mean they are generally good at detecting known threats and their variations. For most Cerber or Spora families, my experiences is that AMS will first kick in if it detects de-cloaked code in memory, and if not, rule-based HIPS will kick in, but at the cost of sacrificing some files.
But I never see these two detect new family of ransomware (like if the author of the malware rewrite the core code or change its behavior dramatically, a typical example is the Jaff ransomware recently, AMS and HIPS generally kept silence until more signatures are added some days later). I don't expect ESET or any other security product to detect these new threats at high rate at the initial stage, but it would be good to have some better rule-based HIPS blocking mechanism for post-execution protection when a new threat bypasses AMS or the very conservative HIPS-based ransom protection. I know it is hard to do this well with very few FPs though... but I've seen other vendors use process API call monitoring and auto scoring system to monitor and detect these unknown threats
-
42 minutes ago, Marcos said:
Again, ESET is a pioneer in using advanced detection and protection methods and we indeed employ machine learning as well.
One should understand that no matter what methods are used, it's not possible to prevent attackers from targeting specific vendors and modifying malware until it becomes undetected, especially if a user relies only on the AV and doesn't practice safe computing.
The special thing about WannaCry was the method it utilized for spreading. Since ESET protected unpatched computers from the exploit, we were able to protect not only from WannaCry but also from other malware that exploited it. Again, it's normal that not 100% malware is detected and especially detected proactively. A detection for WannaCry was added immediately as we got the necessary data from LiveGrid. There are myriads of examples where ESET detects malware, especially Filecoders that are not detected by any other famous vendor.
In a nutshell - there's nothing like 100% malware protection. If there was a security product that would detect 100% malware without FPs and the need to update, there would be no other AV vendors as everybody would go for that product. The point is to detect as much as possible proactively without FPs and to react very quickly if a new threat emerges. In my opinion, ESET does very well and the very low number of malware incidents reported by users of new product versions compared to the number of reports from older versions supports my opinion.
Well, it is hard to find a vendor which does not use machine learning techniques these days. I am asking for deep learning, but it is fine if ESET does not want to disclose more details about it.
Modifying malware to avoid the detection of security products is common, but this cannot explain why those threats are not also tailored for products with similar or larger market share. The cost for these customizations will for sure rise if the protection layers are harder to bypass
I saw many improvements in ESET products generation by generation, like the introduction of HIPS, AMS, and exploit blocker. But I feel that the behavior blocking of HIPS is still crude with respect to its rules after many generations. By default, the automatic mode barely does anything unless for modification on key areas. This is not very helpful for many malwares that do not touch these areas. The HIPS-based ransomware protection seems to be very conservative and blocks the threat at the cost of partial encryption of files. AMS is very effective but is restricted to known signatures. BTW, the HIPS rules for Windows Linux Subsystem is still not functioning correctly.
Of course cybersecurity protection is a probability game. From the results from those AMTSO organizations with large sample set, ESET does exceptionally well in FPs and performance impact, but still has room for improvement in detection rate.
-
13 minutes ago, Marcos said:
If all technologies employed by ESET are traditional for you, including anti-ransomware that monitors the behavior of running processes for ransomware behavior, then I don't know what you would expect.
Please provide some examples where ESET failed to protect a system while other AV prevented the infection. There's nothing like 100% malware detection but ESET with all the different protection layers and technologies comes very close to it from my observation. Also the fact that users of new versions report ransomware incidents extremely rarely compared to users with older versions is an important indicator that advanced technologies employed by recent versions of ESET products are very effective.
It is the description ESET made in whitepapers or other public materials make me think in this way. The blog in welivesecurity further implies that ESET is not interested in those deep learning techniques, which only began to be widely adopted in cybersecurity in recent 3 years or so. These are relatively "non-traditional" compared to those well developed ones. I didn't mean these techniques are superior, but am just wondering if ESET has ever adopted these in the detection process.
One example is Wannacry. Although during the time it initially outbroke the exploit blocker can already block the SMB exploit and stop the propagation, the malware itself is not detected before the new virus db release (I tested the ESET snapshot right before the Wannacry.D virus db release, none of the protection layer from ESET detected the threat). This implies 1) if the author uses some non-public/zero-day exploit in Wannacry, then ESET can hardly detect this threat in a timely manner. Especially because this ransomware quickly infect LAN computers, the cloud blacklisting (like the ESET "suspicious object" detection) also can't help much 2) the entry point is not protected. That is, if a user initially download the wannacry payload to the computer and execute it instead of being infected through SMB exploit, ESET cannot detect it in a timely manner.
As a comparison, some AV vendors can effectively detect and block the threat either at the heuristic stage, or at the behavior block stage (some people tested and verified that some product can even effectively detect and block Wannacry using the virus definition from last December). I am not sure if it is appropriate to mention their names here, but I believe you guys have some idea.
I don't mean to criticize anything, but as a ESET user for over 10 years, I start to worry about what if this kind of outbreak happen again.
-
18 minutes ago, Marcos said:
ESET is actually a pioneer in utilizing new techniques
For example, we developed ThreatSense.Net system before the term "cloud" was introduced by Google CEO in 2006. At https://www.eset.com/int/about/technology/
you can read more about advanced protection modules developed and utilized by ESET. Machine learning is used in the process of analyzing malware by Cloud malware protection system. The samples collected are subjected to automatic sandboxing and behavioral analysis, which results in the creation of automated detections if malicious characteristics are confirmed. ESET clients learn about these automated detections via the ESET LiveGrid® Reputation System within minutes without the need to wait for the next detection engine update.
I've read the tech white paper, but it seems to me what ESET discloses is still close to traditional approaches. The heuristic that pre-execute the malware and do scoring based on the collected behavior has been used by traditional vendors for decades (can't deny that ESET is one of the best). Though I am not sure about adv mem scanner and other techniques, I feel that they are still based on same/similar techniques except for being applied at different stages. On the other hand, some vendors uses static engines to detect malware through their statistics features (like avg entropy or more complex ones), but I've never seen ESET mention these techniques. Although most of these static engines raises many more FPs, but I think it might enhance detection if used in collaboration with traditional approaches. That's why I am wondering if ESET has ever adopted these approaches in the current product.
From what I've tested, although heuristic or adv mem scanner can deal with most threats, they are less effective with new families (especially those new ransomware families). HIPS-based anti-ransomware helps very little also, making me worrying about the protection against the explosion of new malware families, like Wannacry
-
Recent years I've seen many vendors started using new machine learning techniques to enhance their detection rate. e.g. RNN or other neural network variations, as can be seen from the patents they filed. I am wondering if ESET is keeping up with these techniques. From what I've seen in the articles posted in Welivesecurity about ESET's attitude to the machine learning, it seems to me that ESET is rather conservative in adopting these new techniques and a large portion is due to the concern about FPs. I know ESET is one of the vendors that has lowest FP rate (while those aggressive/paranoid designs often suffer from more FPs), but I am also curious if ESET is ever considering or even already has adopted these new techniques to overcome its own limitation currently. Any plans to add protection layers to deal with threats like wannacry that outbreaks so quickly and cannot be easily rescued by cloud blacklisting?
Question about AVC real-world test
in General Discussion
Posted · Edited by 0xDEADBEEF
It is hard for testers to correlate the testing case with each individual user's pattern. They have to assume a virtual user who faces all possible threats equally (and based of the prevalence of the threat). I see no problem doing this simplification in reality.
An antivirus that needs users' frequent intervention is not antivirus, but more of a system control tool. Since detecting malware itself is an undecidable problem, it will be ironic to let this responsibility fall back again to users, who already paid some money for letting experts do the job through their product. A good HIPS should not be per-step popups, and there are plenty of vendors that have implemented more intelligent ones and achieved good results.
All I can say is that ESET could have done better
Finally, I feel that the statement "the user should blame themselves if their computer got infected" is really weird. Ideally it is antivirus's job to help users distinguish good from bad. If users have to force themselves to behave like an "ordinary" user who never visit suspicious website, I don't think they would bother to pay for the protection. Antivirus gives users more freedom, not shackles. If users got infected, it is their right to question the service they have paid for.