J.D.

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/

Hi, We had multiple talks with Intel and evaluated this technology. It may be really interesting but for poorly written security software ;-) Our real-time memory scanner has negligible performance impact. Our HIPS is monitoring operations of the processes and only new or changed executables pages are needed to be scanned, which are not created from image on the disk (like exe or dll). In standard applications there are almost no pages that need to be checked (with exclusion of JIT, we have it handled). Additionally their scanner is just a pattern matching. We do much more - deep analysis of file to extract DNA features.

The change has been released to the all Windows products.

Maybe what I said sounded a bit pessimistic but working in the security business I learned to look at the worst possible scenario ;-) While attacker can spend time & resources to even reverse engineer feature extraction methods, having multiple layers of protection (that base on different principles) make it way harder and costly. In security it is always a balance between protection, FPs, performance impact and user-experience impact. Sure, you can create a very secure and restricted attack-resistant environment but would the user be happy? I do not hide in a bunker wearing a full plate armor even if it could greatly decrease chance of being killed by a hit-man targeted attack ;-) 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. Every security can be bypassed and we are improving our detection methods reacting to what malware authors do. If they modify the code too much, it won't look like generated by a compiler an would trigger an anomaly detection. That's a philosophical questions if security can be really preventive. If you implemented a proactive protection against specific method of attack then attacker would not use it anymore, he will focus on a different technique. Was the implementation not necessary then? :-) No security is perfect but all added layers of protection make attacks more costly to perform.

That is exactly our point of view. Such “aggressive detections” are good for limited set of users who can handle higher FP rate and we consider providing them to some business customers. We have such anomaly detection implemented for a few years as “silent detections” – they provide us interesting samples without triggering detections. It is a strategy, which allows us to react on the use of VirusTotal-like scanners by malware authors. We move the detection to other layers and malware authors when check only the file-based scanner (quick and cheap check) think see that they bypassed our detection. It is a “catch less to catch more” scenario, quite similar to what law enforcement do. Very infrequent updates work only if the security product is not popular. Many of the startup products are still not in the underground multi-scanners because malware authors do not care to bypass them – theirs user base is just too small to care. As soon as your product is directly targeted, you have to react quickly on the attacks to fix the miss. It is a kind of paradox of any proactive prevention – as soon as you block the attack method, the attacker will not use it anymore and will use the one that is not covered. We have tested the “next-gen” products and they are easier to bypass than “AV products” because of poor monitoring and feature extracting capabilities. Their only advantage (short term) is lack of popularity. Talking about sandbox it depends on what do you mean. We have a lightweight in-product sandbox using emulation/binary translation. It has two weaknesses: it’s a “one point of analysis” and it’s imperfect environment. The other option would be to implement virtualization of application for behavioral analysis using a copy of the file system and registry like one product does. It has some serious drawbacks because of performance, sharing violations, race conditions, potential escapes of the sandbox and still can be quite easily detected from inside of the sandbox. The other options are “per-process” or “per-domain” sandboxes (like Sandboxie, Bromium, Subgraph or QubesOS). While there are some serious limitations to implement such sandboxing on Windows using hypervisors the biggest problem is user experience. Usually it is changed that users are lost. Imagine virtualization of the browser. You got it exploited and the system is not compromised – from the security perspective well done. However you browse something and save a document on the desktop… and it is not seen, because the file-system is virtualized. Or you download some app and try to run it. Should it be allowed (installer of game) or disallowed (malware)? Sandboxes do not solve this problem and it’s up to somebody (security software vendor or the end-user) to decide. The biggest problem however is with data access model, which in Windows is “per user” – any applications running in the context of the user have access to read/create/modify/delete. As long as the data belong to the user, any app running in the context of this user can modify it. The only solution is non-user-friendly model of data belonging to apps (like in iOS). ESET implemented a few years ago a process-level sandboxing however after user experience testing we decided not to proceed with this feature. For great majority of the users it was too confusing to understand why some operations are non-persistent, which one are or how to make them. There are three types of rollback layers implemented in security software: 1. Using OS features e.g. Shadow Copy – most of ransomware just disable this or remove the copies. Very ineffective solution. 2. Lightweight rollback – only a few small files are copied, the big ones are skipped. 3. Heavy rollback - including a big ones like 16MB pictures, 100MB PowerPoint presentations etc. 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.

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.