Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.
SECRE
T//
NOFORN
Pique Analysis Report
20150911-278-VB-Gamker
Ra
y
theon Blackbird Technolo
g
i
es,
Inc. 1 11 Se
p
tember 2015
Use or disclosure of data contained on this sheet is su
bje
ct to the restrictions on the title
page
of this document.
SECRE
T//
NOFORN
1.0 (U) Analysis Summary
(S//NF) This report details the code injection and API hooking methods of an information
stealing Trojan known as Gamker. This August 2015 three-page report from Virus Bulletin
contains more technical detail than many 30+ page reports from other sources. We recommend
continued review of Virus Bulletin reports going forward.
(S//NF) Gamker begins by decrypting itself using a simple XOR method and parsing the PEB to
get the ImageBase of kernel32.dll. It then parses the PE header of kernel32.dll in memory to find
the address of the export table, which is used to search for GetProcAddress(). Next, the following
APIs are resolved using GetProcAddress(): LoadLibraryA(), VirtualAlloc(), VirtualFree(),
VirtualProtect(), ExitThread(), and GetModuleHandleExW(). There is nothing unique or
particularly interesting in how Gamker resolves its APIs.
(S//NF) Gamker uses an interesting process for self-code injection that ensures nothing is written
to disk. We defer to the Sponsor on making a recommendation for PoC development of this self-
code injection technique as we are unaware if a similar technique already exists in their
inventory. After the APIs are resolved as described in the preceding paragraph, Gamker decrypts
a few more blocks of code. On executing the second decryption routine, a new executable image
is placed in memory, complete with MZ/PE header and body. Gamker parses the PE to
determine its size and changes the memory protection to PAGE_EXECUTE_READWRITE
using VirtualProtect(). The current module’s memory space is cleared by filling it with zeroes
and the MZ/PE header of the new executable is copied to the location of the current module.
Then Gamker copies each section of the new executable to the current module’s image area,
calculating the exact location where each section should be written. A custom loader, as it were.
The IAT requires fixing after the code is copied. This self-code injection technique should help
avoid detection by PSPs.
(S//NF) Gamker uses routine API hooking with one interesting variation that we haven’t seen
before, the use of an unusual Assembly language instruction twice in its hooking routine instead
of using the more normal mov instruction, thereby providing some obfuscation:
lock cmpxchng8b qword ptr [esi] (compare exchange 8-byte)
The first use of this unusual Assembly language instruction assists in making a copy of the
original NtQueryInformationProcess(), the API being hooked. The second use implements the
hook and the first few bytes of the hooked NtQueryInformationProcess() becomes a jump to the
hook function.
(S//NF) We defer to Sponsor on whether or not Gamer’s self-code injection technique should be
developed as a PoC.
2.0 (U) Description of the Technique
(S//NF) In-memory only code injection via custom loader that copies header and all sections into
memory space reserved and fixing up IAT.