前言

自上一篇《ATT&CK实战指南》发布以来，这一年间ATT&CK更新的内容比较多，有必要再写一篇文章来对这些更新进行说明。去年的ATT&CK版本是V6.3，目前的ATT&CK版本是V8.1，可见更新了两个大的版本，目前的ATT&CK for Enterprise包含了14个战术，177个技术以及348个子技术。根据ATT&CK的Roadmap来看，今年在社区的努力下更新了很多的内容。下面，本文将分几个方面进行说明。

子技术更新

子技术的更新是今年最大的变化，之前版本的ATT&CK只有技术的概念，没有子技术。

子技术是技术里面一些很特定的技术点，比如进程注入这个技术就包含了11个子技术：动态链接库注入、PE文件注入、线程执行劫持、异步过程调用、线程本地存储、Ptrace系统调用、Proc文件系统注入、EWM注入、Process Hollowing技术、Process Doppelgänging技术、VDSO截获。这些技术都属于进程注入的子技术，但是具体技术实现细节不一样，所以都从属于进程注入技术。

图1. 进程技术及其子技术

这样ATT&CK的具体技术ID的描述如下图所示，包括矩阵ID，战术ID，技术ID，子技术ID，缓解措施ID，组织ID和软件ID。

图2. 技术ID描述示例

2019年10月之前的版本转换到目前版本的子技术，ATT&CK社区提供了转换的内容，有JSON（https://attack.mitre.org/docs/subtechniques/subtechniques-crosswalk.json）和CSV格式

（https://attack.mitre.org/docs/subtechniques/subtechniques-csv.zip ）可以进行对照转换。

之前的技术转换成子技术的架构有7种形式：

1. 保持技术本身

2. 变成子技术

3. 一些技术合并变成新的子技术

4. 一些技术合并变成新的技术

5. 合并到已有的技术

6. 删除

7. 分拆成多种子技术

这几种变化，在转换的JSON和CSV中都有所体现。

图3. 技术转化成子技术的形式示例

随着子技术的变化，Navigator项目和CAR项目已经做了相关的变化。比如点开命令和脚本执行的技术就会发现有8个子技术的脚本引擎。

图4. 子技术的展示示例

网络技术的新增

ATT&CK之前的矩阵主要是主机端、云端、移动端和工控方面的内容，今年新增了网络方面的攻击技术内容的单独矩阵。从下图可以看出内容并不是很多，只有18项攻击技术，有些还是重复的相关技术，比如命令和脚本引擎。

图5. ATT&CK 网络矩阵

比如第一个技术初始攻击，基本就是涵盖了相关OWASP的相关攻击技术。

PRE和Enterprise合并

今年的另外一个重大变化是将PRE-ATT&CK和ATT&CK for Enterprise进行了合并，对ATT&CK 增加了两个战术，一个是侦查（信息收集），另一个是资源开发（工具开发）。

图6. PRE和Enterprise合并

笔者发现，之前的PRE-ATT&CK有很多重复的技术，内容不够精炼，不如ATT&CK那么言之有物，合并也是必然。因此，侦查和资源开发保留了一些精华合并到ATT&CK也是好事。

图7. 侦查和资源开发合并到ATT&CK框架中

对于侦查和资源开发形成了精简版本的PRE matrix，也是通过子技术展示的。但是基本上没有这些技术的缓解措施，而只是可以参照这些攻击的行为，做到一些暴露面的收缩。

图8. 精简版本的PRE matrix

检测中的DataSource说明

谈到ATT&CK的时候，我们谈论更多的是TTP以及检测和缓解措施，但是忽略了更重要的一点就是数据源。比如我们在实现ATT&CK的某种检测技术的时候，首先选择一个技术，然后了解这个技术如何工作的，确定数据源，再次设计检测场景，获取数据源日志，再进行检测查询，最后调整检测的漏报率和误报率问题。

图9.ATT&CK技术的检测流程

真正落地ATT&CK检测的产品，首先要考虑的就是如何规划数据源的问题。现在每一项技术/子技术都有数据源的说明。

图10. 技术/子技术的数据源示例

标准化地从这些数据源收集数据为后来标准化地检测攻击技术提供了很好的基础。

略过MITRE的分析过程，直接的结论就是将数据分级分类表达出来，比如下图首先是数据源，然后是数据组件，再是关系和数据元素，最后就是数据的最终来源Windows下的EID。

图11. 数据的分级分类

最终使用的过程就是先选择一个攻击技术，再对应相关的数据源，针对数据源中具体的组件进行对应。当然，前提是要了解到此种攻击技术检测的具体数据组件，再找到相关的数据根源，这可能来自于系统或者其他工具，比如sysmon等。有了这一套标准的数据格式，并按照这种数据格式做到尽可能全面的采集，才能做到攻击技术的检测。

图12. 标准化的数据收集

缓解措施更新

