架构	X86				X64
长度	BYTE	WORD	DWORD	QWORD	BYTE	WORD	DWORD	QWORD
冷：内存	244	241	246	250	254	254	260	261
热：L1	31	31	31	31	35	35	35	35

指令周期
数据类型	整型	浮点数
指令组合	m*	m/	m, m	m, n	m/, m/	m/, n/	m*, m/	f*	f/
指行时间	2	20	4	4	48	26	24	17	26

0 前言

安全软件为了达成进程安全及行为审计的目标经常会采用进程注入的方式，即将自己的DLL注入至用户进程中，以对恶意的注入模块进行对抗。就进程注入方法来说有多种方式，木马及攻击方可使用的手段更多，毕竟攻击者对稳定性及善后部分不用做过多考虑。本文将对注入方式做一个简单的汇总对比，下面分别从应用层及内核层的不同实现方案进行拆解：

1 应用层注入手段

本章节将主要介绍完全应用层的注入实现。

1.1 远程线程及APC注入、SetThreadContext

这两种方式的实现机制是不同的，但思路是一样的，都需要上传负载（Payload）至要注入的进程空间，一般的操作过程如下：

通过OpenProcess获取进程句柄(HANDLE)，然后在目标进程空间申请内存（VirtualAlloc或VirtualAllocEx]），然后调用WriteProcessMemory将shellcode负载写入目标进程空间，最后调用CreateRemoteThread、NtCreateThreadEx、RtlCreateUserThread等创建用户线程，或者添加APC（QueueUserApc）至用户线程以完成shellcode的执行目的。

SetThreadContxt机制是将原线程挂起（SuspendThread），通过修改线程Context中的eip/rip指针至上传的shellcode地址。

Shellcode的设计一般只是简单的LdrLoadDll的调用，复杂的有如DoublePulsar木马所采用的，直接将Payload DLL进行展开并手工加载。

用户层注入的问题是权限受限，另外很容易被检测到，现在的杀软普遍都会特殊关照上述的这些特征函数。

1.2 Win32消息钩子

通过Win32 API SetWindowsHookEx注册系统级消息钩子，以截获同一桌面上所有线程的消息通信，从而实现了DLL模块的注入。当然消息钩子的局限也很明显：

被注入进程必须接受用户输入，使用了消息队列，如带GUI界面程序；服务进程一般无需用户输入，所以此种注入方法对服务进程无效 64位系统中，64位进程只能设置针对64位程序的消息HOOK，32位进程只针对32位程序，不可交叉混用。和SetWindowsHookEx类似的2. SetWinEventHook 虽然同样可以取到所有进程的消息，但并不能导致DLL注入。
Windows Automation API：Windows Automation API提供给程序访问其它程序窗口及组件（UI elements）的能力，一般用于自动化测试。利用Windows Automation API实现注入的过程，和消息钩子的方式没有本质区别，也有着同样的限制。
1.3 系统提供机制（注册表选项）

1) App Init DLLs

所有加载User32.dll的程序均会自动加载此键值下的DLL，主要针对Win7及之前的Windows版本，从Win8之后此机制不被推荐使用，在UEFI Secure Boot模式下此项被默认关闭。

所在注册表位置：

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs

使用此方式的木马及病毒：Ginwui、Cherry Picker、T9000

2) App Cert DLLs

所有调用下面Win32 API的程序均会自动加载上述注册表中所列的DLL文件：

CreateProcess
CreateProcessAsUser
CreateProcessWithLoginW
CreateProcessWithTokenW
WinExec

所在注册表位置：

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager

使用此方式的木马及病毒：Honeybee、FIN8 PUNCHBUGGY

3) Image File Execution Options

这是Windows系统提供的一个调试辅助机制，用以在特定进程启动或退出时启动指定程序（如调试器等）。用户通过更改IFEO键值达成启动不同进程的目的，从而导致原进程加载请求失败。

所在注册表位置：

HKLM\SOFTWARE{\Wow6432Node}\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\

4) Shim Database (SDB)攻击

Windows系统通过Shim数据库（SDB文件，位于%windir%\AppPatch\sysmain.sdb）以提升应用程序的向后兼容（backward compatibility）。SDB数据库中包含针对上千个程序的上百种配置，只要有管理员权限就可操纵此数据库，就可以修改任意程序的各种属性，如以下多种属性：

InjectDll
LoadLibraryRedirectFlag
ForceAdminAccess
RelaunchElevated
WrpMitigation
DisableNX
ModifyShellLinkPath
VirtualRegistry
DisableAdvancedRPCClientHardening
CorrectFilePaths
DisableSeh
DisableWindowsDefender
ShellExecuteXP

涉及注册表项：

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB

