Last we checked, cybercriminals make their living by breaking rules. Exploits and malware often leverage system misconfiguration, application and operating system vulnerabilities, non-standard ports and protocols, and even misdirection (sleight of hand) in order to communicate with C&C servers, download malicious binaries and scripts, and deploy payloads. All is fair in love and war.

NSS Labs is well-known for measuring security product capabilities to detect and block malware and exploits. However, evasion handling, or a security product’s ability to recognize an obfuscated threat, is equally important. This is because of how frequently evasions successfully bypass controls and the consequences of results (NSS Labs testing has shown that many evasions permit malware to bypass security controls, even products from well-known vendors).

NSS stipulates that evasion handling must be part of a product’s default threat protection coverage. It is reasonable to believe that administrators enable threat protection on the security controls they manage and expect it to deliver on that protection without having to enable specific coverage to block evasions. An alert, by definition, is a passive signal, and would be disqualified from counting towards evasion handling during our tests as it would require administrators to change system configuration in order to achieve adequate protection. This doesn’t align with actual enterprise use.

Is evasion handling something your organization should be concerned about? Yes, absolutely. In fact, at NSS we consider evasion handling so important, we’ve written a test methodology on the subject. If an evasion technique is missed, any attack that can be implemented with that technique has the potential to succeed.

“When testing products for security effectiveness, providing results for protection against exploits without fully factoring in various evasion techniques can be misleading. Attackers use evasions to disguise attacks so they can avoid detection. This enables them to bypass security products and carry out their motives on the target. If a security product fails to identify and properly normalize a method of evasion, this could allow an attacker to utilize an entire class of exploits for which the product is assumed to have protection, rendering it ineffective. For this reason, NSS Labs verifies that tested products are capable not only of detecting and blocking exploits, but also of providing protection when exploits are delivered using a wide variety of evasion techniques.”

– NSS Labs Evasions Test Methodology v1.0

Security controls must be configured to handle evasions. They must be resistant to attacks that bend rules and ignore standards while at the same time minimizing impact to legitimate, non-malicious traffic.

Common Evasion Categories

Evasions take many forms and are found in all phases of digital communication. Here are some evasion categories with examples:

• IP packet fragmentation – Sending packets out of order, or reverse order fragments. Various size fragments, or adding random chaff
• HTML obfuscation – UTF-16 and UTF-32 character set encoding (big-endian), compression (deflate), chunked encoding
• Binary obfuscation – Packing/compression/crypters/encoding, polymorphism
• Virtual machine evasions – Hypervisor (VMware I/O port, backdoor instruction, CPU information) and Guest OS profile (number of processors, registry, named pipe)
• Sandbox evasions – Human interaction (cursor position, keyboard stroke, clipboard content), stalling code
• Layered evasions – Any combination of evasion techniques

More examples of evasions can be found in our evasions test methodology; however, it should be noted that the most effective type of evasion is the one that isn’t documented.

An Example of a Unicode Character Encoding Evasion

Unicode is the international standard for representing text used in modern writing systems. Multiple bytes are used to describe each character with the number of bytes depending on the chosen encoding. Unicode character encoding is a common practice and errors in the presentation of encoding are equally common.

Part of our evasions testing is to be deceptive about the Unicode character encoding actually used. For example, we may claim an encoding to be UTF-8 while actually presenting an encoding of UTF-16. Adding the Content-Type header is not an option because giving the defensive technology a hint isn’t something an attacker is likely to do. So long as the target can be successfully exploited, this is considered an appropriate test case (see “all is fair in love and war” above).

Let’s be more specific. The text “ABCD123” can be represented by several encodings (countless actually, but, some encodings are more common than others), e.g., ASCII, ANSI, ISO8859-1, UTF-8, UTF-16 (big- and little-endian), and UTF-32 (big- and little-endian). Take a look at some of the variations of “ABCD123” as HEX output by a common editor:

There are many ways to detect the various encodings of “ABCD123,” but properly implementing all of them would make it impossible to transmit the text “ABCD123” and have the receiver understand it as such. A common answer to this challenge is to first normalize each representation to a common encoding and then inspect against that new normalization. In this example, you would normalize the UTF-16LE encoded version of “ABCD123” back into UTF-8 encoding and then look for “ABCD123.” In this way, there is only one conversion and the process is much more scalable.

16-bit encoding is considered a high priority because it is supported and codified in modern standards. If a security control misses 16-bit encoding, this indicates that other encodings of text are not normalized to a baseline representation of that text before inspection is applied. And this means that the security control is susceptible to the HTML obfuscation evasion category.

Evasion Handling is as Important as Security Effectiveness

Our principles reflect those of the enterprise—zero tolerance for any path that bypasses security controls. Security control vendors have their work cut out for them. Not only must they detect threats, but they must also adhere to protocol standards and deliver protection in the face of ambiguity. Products must incorporate a workflow, which allows for the identification of traffic that moves outside these standards. Admittedly, this is not easy, but if we want to do what is best for the enterprise, it’s the only option.

Visit the NSS Labs Research Library to view and download group test reports, analyst briefs and other valuable resources that help enterprises to make informed cybersecurity purchasing decisions.