原文:https://www.mdsec.co.uk/2018/09/applocker-clm-bypass-via-com/

约束语言模式是一种用来限制PowerShell访问权限的方法,不仅可以用来禁止访问诸如Add-Type之类得功能,还能禁止其访问可用于利用PowerShell运行时来启动post-exploitation工具的各种反射方法。

尽管微软可能会声称,这个特性在很大程度上被用作一种安全控制措施,能够让防御者使“Invoke-Mimikatz”等工具无法运行,因为它们严重依赖于反射型技术。

当将要在强制执行约束语言模式的环境中执行任务时,我会设法寻找绕过该保护措施的方法。为此,我启动了一个Windows 10实例,并通过默认规则集配置了CLM。在这篇文章中,我们将为读者详细展示这项研究的结果,以及作为非管理员用户绕过该保护措施的方法。

出发吧…


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

$ExecutionContext.SessionState.LanguageMode

在这里,我们应该看到返回ConstrainedLanguage的值,表明我们现在处于受限制的环境中。为了进一步确认这一点,我们可以尝试使用PowerShell中的受限命令执行一项简单的任务,看看系统有什么反应:

Add-Type "namespace test { }"

很好,现在CLM已经启用了,接下来,我们要做的事情就是设法绕过它?

AppLocker CLM中的新对象......管用吗?


令人惊讶的是,当我考察CLM的攻击面时,我惊奇地发现,当通过AppLocker启用CLM时,New-Object是可以正常工作的(尽管有一些限制)。这似乎与预期的目标不一致,可实践证明,以下命令确实能够运行:

New-Object -ComObject WScript.Shell

毫无疑问,这为我们提供了一种在PowerShell中操作PowerShell进程的完美方式,因为COM对象完全可以通过DLL加载到调用进程中。那么,我们怎样才能创建一个可以加载的COM对象呢?好吧,如果我们在尝试调用New-Object-ComObject xpntest时查看ProcMon,就会发现针对HKEY_CURRENT_USER的请求有许多:

经过一番折腾后发现,我们可以使用以下脚本在HKCU中创建所需的注册表项:

现在,如果尝试加载COM对象,就会看到我们的自定义的DLL将被加载到PowerShell进程空间中:

太棒了,我们现在可以将任意的DLL加载到PowerShell中,而不用求助于“动静太大”的CreateRemoteThread或WriteProcessMemory调用,并且,所有这些都是在受限的上下文中进行的。但是,如果禁用了约束语言模式,我们如何通过非托管DLL加载方法来实现这一点呢?实际上,我们可以利用.NET CLR,或者确切地说,我们利用非托管DLL来加载.NET CLR,从而帮助调用.NET程序集......

从非托管DLL到托管DLL再到反射


现在,人们认为将CLR加载到非托管进程中是理所当然的,比如,Cobalt Strike就提供了Execute-Assembly等工具来简化这一过程。我之前已经分享过如何在不借助Cobalt Strike的情况下,实现相同技术的相关要点:

当然,我们不会在这里讨论这段代码的内部机制(如果读者有兴趣的话,建议阅读微软的相关文章),但最终结果是,DLL将加载.NET CLR,然后是.NET程序集,并且将执行流程传给指定的方法。

完成上述操作后,现在就可以访问.NET了,更重要的是,还能使用.NET的反射功能。接下来,我们需要弄清楚CLM的开/关“机关”在哪里。

通过对PowerShell、System.Management.Automation.dll的.NET程序集进行反汇编处理,我们发现其中一个用于标识语言模式的地方,即属性System.Management.Automation.Runspaces.RunspaceBase.LanguageMode。由于我们将使用反射技术,所以,我们需要通过一个变量找到对Runspace的引用,当然,这个变量必须是在运行时可以受我们控制的。我发现完成这些任务的最好方式,是借助于Runspaces.Runspace.DefaultRunspace.SessionStateProxy.LanguageMode,例如:

将其编译为.NET程序集后,我们就可以通过反射方法来禁用CLM了。这样一来,剩下的事情就是创建一个PowerShell脚本来处理相应的事项了:

好了,我们来看一段视频:

https://youtu.be/ghi2M80fiMU

为什么会这样呢?


那么,为什么COM能够绕过这项保护措施,同时,PowerShell又是如何处理COM加载的呢?

答案可以在SystemPolicy.IsClassInApprovedList方法中找到,该方法用于检查我们是否允许向New-Object提供的CLSID。当我们深入研究这种方法时,会发现大部分工作都是由以下代码完成的:

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

该调用只是wldp.dll公开的WldpIsClassInApprovedList函数的包装器,它用于根据DeviceGuard策略(或现在已知的Windows Defender Application Control)来检查CLSID。由于该方法不适用于AppLocker,这就意味着任何CLSID都能通过检查。

怪哉??!!


因此,在测试这种技术时,我遇到了一个奇怪的情况:通过以下方法设置CLM时,该技术将失效:

$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"

这个问题困扰了我一段时间,因为我过去曾使用上面的方法测试过有效载荷,那有,区别在哪呢?回到我们的反汇编代码,最终在程序集Microsoft.Powershell.Commands.Utility.dll中找到了答案,准确的说是NewObjectCommand类的BeginProcessing方法:

在这里,我们可以看到实际上有两个代码路径,走哪条路径具体取决于CLM的启用方式。如果SystemPolicy.GetSystemLockdownPolicy返回Enforce,则会采用第一个代码路径,这是启用AppLocker或DeviceGuard时的情况,但是,如果直接设置ExecutionContext.SessionState.LanguageMode属性的话,情况就不同了。如果直接设置该属性,我们就会直接进入if(!flag)...代码块,这时,它会抛出异常。由此得出的结论是,CLM的反应实际上会略有不同,具体取决于它是通过AppLocker、DeviceGuard还是通过LanguageMode属性启用的。

当然,这绝不是绕过CLM的唯一方法,因为即使粗略地看一下PowerShell也会发现,还有许多潜在的路径可以实现类似的效果。需要推荐的是,Oddvar Moe是这方面的专家,读者可以通过他的Derbycon演讲来了解更多的高超技巧!

点击收藏 | 2 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