Applying Intelligence to Exploit Detection

Today’s exploits have much more thought and sophistication put into the methodologies they use, primarily so they can get past traditional types of defenses exploit detection capabilities. The problem with most defensive techniques used against exploits is that they attempt to determine an exploit is taking place, or has happened, by looking for a single specific activity as a determinant.

Hackers know this and will conduct their exploit as a set of smaller and discreet individual actions that, taken alone, leave little indication an exploit has taken place. If a solution does attempt to alert on these individual actions, it will tend to create a great deal of false positives, thus reducing its credibility for detecting exploits.

On top of breaking down an exploit into smaller and less discernable steps, hackers also attempt to obfuscate their activity. One way they can do this is by erasing any traces of their presence. Additionally, they can apply programming techniques to evade detection, which can be particularly effective if they have knowledge about the solutions being used to detect attacks.

Think of the deployment of a more robust exploit defense as setting up a series of security barriers that each check for a unique set of characteristics before allowing traffic to go to the next investigation point – similar to checkpoints used at airports. Each action taken at a barrier examines activities based on different criteria than a previous or following barrier. For instance, one barrier may look at identity to verify the authenticity of the event, and the next barrier could check for particular characteristics of a process or executable.

The barrier is a digital process designed to detect a step in a computing process that could indicate exploit activity. It observes ongoing processes or related steps an exploit might take and correlates them to ascertain that something suspicious is taking place. As soon as a combination of various exploit steps arrive at a threshold together, the exploit detection system confidently determines an exploit has happened and provides an alert.

This is how FireEye exploit detection works – by continually checking and evaluating specific processes and connecting and correlating them to normal operational aspects. As processes execute, HX reviews both the individual and their combined operations to determine whether there is enough evidence to indicate an exploit.

The following are some examples of evasion techniques and tactics that hackers may use in order to avoid detection:

• In an attack process, attackers can attempt to skip, evade or go around a barrier. This means the attacker may have knowledge of a defensive technique, or can assume a defense exists based on reconnoitering a target, and consequently programs their exploit code to evade a particular barrier. In this case their evasion could use an API that is not hooked or jumping over the existing API hooks.
• If attackers know the detection techniques the barrier is looking for, they may substitute a different technique or use a characteristic a barrier can’t detect. This technique attempts to take advantage of any potential gap in an exploit detection system by using an exploit technique, such as a specially crafted heap spray, that may not be identifiable by the system.

To address these types of evasion techniques, HX reviews individual processes for specific types of actions and essentially assigns a risk score. These scores are based on how likely the individual process can be part of an attempted exploit. HX will review each process as a part of a sequence and link them together to identify what they are attempting to achieve. Only when the combined cumulative score passes a threshold score will it determine that an exploit has taken place.

The cumulative scoring process provides a high level of accuracy for detecting an exploit, significantly reducing the chances of producing false positives. Detecting an exploit not only help stops an incident, but it can also provide the information necessary to address an underlying vulnerability and thus prevent future exploitation. This allows HX exploit detection to help close gaps that traditional endpoint solutions struggle to detect.

A full exploit – from a user opening a compromised document or web page on through execution of the payload – can occur in less than a second. The rapid nature of the action and exposure means that an alert will likely only come after the exploit’s execution. However, using HX to get any alert within a few minutes is far better than not finding out about a breach for weeks or months, particularly because an attacker can do more and more damage the longer they are in a system. Then after getting the alert, analysts can use HX’s other capabilities to conduct quick and effective inspections into where the exploit took place and where the threat may have gone. Quicker identification of an exploit, and the ability to stop it and patch a system, will reduce exposure time to a hacker and minimize damage.

FireEye HX exploit detection (ExD) can monitor the behavior of applications and use those behaviors to match against exploit detection rules, similar to how IOCs are matched. The exploit detection engine is completely data driven, using a set of rules that are kept up to date through DTI. HX exploit detection uses rules because they can be continually adjusted to deal with the nuances of exploit activities. This is different from traditional systems that use fixed files, as they can only compare a threat to their local files, which are always out of date. HX flexibility means it can analyze a process (not just compare) for malicious behavior such as heap sprays or shellcode execution, rating each process individually and as a whole to determine if they signify exploit activity. Additionally, these rules define non-traditional behaviors such as Microsoft Office macros or Java sandbox bypasses.

HX currently monitors the most popular applications, including Adobe Flash and Reader, Java, and Microsoft Word, Excel and PowerPoint, as well as popular web browsers such as Chrome, Firefox and Internet Explorer. Earlier this year, HX assisted in the detection of CVE-2016-1019, a previously unknown vulnerability in Adobe Flash Player that was incorporated into the Magnitude Exploit Kit.

Click here for more information on FireEye’s HX Series.