投稿
一、前言
在当今，网络犯罪分子致力于开发恶意软件，并用于感染主机以执行特定的活动。考虑到目前反病毒软件能力的不断提升，这些恶意软件也必须保持较强的存活能力，必须要在暗中进行操作，以避免被反病毒软件和系统管理员觉察。在众多方法之中，代码注入是一个保证隐蔽性的较好方法。
本文主要描述恶意软件及其与Windows应用程序编程接口（WinAPI）交互的相关研究成果，详细介绍恶意软件是如何将恶意Payload植入其他进程，以及如何通过监控Windows操作系统的通信来检测此类行为。关于监控API调用的这一概念，在本文中也将会通过对特定函数进行Hook的过程来向大家展现，并且该概念将用于实现代码注入。
由于时间有限，我们以非常快的速度完成了该项目的研究，因此如果本文中有任何疏漏或错误之处，希望大家能够谅解，并期待各位的指正。此外，本文附带的代码可能会存在一些未知的设计缺陷，请各位自行参考。
二、相关概念
2.1 Inline Hooking
内联挂钩（Inline Hooking）是通过热补丁（Hotpatching）的方式绕开代码流的行为。在这里，热补丁是指在可执行映像运行期间对代码进行修改。之所以使用内联挂钩的方式，是为了能够捕获程序在何时调用函数的实例，以进行监控或实现调用。以下是一次函数调用正常执行的过程：
Normal Execution of a Function Call
+---------+ +----------+
| Program | ----------------------- calls function -----------------------------> | Function | | execution
+---------+ | . | | of
| . | | function
| . | |
| | v
+----------+
与执行一个挂钩后的函数相比：
Execution of a Hooked Function Call
+---------+ +--------------+ + -------> +----------+
| Program | -- calls function --> | Intermediate | | execution | | Function | | execution
+---------+ | Function | | of calls | . | | of
| . | | intermediate normal | . | | function
| . | | function function | . | |
| . | v | | | v
+--------------+ ------------------+ +----------+
该过程可以分为三个步骤。我们在这里，以WinAPI函数MessageBox为例，演示此过程。
(1) 对函数进行挂钩
想要挂钩（Hook）函数，我们首先需要一个中间函数，它必须能够复制目标函数的参数。在MSDN中对MessageBox的定义如下：
int WINAPI MessageBox(
_In_opt_ HWND hWnd,
_In_opt_ LPCTSTR lpText,
_In_opt_ LPCTSTR lpCaption,
_In_ UINT uType
);
所以，我们的中间函数可以这样定义：
int WINAPI HookedMessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType) {
// our code in here
}
一旦存在，执行流就会重定向到代码中的特定位置。如果想要真正对MessageBox函数进行挂钩，我们可以修补代码的前几个字节（请注意，必须要对原始字节进行记录，以便在中间函数完成时能够恢复该函数）。以下是该函数的原始汇编指令，如该函数的相应模块user32.dll中所示：
; MessageBox
8B FF mov edi, edi
55 push ebp
8B EC mov ebp, esp
与挂钩后的函数相比：
; MessageBox
68 xx xx xx xx push <HookedMessageBox> ; our intermediate function
C3 ret
在这里，我选择了PUSH和RET的组合，而没有选择JMP，这是基于我之前的经验，前者会有更强的隐蔽性。其中的xx xx xx xx表示HookedMessageBox的小字节序顺序地址（Little-Endian Byte-Order Address）。
(2) 捕获函数调用
当程序调用MessageBox时，它将执行PUSH-RET并会成功跳入HookedMessageBox函数。一旦完成，程序就会完全控制参数和调用本身。如果想替换在消息对话框中所显示的文本，可以在HookedMessageBox中定义如下内容：
int WINAPI HookedMessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType) {
TCHAR szMyText[] = TEXT("This function has been hooked!");
}
其中，szMyText可以用来替换MessageBox的LPCTSTR lpText参数。
(3) 恢复正常执行
要转发此参数，执行过程需要回到原始的MessageBox，以让操作系统可以显示该对话框。如果现在再次调用MessageBox，会导致无限递归（死循环），因此我们必须要恢复原始字节（如前所述）。
int WINAPI HookedMessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType) {
TCHAR szMyText[] = TEXT("This function has been hooked!");
// restore the original bytes of MessageBox
// ...
// continue to MessageBox with the replaced parameter and return the return value to the program
return MessageBox(hWnd, szMyText, lpCaption, uType);
}
如果需要拒绝调用MessageBox，方法也非常简单，就像返回一个值一样，但这个值最好是在文档中定义过的。例如，想要从”是/否”对话框中返回”否”选项的值，其中间函数可以是：
int WINAPI HookedMessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType) {
return IDNO; // IDNO defined as 7
}
2.2 API监控
在了解函数挂钩以后，我们紧接着讲解API监控的概念。我们有能力获得对函数调用的控制，同时也可以对所有参数进行监控，也就是标题所说的API监控。但是，还存在一个小问题，是由不同级别的API调用可用性导致的，尽管这些调用是唯一的，但在较低级别会使用相同的一组API。这就称为函数包装（Function Wrapping），定义为用于调用次级子程序的子程序。让我们回到MessageBox的示例，其中有两个定义的函数：MessageBoxA用于包含ASCII字符的参数，MessageBoxW用于包含宽字符的参数。实际上，如果我们要对MessageBox进行挂钩，就必须要同时修补MessageBoxA和MessageBoxW。要解决这一问题，我们需要尽可能在函数调用层次（Call Hierarchy）结构的最低公共点位置进行挂钩。
+---------+
| Program |
+---------+
/
| |
+------------+ +------------+
| Function A | | Function B |
+------------+ +------------+
| |
+-------------------------------+
| user32.dll, kernel32.dll, ... |
+-------------------------------+
+---------+ +-------- hook -----------------> |
| API | <---- + +-------------------------------------+
| Monitor | <-----+ | ntdll.dll |
+---------+ | +-------------------------------------+
+-------- hook -----------------> | User mode
-----------------------------------------------------
Kernel mode
以下是MessageBox调用层次结构：
MessageBoxA：
user32!MessageBoxA -> user32!MessageBoxExA -> user32!MessageBoxTimeoutA -> user32!MessageBoxTimeoutW
MessageBoxW：
user32!MessageBoxW -> user32!MessageBoxExW -> user32!MessageBoxTimeoutW
上述的调用层次，都将汇入MessageBoxTimeoutW，这是一个挂钩的绝佳位置。在这里要特别指出，对于具有更深层次结构的函数，由于函数参数的复杂程度有所增加，对较低位置的值进行挂钩可能会产生一些问题。MessageBoxTimeoutW是一个没有出现在文档中的WinAPI函数（Undocumented WinAPI Function），其定义如下：
int WINAPI MessageBoxTimeoutW(
HWND hWnd,
LPCWSTR lpText,
LPCWSTR lpCaption,
UINT uType,
WORD wLanguageId,
DWORD dwMilliseconds
);
其用法如下：
int WINAPI MessageBoxTimeoutW(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uType, WORD wLanguageId, DWORD dwMilliseconds) {
std::wofstream logfile; // declare wide stream because of wide parameters
logfile.open(L"log.txt", std::ios::out | std::ios::app);
logfile << L"Caption: " << lpCaption << L"n";
logfile << L"Text: " << lpText << L"n";
logfile << L"Type: " << uType << :"n";
logfile.close();
// restore the original bytes
// ...
// pass execution to the normal function and save the return value
int ret = MessageBoxTimeoutW(hWnd, lpText, lpCaption, uType, wLanguageId, dwMilliseconds);
// rehook the function for next calls
// ...
return ret; // return the value of the original function
}
当挂钩被放入MessageBoxTimeoutW中之后，MessageBoxA和MessageBoxW就都可以被捕获了。
2.3 代码注入入门
就本文而言，我们所讲解的”代码注入”是指将可执行代码插入到外部进程中。在WinAPI中，允许了一些功能，从而让代码注入成为了可能。在某些函数的共同作用下，我们可以访问现有进程，向其中写入数据，并且在其上下文中进行远程执行。在本节中，我们将介绍研究中涉及到的相关代码注入技术。
2.3.1 DLL注入
关于代码注入，代码可以是各种形式，其中之一就是动态链接库（DLL）。DLL是用来为可执行程序提供扩展功能的库，通过导出子程序的方式我们就可以使用该程序。下面是一个DLL示例，下文中都将以此为例：
extern "C" void __declspec(dllexport) Demo() {
::MessageBox(nullptr, TEXT("This is a demo!"), TEXT("Demo"), MB_OK);
}
bool APIENTRY DllMain(HINSTANCE hInstDll, DWORD fdwReason, LPVOID lpvReserved) {
if (fdwReason == DLL_PROCESS_ATTACH)
::CreateThread(nullptr, 0, (LPTHREAD_START_ROUTINE)Demo, nullptr, 0, nullptr);
return true;
}
当一个DLL被加载到进程并初始化时，加载程序将会调用Dllmain，并将fdwReason设置为DLL_PROCESS_ATTACH。在这个例子中，当它被加载到进程中时，会通过Demo子例程来显示一个消息框，其标题为”Demo”，文本内容为”This is a demo!”。要正确完成DLL的初始化，它必须返回True，否则就会被卸载。
2.3.1.1 CreateRemoteThread
通过CreateRemoteThread函数的DLL注入会利用此函数在另一个进程的虚拟空间中执行远程线程（Remote Thread）。如上所述，我们要执行DLL，只需要通过强制执行LoadLibrary函数来将其加载到进程中。以下代码可以完成此操作：
void injectDll(const HANDLE hProcess, const std::string dllPath) {
LPVOID lpBaseAddress = ::VirtualAllocEx(hProcess, nullptr, dllPath.length(), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
::WriteProcessMemory(hProcess, lpBaseAddress, dllPath.c_str(), dllPath.length(), &dwWritten);
HMODULE hModule = ::GetModuleHandle(TEXT("kernel32.dll"));
LPVOID lpStartAddress = ::GetProcAddress(hModule, "LoadLibraryA"); // LoadLibraryA for ASCII string
::CreateRemoteThread(hProcess, nullptr, 0, (LPTHREAD_START_ROUTINE)lpStartAddress, lpBaseAddress, 0, nullptr);
}
在MSDN中，对LoadLibrary的定义如下：
HMODULE WINAPI LoadLibrary(
_In_ LPCTSTR lpFileName
);
该定义使用了一个参数，即要加载的所需库的路径名称。CreateRemoteThread函数允许将一个参数传递到与LoadLibrary的函数定义完全匹配的线程例程。其目标是在目标进程的虚拟地址空间中分配字符串参数，然后将分配的空间地址传递给CreateRemoteThread的参数中，以便调用LoadLibrary来加载DLL。
(1) 在目标进程中分配虚拟内存
使用VirtualAllocEx可以允许在选定的进程哪分配空间，一旦成功，会返回分配内存的起始地址。
Virtual Address Space of Target Process
+--------------------+
| |
VirtualAllocEx +--------------------+
Allocated memory ---> | Empty space |
+--------------------+
| |
+--------------------+
| Executable |
| Image |
+--------------------+
| |
| |
+--------------------+
| kernel32.dll |
+--------------------+
| |
+--------------------+
(2) 将DLL路径写入分配的内存
一旦内存被初始化，DLL的路径可以被注入到VirtualAllocEx使用WriteProcessMemory返回的分配内存中。
Virtual Address Space of Target Process
+--------------------+
| |
WriteProcessMemory +--------------------+
Inject DLL path ----> | "....myDll.dll" |
+--------------------+
| |
+--------------------+
| Executable |
| Image |
+--------------------+
| |
| |
+--------------------+
| kernel32.dll |
+--------------------+
| |
+--------------------+
(3) 获取LoadLibrary的地址
由于所有系统DLL都映射到所有进程的相同地址空间，因此LoadLibrary的地址不必直接从目标进程中检索，只需调用GetModuleHandle(TEXT(“kernel32.dll”))和GetProcAddress(hModule, “LoadLibraryA”)即可完成这项工作。
(4) 加载DLL
如果要加载DLL，就需要LoadLibrary的地址和DLL的路径。此时使用CreateRemoteThread函数，LoadLibrary会在目标进程的上下文中以DLL路径作为参数执行。
Virtual Address Space of Target Process
+--------------------+
| |
+--------------------+
+--------- | "....myDll.dll" |
| +--------------------+
| | |
| +--------------------+ <---+
| | myDll.dll | |
| +--------------------+ |
| | | | LoadLibrary
| +--------------------+ | loads
| | Executable | | and
| | Image | | initialises
| +--------------------+ | myDll.dll
| | | |
| | | |
CreateRemoteThread v +--------------------+ |
LoadLibraryA("....myDll.dll") --> | kernel32.dll | ----+
+--------------------+
| |
+--------------------+
2.3.1.2 SetWindowsHookEx
在Windows中，通过SetWindowsHookEx函数为开发人员提供了通过安装钩子来监视某些事件的功能。虽然这一功能经常被用于监控键盘输入并记录，但它其实也能用于注入DLL。以下代码演示了如何向其自身注入DLL：
int main() {
HMODULE hMod = ::LoadLibrary(DLL_PATH);
HOOKPROC lpfn = (HOOKPROC)::GetProcAddress(hMod, "Demo");
HHOOK hHook = ::SetWindowsHookEx(WH_GETMESSAGE, lpfn, hMod, ::GetCurrentThreadId());
::PostThreadMessageW(::GetCurrentThreadId(), WM_RBUTTONDOWN, (WPARAM)0, (LPARAM)0);
// message queue to capture events
MSG msg;
while (::GetMessage(&msg, nullptr, 0, 0) > 0) {
::TranslateMessage(&msg);
::DispatchMessage(&msg);
}
return 0;
}
MSDN中定义的SetWindowsHookEx如下：
HHOOK WINAPI SetWindowsHookEx(
_In_ int idHook,
_In_ HOOKPROC lpfn,
_In_ HINSTANCE hMod,
_In_ DWORD dwThreadId
);
在这里，需要一个HOOKPROC参数，该参数是触发特定挂钩事件时执行的用户定义的回调子例程。在这种情况下，事件是WH_GETMESSAGE，它负责处理消息队列中的消息。该代码最初将DLL加载到其自身的虚拟进程空间中，并且导出的Demo函数的地址将被获取并定义为调用SetWindowsHookEx中的回调函数。为了强制回调函数执行，使用了消息WM_RBUTTONDOWN调用PostThreadMessage，这样就能触发WH_GETMESSAGE钩子，从而显示消息框。
2.3.1.3 QueueUserAPC
使用QueueUserAPC的DLL注入与CreateRemoteThread类似，都是分配DLL路径并注入到目标进程的虚拟地址空间，然后在其上下文中强制调用LoadLibrary。
int injectDll(const std::string dllPath, const DWORD dwProcessId, const DWORD dwThreadId) {
HANDLE hProcess = ::OpenProcess(PROCESS_ALL_ACCESS, false, dwProcessId);
HANDLE hThread = ::OpenThread(THREAD_ALL_ACCESS, false, dwThreadId);
LPVOID lpLoadLibraryParam = ::VirtualAllocEx(hProcess, nullptr, dllPath.length(), MEM_COMMIT, PAGE_READWRITE);
::WriteProcessMemory(hProcess, lpLoadLibraryParam, dllPath.data(), dllPath.length(), &dwWritten);
::QueueUserAPC((PAPCFUNC)::GetProcAddress(::GetModuleHandle(TEXT("kernel32.dll")), "LoadLibraryA"), hThread, (ULONG_PTR)lpLoadLibraryParam);
return 0;
}
其与CreateRemoteThread之间的一个主要区别是，QueueUserAPC能在可报警状态（Alertable State）下运行。由QueueUserAPC进行排队的异步过程仅在线程进入此状态时才进行处理。
2.3.2 Process Hollowing
Process Hollowing，也称RunPE，适用于逃避反病毒检测的一种常用方式。该方式允许将整个可执行文件的注入部分加载到目标进程中，并在其上下文中执行。通常我们可以在加密的应用程序中看到，与Payload相兼容的磁盘上文件会被选为主文件，并创建为进程，其主要可执行模块会被替换。该过程可以分为下述四个阶段。
(1) 创建主进程
为了注入Payload，引导程序必须会首先找到合适的主文件。如果Payload是.NET应用程序，那么主文件也必须是.NET应用程序。如果Payload是定义为使用控制台子系统的本地可执行文件，那么主文件也必须有相同的属性。这一原则在x86和x64程序时都要满足。一旦选择了主文件，随后便会使用CreateProcess(PATH_TO_HOST_EXE, …, CREATE_SUSPENDED, …)将其作为挂起的进程创建。
Executable Image of Host Process
+--- +--------------------+
| | PE |
| | Headers |
| +--------------------+
| | .text |
| +--------------------+
CreateProcess + | .data |
| +--------------------+
| | ... |
| +--------------------+
| | ... |
| +--------------------+
| | ... |
+--- +--------------------+
(2) 对主进程的Hollowing
为了让Payload能在注入后正常工作，必须要将其映射到虚拟地址空间，该虚拟地址空间要与在Payload PE头部的可选头中找到的ImageBase值相匹配。
typedef struct _IMAGE_OPTIONAL_HEADER {
WORD Magic;
BYTE MajorLinkerVersion;
BYTE MinorLinkerVersion;
DWORD SizeOfCode;
DWORD SizeOfInitializedData;
DWORD SizeOfUninitializedData;
DWORD AddressOfEntryPoint; // <---- this is required later
DWORD BaseOfCode;
DWORD BaseOfData;
DWORD ImageBase; // <----
DWORD SectionAlignment;
DWORD FileAlignment;
WORD MajorOperatingSystemVersion;
WORD MinorOperatingSystemVersion;
WORD MajorImageVersion;
WORD MinorImageVersion;
WORD MajorSubsystemVersion;
WORD MinorSubsystemVersion;
DWORD Win32VersionValue;
DWORD SizeOfImage; // <---- size of the PE file as an image
DWORD SizeOfHeaders;
DWORD CheckSum;
WORD Subsystem;
WORD DllCharacteristics;
DWORD SizeOfStackReserve;
DWORD SizeOfStackCommit;
DWORD SizeOfHeapReserve;
DWORD SizeOfHeapCommit;
DWORD LoaderFlags;
DWORD NumberOfRvaAndSizes;
IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
} IMAGE_OPTIONAL_HEADER, *PIMAGE_OPTIONAL_HEADER;
这一点非常重要，因为绝对地址很可能完全依赖于其内存位置的代码。为了安全地映射可执行映像，必须从描述的ImageBase值开始的虚拟内存空间取消映射。由于许多可执行文件都会使用公共的基地址（通常是0x400000），因此主进程自己的可执行映像未映射的情况并不罕见。这一过程是通过NtUnmapViewOfSection(IMAGE_BASE, SIZE_OF_IMAGE)来完成的。
Executable Image of Host Process
+--- +--------------------+
| | |
| | |
| | |
| | |
| | |
NtUnmapViewOfSection + | |
| | |
| | |
| | |
| | |
| | |
| | |
+--- +--------------------+
(3) 注入Payload
要注入Payload，必须手动解析PE文件，以将其从磁盘形式转换为映像形式。在使用VirtualAllocEx分配虚拟内存之后，要将PE头部直接复制到该基地址。
Executable Image of Host Process
+--- +--------------------+
| | PE |
| | Headers |
+--- +--------------------+
| | |
| | |
WriteProcessMemory + | |
| |
| |
| |
| |
| |
| |
+--------------------+
要将PE文件转换为映像，必须单独从文件偏移量中读取所有部分，然后使用WriteProcessMemory将其正确放置到相应的虚拟偏移量中。这一点在本文每一节中都有详细的讲解。
typedef struct _IMAGE_SECTION_HEADER {
BYTE Name[IMAGE_SIZEOF_SHORT_NAME];
union {
DWORD PhysicalAddress;
DWORD VirtualSize;
} Misc;
DWORD VirtualAddress; // <---- virtual offset
DWORD SizeOfRawData;
DWORD PointerToRawData; // <---- file offset
DWORD PointerToRelocations;
DWORD PointerToLinenumbers;
WORD NumberOfRelocations;
WORD NumberOfLinenumbers;
DWORD Characteristics;
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
Executable Image of Host Process
+--------------------+
| PE |
| Headers |
+--- +--------------------+
| | .text |
+--- +--------------------+
WriteProcessMemory + | .data |
+--- +--------------------+
| | ... |
+---- +--------------------+
| | ... |
+---- +--------------------+
| | ... |
+---- +--------------------+
(4) 执行Payload
最后一步，就是将执行的起始地址指向Payload的AddressOfEntryPoint。由于进程的主线程已经被挂起，所以可以使用GetThreadContext来检索相关信息。其上下文结构被定义为：
typedef struct _CONTEXT
{
ULONG ContextFlags;
ULONG Dr0;
ULONG Dr1;
ULONG Dr2;
ULONG Dr3;
ULONG Dr6;
ULONG Dr7;
FLOATING_SAVE_AREA FloatSave;
ULONG SegGs;
ULONG SegFs;
ULONG SegEs;
ULONG SegDs;
ULONG Edi;
ULONG Esi;
ULONG Ebx;
ULONG Edx;
ULONG Ecx;
ULONG Eax; // <----
ULONG Ebp;
ULONG Eip;
ULONG SegCs;
ULONG EFlags;
ULONG Esp;
ULONG SegSs;
UCHAR ExtendedRegisters[512];
} CONTEXT, *PCONTEXT;
要修改起始地址，必须将Eax成员更改为Payload的AddressOfEntryPoint的虚拟地址。简单来说，context.Eax = ImageBase + AddressOfEntryPoint。通过调用SetThreadContext，将修改的部分传入CONTEXT结构，即可将上述更改应用到进程的线程。接下来，我们只需调用ResumeThread，就可以使Payload执行。
2.3.3 Atom Bombing
Atom Bombing是一种代码注入技术，它利用Windows全局原子表（Windows’s Global Atom Table）进行全局数据存储。全局原子表的数据可以通过所有进程访问，这样就使我们的代码注入成为了可能。存储在表中的数据是以空字符结尾的C字符串类型，使用一个名为atom的16位整数键表示，类似于map数据结构。在MSDN中提供了一个用于添加数据的GlobalAddAtom函数，其定义如下：
ATOM WINAPI GlobalAddAtom(
_In_ LPCTSTR lpString
);
其中，lpString是要存储的数据。在成功调用时，会返回16位整数的原子。为了检索存储在全局原子表中的数据，MSDN提供了一个GlobalGetAtomName，其定义如下：
UINT WINAPI GlobalGetAtomName(
_In_ ATOM nAtom,
_Out_ LPTSTR lpBuffer,
_In_ int nSize
);
其功能是传入从GlobalAddAtom返回的标识原子，会将数据放入lpBuffer并返回不包含空终止符的字符串长度。
Atom Bombing通过迫使目标进程加载并执行放置在全局原子表中的代码来实现，该过程依赖于另一个至关重要的函数NtQueueApcThread，它是QueueUserAPC的最低级用户空间调用。我们之所以使用NtQueueApcThread而不是QueueUserAPC的原因在于，与GlobalGetAtomName相比，QueueUserAPC的APCProc只能接收一个不匹配的参数。
VOID CALLBACK APCProc( UINT WINAPI GlobalGetAtomName(
_In_ ATOM nAtom,
_In_ ULONG_PTR dwParam -> _Out_ LPTSTR lpBuffer,
_In_ int nSize
); );
然而，在NtQueueApcThread的底层实现中，实际上是允许三个参数的：
NTSTATUS NTAPI NtQueueApcThread( UINT WINAPI GlobalGetAtomName(
_In_ HANDLE ThreadHandle, // target process's thread
_In_ PIO_APC_ROUTINE ApcRoutine, // APCProc (GlobalGetAtomName)
_In_opt_ PVOID ApcRoutineContext, -> _In_ ATOM nAtom,
_In_opt_ PIO_STATUS_BLOCK ApcStatusBlock, _Out_ LPTSTR lpBuffer,
_In_opt_ ULONG ApcReserved _In_ int nSize
); );
这是代码注入过程的可视化表示：
Atom bombing code injection
+--------------------+
| |
+--------------------+
| lpBuffer | <-+
| | |
+--------------------+ |
+---------+ | | | Calls
| Atom | +--------------------+ | GlobalGetAtomName
| Bombing | | Executable | | specifying
| Process | | Image | | arbitrary
+---------+ +--------------------+ | address space
| | | | and loads shellcode
| | | |
| NtQueueApcThread +--------------------+ |
+---------- GlobalGetAtomName ----> | ntdll.dll | --+
+--------------------+
| |
+--------------------+
以上，我们以简洁的方式介绍了Atom Bombing，但这些基础知识对于本文的研究已经足够了。如果你想了解更多关于Atom Bombing的只是，请参考enSilo的文章：https://blog.ensilo.com/atombombing-brand-new-code-injection-for-windows 。
三、UnRunPE
UnRunPE是我们的概念验证（PoC）工具，是为了将API监控的理论应用于实践之中而写的。该工具目的在于选定一个可执行文件，并创建挂起的进程，随后将DLL注入到该进程中，利用Process Hollowing技术来实现特定的功能。
3.1 代码注入检测
读完了我们代码注入的基础知识，Hollowing方法可以用下面的WinAPI调用链来描述：
CreateProcess
NtUnmapViewOfSection
VirtualAllocEx
WriteProcessMemory
GetThreadContext
SetThreadContext
ResumeThread
这些调用过程，不必按照特定顺序进行调用。例如，也可以在VirtualAllocEx之前调用GetThreadContext。然而，一些调用需要依赖之前的API调用，也不能将这些调用完全颠倒先后顺序。例如，SetThreadContext必须要在GetThreadContext或CreateProcess之前调用，否则目标进程就不会有Payload注入。该工具以上述内容为运行的基础，试图检测潜在的Process Hollowing过程。
根据API监控的理论，我们最好对较低的位置进行挂钩，但如果考虑到对恶意软件检测的场景，那么我们最理想的是在最低的位置挂钩。最厉害的恶意软件可能会尝试跳过更高级别的WinAPI函数，直接调用通常在ntdll.dll模块中所找到的调用层次结构中最低的函数。以下WinAPI函数是Process Hollowing的调用层次结构最低的函数：
NtCreateUserProcess
NtUnmapViewOfSection
NtAllocateVirtualMemory
NtWriteVirtualMemory
NtGetContextThread
NtSetContextThread
NtResumeThread
3.2 代码注入转储
当我们对必要的函数进行挂钩之后，就会执行目标进程，并记录每个已挂钩函数的参数，这样能跟踪Process Hollowing以及主进程的当前状态。最重要的两个钩子是NtWriteVirtualMemory和NtResumeThread，前者负责在代码注入后进行应用，后者负责执行。除了记录参数之外，UnRunPE还会尝试转储使用NtWriteVirtualMemory写入的字节，然后当到达NtResumeThread时，会尝试转储已经注入主进程的全部Payload。为了完成上述任务，它使用NtCreateUserProcess中记录的进程和线程句柄参数，以及NtUnmapViewOfSection记录的基地址和大小。在这里，如果使用NtAllocateVirtualMemory提供的参数可能更为合适，但实际过程中，由于某些暂不清楚的原因，如果挂钩该函数会在运行过程中出现一些错误。当Payload从NtResumeThread中转储出来后，它将会终止目标进程及其宿主进程，以防止注入的代码被真正执行。
3.3 UnRunPE示例
为了演示，我使用了之前创建的二进制木马文件，它包含主要可执行文件PEview.exe，同时隐藏了可执行文件PuTTY.exe。
四、实战：Dreadnought工具
Dreadnought是基于UnRunPE构建的PoC工具，用于更广泛的代码注入检测，也就是我们在本文2.3中讲解的全部代码注入。我们要实现全面的代码注入检测，就需要对工具进行一些强化。
4.1 代码注入检测方法
考虑到当前有很多种代码注入方法，因此必须对不同的代码注入技术进行区分。第一种方法是识别”触发”API调用，即负责远程执行Payload的API调用。共有四种类型：
段（Section）：代码作为段被注入/代码被注入到段中。
进程：代码被注入到进程中。
代码：通用代码注入或Shellcode。
DLL：代码作为DLL被注入。
每一个触发API都列在相应的执行下面。当符合这些API中的任何一个时，Dreadought将会执行相应的代码转储方法，该方法与假设的注入类型相匹配，就类似于UnRunPE中Porcess Hollowing的方式。但是，这还远远不够，因为API调用仍然与可能会被混合，实现如箭头所示的功能。
4.2 启发式检测
为了让Dreadnought更准确地确定代码注入的方法，我们应该使用启发式检测。在开发过程中，我们应用了非常简单的启发式方法。在进程注入后，每次对API进行挂钩时，都会增加一个或多个存储在map数据结构中的相关代码注入类型的权重。由于它会跟踪每一个API调用，因此从一开始就有一个最高可能性的注入类型。一旦触发API被输入，它将识别并比较相关类型的权重，并进行调整。
4.3 Dreadnought实战
4.3.1 进程注入 – Process Hollowing
4.3.2 DLL注入 – SetWindowsHookEx
4.3.3 DLL注入 – QueueUserAPC
4.3.4 代码注入 – Atom Bombing
五、结论
本文对代码注入的技术进行了讲解，并帮助大家理解了其与WinAPI的交互过程。恶意软件利用注入的方式来绕过反病毒检测，我们可以使用Dreadnought来有效对这种行为进行检测。
然而，Dreadnought仍然存在一些局限性，它的启发式检测设计尚不完善，目前只能用于理论演示的目的，在实际使用中效果可能并不理想。因此，在操作系统正常运行期间，其可能会出现误报与漏报的情况。
六、PoC与相关源代码
https://github.com/NtRaiseHardError/UnRunPE
https://github.com/NtRaiseHardError/Dreadnought
七、参考
[1] https://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Sotirov.pdf
[2] https://www.codeproject.com/Articles/7914/MessageBoxTimeout-API
[3] https://blog.ensilo.com/atombombing-brand-new-code-injection-for-windows
[4] http://struppigel.blogspot.com.au/2017/07/process-injection-info-graphic.html
[5] https://www.reactos.org/
[6] https://undocumented.ntinternals.net/
[7] http://ntcoder.com/category/undocumented-winapi/
[8] https://github.com/processhacker/processhacker
[9] https://www.youtube.com/channel/UCVFXrUwuWxNlm6UNZtBLJ-A
[10] https://www.youtube.com/channel/UC–DwaiMV-jtO-6EvmKOnqg
