不可思议的PowerShell – 红色团队的克服简单AppLocker策略的故事

[youziku id=e6c5f417d93c40f69e9bd3c7ccce7e01]

大多数防御者或系统管理员,攻击者已经演变成爱PowerShell。像Powersploit,Veil Power *和Nishang这样的工具已经成为Red Teams,Pentesters,Evil attackers,and skiddies一样的常规功能。随着这种演进和技术整合到一个单一的脚本语言中,捍卫者们肯定已经找到了一种可以预防PowerShell执行的方法。当然软件限制策略(SRP)还是AppLocker可以节省一天?不要那么肯定…

评估后评估,我发现我们可以妥协域用户,提升本地权限,窃取凭据,注入有效负载,并在域中升级所有使用PowerShell。我有一天有恶梦,有人有效地限制了PowerShell,一些旧的学校策略必须返回。从与捍卫者或信息通讯的谈话中,这些技术的意识越来越高,人们终于开始关注PowerShell工具的例行发布来帮助进攻。据说,直到在不需要的系统上禁用PowerShell才成为商业企业的普遍做法,攻击者仍然会有一个简单的赢家。在这一点上,PowerShell的限制是不可能发生的,直到实施这种防御措施所需的时间/成本被最小化到可以在现实中实现的规模化的程度。

对于以前的研究攻击者使用PowerShell:

在捍卫者的话 – “使用Applocker”

免责声明:这不是一个AppLocker的指南。后来你会看到,这是一个什么不做的指南!此外,我不是Microsoft认证系统工程师(MSCE)或任何微软专业人士。可能有办法正确配置AppLocker来防止PowerShell …但是如果它们存在,它们不会被广泛宣传!我像平均网络防守者一样上网。

AppLocker是Microsoft的“企业应用程序控制”解决方案。它旨在限制不需要的软件被执行,并提供各种方法来实现此目的。它允许您指定通过路径,散列或发布者限制可执行文件,DLL,安装程序或脚本的策略。然后由组策略推出生成的策略,并集中管理。

显然,可用性和安全性之间经常传播平衡,但我发现重要的是要提到AppLocker最好的设置可以利用白名单的方法。组织可以分析他们的标准图像并构建政策以匹配此图像。据说,CEO不能安装他们的P2P软件,用户将无法运行魔兽世界,技术支持将增加呼叫量的3000%(真诚希望永远不会帮助桌子…但我确实很感激他们所做的工作!)。因此,组织仍然依赖基于黑名单的策略来阻止使用net * .exe,cmd.exe和powershell.exe。

为了我的演示的目的,我打算模仿一个以黑名单方式使用AppLocker的组织。我的目标是尽可能多地使用AppLocker来阻止PowerShell,并测试适当的措施来绕开黑名单。

我用Windows 7系统进行了测试。我执行了以下操作来尝试设置和保护我的测试机器:

  • 启动应用程序身份服务
  • 添加可执行规则以通过哈希以下可执行文件来拒绝:
    • C:\ WINDOWS \ SYSTEM32 \ WindowsPowerShellv1.0 \ powershell.exe
    • C:\ WINDOWS \ SYSTEM32 \ WindowsPowerShellv1.0 \ powershell_ise.exe
    • C:\ WINDOWS \ SYSWOW64 \ WindowsPowerShellv1.0 \ powershell.exe
    • C:\ WINDOWS \ SYSWOW64 \ WindowsPowerShellv1.0 \ powershell_ise.exe
  • 添加脚本规则以拒绝路径:* .ps1 *
  • 启用“强制执行”DLL规则(AppLocker->属性)
  • 添加DLL规则通过散列以下DLL来拒绝:
    • C:\ Program Files \ Reference Assemblies \ Microsoft \ WindowsPowerShellv1.0 \ Microsoft.PowerShell.Commands.Management.dll
    • C:\ Program Files \ Reference Assemblies \ Microsoft \ WindowsPowerShellv1.0 \ Microsoft.PowerShell.Commands.Utility.dll
    • C:\ Program Files \ Reference Assemblies \ Microsoft \ WindowsPowerShellv1.0 \ Microsoft.PowerShell.ConsoleHost.dll
    • C:\ Program Files \ Reference Assemblies \ Microsoft \ WindowsPowerShellv1.0 \ Microsoft.PowerShell.Security.dll
    • C:\ Program Files \ Reference Assemblies \ Microsoft \ WindowsPowerShellv1.0 \ System.Management.Automation.dll
  • 测试确保块工作!成功!

