基于 ATT＆CK 的 APT 威胁跟踪和狩猎

2021-02-26 11:30:11 浏览数 (1)

这是我在 BCS2019上演讲的议题的文字版，由于议题的时间限制后面内容基本都没有展开，所以再形成一个文字版本把一些想法再记录一遍，也是公开出来供业内同仁进行批判和探讨。

我主要从今年上半年重点对 ATT&CK 框架进行研究，并且发现其有助于我对网络威胁攻击和对抗的更全面理解，甚至可以延伸至从数据和检测的视角来看待威胁本身。

从我的角度 ATT&CK 是：

  • ATT&CK是对 TTP 的一种标准化表达，包括战术目的、技术手段以及攻击过程中技术手段的选择；
  • ATT&CK 一定程度上是偏实战化的，毕竟其研究基础是真实曝光的网络威胁活动；
  • ATT&CK是具有应用场景限定的，同样因为其关注的威胁类型和研究基础所选取的来源范围，其更适用与面向具有网络边界的网络攻防场景，而和像云安全、业务安全、工控安全，甚至移动安全的威胁场景都存在一些不太适用或不太全面的情况。

我在研究 ATT&CK 的框架时，也研究了国外安全研究人员对其的一些应用和实践，并且在一些群里也看到相关研究者对其应用和实践存在疑惑或是存在差异，我认为其和威胁情报的概念一样，当研究者自身的知识储备和视角，以及其面对的需要解决的问题不同时，对其的理解和认知就会出现差异。所以，在这里我只是以我个人过去的安全经验对 ATT&CK 本身的一些看法和思考罢了。

OK，啰嗦了这么多，下面将进入正文，那么这篇文章会从以下几个维度来介绍 ATT&CK：

  1. 从其设计角度剖析 ATT&CK 的框架原理；
  2. 从数据视角谈谈如何对 ATT&CK 进行运营；
  3. 对 ATT&CK 的战技术以及其在分析狩猎时的应用进行简单介绍。

什么是 ATT&CK

在多年以前，大家讨论的比较多的可能是恶意代码家族、钓鱼 URL、控制域名或 IP 之类的。后来，威胁情报来了，威胁情报会告诉威胁分析师或运营人员，攻击来源是谁，其意图和目的是什么，用了什么样的战术、技术和过程，也就是 TTP，并且从威胁情报的角度，恶意载荷 Hash、域名、IP 是容易变更的，而 TTP 是难以变更的，或是需要更大的成本。TTP 其实是一个偏描述性的东西，那么问题来了，一旦需要人去描述，对于不同的人来说，同一个东西，其表述方式可能差异很大，这样就很难去统一，就好比英式英语和美式英语中很多单词其实是不一样的。

那么说到 TTP，说到 ATT&CK不得不提到 MITRE 这个组织，MITRE 是一个非营利性组织，其设计和公开的一些标准化的东西其实有不少。MITRE 在定义 STIX 1.x （即对网络威胁信息的标准化表达）时，应该是首次将 TTP 进行结构化，但直至其最后的1.2版本，TTP的结构化设计和字段依然不是很清晰而且存在大量描述性字段。大概是因为这个原因，在 STIX 2.0的重新设计时，TTP 结构被删掉了，替代为Attack Pattern，并且使用了 CAPEC进行映射，但 CAPEC 依然不是很满足真实网络威胁的场景。而 MITRE 后续设计了 ATT&CK 框架，并且将其融入到 STIX2的结构定义中。

ATT&CK 框架分成 PRE-ATT&CK 和 Enterprise，如果和 Kill-Chain 中的攻击步骤来映射的话，PRE-ATT&CK 是用于表达攻击实施前的战技术，例如攻击团伙进行决策，确定要达到的阶段性目标和攻击目标范围，以及需要进行前置性的信息收集、探测和武器化过程。而 Enterprise 则主要针对攻击实施开始，即从分发和初始投放开始。ATT&CK框架还设计了一个 Mobile ATT&CK，但结合过去我在移动安全场景下的经验，我觉得还不是非常完善，这里暂不多提。下面我们主要讨论 Enterprise 这部分。

ATT&CK 框架，通常我也喜欢称为矩阵，其是分层次的，并且层次是存在缺失的，其包含12项战术目的和244项达到战术目的的技术实现方式，战术目的之上我认为应该存在攻击阶段（Phase）的对应，攻击技术以下则是对具体的一些行为层面或 Indicator 层面的拆解和标签化。其除了战术目的、攻击技术，还包含了具体的攻击团伙及其使用的攻击武器、攻击工具，并且展示了其要素的关系。

ATT&CK 的数据和运营视角

如果从数据来源和运营角度来看 ATT&CK，我比较倾向于下图，这里的逻辑关系也是 MITRE 如何去总结和更新 ATT&CK 矩阵的：

其基础来源是主要对真实披露和公开的威胁报告、事件中总结的一些攻击技术和目的，MITRE 还模拟了一个真实的组织网络环境来进行日志数据的收集、处理，并且进行攻击技术的抽象、归纳和定义对应的战术目的，并且和具体的攻击团伙及其使用的载荷、工具进行映射，以及提出了一些用于缓解和检测的方式。

