Threat Intelligence

    The Return of the Equation Editor Exploit – DIFAT Overflow

    The latest from Mimecast Research Labs.

    by Meni Farjon


    In the last few months, the Mimecast Research Labs team has seen several unique variants of Microsoft Office Word exploits, more specifically combining the previously-patched memory corruption issue CVE-2017-11882 (AKA the Equation Editor Exploit), with another issue to amplify the attack and make it go undetected. These exploits were chaining what we believed to be an unfixed vulnerability in the Object Linking and Embedding (OLE) file format and the way it’s handled in Microsoft Office Word.

    Our detection engines spotted an attacker group, which seems to originate from Serbia, using specially-crafted Microsoft Word documents to take advantage of how Microsoft Word handles Integer Overflow errors in the OLE file format. The group was able to exploit this bug to circumvent many security solutions designed to protect data from infestation, including leading sandbox and anti-malware technologies.

    We reached out to Microsoft when we discovered this issue, following Coordinated Vulnerability Disclosure (CVD) and with a working proof-of-concept (POC). Microsoft acknowledged it was unintended behavior, but declined to release a security patch at this time, as the issue on its own does not result in memory corruption or code execution. The issue may be fixed at a later date. You can find the timeline of our correspondence below.

    Get articles like this delivered to your inbox every week. Subscribe to Cyber Resilience Insights today.

    In this article, we would like to share how we found a bug in OLE32.dll incorrectly handles Integer Overflow and is used to bypass security solutions and fool parsers.

    Technical Analysis

    According to the format specifications for the Compound File Binary File Format, the OLE stream header contains a table called DIFAT (double-indirect file allocation table) that is an array of numbers. Each sector has an ID, which can be any 32-bit, unsigned number under 0xFFFFFFA. The DIFAT table contains all the section IDs and some special numbers. To access the sector N in the table, it’s offset computed using the following formula: sector size * (sector ID + 1), when sector ID is DIFAT[N].

    The relevant parts [Pages 15-20] from the official spec are presented below:



    It seems that when a big sector ID exists, the formula mentioned above leads to an integer-overflow that results in a relatively small offset. The following screenshots show the code snippets that cause the overflow.


    Section size is 512, and the first sector ID is 0xFF000000. Let’s apply the above formula (as in the official specification): (0xFF000000+1) * 512 = 2190433321472, or 0x1fe00000200 in hex. 

    Because the result is more than 32 bits (integer overflow), only the lowest 32 bits will be the product when the code above performs the calculation. In other words, the calculated offset will be 0x200 = 512, as can be seen in the following debug screenshot.


    This result makes sense because it points just after the header, which is the natural place for the first section.

    This behavior is not documented by Microsoft in the format specifications, but it can confuse high-level parsers, which will not notice the overflow. The calculation results will also point to an impossible offset, which will lead to, in the best-case scenario, ignoring the section containing the exploit, or in the worst-case scenario result in a crash.

    In one case we examined using this vulnerability in OLE, the attacks consisted of exploiting CVE-2017-11882 with an Equation stream defined inside an OLE object with an overflowed sector ID, as described above, causing the object containing the exploit and shellcode to go unextracted and therefore undetected by security solutions. When the Equation Editor Exploit is chained with this integer overflow, Microsoft Office Word mishandles the error as it ignores the higher bytes of the OLE sector ID and loads the malicious object (CVE-2017-11882) into memory while not following the correct guidelines.

    In the case we examined, the attack dropped a new variant of Java JACKSBOT, a remote access backdoor that could only be active or infect its target if Java was installed. JACKSBOT is capable of taking complete control of the compromised system. Malware code reveals that it is capable of visiting URLs, creating files and/or folders, running shell commands, and executing and ending programs. It can also steal information by logging keystrokes and mouse events.

    JACKSBOT’s General Capabilities:

    • Collect keystrokes
    • Steal cached passwords and grab data from web forms
    • Take screenshots
    • Take pictures and record video from a webcam
    • Record sound from the microphone
    • Transfer files
    • Collect general system and user information
    • Steal keys for cryptocurrency wallets
    • Manage SMS (for Android)
    • Steals VPN certificates

    The following table lists indicators of compromise (IoC) such as hashes of files and command-and-control servers used by JACKSBOT.

    DescriptionIOC TypeIOC



    Dropped htaSha256



    Dropped jar (1)




    Dropped jar (2)




    Dropped vbs




    Malware Names

    File Name











    Malware installation path




    C&C Dropper


    AutoStart Path

    Registry Key



    Value: ntfsmgr

    Data: "C:\Program Files\Java\jre1.8.0_144

    \bin\javaw.exe" -jar "C:\Users\user\AppData\Roaming\ntfsmgr.jar"



    Mimecast Targeted Threat Protection was able to detect the samples described in this report as it does not rely on structured format specifications to determine malfeasance. The code detection engine can easily read through unstructured or even entirely “broken” files to detect malicious code no matter how deeply buried or obfuscated in any given file format. The engine was designed with an “attack focused” methodology, where the engine does not “trust” any given file format and does not “follow” RFC or Format Guidelines. Instead, the engine goes byte-by-byte, trying every possible technique to decode, decrypt and de-obfuscate attack code.


    Mimecast detects machine code (x86) in the file


    Disclosure Timeline

    • May 15, 2018 – Reached out to Microsoft Security Response Center (MSRC) with information + working POC.
    • May 16, 2018 – Case opened MSRC Case 45367.
    • May 17, 2018 – MSRC responds that Microsoft will not be fixing this behavior with a security patch, as the issue by itself does not result in memory corruption and doesn't meet the security bar.
    • May 18, 2018 – As per CVD, Microsoft allows the publishing of this article.

    Subscribe to Cyber Resilience Insights for more articles like these

    Get all the latest news and cybersecurity industry analysis delivered right to your inbox

    Sign up successful

    Thank you for signing up to receive updates from our blog

    We will be in touch!

    Back to Top