Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.

UNCLASSIFIED
PoC Report
He
ap
Destro
y
- DLL Rootkit PoC R
epo
rt
Ra
y
theon Blackbird Technolo
g
i
es,
Inc. 1 28 Au
g
ust 2015
Use or disclosure of data contained on this sheet is su
bje
ct to the restrictions on the title
page
of this document.
UNCLASSIFIED
1.0 (U) Analysis Summary
(U) ZxShell contained an interesting technique that might allow for hiding malicious DLLs and
self deletion. Due to the description of this technique, additional research was performed to
determine the viability of a Proof of Concept (PoC). In particular, the API call and DLL load
procedure were investigated.
(U) Ultimately, we believe the overarching technique is valid; however, the description appears
to contain multiple flaws that need to be mitigated during PoC development.
2.0 (U) Detailed Analysis
(U) For reference purposes, the text below describes the original process to implement the
technique.
(U) The ZxShell’s ShellMain() performs and interesting rootkit implementation. The
ZxShell ShellMain function is a stub that relocates the main DLL to another buffer and
spawns a new thread and performs an interesting hook of the HeapDestroy() API in order
to hide the ZxShell.DLL. It replaces the first three bytes of HeapDestroy() with the RET 4
(opcode) and calls FreeLibrary() to free its own buffer. The allocated heaps will not be
freed. It re-copies the DLL from the new buffer to the original one using memcpy(). It then
spawns the main thread that starts at the original location of the ShellMainThread
procedure, and terminates. At this point, the ZxShell library is no longer linked in the
module list of the host process and any too that tries to open the host process will never
see the ZxShell.DLL.
(U) There primary concern with this technique is the purpose of the HeapDestroy() hook and is
detailed below.
2.1 (U) API Hook
(U) Hooking HeapDestroy(), while possible, does not seem useful when trying to prevent DLL
memory allocation and freeing. Typically, when a DLL is loaded, it inherits the parent process’s
heap and does not create its own.
(U) Further research into exactly how a DLL is loaded into memory showed that the above is, in
fact, true. In actuality, when a DLL is loaded, the file is memory mapped into the virtual address
space of the process. When one of the regions in the mapped file is accessed, a page fault occurs
and the data is paged in by the OS’s page fault handler (which resides in the kernel). Because of
this procedure, it is impossible for us to hook anything to prevent unmapping the memory from
usermode.
2.2 (U) Mitigation
(U) Because there is no manner easily available to prevent the memory from [potentially] being
freed when unloaded, we believe a workaround was necessary to properly handle the situation.
Instead of preventing the memory from being freed, the full loaded image is copied to a newly
allocated block of memory. After freeing the library, the exact exact virtual address that the
library was mapped to is allocated using VirtualAlloc() and the backed up image is copied in. In

e-Highlighter

Click to send permalink to address bar, or right-click to copy permalink.

Un-highlight all Un-highlight selectionu Highlight selectionh