As a follow-up to my colleagues’ blog post about the newest Office exploits, here is an analysis of one of the Microsoft PowerPoint Zero-Day exploits that once again are used in targeted attacks to infect victims with a trojan horse. The malicious presentation files abuse a new, yet unpatched hole in Microsoft PowerPoint and causes it to execute code infiltrated by the attackers. This blog post shows how the shellcode works and what it does, right after an innocent victim opens the malicious file – if the attacker gets their way of course!

For size reasons, the code is split up into several parts that are scattered among the malicious PowerPoint file. Part one of the shellcode consists of an “egghunter”, which is used to relocate the remaining part of the shellcode in memory. In order to do that, it first sets up an exception handler that prevents crashes when accessing bad memory locations, then goes on a hunt for the shellcode’s prepended egg (0xD1CF11E0). Once that egg (which is a marker for the beginning of the shellcode’s second part) is found in memory, code execution is transfered to the code following it.

Part two of the shellcode begins with a loop that looks for a writable memory block of at least 1KB in size (starting at address 0×30000000). Another loop then XOR decodes another part of the shellcode into that memory location and branches to it. Once decoded, a filename (”fssm32.exe”) can be seen in the disassembly. In order to either download or drop a second-stage executable, shellcode needs access to operating system API functions. The ones it needs are going to be imported by parsing OS internal structures, such as the Process Environment Block, to locate kernel32.dll, then parsing the library’s PE header to locate the desired function pointers.

As shellcode mostly needs to fit into a size-limited block of memory, this piece of exploit not only has its code split into several parts for it to work reliably, it also uses 32bit hashes of API functions to import, rather than a list of respective function names which would consume more space. The shellcode’s ROR-13 hashing algorithm iterates over any exported API function name and compares it against its given list at run-time. Applying the same technique when statically analyzing shellcode, the list of imported functions becomes readable. Looking at the now readable list, it does not contain any function which would indicate the shellcode to download a file but rather drop an embedded one from the PowerPoint file and execute it.

Using a hex-search for typical indicators of an executable file, such as an “MZ” or “PE” header doesn’t yield any feasible results – which is not astonishing at all. Of course, the attackers responsible for having built the exploit intended to prevent their cover being blown by something as obvious as an executable that is embedded into a PowerPoint presentation file! By looking more closely at the shellcode, there is another suspicious XOR-decoding loop.

The loop decrypts a given memory block using an 8bit XOR key. By incorporating the same decryption-loop into a Python script and applying it to the PowerPoint file (see screenshot below), both an MZ- and PE header surface in the hex editor. It’s the embedded executable that was assumed to hide between the PowerPoint “slides” – the malware can finally be extracted.

McAfee VirusScan products detect this threat as Exploit-PPT.k trojan, McAfee Anti-Malware Gateway Edition (former Secure Computing) detects the new exploits as Heuristic.Exploit.OLE2.CodeExec.PGPG.