“Now You See Me Now You Don’t”: Making Threat Detection Persistently Undetectable by Malware (part 2 of 3)

On July 28, 2014, Posted by , In Embedded Lynx Blog,

In our previous post we explained why evasion and persistence are the 2 main “malware virtues” challenging existing detection methods.

We assert that a twofold new approach must be introduced to augment existing solutions, in order to successfully thwart advanced malware:

  1. Separation of the detection layer from the attack surface (this blog)
  2. Placement of high-interaction honeypots closer to the attacked users (next blog)

First things first: Why is it so hard to detect advanced malware?

Well, the short answer is: Because malware has become so sophisticated and fast-changing, while operating systems have become unbearably large and complex. Malware detection is uncomfortably situated between the rock and the hard place: It needs to deal with both the vulnerabilities and complexity of the operating system and the malicious activity to the malware.

The attack surface: Size matters
Windows XP, Windows 7 and Windows 8 are in the vicinity of 40-50 million lines of code each. It is estimated that Windows 7 kernel alone measures more than 2 million lines of code. This is a huge attack surface, and it’s not likely to decrease in size. Large attack surface means a lot of hidden vulnerabilities waiting to be exploited by malware to infect its target, and just as much room for the malware to hide itself. Therefore, from a pure security perspective, there isn’t a way to seal nor secure this code-base — it’s simply too large to be secured.

Current malware detection methods: “As long as there are holes in the net, there will always be a way to go through it”
No detection technique is perfect, each has its shortcomings. Here’s a very high level view of the inherent weaknesses of existing malware detection techniques (note: as this is a VERY short description, it leans towards generalities. The pros and cons of malware detection methods duly deserve a separate deep-dive discussion):

  1. Reactive detection (aka “signature/pattern-based”):
    • Can detect only known, pre-identified and analyzed malware
  2. Proactive detection (aka “behavior-based” and “heuristics”):
    • Coverage of malware-types is too narrow; broadening and generalizing the scope lead to far too many false-positives
  3. Static analysis detection:
    • Cannot deal with behavioral and dynamic aspects of the malware (e.g. cannot detect multi-stage malware) nor malware with elaborate evasion/obfuscation mechanisms
  4. Dynamic analysis detection:
    • Cannot deal with sub-OS rootkits, multi-stage attacks and delayed/time-based attacks; easily detectable by malware

The “heavier-weight detection” (static analysis, but mainly dynamic analysis), which can only be performed on high-performance servers, was brought from the security research labs to IT networks due to the increased inability of endpoint and gateway security (reactive+proactive) to provide satisfactory level of detection. It became apparent that purposely executing the malware will allow better detection and analysis, because it’s based on actual data generated close to real-time.

There’s an acute need for a new method of detection which will be able to avoid the above weaknesses and augment the existing methods.

The undetectable detection

One of the main weaknesses of all existing detection methods is that they are easily detectable by sophisticated malware. None of the known detection methods were designed to be undetected by the malware it analyzes. However, without robust anti-evasion capabilities, threat detection — sophisticated as it may be — won’t work.

It’s nearly impossible to add anti-evasion measures to malware detection technology which was not designed to be undetected. As long as there’s a footprint of the detection on the attack surface, it’s detectable by malware.

The approach should be altogether different.

In order to prevent malware from detecting it’s being detected and analyzed, the entire detection must be delivered completely outside of the attack surface, and in a way that will be invisible to the prying eyes of the malware as well as beyond its reach (so it won’t be able to find a way to disable or deactivate it).

On the face of it, virtualization has what it takes to deliver threat detection in a superior manner to OS-resident detection. However, common COTS bare-metal hypervisors were not designed to do that. They are single-purpose operating systems designed to run other operating systems. As such they have a very large code-base, and are visible and recognizable as hypervisor (they were not designed to be stealthy). Their inherent security is as weak as the operating systems they run.