使用此方式的木马及病毒：BlackEnergy, GooKit, Roaming Tiger,QianSet.exe,VzQqgi.dll木马

1.4 PE程序IAT表静态修改

早期的Win32病毒常采用的就是静态感染方式，会将自身的代码写入被被感染程序，然后修改PE入口函数至病毒的代码段；同样的方式，静态修改PE文件的导入表以增加新的DLL注入亦不是难事。

针对有签名的PE程序，类似的修改会导致签名校验失败。

1.5 DLL替换

创建一个假个但导出一模一样的DLL文件用以替换原系统的，替换办法一般有两种办法：

系统原DLL文件改名，并替换系统DLL
更改DLL搜索路径（SetDLLDirectory）

这种方式要处理的问题：

系统模块签名问题无法处理：PPL进程将无法运行
不同版本的系统DLL处理堆积

2 内核层注入手段

内核R0层注入要比应用层R3的手段少了很多，实现难度会大一些，但内核实现更加隐蔽，难以被屏蔽。通过创建用户层线程或插入APC以实现注入的方式被普遍使用，原理上同R3的远程线程及APC注入的思路基本一致，均需要向目标进程空间上载参数及shellcode代码，只是R0及R3各自使用的支持函数不同。

2.1 IAT表注入

在进程创建过程中，内核驱动通过PsSetCreateProcessNotifyRoutine或PsSetCreateProcessNotifyRoutineEx得到通知，此时用户进程的创建过程是被阻塞的，在处理通知的回调中，内核驱动可以修改进程的内存镜像中的导入表，将要注入的驱动加入其中。

以wermgr.exe进程（PID: 0x6bc）的创建为例，此进程由services.exe（PID: 0x2bc）创建： Windows注入-IAT表后续会收到模块加载的通知回调，加载模块的顺序依次为wermgr.exe自身、ntdll.dll、kernel32.dll、KernelBase.dll、msvcrt.dll等，回调时的调用栈为： Windows IAT注入导入表修改动作是在进程镜像本身的模块加载回调中执行的，即程序本身模块加载的时机。

IAT表注入的主要问题：

.NET程序的兼容性问题
托管代码与非托管DLL代码的混合
64位.NET程序没有导入表项
受保护进程的注入问题，必须要通过NTDLL HOOK来解决，因为创建Section对象时内核会验证DLL签名等，在IAT已注入的情况下签名又无法签证通过时会导致程序加载失败

2.2 Shellcode注入

创建用户线程及插入APC的注入手段均需要上载shellcode代码至目标进程，shellcode可以只是简单的LdrLoadDll调用用以加载HOOK引擎及工作模块，复杂一些的话可以在内核层将DLL手工加载至目标进程空间，正如木马DoublePulsar所实现的加载器【D23】"Generic Relective DLL Loader"或者内核层Turla Driver Loader（TDL）驱动加载器【D18】。

常用shellcode/payload构造（BlackBone的实现）：

// shellcode for X64
UCHAR code[] =
{
0x48, 0x83, 0xEC, 0x28,             // sub rsp, 0x28
0x48, 0x31, 0xC9,                   // xor rcx, rcx
0x48, 0x31, 0xD2,                   // xor rdx, rdx
0x49, 0xB8, 0, 0, 0, 0, 0, 0, 0, 0, // mov r8, ModuleFileName   offset+12
0x49, 0xB9, 0, 0, 0, 0, 0, 0, 0, 0, // mov r9, ModuleHandle     offset+28
0x48, 0xB8, 0, 0, 0, 0, 0, 0, 0, 0, // mov rax, LdrLoadDll      offset+32
0xFF, 0xD0,                         // call rax
0x48, 0xBA, 0, 0, 0, 0, 0, 0, 0, 0, // mov rdx, COMPLETE_OFFSET offset+44
0xC7, 0x02, 0x7E, 0x1E, 0x37, 0xC0, // mov [rdx], CALL_COMPLETE
0x48, 0x83, 0xC4, 0x28,             // add rsp, 0x28
0xC3                                // ret
};

// shellcode for X86
UCHAR code[] =
{
0x68, 0, 0, 0, 0,                   // push ModuleHandle        offset+01
0x68, 0, 0, 0, 0,                   // push ModuleFileName      offset+06
0x6A, 0,                            // push Flags
0x6A, 0,                            // push PathToFile
0xE8, 0, 0, 0, 0,                   // call LdrLoadDll          offset+15
0xBA, 0, 0, 0, 0,                   // mov edx, COMPLETE_OFFSET offset+20
0xC7, 0x02, 0x7E, 0x1E, 0x37, 0xC0, // mov [edx], CALL_COMPLETE
0xC2, 0x04, 0x00                    // ret 4
};

