如需查看最新版本的 Dent 或提交问题，请参考 https://github.com/Tylous/Dent。
Dent
如果您想了解更多关于本框架所利用的技术，请参阅此文章。
此框架生成代码，用于利用 Microsoft Defender 高级威胁防护的攻击面减少（ASR）规则中的漏洞，以在不被检测或阻止的情况下执行 shellcode。ASR 被设计为第一道防线，通过检测违反一组规则的事件来发现威胁。这些规则专注于终端上通常与攻击者的策略、技术或程序（TTP）相关的特定行为指标。这些规则重点关注 Microsoft Office 套件，因为这是建立远程终端立足点的常见攻击向量。许多基于规则的控制侧重于与正常业务操作不同的基于网络或基于进程的行为指标。这些规则要么针对系统的初始入侵，要么针对可能严重影响组织的技术（例如，凭据泄露或勒索软件）。它们覆盖了大部分常见的攻击面，并侧重于阻碍用于危害资产的已知技术。
Dent 利用多个漏洞绕过这些限制性控制，从而在终端上执行有效载荷，而不会被 Microsoft Defender 高级威胁防护传感器阻止或有效检测。上述文章描述了这些漏洞，即使在披露后，这些漏洞仍然存在于 Microsoft Defender 高级威胁防护中。
第一步一如既往地是克隆仓库，然后构建它。
go build Dent.go
./Dent -h
________ __
\______ \ ____ _____/ |_
| | \_/ __ \ / \ __\
| | \ ___/| | \ |
/_______ /\___ >___| /__|
\/ \/ \/
(@Tyl0us)
“长时间称某人为英雄，他们会相信。他们会成为英雄。
他们别无选择。让他们称你为怪物，你就会成为怪物。”
./Dent 的使用方法：
-C 字符串
COM 对象的名称。
-N 字符串
XLL 有效载荷写入磁盘时的名称。
-O 字符串
输出文件的名称。（默认值："output.txt"）
-P 字符串
COM 对象的 DLL 路径。（请使用 \\ 或使用引号包裹路径）
-U 字符串
托管 Base64 编码的 XLL 有效载荷的 URL。
-show
在终端中显示脚本。
此框架旨在利用 Microsoft Defender 高级威胁防护中的漏洞和缺陷，因此它实际上并不生成任何有效载荷/植入程序。要生成这些内容，您可以使用大量公开可用的工具，但所有研究、开发和测试均使用 ScareCrow 完成。Microsoft Defender 高级威胁防护不依赖用户态钩子进行遥测，而是利用各种其他机制，如内核回调。根据测试，此框架在绕过 Microsoft Defender 高级威胁防护以执行 shellcode 方面表现极为出色。
发布时有两种技术。我会定期添加利用这些漏洞的不同技术，敬请期待更多内容。
在将应用程序安装到系统上时，通常会创建 COM 对象。一旦创建，任何应用程序或脚本都可以调用它们，但这并非创建它们的唯一方式。通过修改/创建 Windows 注册表中 HKEY_CLASSES_ROOT 部分的注册表项，我们可以创建一个指向系统上我们的 shellcode 的 COM 对象。这意味着任何能够利用 COM 的应用程序或脚本都可以调用它，从而执行 shellcode。
这之所以有效，是因为 CoCreateInstance API 函数的工作方式。CoCreateInstance 用于根据 CLSID（一个用于标识特定 COM 类对象的全局唯一标识符）创建并初始化 COM 对象。此函数从存储在注册表项中的值中提取信息以执行调用。这些 CLSID 值可以在注册表的 HKEY_CLASSES_ROOT\CLSID\ 路径下找到。然而，在一个进程调用 CLSID 之前，它必须知道该 CLSID 的值。这是通过首先在 HKEY_CLASSES_ROOT\<COM 对象名称> 中执行注册表查询来查找 COM 对象，如果存在，则会在子文件夹中执行第二次注册表查询以获取存储的 CLSID 值。
进一步检查注册表子文件夹的权限会发现，CLSID 值的权限并不一致。此处存储的绝大多数 COM 对象仅允许“完全控制”权限给 Trusted Installer。Trusted Installer 是一个服务帐户，拥有资源以保护它们，甚至对管理员也是如此。这是为了确保即使攻击者获得管理员权限，也无法恶意篡改资源。不幸的是，许多 COM 对象允许 Administrators 组拥有“完全控制”权限。此外，根键 CLSID 允许 Administrators 组拥有“完全控制”权限，而不是 NT AUTHORITY\System 或 Trusted Installer。因此，在提升的上下文中，我们可以创建甚至修改特定的 COM 对象值。
重要
这些注册表项的创建只有在提升的上下文中运行才有效。通过 GUI 双击不会在提升的上下文中执行 .VBS 文件，即使您以管理员身份登录。建议您从管理 shell 或命令提示符中运行它。然而，一旦创建了这些项，任何应用程序都可以在任何上下文下调用此 COM 对象。
要利用此绕过方式使用 ScareCrow 有效载荷，您可以运行以下命令：
./ScareCrow -I <您的原始无阶段 shellcode 路径> -domain <域名> -Loader dll
一旦您获得有效载荷，请使用 -N 标志指定写入磁盘时的有效载荷名称，-C 标志指定 COM 对象的名称，-I 标志指定写入位置，最后使用 -O 标志指定输出文件以存储内容。
此选项生成一段代码，用于绕过多个 ASR 规则以下载、写入磁盘、加载并执行 shellcode，从而绕过 ASR 预防控制。这是通过使用 Excel.Application COM 对象实现的，该对象代表整个 Excel 应用程序，但以自动化形式存在，并允许与其进行编程交互。因为仍然是 Excel，所以不会触发 ASR 规则。这是因为当我们调用 Excel.Application 时，可以看到它在服务主机进程（Svchost.exe）下生成，而不是 WinWord.exe 进程。虽然 Svchost.exe 是用于托管多个基于 Windows 服务的系统级进程，但创建的子进程（Excel.exe）并未获得系统级权限。
因为我们创建了一个 COM 对象，该对象是一个完整的应用程序，所以 Excel 进程在 Svchost.exe 下创建，以便得到正确处理，防止对 WinWord.exe 进程造成不稳定。尽管此进程在 Svchost.exe 下，但还有另一个挑战需要应对：执行 shellcode。因为在宏内部执行二进制文件或使用 WinAPI 会触发其他 ASR 规则，这限制了我们在不触发 ASR 规则或被 WDAPT 的 EDR 组件检测到的情况下能做什么。这时 DLL 就发挥了作用。如果基于 DLL 的有效载荷使用正确的导出函数编译，它可以作为 Office 插件使用，加载时会自动运行 shellcode。为此，我们可以利用 Excel 的 RegisterXLL 函数。RegisterXLL 函数将 XLL 插件加载到内存中，自动注册并执行它。XLL 文件本质上是基于 Excel 的 DLL。
要获取系统上的内容，我们可以使用另一个 COM 对象（Microsoft.XMLHTTP），从而获得执行 HTTP 请求的能力，在本例中，是向 URL 发送 HTTP GET 请求。第二个 COM 对象（ADODB.stream）提供了读取/写入数据流字节的能力。通过组合这两个 COM 对象，攻击者可以通过 HTTP GET 请求请求远程资源，并将响应（在本例中，文件本身）写入磁盘。这是再次使用 COM 对象（ADODB.stream）处理数据流的读/写字节。第二个 COM 对象（Microsoft.XMLDOM）允许读取存储在文件中的数据。XMLDOM 对象允许设置数据类型（在本例中为 base64），一旦打开并存储在带有正确数据类型的字符串中，ADODB.stream 对象可以使用不同的数据类型（在本例中为 BinaryStreamType）将代码字符串写入磁盘，将 base64 字符串转换回二进制形式。
要利用此绕过方式使用 ScareCrow 有效载荷，您可以运行以下命令：
./ScareCrow -I <您的原始无阶段 shellcode 路径> -domain <域名> -Loader excel -O <输出文件名>
生成后，从输出文件中复制第 13 行和第 14 行，并将它们合并在一起，确保删除：
var <变量名>;
一旦您获得编码后的有效载荷，请使用 -N 标志指定写入磁盘时的有效载荷名称，-U 标志指定托管编码有效载荷的 URL（例如 https://<恶意站点>/），以及 -F 标志指定站点托管的文件名。输出的代码设计用于宏文档中。
通过进一步调查，发现这并非 WDATP 传感器的缺口，而是 WDATP 确实能看到此活动，但被忽略了。通过 WDATP 终端的事件时间线查找对 Appwiz.xll 的任何引用，我们观察到 WDATP 记录了 Word 创建文件 AppWiz.xll 时的“创建文件”事件。需要注意的是，.XLL 文件是可执行文件。
2020年11月20日 - 研究开发及文章撰写完成。
2021年03月14日 - 向 Microsoft 提交了初步披露文档，概述已识别的问题。
2021年03月31日 - Microsoft 确认并承认与生成 Office 子进程和将文件写入磁盘相关的漏洞是真实漏洞，并开始进行修补。然而，注册表中的权限不一致问题因需要提升权限而被认为不是漏洞。
2021年04月21日 - Microsoft 通知作者，于 2021年03月22日发布的签名版本 1.333.1055.0 和于 2021年04月21日发布的 1.335.1321.0 包含了针对基于 Office 应用程序的漏洞的检测，并关闭了案例。
2021年04月22日 - 作者重新测试了相同的技术，确认这些漏洞仍然存在。