Any Deep Learning Techniques in ESET products?

[0xDEADBEEF 43]

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?

[Marcos 5,070]

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.

Speaking about WannaCry (WannaCryptor), ESET was one of 3 AV vendors to have proactively protected unpatched systems from EternalBlue exploit at the time of testing (https://www.mrg-effitas.com/eternalblue-vs-internet-security-suites-and-nextgen-protections/). In fact, ESET had already protected users for 2 weeks when the WannaCry outbreak occurred on May 12.

[0xDEADBEEF 43]

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

Edited June 15, 2017 by 0xDEADBEEF

[Marcos 5,070]

55 minutes ago, 0xDEADBEEF said:

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

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.

[0xDEADBEEF 43]

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.

[Marcos 5,070]

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.

[0xDEADBEEF 43]

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.

Edited June 15, 2017 by 0xDEADBEEF

[Marcos 5,070]

Quote

But I feel that the behavior blocking of HIPS is still crude with respect to its rules after many generations.

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.

[0xDEADBEEF 43]

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

Edited June 15, 2017 by 0xDEADBEEF

[Marcos 5,070]

We have a set of anti-ransowmare HIPS rules available for administrators that they may apply but only after testing them thoroughly in their environment as they may cause various issues.

Quote

a typical example is the Jaff ransomware recently, AMS and HIPS generally kept silence until more signatures are added some days later

Please provide a Filecoder.Jaff sample (or at least its SHA1) along with the date when you received it and the time when it began to be recognized by ESET. The detection of Filecoder.Jeffo was added on May 11, B variant on May 22 which was adjusted on June 2 to cover even more variants.

[peteyt 393]

Machine learning often seems to be just a word thrown around to make things sound more complex. Didn't @itman share something about this

[cyberhash 188]

Predicting code that has not even been written yet is a bit like visiting a fortune teller. They can make a guess, but is it ever right  

[J.D. 33]

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.

[0xDEADBEEF 43]

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?

Edited June 15, 2017 by 0xDEADBEEF

[0xDEADBEEF 43]

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? 

Edited June 16, 2017 by 0xDEADBEEF

[J.D. 33]

On 6/15/2017 at 11:24 PM, 0xDEADBEEF said:

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

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.

On 6/15/2017 at 11:24 PM, 0xDEADBEEF said:

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?

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.

On 6/16/2017 at 6:03 AM, 0xDEADBEEF said:

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? 

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.

[0xDEADBEEF 43]

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)

Edited June 20, 2017 by 0xDEADBEEF

[Marcos 5,070]

1 hour ago, 0xDEADBEEF said:

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?

HIPS was first introduced in v5. Since then it's improved a lot, especially its subfeatures like AMS, Exploit Blocker and the brand new anti-ransomware protection introduced in v10. All these including self-defense are virtually parts of HIPS.

For those who don't mind being asked about an action when a suspicious operation is attempted can switch HIPS to Smart mode which is more effective then automatic mode but some decisions must be made by the user.

Quote

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?

As already said above, AV programs use various protection layers to make it difficult for malware authors to bypass them all. Also J.D. mentioned that even if a particular malware is not visually recognized it doesn't mean we won't learn about it. Quite the contrary; such samples are automatically replicated and detection is added within minutes via LiveGrid.

[J.D. 33]

6 hours ago, 0xDEADBEEF said:

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?

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.

6 hours ago, 0xDEADBEEF said:

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)

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.

Edited June 20, 2017 by J.D.

[itman 1,659]

On ‎6‎/‎19‎/‎2017 at 5:30 AM, J.D. said:

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.

Would like to see this added to the home versions as a "sensitivity" setting option. Many of your home users are IT pros BTW. The current HIPS "Smart" mode is to "silent" for my liking. Also, the current reputation scanning is "too permissive" for my liking.

Also please add HIPS rule file wildcard support to the home versions. This feature request was made years ago.

Edited June 20, 2017 by itman

[0xDEADBEEF 43]

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  

[0xDEADBEEF 43]

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?

[itman 1,659]

On ‎6‎/‎24‎/‎2017 at 1:47 PM, 0xDEADBEEF said:

So Microsoft also has some in-memory detection mechanism? Is there a name for it?

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.

Ref.: https://blogs.technet.microsoft.com/mmpc/2017/06/16/analysis-of-the-shadow-brokers-release-and-mitigation-with-windows-10-virtualization-based-security/

 

[0xDEADBEEF 43]

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.

Ref.: https://blogs.technet.microsoft.com/mmpc/2017/06/16/analysis-of-the-shadow-brokers-release-and-mitigation-with-windows-10-virtualization-based-security/

 

Thanks!