An Introduction to Deep File Inspection®
What is Deep File Inspection®?
Deep File Inspection, or DFI, is the reassembly of packets captured off of the wire into application level content that is then reconstructed, unraveled, and dissected (decompressed, decoded, decrypted, deobfuscated) in an automated fashion. This allows heuristic analysis to better determine the intent by analysis of the file contents (containers, objects, etc.) as an artifact.
Why is Deep File Inspection® Necessary?
Given a document, executable or otherwise, there are a variety of approaches an analyst can take to reverse engineer it. On a real-world network, the volume of traffic and the sheer quantity and complexity of malicious content requires a solution that is both robust and scalable. Deep Packet Inspection (DPI), where individual packets or connections are judged to be benign or malicious, is fast but low-level. This means that packet boundaries and lack of context can mean missing the forest for the trees. Sophisticated threat actors frequently disguise the originator of malicious content, pack binaries, or embed payloads inside of documents.
Sandbox analysis or emulation can provide a behavioral picture of a sample’s effect on a system, and attempt to identify and classify malware this way. The disadvantage in this case is that it works slowly, and relies on its implementation to be susceptible to the attempted attack.
Deep File Inspection as a technique is higher level than Deep Packet Inspection, where individual packets or connections are judged to be benign or malicious, but faster than sandbox approaches that attempt to classify a sample by its effect on a system. This speed advantage allows DFI to be deployed in scenarios where network volume demands quick triage of traffic. A file can be evaluated as benign, suspicious, or malicious in a matter of seconds rather than minutes. Additionally, file evaluation by way of DFI can be done with a high degree of parallelism. Sparing cycles of expensive integrations through the application of a waterfall method ordered from most to least expedient analysis technique. By characterizing the files themselves, we can index which features of the specification and thus the client are going to be used. This can help isolate unusual functionality that may be suspicious, or attempts to activate vulnerable sections of a program’s code in the case of CVEs and 0-day vulnerabilities.
Example: DFI® Unravel
To illustrate this, we’ll examine a piece of malware seen in the wild relating to a vulnerability in Microsoft Office’s equation editor. Further technical writeups about samples from this campaign will be linked at the bottom of this page. First, we use rtfdump to get the list of OLE objects within the file.
rtfdump -d cb3429e608144909ef25df2605c24ec253b10b6e99cbb6657afa6b92e9f32fb5 | grep -i "object"
Next, we can use rtfobj to dump them all for closer inspection. The first OLE object contains a certain OLE CLSID:
\objemb{\*\oleclsid \'7bD5DE8D20-5BB8-11D1-A1E3-00A0C90F2731\'7d}
Looking this up via the Windows registry shows msvbvm60.dll. This DLL, among others, is notable in that many instances it will be loaded at a fixed address. This is desirable to an attacker writing an exploit wishing to bypass ASLR, as it provides reliable addresses on which to base a ROP chain.
Moving on to dump the other two OLE objects, we find compressed Word documents. Once we extract these, we find the heart of the malicious document in the document.xml: it attempts to exploit CVE-2017-11826, a vulnerability in the OOXML parser. The malformed tags and font name are designed to return to a known address in the above DLL, and pivot to the attacker’s stage 2.
<w:body >
<w:shapeDefaults >
<o:OLEObject >
<w:font w:name="LincerCharChar裬࢈font：batang"><o:idmap/>
</o:OLEObject>
</w:shapeDefaults>
</w:body>
What can we discern from these documents in order to detect and prevent them? First, the documents all contain several layers, as is increasingly common in malware campaigns. In an attempt to avoid AV detection or sandbox analysis, attackers will embed exploits within archives, documents, OLE objects, or combinations of each. The key points here are that the outer layers of container file formats need to be recursively peeled away, and the constructs that comprise the exploit itself exposed: the DLL that indicates an attempt at ASLR bypass, and the malformed XML tags that present a telltale indicator for CVE-2017-11826. Linked below are public YARA signatures that run on the output of our proprietary post-processing stack (or on the manual efforts of an analyst) to detect documents containing this exploit.
Example: DFI® De-obfuscate
Another recent example of attempted exploitation leveraged a vulnerability in Microsoft’s HTA handler for RTF files, CVE-2017-0199. In this scenario, an attacker would send a document with an embedded OLE2 link that then fetches a second stage HTA file that serves as a secondary payload. Mshta.exe then executes this payload on the victim computer, giving the attacker control of the target system. Consider the following basic YARA rule for detecting this specific threat within an RTF document:
rule CVE_2017_0199_basic
{
strings:
$rtf_header = "{\\rt"
$objdata = "objdata 0105000002000000" nocase
$urlmoniker = "E0C9EA79F9BACE118C8200AA004BA90B" nocase
$http = "68007400740070003a002f002f00" nocase
condition:
$rtf_header at 0 and $objdata and $urlmoniker and $http
}
Here, we we are looking for several characteristics that will identify attempts to exploit this vulnerability. The $rtf_header will be present in all RTF files, and the combination of $objdata, and the specific $urlmoniker and $http in this case trigger the section of vulnerable code, and all exploitation attempts will need to fundamentally do this.
These strings this example YARA Rule depend on however are easily obfuscated through standard primitives available in the RTF specification. Consider however the following exploit generator https://github.com/tfairane/CVE-2017-0199 (forked from https://github.com/bhdresh/CVE-2017-0199), specifically the following sections:
- https://github.com/tfairane/CVE-2017-0199/blob/master/cve-2017-0199_toolkit.py#L164-L173
- https://github.com/tfairane/CVE-2017-0199/blob/master/cve-2017-0199_toolkit.py#L184-L191
At 1. above, the $urlmoniker string of “E0C9EA79F9BACE118C8200AA004BA90B” is obfuscated with “chaff” to produce the following example output:
...e{\\*\\ZVK}0{\\*\\ZVK}{\\*\\ZVK}c{\\*\\ZVK}{\\*\\ZVK}{\\*\\ZVK}{\\*\\ZVK}{\\*\\ZVK}{\\*\\ZVK}{\\*\\ZVK}{\\*\\ZVK}{\\*\\ZVK}{\\*\\ZVK}9...
These junk directives are ignored by the RTF parser when the document is open and are present solely to evade detection. This form of obfuscation, among many others, is automatically stripped during Deep File Inspection. A myriad of improvements can be made on the above example YARA rule, but the basic principle remains the same: atop our DFI stack, analysts can write signatures based on decompressed, unraveled, deobfuscated, file contents with ease.
Further Examples
There’s many examples we can provide that illustrate the benefits of Deep File Inspection from a variety of angles. We’ll continue exploring some in future blog posts. An excellent example from recent history can be found in our post “Adobe Flash MediaPlayer DRM Use-After-Free Vulnerability” which details the background, dissection, and detection of a 0day Adobe Flash exploit caught in the wild and later assigned CVE-2018-4878. In this specific case DFI carves a SWF file out of a document carrier then extracts and decompiles the embedded ActionScript content. Our signatures run on the original file, extracted SWF file, and the output of the decompiler. In cases such as Flash, we’re able to generically detect exploitation techniques at the ActionScript layer. Anchoring on TTPs allow us to catch 0day exploits that despite leveraging a capability unknown to the community, still rely on known techniques for memory manipulation and eventual code execution.
Looking further back, we invite you to additionally read our series on Microsoft DDE, starting with “DDE, Macro-less Command Execution Vulnerability”.
Summary
In real-world scenarios, identifying malicious content from a massive volume of traffic at gigabit speeds requires an approach that can scale, but still discern the intent of a file based on what it attempts to do. Deep file inspection is a technique that gives analysts a quick way to filter malicious content out and alert on it, or perform threat hunting to triage suspicious content for more detailed analysis. This can cover everything from the presence of LNK objects in a document, to 0-day exploits, or any combination of similar attributes. Multiple modern APT campaigns have nested file types such that it is necessary to recursively apply DFI techniques, and to evade static signatures and AV, this trend is likely set to increase.