In inline hooking, we saw how the series of bytes in a function are patched to redirect control to malicious code. It is possible to perform in-memory patching using the application compatibility shim (the details of the shim were covered previously). Microsoft uses the feature of in-memory patching to apply patches to fix vulnerabilities in their products. In-memory patching is an undocumented feature, and is not available in the Compatibility Administrator Tool (covered earlier), but security researchers, through reverse engineering, have figured out the functionality of in-memory patches, and have developed tools to analyze them. The sdb-explorer by Jon Erickson (https://github.com/evil-e/sdb-explorer) and python-sdb by William Ballenthin (https://github.com/williballenthin/python-sdb) allow you to inspect in-memory patching by parsing the shim database (.sdb) files. The following presentations by these researchers contain detailed information on in-memory patches, and the tools to analyze them:
- Persist It Using and Abusing Microsoft’s Fix It Patches: http://www.blackhat.com/docs/asia-14/materials/Erickson/WP-Asia-14-Erickson-Persist-It-Using-And-Abusing-Microsofts-Fix-It-Patches.pdf
- The Real Shim Shady: http://files.brucon.org/2015/Tomczak_and_Ballenthin_Shims_for_the_Win.pdf
Malware authors have used in-memory patching to inject code and hook the API functions. One of the malware samples that use in-memory patching is GootKit; this malware installs various shim database (files) using the sdbinst utility. The following screenshot shows shims installed for multiple applications, and the screenshot shows the .sdb file associated with explorer.exe:
The installed .sdb files contain the shellcode that will be patched directly into the memory of the target process. You can examine the .sdb file using the sdb_dump_database.py script (part of the python-sdb tool) by using the command shown here:
$ python sdb_dump_database.py {4c895e03-f7a5-4780-b65b-549b3fef0540}.sdb
The output of the preceding command shows the malware targeting explorer.exe and applying a shim named patchdata0. The PATCH_BITS below the shim name is a raw binary data that contains the shellcode that will be patched into the memory of explorer.exe:
To know what the shellcode is doing, we need to be able to parse PATCH_BITS, which is an undocumented structure. To parse this structure, you can use the sdb_dump_patch.py script (part of python-sdb) by giving the patch name, patchdata0, as shown here:
$ python sdb_dump_patch.py {4c895e03-f7a5-4780-b65b-549b3fef0540}.sdb patchdata0
Running the preceding command shows various patches applied in kernel32.dll, within explorer.exe. The following screenshot displays the first patch, where it matches two bytes, 8B FF (mov edi,edi), at the relative virtual address (RVA) 0x0004f0f2, and replaces them with EB F9 (jmp 0x0004f0ed). In other words, it redirects control to the RVA 0x0004f0ed:
The following output shows another patch applied at the RVA 0x0004f0ed in kernel32.dll, where the malware replaced the series of NOP instructions with call 0x000c61a4, thereby redirecting the program control to function at the RVA 0x000c61a4. This way, the malware patches multiple locations in kernel32.dll and performs various redirections, which finally leads it to the actual shellcode:
To understand what the malware is patching in kernel32.dll, you can attach the debugger to the patched explorer.exe process and locate these patches in kernel32.dll. For instance, to inspect the first patch at the RVA 0x0004f0f2, we need to determine the base address where kernel32.dll is loaded. In my case, it is loaded at 0x76730000, and then add the RVA 0x0004f0f2 (in other words, 0x76730000 + 0x0004f0f2 = 0x7677f0f2). The following screenshot shows that this address 0x7677f0f2 is associated with the API function LoadLibraryW():
Inspecting the LoadLibraryW() function shows the jump instruction at the start of the function, which will ultimately reroute the program control to the shellcode:
This technique is interesting, because in this case, the malware does not allocate memory or inject code directly, but relies on Microsoft's shim feature to inject the shellcode and hook the LoadLibraryW() API. It also makes detection difficult by jumping to various locations within kernel32.dll.