检测SyscallNumber的新方法 _信息快讯

为在成熟环境中运行而设计的 Post-exploitation 工具经常需要绕过在目标上运行的终端检测和响应 ( EDR ) 软件。 EDR 经常通过挂钩 Windows API 函数进行操作，尤其是那些由 ntdll 导出的函数（特别是基于 Nt/Zw* ( ) 系统调用的 API 函数）。由于在正常情况下与底层操作系统的所有交互都将通过这些函数，这样在检测不需要的应用程序行为时就提供了一个理想的拦截点。

文章插图
上面函数 LdrpDetectDetour ( ) 的伪代码本质上是检查 5 个本机 API 函数 NtOpenFile ( ) ， NtCreateSection ( ) ， ZwQueryAttributeFile ( ) ，ZwOpenSection ( ) 和 ZwMapViewOfFile ( ) ，并确定这些字节是否已经从存储在 ntdll 中的 LdrpThunkSignature 数组中已知的正确字节被修改。
通过对 LdrpDetectDetour ( ) 函数的快速反汇编确认上述伪代码中描述的行为仍然存在，但应该提到的是，该函数现在额外地验证了另外 27 个本机 API 的完整性，但仍然只是比较了详细的 5 个函数的精确的系统调用存根。
用 IDA Pro 检查 ntdll 发现 LdrpDetectDetour ( ) 函数是从两个地方调用的：LdrpLoadDllInternal ( ) （直接从 LdrpLoadDll ( ) 调用）和 LdrpEnableParallelLoading ( ) （在 LdrpInitializeProcess ( ) 的后期调用）。由于 LdrpDetectDetour ( ) 函数配置了一个全局变量，该变量可以停止并行加载并强制进一步加载同步发生，并且许多安装了 detours 的 DLL（例如 EDR 用户空间组件）在加载到进程时立即执行此操作，它在加载每个新的 DLL 依赖项时重复调用 detour 检测函数是有意义的。
然而，对这一过程的研究又引发了另一个问题，已知的 5 个本机 API 函数的已知良好存根从何而来？最初以为系统调用存根将在代码生成期间的编译时被硬编码，但是静态检查 LdrpThunkSignature 数组表明情况并非如此，因为在映射 ntdll 之前数组没有初始化，原因是数组驻留在未初始化的 .data 中部分。
【检测SyscallNumber的新方法】LdrpThunkSignature 标识的数据交叉引用了另一个数组的使用 , 在 LdrpCaptureCriticalThunks ( ) , 这个函数反过来调用早期 LdrpInitializeProcess ( ) 之前进口依赖加载，因此第三方模块安装的 detours 可能已加载到进程中。
快速手动反编译 LdrpCaptureCriticalThunks ( ) 会显示类似于以下伪代码的实现：

文章插图
从上面可以清楚地看到，LdrpCaptureCriticalThunks ( ) 将五个关键函数的每个系统调用存根的前 16 个字节从每个函数中复制到 LdrpThunkSignature 数组中。
从 LdrpThunkSignature 中恢复系统调用
具有 post-exploitation 工具开发经验的读者无疑会收获颇多，有了这五个关键函数和它们的 Syscall Number（直接从 LdrpThunkSignature 读取）的知识，我们有足够的本机 API 函数能够使用系统调用从磁盘读取 ntdll 的新副本。
由于 LdrpThunkSignature 数组不是由 ntdll 导出的，我们需要在 ntdll .data 节中找到它。该数组可以通过公共系统调用序言的出现被识别出来：

文章插图
下面的代码能够使用这个信息来恢复所需的系统调用（MDSec 提供的用于恢复所有系统调用代码段）：

文章插图
可以在 MDSec ActiveBreach GitHub 存储库中找到使用上述方法从磁盘读取 ntdll 来恢复所有系统调用的实现。
这个实现当然是一个 PoC，从 opsec 的角度来看并不是最优的，例如，系统调用存根是用使用 VirtualAlloc ( ) 创建的 RWX 内存分配的。

特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。