错误识别：当攻击技术并非真正的技术

本文系翻译自Mistaken Identification: When an Attack Technique isn’t a Technique^[1]，文中的“我”均指代原作者。在翻译过程中，为了更好地帮助国内安全从业人员理解，我们对部分内容进行了适度的增删处理，力求保持原意的同时，提升阅读的流畅性和理解度。

本文是威胁检测系列文章的一部分。在这篇文章中，我将讨论检测工程师面临的挑战之一：有时 Mitre ATT&CK 技术根本不是一种技术，使得尝试检测它变得非常复杂！我将在本文中使用 T1059.001 PowerShell 作为示例，但这个概念适用于许多其他技术（太多了！）。最终，我们将证明为什么 T1059.001（以及许多其他技术）甚至不该存在。

让我们开始吧

让我们设想一下，你正在查看 2023 年使用的顶级攻击技术。Red Canary 有一个名为“威胁检测报告^[2]”的优秀网站，提供了大量关于他们所见顶级攻击技术的见解。直接从他们的网站，“下图代表了 2022 年在 Red Canary 客户群中确认威胁中观察到的最普遍的 MITRE ATT&CK®技术。” 

2022年观察到的最常用技术排名前两位的是 Windows CMD和 PowerShell。如果你的领导层看到了这个页面，你很有可能会询问关于你的公司对这些技术的检测态势的问题！所以，为了主动应对，你开始着手研究如何防御它。你决定从 T1059.001 PowerShell 开始，而且刚刚读了我关于检测数据模型（DDMs, Detection Data Models）的文章) 所以，你开始构建你的 DDM。

构建 T1059.001 PowerShell 的 DDM

你打开绘图应用程序，开始为 T1059.001 PowerShell 操作流程。第一个操作是……嗯……。

你不知道该从哪里入手，因为“PowerShell”这个词本身并不能提供任何具体信息。这就好比有人说“坏人要用电脑抢劫银行，现在去阻止他们！”——他们可能以各种不同的方式使用电脑，从将电脑扔出窗外到像《十一罗汉》（Ocean's Eleven）那样的全面接管系统。

工具，而非技术

使用“PowerShell”（或 Windows CMD、WMI）作为攻击技术的问题在于，我们实际上并没有定义一种攻击。我们只是定义了一个工具，一个被攻击者和管理员都使用的工具。攻击者使用 PowerShell 来执行某些操作，如建立命令和控制、窃取数据、横向移动或提升权限。如果仅说“攻击者使用了PowerShell”，这句话是没有意义的，除非接着说明“用以完成X”。实际上，PowerShell是工具，而X才是他们使用该工具进行的具体攻击技术。

信息安全行业在识别像MimiKatz或CobaltStrike这样的专用工具时没有困难，但对于通用工具如PowerShell、Python、WMI、DLLs和共享模块、操作系统API、云API等，ATT&CK框架却显得尤为棘手。

一个补充说明：我认为可以得出结论，整个“执行”战术本身可能就不应该存在。问题类似：执行不是一个攻击者的目标，它是攻击者实现其他目标的手段。“执行”不能独立存在。你执行代码是为了做某事，而这个“某事”才是目标。通过获得初始访问权限，意味着已经在网络中的某个地方获得了执行能力。所有额外的执行都有其特定的目标：横向移动、提升权限、窃取数据。列在“执行”战术下的大多数（如果不是全部的话）技术实际上都是工具。将工具定义为技术的问题可能源于将“执行”错误地定义为目标。

尝试检测工具

当我们把工具定义为技术时，会使自己感到困惑。这使得 ATT&CK 框架对检测工程师来说有点难以处理。当我们试图承担起检测工具而不是技术的任务时，我们会有两种问题之一：

1. 如果工具聚焦较窄，如 Mimikatz，则我们检测到的是一些边缘的、受攻击者控制的因素。如前文所述，我们的检测提供的增量覆盖很少，因为攻击者可以使用他们想要的任何工具，有无限多的选项列表。
2. 如果工具功能广泛，如 PowerShell，那么我们正试图检测每一个特定的实现，就像在一个特定工具中实现的那样。这不仅是一项艰巨的任务，而且非常低效。如果我们试图检测每一种技术，我们最好专注于检测技术本身，包括但不限于使用特定工具的实现。

无论哪种方式，专注于工具而非技术会导致不良的检测工程实践。 这很可能引导我们走向边缘化的检测，这些检测的增量覆盖效果不佳。专注于检测工具，即使是功能强大且频繁使用的工具如PowerShell，也会使概率游戏对攻击者有利。毕竟，攻击者总是可以使用新工具，使我们所有以工具为中心的检测变得毫无价值。

如何区分工具与技术

对于检测工程师来说，我们需要能够区分一种技术是否真的是一个工具，以免浪费宝贵的时间和精力去尝试检测它。我提供以下标准作为判断依据：攻击技术必须专注于实际攻击（即实现特定攻击者目标的行为），并且可以被定义为一个操作链（即使这个链只包含一个步骤）。 换句话说，如果它不能被映射成具体的操作流程，它就不能被明确识别。如果它不能被识别，它就不能被检测到！

一个好的例子可以帮助我们理解这种区别，比如比较T1546.003 WMI事件订阅（用于持久化或权限提升）与T1047 WMI：前者是实现特定攻击者目标的具体操作：获得持久性或提升他们的特权。我们可以画出操作链： 

后者与 PowerShell 完全相同：当我们说“他们使用了 WMI”时，我们根本不知道攻击者实际做了什么。这可能是任何事情，也可能什么都没有。它可能是恶意的，也可能是无害的。它不关注实际攻击，也不能定义为操作链。它是一种工具，而不是一种技术。

检测某些工具的案例

虽然我曾反对花时间在基于工具的检测上，但确实存在一些基于工具的检测可能值得我们投入开发和维护的成本。有些工具（如 CobaltStrike）经常被现实世界的攻击者滥用，有时攻击者以在你特定环境中非常可疑的方式使用它们（例如大多数 LOLBins 和可能高度混淆或经常被滥用的 PowerShell 命令）。在这些情况下，尽管理论上攻击者可以使用任何工具使你的检测变得毫无价值，但这些工具实际被滥用的频率之高，使得它们成为工具特定检测的合理候选对象，只要它们的增量成本不是太高。

总结

ATT&CK框架对检测工程师很有帮助，因为它帮助我们整理已知的攻击技术，然后系统地研究和检测这些技术。然而，ATT&CK 错误地将许多工具识别为技术，这增加了检测工程师的工作难度。专注于工具而非技术使得防御更加困难，因为最终是攻击者选择使用哪种工具。可以通过判断某项“技术”是否专注于实现特定的攻击目标，并且可以在操作链中定义，来区分真正的技术。对于那些实际上是工具的技术，最好不予理会，而是集中精力全面检测真正的技术，不论其是通过何种工具实现的。

参考资料