如何利用COM绕过AppLocker CLM

阅读量    13864 |   稿费 160

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

一、前言

约束语言模式(Constrained Language Mode,CLM)是限制PowerShell的一种方法,可以限制PowerShell访问类似Add-Type之类的功能或者许多反射(reflective)方法(攻击者可以通过这些方法,在后续渗透工具中利用PowerShell运行时作为攻击媒介)。

结合微软的描述,这个功能通常可以作为一种安全控制方案,防御方能够利用该功能阻止运行类似Invoke-Mimikatz之类的工具,因为这些工具非常依赖于反射技术。

当我准备渗透部署了CLM的目标环境时,我需要快速了解有哪些潜在方法能够绕过这种保护措施。我搭建了一个Windows 10测试环境,通过默认设置的规则来部署CLM。在本文中,我会与大家分享我的研究结果,介绍如何以非管理员用户身份绕过这种保护机制。

 

二、进入正题

在测试环境中,我们要做的第一件事就是启用AppLocker。在本文中我们将使用Windows默认部署的规则来限制脚本执行。运行Application Identity服务后,我们可以使用如下命令确保本机已启用CLM:

$ExecutionContext.SessionState.LanguageMode

这里我们可以看到该命令的返回结果为ConstrainedLanguage,表明现在我们处于受限环境中。我们可以尝试使用PowerShell中的受限命令来验证这一点:

Add-Type "namespace test { }"

系统的确启用了CLM,那么我们如何才能绕过这个障碍?

 

三、AppLocker CLM中的New-Object

令人惊讶的是,当我开始搜寻CLM存在的攻击面时,我发现当通过AppLocker启用CLM时,New-Object依然可用(尽管仍受到一些限制)。这似乎与预期的场景不一致,但我们的确可以使用如下命令来确认这一点:

New-Object -ComObject WScript.Shell

这给我留下了一种完美方式,可以从PowerShell内部来操控PowerShell进程,这是因为COM对象由DLL托管,而DLL会被加载到调用进程中。那么我们如何才能创建可以被加载的COM对象?如果我们使用ProcMon工具来观察New-Object -ComObject xpntest的调用过程时,我们可以看到该过程会多次请求HKEY_CURRENT_USER注册表项:

仔细观察后,我们可以使用如下脚本来创建HKCU中所需的注册表键值:

现在如果尝试加载我们的COM对象,可以看到我们的DLL已被加载到PowerShell进程空间中:

非常好,现在我们已经可以在受限的上下文环境中,将任意DLL载入PowerShell进程中,无需调用动作太大的CreateRemoteThread或者WriteProcessMemory。但我们的目标是绕过CLM,如何利用我们的非托管(unmanaged)DLL加载方式来完成这个任务?我们可以利用.NET CLR,或者更确切一点,我们可以通过非托管DLL加载.NET CLR来调用.NET assembly(程序集)。

 

四、从非托管DLL到托管DLL到反射

现在我们可以使用类似Cobalt Strike之类的工具,该工具提供了Execute-Assembly功能,可以将CLR加载到非托管进程中,操作起来非常方便。之前我在GIST上公开了一份代码,可以不依赖Cobalt Strike来完成这个任务:

这里我不会讨论代码的详细内容(如果大家感兴趣可以去阅读微软的官方示例),该代码可以让DLL加载.NET CLR,然后加载.NET assembly,然后将执行权传递给特定的方法。

该过程完成后,我们就可以访问.NET,更重要的一点是,我们可以访问.NET的反射功能。接下来我们需要找到启用/关闭CLM的具体位置。

反汇编组成PowerShell的.NET assembly(即System.Management.Automation.dll)后,我们可以看到程序集的System.Management.Automation.Runspaces.RunspaceBase.LanguageMode属性中有一个地方可以标识当前的语言模式。由于我们要使用反射技术,因此需要找到引用Runspace的变量,在运行时修改该变量。我发现要完成该任务,最好的办法就是通过Runspaces.Runspace.DefaultRunspace.SessionStateProxy.LanguageMode,如下所示:

将代码编译成.NET assembly,现在我们就可以通过反射方式禁用CLM,然后只需要创建一个PowerShell脚本加以运行即可:

这样就能大功告成,详细过程可参考演示视频

 

五、背后原理

那么为什么COM可以绕过这种保护机制,PowerShell如何处理COM加载过程?

我们可以在SystemPolicy.IsClassInApprovedList方法中找到答案,该方法用来检查是否允许我们向New-Object提供的CLSID。深入分析该方法,我们可以看到主要工作由如下关键代码负责:

if (SystemPolicy.WldpNativeMethods.WldpIsClassInApprovedList(ref clsid, ref wldp_HOST_INFORMATION, ref num, 0u) >= 0 && num == 1) { ... }

该调用只是WldpIsClassInApprovedList函数(位于wldp.dll中)的一个封装函数,而后者用来检查CLSID是否匹配DeviceGuard(现在为Windows Defender Application Control)策略。由于该方法没有考虑到AppLocker,这意味着通过检查的任何CLSID都可以畅行无阻。

 

六、奇怪的场景

结合前面分析,当我测试这种技术时,我陷入了一个奇怪的场景,当我们使用如下方法设置CLM时,这种技术将无法正常工作:

$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"

这让我有点困惑,因为之前我经常使用如上命令来测试载荷,此时我们面临的环境又有什么不同呢?回到我们的反汇编代码上,我们可以在Microsoft.Powershell.Commands.Utility.dll程序集中找到问题的答案,具体路径位于NewObjectCommand类的BeginProcessing方法中:

这里我们可以看到代码中存在2条路径,具体取决于CLM的启用方式。如果SystemPolicy.GetSystemLockdownPolicy返回Enfore,那么就会执行第1条路径,此时AppLocker或者DeviceGuard处于启用状态(并非我们使用ExecutionContext.SessionState.LanguageMode的场景)。如果直接设置这个属性,我们会直接进入if (!flag)…代码段,此时就会抛出异常。从这里我们可以看到,CLM的行为实际上会根据具体的启用方法(是通过AppLocker、DeviceGuard启用还是通过LanguageMode属性来启用)而有所不同。

本文介绍的方法并不是绕过CLM的唯一方法,即使粗略分析PowerShell,我们也能找到实现类似效果的其他潜在方法。如果大家想了解其他技巧,可以参考Oddvar Moe在Debycon上的精彩演讲

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多