工作 – 锁定采摘AppLocker

我最近进入了进攻性PowerShell世界,并且在这一点上只提到了脚尖。我听说有几个人讨论关于PowerShell绕过AppLocker规则的方法。就个人而言,我给道具带来灵感和提示的正确方向。我也知道许多想法和初步研究发现这种技术来自黑手党和其他一些在进攻PowerShell社区。感谢那些来过的人铺平了道路。如果你有更好的方法,会很乐意听到

PowerShell通过.NET框架和Windows公共语言接口(CLI)提供后端访问。开发人员喜欢这个提供的可扩展性,许多在线例子如何使用这些功能来创建实用程序来做好sys-ad类型的事情。很少有人意识到相同的代码可用于将PowerShell打包为AppLocker限制的解决方法。

阅读这个关于如何在C#中调用PS脚本的信息。

首先,我必须配置我的项目并添加自动化程序集作为参考:

  • RC参考 – >添加参考
  • 浏览并选择:C:Program FilesReference AssembliesMicrosoftWindowsPowerShellv1.0System.Management.Automation.dll

为了从资源加载,我必须首先创建一个资源:

  • 打开Resources.resx
  • 添加字符串资源
  • 将字符串命名为“脚本”
  • 将值设置为“Get-Process”或您要执行的任何脚本

创建项目后,我实例化了我的Runspace并创建了将用于执行命令的流水线

// Init东西
Runspace runspace = RunspaceFactory.CreateRunspace();
runspace.Open();
RunspaceInvoke scriptInvoker = new RunspaceInvokerunspace);
管道管道= runspace.CreatePipeline();

接下来,我从资源部分提取PowerShell脚本并将其添加到管道中。这可以被更改为从互联网,加密字符串等读取PowerShell脚本。在目标环境中,对脚本进行模糊/加密以防止AV或HIPS在明文脚本上触发非常重要。我看到在磁盘脚本上得到一个红色团队抓住每一个,然后…。

//添加命令
string script = Properties.Resources.ResourceManager.GetString(“Script”);
pipeline.Commands.AddScript(脚本);

要从脚本中检索输出,我将“Out-String”命令添加到管道中,并获取返回对象。使用字符串构建器迭代这些对象以返回最终的输出字符串。

//为PS输出并调用PS
pipeline.Commands.Add OUT-字符串”);
收集结果= pipeline.Invoke();
runspace.Close();

//将记录转换为字符串
StringBuilder stringBuilder = new StringBuilder();
foreach(结果中的PSObject对象)
{
    stringBuilder.AppendLineobj.ToString());
}
Console.WritestringBuilder.ToString());

编译这个可执行文件并将其投入到测试环境中可以取得令人瞩目的成功。尽管运行PowerShell的所有预防措施,我们的可执行文件能够访问API并运行我们选择的任何脚本。我用Veil-PowerView测试了它。C#的20行显示了一个很基本的概念证明。这个旁路有一些明显的缺点

  • 磁盘上的攻击能力(尽管脚本可以从互联网获取)
  • 托管代码,即.NET很容易被反编译
  • 白名单环境打败了这个

打败解决方法

这太简单了…对.NET的沉重依赖让我有信心有一个简单的方法来阻止这一点。在我的测试环境中,我花了一些时间在Process Explorer和Process Monitor中挖掘恶意应用程序的转储。我确认自定义可执行文件正在加载.NET程序集以完成PowerShell的执行。用Microsoft的话来说,“Assemblies是.NET Framework的构建块”。基本上,程序集是构成CLI的库。在大多数情况下,程序集存储在C:WindowsAssembly中的全局程序集缓存(GAC)中。事实上,.NET在运行时会根据需要加载程序集,而不是在执行初始应用程序时。当我玩代码时,我可以看到装配体的加载点。以下是我看到的文件句柄的示例:

  • C:WindowsassemblyGAC_MSILMicrosoft.PowerShell.Commands.Diagnostics1.0.0.0__31bf3856ad364e35Microsoft.PowerShell.Commands.Diagnostics.dll
  • C:WindowsassemblyGAC_MSILSystem.Management.Automation1.0.0.0__31bf3856ad364e35System.Management.Automation.dll