与日常的威胁分析类似，对 ATT&CK 的运营和更新一方面依赖于对已知团伙的攻击 TTP 的分析和归纳，以及新的活动中使用的 TTP，另外基于一些红蓝对抗、安全研究中所发现和披露的常用攻击技术、攻击面、攻击向量同样可以补充到矩阵中，并且需要向下拆解映射到具体的检测点和检测特征中，从而可以应用于 Threat Hunting 过程。

上述过程不仅是 MITRE 在建立和更新 ATT&CK 的流程，也同样适用于我们对 ATT&CK 进行扩展和运营的流程。

在 ATT&CK 中，MITRE 的数据采集机制包括 Windows 系统日志、Sysmon 日志、Autoruns 以及其开发的自定义的终端网络行为监测和系统行为监测的 agent。

但从我来看，在 Observable或 Indicator 层面到 ATT&CK 的 Technique 层面存在一些层次上的缺失，也就是我认为中间包含一个富有更多上下文信息的复合结构，并且其能够容易映射到检测点以及实现规则的过滤，我在这里称为Behavior。举个例子，这个复合结构可以用文字表述为：

代码语言：javascript复制
在某个时间，父进程用xxx的参数创建了子进程，其关联文件为xxx。

可以看到，这是一个进程链行为的描述，并且涉及了进程和文件两个维度的 Observable 类型，还包含了时间和关系。我在今年 BlackHat Arsenal 上发布了一个示例工具，基于 Sysmon 的日志数据结构定义了这样的一些 Behavior 结构示例，如果有兴趣的可以参考 SysmonHunter。

https://github.com/baronpan/SysmonHunter

ATT&CK 的战术与技术

在 PPT 中我借用了北美一家安全厂商Red Canary的一份报告的截图，其基于其数据对 ATT&CK 的 Technique 使用频率进行了统计，其中 PowerShell 和 Scripting 位于第一二位，并且 PowerShell 的频率远超于其他技术。

这里我想表达的是在 ATT&CK 矩阵的 Technique 列表中，应该存在层次划分，也就是哪些技术是我们应该优先考虑和覆盖的，哪些技术是比较关键的和异常度高的，244项技术总会存在一些优先级在里面，并且随着防御策略的不断调整，其优先级可能出现变化。

这里举个例子，在过去几年中，海莲花组织比较喜欢使用 DNS 隧道进行渗出，一方面在 Cobalt Strike 中确实提供了同时支持 DNS 隧道和 HTTP/S 渗出的方式，另一方面大概是因为当时的防御体系中，DNS 隧道能够较好的进行隐匿传输而不被发现。但后续，由于公开曝光和披露，在对 DNS 协议层面的威胁检测和发现进行了针对性的补充和加强，导致近年来这种方式反而变得比较少了，而一些中东的 APT组织在近年来的一些样本中反而开始使用 DNS 隧道的方式。

另一方面，作为防御方或威胁分析人员还应该多考虑被攻击目标所处的环境，例如针对境内目标的攻击活动大概率不应该出现利用 google 相关网站实现存活探测，或是使用 Dropbox、 Twitter 这种平台实现一些命令控制或者数据渗出。

为了达到同一个战术目标，攻击者可能会采用多样性的方式来实现，例如不同的系统 API，利用系统本地的代码执行和模块装载命令和程序来实现。在 PPT 中我也截取了 Vault7项目中某国情报机构 OSB 部门中实现的代码执行向量模块的不同实现方式。

近年来，APT 组织也偏好“拿来主义”，一方面利用公开的、开源的或者商业的攻击工具，这种即降低了攻击武器的制作成本，也消除和模糊了攻击组织的指纹特征，曾经完全利用特定家族来归属判定组织的时代也许即将一去不复返了吧。另一方面，技术盗用也能达到上述的目的，同样在 Vault7中提到的UMBRAGE 项目，就是将一些公开木马工具或者技术研究再实现并应用到自身项目中。另外，一旦一个APT 组织的攻击技术和手法被曝光，那么后续再次利用该方式进行归属判定时需要进行斟酌，因为其可能被模仿和伪造。

我们也应该关注于LOTL 相关技术的利用，因为其利用和执行的是系统固有的命令和程序，不存在黑名单的问题，并且能有效减少载荷的上传和落地。

结合 ATT&CK 的分析和狩猎

对于威胁分析人员来说，有时候真的和“盲人摸象”和“管中窥豹”的故事比较类似，往往需要通过单一线索关联出更多，并且通过碎片化的证据还原攻击的全貌。

对于 APT 攻击来说，有两个非常关键性的阶段和目标，一是突破网络边界防护并立足，二是维持持久性。如果阅读过国内外的一些 APT 报告，对于投放载荷和恶意攻击工具的分析一般更多，其可能的原因是其更容易被采集和捕获，那么如果要更全面的还原整个攻击活动的情况，除了需要对其攻击载荷进行更细致的分析外，还依赖于一些日志数据等，去补齐我们所缺失的观察部分。