In order to to deliver undetectable detection, the hypervisor itself must be (1) undetectable and (2) equipped with inherent detection and monitoring capabilities. This can only be done with a novel and non-conventional use of custom-designed virtualization.

The undetectable hypervisor

To be undetectable, a hypervisor should present itself to anything running on top of it as physical hardware and nothing more. This requires the removal of all non-hardware properties from the hypervisor (e.g. file-system, device drivers), to the extent that the OS or malware running in the virtual machine won’t be able to recognize that the hard-disk, memory, CPU, BIOS and I/O are in effect virtual ones and not physical. Removal of these elements also results in significant reduction of the hypervisor’s size — its attack surface is barely visible. We call this approach “the virtual motherboard“. As a matter of fact, it can reduce the size of the hypervisor to a few hundreds kilobytes (!).

A critical part of this approach is to assure that this virtual hardware will be strictly isolated and secured in its own partition — same partition of the virtual machine — so to prevent the OS and/or malware to be aware they are virtualized and that there are other virtual entities running in parallel to them.

To round up the anti-evasion capabilities, the hypervisor should be equipped with its own cloaking and obfuscation means, in order to further enhance its stealthiness. Cloaking and obfuscation are achievable given the straightforward virtual hardware properties it has.

LynxSecure hypervisor was designed to achieve all that.

LynxSecureVirtualMotherboard

Virtual Heimdall: The self-aware and all-seeing hypervisor
To detect and monitor malicious activity and behavior, the hypervisor should be able to monitor and introspect, in real-time, all elements of the hardware. Since all of the hardware is virtualized and controlled by the hypervisor, this critical task is feasible (the virtual hardware is in effect part of the hypervisor). Furthermore — it can be done with zero footprint on the running virtual machine. This type of real-time monitoring and introspection allows for detection of byte-size changes to the hard-disk, memory and CPU.

The hypervisor enjoys a superior security privilege than the virtual machine (i.e., cannot be bypassed by the malware). Due to its location BELOW the virtual machine, it enjoys a superior vantage point: Nothing can escape its view.

LynxSecureHDDDetection

Examples:
Hard-disk and CPU data-structures infections:

  • Rootkits achieve their superior privileges by changing the boot sectors (bootkits)
  • Rootkits and advanced malware also hide their file-systems in hidden parts of the hard-disk (e.g. unpartitioned space).
  • Boot sectors and hidden disk sectors are for the most part out of reach of the operating system.
  • Not so for our hypervisor: It can detect these changes regardless of the malware’s evasive actions, as it’s looking at the changes that occur on the hardware, agnostic to the operating system, AS THEY OCCUR.

Memory infections:

  • All malware — persistent and volatile malware alike — use the memory. Being malicious, even the stealthiest and most evasive malware at some point in the process of infection performs an illegitimate or anomalous action — using an API or a collection of APIs in a way that’s malicious.
  • By monitoring the memory itself, and knowing the memory locations these APIs execute, the hypervisor can easily trap the malicious activity. It cannot be “fooled” or bypassed by the malware (i.e. spoofed/hacked APIs and the likes).

The deathblow:
Correlating both levels of detection — the memory execution introspection with the hard-disk detection — results in a very fine-grained detection, that captures the malicious and anomalous activity at its core.

Last: Live forensics
Since virtual environment includes a “golden image” of the virtualized operating system, this method also allows to provide what we call “live forensics” — a real-time comparison between the original “clean” state of the machine and the “infected” one. This mechanism, providing the security and incident professionals with the needle in the haystack, shorten the analysis and response time by orders of magnitude.

To sum up:

The above approach provides substantial benefits to detection of threats. In many ways, it pulls the rug from under the malware.

Our next post will deal with incorporating the undetectable detection in an advanced honeypot. We proclaim it’s not enough to provide superior detection technology. Given the nature and dynamics of malware, dynamic detection has to take a step further beyond the sandbox — The Coming of the Honeypot.