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）创建：
后续会收到模块加载的通知回调，加载模块的顺序依次为wermgr.exe自身、ntdll.dll、kernel32.dll、KernelBase.dll、msvcrt.dll等，回调时的调用栈为：
导入表修改动作是在进程镜像本身的模块加载回调中执行的，即程序本身模块加载的时机。
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注入的目的。
相关函数原型如下：
NTKERNELAPI VOID NTAPI
KeInitializeApc (
__out PRKAPC Apc,
__in PRKTHREAD Thread,
__in KAPC_ENVIRONMENT Environment,
__in PKKERNEL_ROUTINE KernelRoutine,
__in_opt PKRUNDOWN_ROUTINE RundownRoutine,
__in_opt PKNORMAL_ROUTINE NormalRoutine,
__in_opt KPROCESSOR_MODE ProcessorMode,
__in_opt PVOID NormalContext
);
NTKERNELAPI BOOLEAN NTAPI
KeInsertQueueApc (
__inout PRKAPC Apc,
__in_opt PVOID SystemArgument1,
__in_opt PVOID SystemArgument2,
__in KPRIORITY Increment
);
360安全卫士的驱动360fsflt.sys、木马DoublePulsar【D22】等所采用的方式就是Kernel APC注入，这种方式被普遍使用。但APC注入要注意以下问题：
- 时机问题：要求所注入进程已经创建了线程并且已经执行（主线程都是紧随进程创建的）
- 依赖线程状态：APC的执行依赖于所注入线程的状态：一般是从内核态切换回用户态时执行
- 必须与注入线程做同步，或者在所注入线程环境中插入APC，不然可能会注入至错误进程，另外与第三方驱动同时注入APC存在竞争及一致性问题，当然竞争窗口极小; 每个线程均有两个APC队列，当线程在内核态下调用KeAttachProcess时会做切换，切换过程中没有任何保护
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 参考资料
3.1 浏览器自身防护资讯
B1: About Google Chrome's incompatible applications warning
B2: Firefox will block DLL Injections
B3: Protecting Microsoft Edge against binary injection
3.2 进程DLL注入资料
D1: DLL Injection with SetThreadContext
D2: R3 DLL Injection: Inject All The Things
D3: COUNTERCEPT: Analyzing the DOUBLEPULSAR Kernel DLL Injection Technique
D4: COUNTERCEPT: Dynamic Shellcode Execution
D5: Ten Process Injection Techniques
D6: DLL Injector via Windows Automation API
D7: Microsoft: AppInit DLLs and Secure Boot
D8: BlackHat: Malicious Application Compatibility Shims
D9: To SDB, Or Not To SDB: FIN7 Leveraging Shim Databases for Persistence
D10: FreeBuf: 走近微软安全技术Shim
D11: ABICC: Windows API/ABI Changes Analysis
D12: MITRE ATT&CK: Application Shimming
D13: FireEye: The Real Shim Shady
D14: iSIGHTPARTNERS: 固守: 微软Fix It补丁机制原理及攻击利用
D15: 腾讯：木马牟利再出新招-恶意利用Windows shim技术锁主页
D16: 腾讯：Haiheiwang木马分析
D17: Windows Vista APC Internals
D18: TDL: Turla Driver Loader
D19: Scylla and API Set Map
D20: Microsoft Docs: Windows API Sets
D21: Windows_7_Kernel_Changes: api-ms-win-core DLLs
D22: DOUBLEPULSAR Kernel DLL Injection Technique
D23: DOUBLEPULSAR: Generic Reflective DLL Loader
D24: MalwareFox AntiMalware 2.74.0.150 - LPE
D25：DLL Injection via SetDLLDirectory
D26: CodeProject: Create your Proxy DLLs automatically
D27: Proxy WS2_32.DLL to create your own firewall
D28: CodeProject: API hooking revealed
3.3 DLL注入商业方案
D30: Shellter Pro: DLL Injection Kit
D31: madCodeHook: DLL Injection Kit
3.4 开源HOOK引擎
H1: Microsoft Detours
H2: Detours NT
H3: minhook
H4: mhook
H5: EasyHook
H6: Deviare Hook Engine
3.5 Instrumentation Callback
I1: 利用KPROCESS结构的InstrumentationCallback域实现Hook
I2: Hooking-via-InstrumentationCallback
I3: Alex Ionescu: Hooking Nirvana
3.6 PPL (Protected Process Light)
P1: Injecting Code into Windows Protected Processes using COM - Part 1
P2: Injecting Code into Windows Protected Processes using COM - Part 2
P3: The Evolution of Protected Processes Part 1: Pass-the-Hash Mitigations in Windows 8.1
P4: The Evolution of Protected Processes Part 2: Exploit/Jailbreak Mitigations, Unkillable Processes and Protected Services
P5: Protected Processes Part 3 : Windows PKI Internals (Signing Levels, Scenarios, Root Keys, EKUs & Runtime Signers)
P6: Protected Processes Light killer
P7: Why Protected Processes Are A Bad Idea
P8: Micorosft: Protecting Anti-Malware Services
P9: Microsoft: Early launch antimalware
P10: Microsoft Virus Initiative
P11: Early Launch Anti-Malware Driver
3.7 WSL (Windows Subsystem for Linux)
W1: The Linux kernel hidden inside Windows 10
W2: Fun with the Windows Subsystem for Linux (WSL/LXSS)
W3: Hunting for Windows Subsystem for Linux
W4: Exploring Windows Subsystem for Linux
W5: Windows 10 and the Anti-malware Ecosystem
W6: Pico Process Overview
W7: WSL System Calls
--- END ---
直接映射方式其实是组相联映射的一种特例，亦称作是单路组相联。
L2及LLC，以及早期的CPU的L1均是使用PIPT的方式，这是因为内存的物理地址是唯一的，这就大大简单化PIPT的实现逻辑。