对于 APT 分析来说，我认为可以分为四个分析维度：

  • 技术分析，即对攻击的样本，使用的漏洞利用工具等进行分析，一方面分析其具体使用了哪些技术手段，用来做什么，另一方面是提取指纹特征；
  • 战术分析，需要去对应当前的攻击阶段，是初始立足阶段，还是横向移动过程；
  • 意图分析，攻击的意图可以是短期的，也可以是中长期的，短期意图可以是一阶段载荷和初步的信息收集，而中长期的可能是要拿下一个内网核心节点，目标数据库或是制定的战略目标；
  • 归属分析，归属分析是可以对攻击来源的可信程度的判断，其用于归属判定的依据可以是一个具体的 IP、终端设备或者地域区域，也可以是一个网络 ID 或者真实的人。对于归属分析和如何利用证据来作证判定结果，最好的案例就是去年美国 DoJ对朝鲜黑客的指控书。

别忘了，对于 APT 攻击来说，攻击工具和基础设施是易变的，但制定的攻击目的不会轻易的变化。

一些应用实例的介绍：

  • T1189 Drive-by Compromise

利用失陷网站驱动的攻击投递方式，我们在过去也曾发现某组织喜好针对邻国的网站进行渗透，并用于载荷分发和控制回传通道，并且这些网站拥有相同的后台，甚至是同一个主机服务提供商，那么我们可以推测攻击组织可能开发了针对性的批量渗透工具，并用于上传其后台文件和模块，往往具备类似的 URI 路径，及时域名是完全不同的。

另外也有入侵站点后通过修改站点文件的，包括外联一个外部 JS 脚本或是将JS 代码片段直接插入到站点原有的 JS 文件中。

  • T1086 PowerShell

由于 PowerShell 具有灵活的语法，包括随机的大小写，或是关键词的不同缩写方式等，会对 PS 内容特征的检测造成一些困扰，但从 PowerShell 行为触发上来检测反而较为容易一些。

Windows 系统对 PowerShell 默认的执行策略会有一些限制，所以其执行可能需要带有一些特定的策略绕过参数，例如 -ExecutePolicy bypass。我也注意到如果 PS 脚本中利用到了一些.Net 的模块或特性，会触发csc.exe 进程的执行，而 csc.exe 是.Net 的一个编译命令。例如在 VT 高级帐号中检索 PowerShell 和 csc.exe 进程并存的情况，结果中基本都是高检出的样本，其中部分是 CobaltStrike 生成的载荷。

  • Shortcut Modification

这里我列举了三种形态的 LNK 文件修改方式，都是在 APT 场景下使用过，既可以在目标命令中插入脚本执行或加载一个特定 DLL，或是利用 LNK 格式本身的特性来隐藏执行的命令。

除了上述这类 Enterprise 矩阵的技术，对于 PRE-ATT&CK 我们也有一些验证。例如控制域名的一次注册，分批使用，我们发现过某组织在某个连续的两天注册了多个域名，而对域名的使用则分布在不同的三起事件中，并且每起事件针对的目标是完全不同的。对于 IP、域名相关的 DNS 记录的历史重叠在 APT 活动中还是出现过。即使在 APT 攻击中，往往会尽可能避免重复使用过去的基础设施，但我们依然还是看到过诸多案例，一方面可能是源于一些基础设施确实被攻击组织长期持有。另一个比较有趣的现象是不同 APT 组织使用了重叠的基础设施，那么这个主要有两种可能，一种是两个组织确实存在潜在联系，但可能组织架构上出现了分裂，或者工具出现了更迭，但部分资源确实被传承或复用了；另一种，可能是有意的抢占另一个组织已经废弃的资源。

在这里我们也列举了一些有趣的狩猎策略，例如某个欧洲 APT 组织，也被卡巴称为Animal Farm（动物农场），其错误的 User-Agent 拼写也给予我们一些狩猎启发，对于一些数量分布上比较小众的 User-Agent 通信行为可能出现异常。

再就是基础设施的劫持，一些更高能力的 APT 组织可能针对较低能力的 APT 组织的基础设施，通过劫持或者接入监听的手段或获取情报、实施攻击，这类技术在某国的泄露文档中也曾提到过相关项目，在今年确实被安全厂商发现了这种类型的攻击。

在这一部分介绍的这么多，旨在于对于 ATT&CK，我们需要更多思考攻击者是如何在实战中实现的，可能会采用什么样的方式去绕过已有的防御，并完善现有的检测点和检测策略。

最后

作为最后的总结，我认为 ATT&CK 还是非常具有指导意义和提供知识基础的，但在真实场景下仍需进行拆解，并通过运营来完善缺失的攻击面和攻击向量。

关于会议 PPT 可以访问链接进行下载。

https://github.com/baronpan/PPTs/blob/master/基于ATT&CK的APT威胁跟踪和狩猎.pdf

安全 apt-get http https 网络安全

0 人点赞