前面的几个版本的ATT&CK对缓解措施描述的比较少，而这个版本的缓解措施（Mitigations）还是言之有物的。目前每个技术和子技术都有相关的缓解措施。以命令和脚本引擎为例，可以看出缓解措施的相关内容。

图13. 缓解措施示例

一共有五种措施进行缓解，第一个是防病毒，可以自动隔离文件；第二个是脚本签名；第三个是禁用和删除不需要的shell或者脚本引擎；第四个是使用应用控制；第五个是进行权限控制；第六个是限制web层面的内容执行。

检测能力主要是通过数据源收集并分析得出的结果，缓解措施基本都是事前的技术手段，也可以很好地从攻击面减缓的角度来减少这些攻击技术的危害。除了从攻击技术来看缓解措施，也可以从缓解措施来反查能够缓解哪些攻击技术。

TRAM项目介绍

简单来说，TRAM（Threat Report ATT&CK Mapper）项目就是将自然语言书写的安全报告中涉及的ATT&CK技术标记出来。现在越来越多的安全报告会提到很多的技术，但是要对照到ATT&CK上可能需要完全学习框架所涉及的200多种技术，这样的工作量比较大，无论对于厂商还是ATT&CK社区来说都是如此。TRAM项目可以通过安全报告迅速地分析出这种安全事件中使用的ATT&CK内容包括哪些，如果有些不存在，也可以人工补全。

本质上来说，这个过程是一个机器学习过程，用到的技术主要是NLP（自然语言处理），首先先获取相关的数据，包括之前标记过的相关的信息，以及相关的对应技术；然后进行相关数据的清理，也就是重复确认；其次就是开始相关的训练，针对相关的描述语言对应相关技术；再次进行报告的收集，进行测试，再之后就判断是否对应正确；最后就，如果对应不正确，就需要重复这个循环过程。这个过程中主要使用的技术环境是Python的Sci-kit库，以及使用的算法是逻辑回归。

图14. TRAM项目的运行原理

这个项目目前已经在Github上开源，使用方法是输入一个URL的报告地址，比如PA的安全报告地址，输入一个标题提交，就开始分析这篇文章了。

图15. TRAM项目的使用

分析的结果会以高亮的形式提示，右边会弹出相关的ATT&CK技术。这个项目很明显主要是针对于英文的，没有中文的报告可以解析。如果按照这个思路去思考，建立国内的ATT&CK标准，再利用这样的引擎进行转换，也可以统一大家描述攻击和形成报告的语境。

图16.TRAM项目的映射结果示例

云原生技术的ATT&CK 

随着云原生技术的普及，对于容器技术的安全也日益重视起来。微软根据相关容器编排工具（Kubernetes）可能遇到的安全攻击，根据ATT&CK矩阵设计了一个针对Kubernetes的安全攻击技术矩阵。

图17. ATT&CK for Kubernetes

目前，一些厂商已经根据这些技术做了相关的产品化。

图18. ATT&CK for Kubernetes示例

这个矩阵目前还不算是MITRE的官方项目，不过会根据社区的贡献进行相关的规划。可以看出来ATT&CK这个框架的普适性比较强，跟其他的技术结合，就可以枚举出相关的攻击技术，在我们采用相关新技术的时候可以全面思考可能遇到的安全状况。

ATT&CK会议变化

前两届的会议都是集中式的一天会议，而今年的会议叫做Power Hour，分为4次，从2020年10月开始，一个月一期，每期维持在1个小时左右，一共有四期，一直持续到2021年1月。会议上会针对这些更新或者一些社区成员的使用场景进行了一些说明，会给大家一些新的角度。比如美国Temple大学使用ATT&CK相关框架进行网络犯罪教育的素材，最重要的是提供了一些关键基础设施的勒索软件的数据库。FPT集团使用ATT&CK作为通用语言进行威胁狩猎，并对威胁狩猎和威胁检测做了区分。威胁狩猎是主动性地发现更多的威胁，但是需要高级的安全专家并耗时进行搜索和分析；威胁检测是被动性的，成本比较低，但是需要更多的事件进行误报的排查。其他的主题也重点的介绍了在云计算和工控方面的应用。

图19. 威胁狩猎与威胁检测的异同

总结

本篇文章是继《ATT&CK实战指南》之后的一篇更新指南。在社区的努力下，ATT&CK框架更新的速度较快，在一年的时间内发布了三次大的更新，重点的更新内容是：子技术更新、PRE矩阵和Enterprise结合。需要关注的一些细节是数据源的内容和缓解措施的相关内容，之前框架里面强调的并不是很多。后来，又新增了相关的TRAM项目，可以方便大家针对安全报告迅速对应ATT&CK的相关技术。ATT&CK框架适应能力比较强，可以针对新技术对安全进行全面的思考，比如云原生的相关安全风险，也可以按照这个框架进行梳理。笔者也观察到，相关人工智能的相关攻击技术也在按照ATT&CK的架构进行梳理。