为什么我的LoadLibraryA ( LLA )挂钩不能阻止使用CreateRemoteThread +LLA的dll注入？

Question

根据这个答案的说法，通过CreateRemoteThread和LoadLibraryA一起注入DLL可以通过挂钩LoadLibraryA来防止。我努力的完成了进攻和防守两个方面的实际执行。我使用这文章作为创建这两个应用程序的基线。

防御方成功地钩住LoadLibraryA并用一个虚拟函数替换它。每当防御进程调用LoadLibraryA时，都会调用虚拟函数。

但是，为什么在防御进程中创建远程线程之后，攻击进程仍然能够调用原始的LoadLibraryA？

就好像它没有通过IAT访问它一样。否则它不会被转发到虚拟函数中吗？

Answer 1

听起来，您可能已经弄清楚了到底发生了什么(不过，我必须查看所讨论的代码，最好是在调试器中运行)。然而，我想指出的是，这实际上根本行不通。充其量，这是一个速度碰撞，将打破脆弱的有效载荷，但一个知识渊博的攻击者可以轻易绕过它。这里有几种方法，在大致上增加了复杂性：

• 使用不同的函数，如LoadLibraryW或LoadLibraryExA (除非在某个时候内部调用LLA，但我对此表示怀疑)。
• 使用WriteProcessMemory (WPM)和VirtualProtectEx (VPX)以攻击者版本的函数作为模板，使用un LLA。
• 使用WPM VirtualAllocEx将LLA的二进制代码写入目标进程，并在该入口点注入线程。
• 只需转储任何您想要注入到目标地址空间的DLL的有效负载，然后输入它。
• 做所有LLA所做的事情(包括确保新线程调用库的DllMain)，但远程到目标进程，甚至在其中生成一个线程。

换句话说，即使您的钩子阻止将CreateRemoteThread调用到LLA的地址，通常它也不会对DLL注入做任何重要的操作。

Answer 2

我睡了一夜，找到了答案。有两个原因：

攻击模块使用LoadLibraryA查找GetProcAddress地址。这是基于这样的假设，即两个进程之间的地址是相同的，这恰好是kernel32.dll中函数的情况。但是，由于只有防御进程的IAT是连接的，攻击模块的IAT仍然具有原始LoadLibraryA调用的地址。

但除此之外，我还在我的防御模块中测试了GetProcAddress的行为，它在连接LoadLibraryA之前和之后都返回相同的地址。从这一点我只能推断出GetProcAddress的实现方式，它除了搜索IAT之外还有其他的方法。