绕过基于签名的 AV

反病毒引擎使用两种检测方法来识别恶意代码——基于签名的检测和基于行为的检测。

基于行为的检测

基于行为的检测涉及分析代码在执行时的行为，并确定该行为是否表示恶意行为。行为检测的示例是识别进程空心化的使用或CreateRemoteThreadDLL 注入的使用。

基于签名的检测

基于签名的检测涉及寻找与已知错误代码匹配的静态签名。基于签名的检测示例包括将文件哈希与已知恶意软件匹配以及匹配潜在恶意软件中的字符串。众所周知，许多 AV 供应商将有效负载标记为恶意软件，因为@harmj0y 出现在文件中的某个位置。在此博客中，我们将通过修改 Mimikatz 源代码来规避基于签名的检测来规避 Windows Defender。

跳动检测 - 级别 1：文本替换

基于签名的检测很脆弱，因为它依赖于匹配被扫描对象内的特定签名——通常是文本字符串。因此，如果我们修改我们的有效负载，从而不再找到相关的签名，我们可以逃避基于签名的检测。一个众所周知的例子是将 Mimikatz 更改为 Mimidogz。我遇到过仅仅因为 Will Schroeder 的 Twitter 句柄@harmj0y出现在 PowerShell 脚本中而发出警报的 AV 产品。

既然我们知道什么是基于签名的检测，那么我们如何确定哪些特定签名导致 Windows Defender 将我们的有效负载识别为恶意？Matt Hand ( @matterpreter ) 创建了DefenderCheck以帮助准确识别有效负载中的哪些字节导致 Defender 将有效负载标记为恶意。

我下载了Mimikatz 源代码，并使用 Microsoft 的Visual Studio 2019进行编译。在开始编译之前，您需要进行一些修改。在解决方案资源管理器中，右键单击 mimikatz，然后单击属性。您需要更改默认的 Platform Toolset 选项。在撰写本文时，我将我的设置为“Visual Studio 2019 (v142)”。对 mimilib 解决方案也重复此过程。

我没有花时间深入研究为什么需要这样做，但是 mimikatz/common modules/rpc/kull_m_rpc_ms-rprn.h 的第 7 行导致了构建错误。删除此行后，我能够毫无问题地构建。请注意，这是一个超级笨拙的黑客攻击，在尝试从远程计算机转储时可能会导致问题。

编译源代码后，我使用 DefenderCheck 来查看二进制文件是否被检测为恶意。这并不奇怪，因为HackTool:Win64/Mikatz!dha.DefenderCheck 返回导致 Defender 在有效负载上发出警报的字节的十六进制转储，所以检测到它。在下面的屏幕截图中，我们可以看到检测发生在二进制文件中包含的错误消息字符串中。特定的字符串似乎是mimikatz_doLocal.

我有根据地猜测是mimikatz字符串中的存在导致了检测，所以我执行了搜索和替换以替换所有实例mimikatz并mimidogz重新编译二进制文件。这些类型的字符串不再有问题！

跳动检测 - 级别 2：DLL 名称

我通过 DefenderCheck 运行了新的二进制文件，发现了一个新问题。这次违规签名似乎wdigest.dll如下所示：

我在源代码中搜索wdigest.dll，发现它出现在两个文件中：

花了一段时间才确切地找到在这里逃避检测所需的东西。Wdigest.dll出现在 DLL 列表中。我尝试重新排序该列表，但每次尝试仍然导致检测。下一步是了解如何使用该 DLL 列表。我们可以在这里看到 DLL 列表是数组的一部分，version_libs[].

再深入一点，我们可以看到 DLLversion_libs被传递给GetFileVersionInfoSize和GetFileVersionInfo。查看 GetFileVersionInfo 的详细信息，我们发现如果没有指定要查询的文件的完整路径，则使用LoadLibrary搜索序列。具体来说，如果省略文件扩展名，该函数会将.dll和附加.exe到文件名中。最后，绕过这个特定签名所需要做的就是删除.dllfrom wdigest.dll！

跳动检测 - 第 3 级：函数名称

让二进制文件与最新版本的 Defender 一起工作需要许多其他更改。这包括更改以下字符串的实例：kull, kuhl, kiwi, sekurlsa, logonpasswords, credman.

也许最有趣的签名是用于以下函数：I_NetServerAuthenticate2、I_NetServerReqChallenge和I_NetServerTrustPasswordsGet。这些功能是netapi32.dll. 该库的精简版本包含在 mimikatz/lib 目录中，为netapi32.min.lib. 经过一番搜索，我找到了一个讨论绕过这个特定检测的博客。首先，我需要创建一个.def文件，用于构建一个新的库模块，该模块将包含在 Mimikatz 构建过程中。该文件的内容如下所示。以下是正在发生的事情：一个库 (DLL) 可能会导出一个或多个可供其他程序使用的函数。这些函数通常按名称调用，例如I_NetServerAuthenticate2fromnetapi32.dll.但是，也可以通过它们的名称调用这些函数ordinal– 表示功能的数字。

库 netapi32.dll

         出口

                   I_NetServerAuthenticate2 @ 59

                   I_NetServerReqChallenge @ 65

                   I_NetServerTrustPasswordsGet @ 62

我需要.def使用 Visual Studio 开发者控制台和以下命令将此文件编译成一个模块：lib /DEF:netapi32.def /OUT:netapi32.min.lib. 构建后netapi32.min.lib,，我将文件放在 libx64 目录中，替换原始文件。重建后，mimikatz 不再包含来自netapi32.dll.

DefenderCheck 的最终检查表明该文件不再被检测为恶意文件。

最后的测试

是时候看看所有这些辛勤工作是否会得到回报。如您所见，我能够在不触发 Defender 的情况下执行 Mimikatz 并提取凭据。屏幕截图中可以看到一些所需的修改，包括mimidogz, securelsa,和loginpasswords.

其他AV呢？

同样的技术可以用于任何你想在运行 Defender 的系统上执行的负载。事实上，您只需多做一点工作即可针对任何 AV 进行此操作。PowerSploit 的Find-AVSignature.ps1可以帮助自动化该过程，但基本方法是二叉树式搜索。这个过程可能很耗时，即使您通过了基于签名的检测，您也可能被行为分析捕获。但是，在许多情况下，您的努力将得到代码执行的回报。请记住，由于 AV 供应商会不断更新他们的签名，因此周五下午有效的方法可能无法在您需要的周一早上有效。