1) 创建用户线程

创建用户线程一般通过NtCreateThreadEx（Visata及以后OS）或NtCreateThread（XP），这两个函数在内核中均未导出且是未公开的，其地址获取可以通过SSDT或者ntoskrnl镜像解析完成。

NTKERNELAPI NTSTATUS NTAPI
NtCreateThread(
__out PHANDLE ThreadHandle,
__in ACCESS_MASK DesiredAccess,
__in_opt POBJECT_ATTRIBUTES ObjectAttributes,
__in HANDLE ProcessHandle,
__out PCLIENT_ID ClientId,
__in PCONTEXT ThreadContext,
__in PINITIAL_TEB InitialTeb,
__in BOOLEAN CreateSuspended
);

NTKERNELAPI NTSTATUS NTAPI
NtCreateThreadEx(
OUT PHANDLE hThread,
IN ACCESS_MASK DesiredAccess,
IN PVOID ObjectAttributes,
IN HANDLE ProcessHandle,
IN PVOID lpStartAddress,
IN PVOID lpParameter,
IN ULONG Flags,
IN SIZE_T StackZeroBits,
IN SIZE_T SizeOfStackCommit,
IN SIZE_T SizeOfStackReserve,
OUT PVOID lpBytesBuffer
);

2) APC注入

在内核中构造一个APC结构并添加至用户线程的APC队列，等条件满足时系统会执行APC中设定的callback，从而达成进程DLL注入的目的。

3) HOOK NTDLL方式

内核驱动可以通过内核的回调机制截获用户进程创建及PE加载器加载并初始化DLL链的每个环节，可以监控到指定模块加载时同步进行inline hook，并将关注点的执行流程导向至已上载的shellcode负载。

回调本身是串行在程序的加载流程中的，即回调不返回，进程的创建及DLL的加载过程是被阻塞的，省却了同步与不一致性的问题的处理。

之所以要选择ntdll.dll的原因是，ntdll.dll是所有的Win32程序必须加载的，并且其执行过程比程序本身的入口执行要早；另外选择ntdll.dll而不是Kernel32.dll等模块的原因是，Kernel32.dll等模块并不是必须的，比如Native程序如csrss,exe、autochk.exe等，还有一些程序将Kernel32.dll等模块设置为Delay-Loading-DLL，并不会在程序启动之初就立即加载并执行。

为了尽早地获取控制权，常用的HOOK点一般放在ntdll!LdrInitializeThunk、ntdll!NtOpenDirectoryObject或者ntdll!LdrLoadDLL等关键函数点。Haiheiwang木马【D16】就是通过修改ntdll!NtTestAlert的流程将自己的工作模块加入被感染进程的，当然ntdll!NtTestAlert也存在时机较晚的问题，并不能满足咱们的需求。

这种方式在安全软件中也广泛使用，特别是对针对Win8系统年引入的受保护进程的注入问题，由内核注入Shellcode并通过HOOK ntdll!NtCreateSection来加载非系统模块是最实用且有效方式，目前360安全卫士的注入亦是采用此方式。受保护PPL进程只对用户层的Section对象创建有签名验证，我们通过将内核层创建Section对象映射至用户空间的方式达成向受保护PPL进程注入的目的。

其它的替代方案会导致受保护进行安全性的妥协等，比如短暂取消受保护进行的保护状态以达成注入目的，此种方式有可能会触发KPP/PG检测失效，另外也很容易被第三方恶意利用，比如MalwareFox AntiMalware的一个被曝光的漏洞【D24: MalwareFox AntiMalware 2.74.0.150 LPE】。

Shellcode内存映射可以在HOOK引擎模块加载之后进行销毁，存在窗口时间非常短，被其它安全软件查到或被其它恶意程序所利用的可能比较小。

3 参考资料

--- END ---

通过TSC观察CPU

CPU指令：

调用:

示例：

注意事项：

Windows进程注入

0 前言

1 应用层注入手段

1.1 远程线程及APC注入、SetThreadContext

1.2 Win32消息钩子

1.3 系统提供机制（注册表选项）

1) App Init DLLs

2) App Cert DLLs

3) Image File Execution Options

4) Shim Database (SDB)攻击

1.4 PE程序IAT表静态修改

1.5 DLL替换

2 内核层注入手段

2.1 IAT表注入

2.2 Shellcode注入

1) 创建用户线程

2) APC注入

3) HOOK NTDLL方式

3 参考资料

3.1 浏览器自身防护资讯

3.2 进程DLL注入资料

3.3 DLL注入商业方案

3.4 开源HOOK引擎

3.5 Instrumentation Callback

3.6 PPL (Protected Process Light)

3.7 WSL (Windows Subsystem for Linux)