快速回到AppLocker,我将所有PowerShell特定的程序集从GAC添加到deny策略中。要让AppLocker中的程序集DLL被阻止,并允许资源管理器访问后台程序集库,我必须禁用“缓存查看器”功能。如果你想拖放安装程序集,肯定要重新启用。快速指令FTW:

reg添加HKLMSoftwareMicrosoftFusion / v DisableCacheViewer / t REG_DWORD / d 1

由于某种原因,组委会拒绝政策仍未能否认我的恶意应用程序的执行。起初我以为这可能是由于DLL被隐藏在一个程序集中,但在测试之后,这被证明是假的。其他程序集DLL可能被阻止。有关更多信息,请参阅后续部分 可以通过AppLocker DLL规则成功防止执行的唯一DLL是:

C:WindowsMicrosoft.NETassemblyGAC_32System.Transactionsv4.0_4.0.0.0__b77a5c561934e089System.Transactions.dll

这阻止了我的恶意脚本的执行,但被阻止的DLL是负责所有事务类(也称为创建资源管理器的能力)的库。这是一个不合理的块,因为许多合法的.NET应用程序需要资源。最后,我转移到了明显的:重命名/移动PowerShell程序集。

mkdir c:windowsassemblydisabled
移动c:windowsassemblyGAC_MSILMicrosoft.PowerShell.Commands.Management1.0.0.0__31bf3856ad364e35Microsoft.PowerShell.Commands.Management.dll c:windowsassemblydisabled

显然这样做有效并且阻止了我的恶意应用的执行。在我看来,这是一个有限的解决方案,因为不得不安装/卸载程序集。具有可配置策略以使特定用户使用或在某些情况下使用,但防止标准用户使用是理想的选择。

*后续*(后贴)

最初发布之后,有几个人通过Twitter进行了讨论。在进一步推进之前,我必须指出,使用最好的政策是基于白名单的政策。黑名单只能被视为一个暂停的空白,并将被专门的攻击者克服。这篇文章是为了演示。据说,我很少甚至发现公司已经跳到任何一种AppLocker政策。

非常感谢Lee Holmes(@Lee_Holmes)和Carlos Perez(@Carlos_Perez)进行跟进和Twitter讨论。Lee Holmes挖了一下,发现为什么我无法在DLL黑名单模式下使PowerShell程序集成功。他使用AppLocker审核模式结合Windows事件日志来检测根据策略加载和阻止哪些DLL。这绝对有助于缩小您可以阻止的具体内容。经过一大堆玩这个方法,我可以证明它是有用的。

要将.NET程序集特别是PowerShell黑名单,您必须阻止程序集后面的所有相关的DLL。这包括GAC_MSIL和NativeImages中的DLL,如果它们都存在。要发现PowerShell程序集的DLL,可以在PowerShell中运行:[PSObject] .Assembly.Location。.NET程序集中还有几个不同的PowerShell依赖关系,所以请随意查看。使用这种方法,我能够阻止.NET导入所需的程序集DLL。

这是所有人…

我希望探讨这个项目的一些明显的工作:

  • 通过非托管代码执行/使用PowerShell API。可能有一种通过COM对象访问CLI的方法,允许您将PowerShell集成到现有的RAT和工具中,而无需使用PS可执行文件
  • 使用.NET程序集浏览和测试不同的AV / HIPS产品

希望这激起了一些讨论,并鼓励防守和进攻PowerShell社区深入挖掘。不要认为在单个可执行文件上的阻止列表或设置权限将阻止使用PowerShell语言。需要有一个有效和本地的能力来阻止或限制对手使用PowerShell。由于这是概念工作类型的证明,请让我知道如果您有更好的防御方法或者看到具体的软件,以防止PowerShell真的很好。

[/youziku]

评论

还没有任何评论,你来说两句吧

你必须 登录 才能发表评论.