ATT&CK威胁检测技术在云工作负载的实践

 

随着云计算、云原生技术的蓬勃发展，越来越多的业务正以数字化的形态运转在以主机和容器为代表的云工作负载上。从日益新增的新型攻击威胁来看，保护云工作负载安全将成为今后网络安全防护的关键。尽道“输攻墨守”（只要有一种攻击的战术，就会有防守的方法）。兼具系统性和详细性的ATT&CK知识库可帮助网络空间安全从业者评估、强化安全产品的能力，掌握主动权。本文主要围绕ATT&CK发展态势、落地ATT&CK的思考与实践、安全狗基于ATT&CK框架进行攻防实战的案例以及总结与展望等四大部分进行内容分享。

 

ATT&CK发展态势

在第1章，笔者将和大家分享对ATT&CK的背景以及发展趋势的看法。

1.1ATT&CK背景介绍

ATT&CK是对抗战术、技术和常识（Adversarial Tactics, Techniques, and Common Knowledge）的缩写。这一开源的对抗战术和技术的知识库已经对安全行业产生了广泛而深刻的影响。笔者认为其原因是：ATT&CK框架兼具系统性和详细性。它将矩阵、战术、技术、过程以及阻断措施系统性地组织在了一起，如图1-1所示。

图1-1

ATT&CK不像“杀伤链”这类高层次模型无法表达具体攻击，也不像“漏洞库”等等低层次的模型无法窥视全貌，如图1-2所示。

图1-2

1.2ATT&CK趋于丰富化、详细化

MITRE ATT&CK历久弥新，趋于丰富化、详细化。截止今年的4月份，版本已经迭代到第9版。在这一版的变化中，新增了容器安全部分，如图1-3所示。

图1-3

此次更新也改进了数据源，细化了战术描述内容，增强了可落地性，也不断例行优化着企业场景的攻防技术。

落地ATT&CK的思考与实践

在第2章中将从以下几点与大家分享经验：（1）借助ATT&CK评估并强化安全产品的能力的实践的方法或经验；（2）ATT&CK检测技术在CWPP的落地难点与改进方向；（3）我司的ATT&CK落地情况；（4）ATT&CK运用在威胁检测过程的不足。

2.1云工作负载攻击场景

随着云计算、云原生技术的蓬勃发展，越来越多的业务正以数字化的形态运转在以主机和容器为代表的云工作负载上。在这样子的转变中，传统的WEB渗透、内网渗透等攻击手段依然奏效，并且针对K8s容器环境的新型攻击利用方式也带来了新的威胁，如图2-1所示。

图2-1

2.2借助ATT&CK评估、强化安全产品能力

ATT&CK可用于评估、强化安全产品的能力。安全狗的安全研究人员经过在该方向的长期实践，总结出了“模拟红蓝对抗，构建攻防知识图谱，确定数据源，确定威胁检测算法”的方法和经验，如图2-2所示。

图2-2

下文将对这些方法、经验进行简要的介绍。

2.3模拟红蓝对抗

“模拟红蓝对抗”是许多需要“既知攻，又知防”的安全研究人员的日常工作。图2-3展示了红队人员利用“WEB应用或服务漏洞”拿下网络边界的WEB服务器，继而将其作为跳板，分别针对内网主机A、B做横向渗透的过程。在这一过程中，攻击者通常会用到无文件攻击配合实现中间人攻击、内网穿透以及木马后门植入等技法，为二次攻击做准备。

图2-3

而这图2-4是蓝队人员在红队人员攻击后，进行安全事件分析、入侵溯源所创建的热力图。我们可以发现，红方的攻击链可对应ATT&CK矩阵中的多项技战术。ATT&CK宛若红蓝对抗的“战术板”或“仪表盘”。

图2-4

2.4攻击知识图谱

基于“模拟红蓝对抗”，我们可进行ATT&CK的攻防知识图谱的构建，如图2-5所示。“攻防知识图谱”的依据主要在于“红队在实施攻击的时候，将不可避免地产生失陷信标IoC以及攻击信标IoA，因而蓝队在识别攻击的时候是有迹可循的”。由攻防对抗图谱可以看到红蓝双方的博弈，在这张图中，蓝队的目标是“监控”，需要从左往右看，而红队的目标是“攻击”，需要从从右往左看。蓝队可通过此图思考防御规则的设置，而红队可通过此图思考防御规则的绕过。

图2-5

2.5数据源

基于“攻防知识图谱”，我们可以确定数据源。在ATT&CK框架里的每项技术描述中都有对应于该技术的数据源信息。例如对于“命令及脚本执行”的攻击战术，数据源可以是命令执行、模块加载、进程创建以及脚本执行，如图2-6所示。

图2-6

据统计，在可检测ATT&CK技术点的数据源排行榜中，位列前三的分别是进程监控、进程命令行参数以及文件监控，如图2-7所示。这和诸多安全厂商的普遍关注点是相一致的。

图2-7

2.6威胁检测算法

接下来看“威胁检测算法”，我们可以基于进程行为、文件行为、网络行为以及注册表行为等等关键行为，通过威胁检测算法判断出“异常行为”对ATT&CK技战术的命中情况，如图2-8所示。

图2-8

威胁检测算法的构建往往需要不同专业背景的人员进行协作。例如，由安全研究人员梳理具有专业背景的知识库、标签，由编程人员、算法研究人员一道设计、优化基于规则的静态匹配算法、基于AI的智能算法，或者基于关联分析的算法。

2.7ATT&CK检测技术在CWPP落地难点与改进方向

在将ATT&CK检测技术落地到云工作负载保护平台的过程中，我们梳理了4个落地难点以及应对措施，如图2-9所示。

难点1是“威胁检测技术的不成熟性”。现阶段，不少安全产品对ATT&CK的覆盖广度基本达到，但对覆盖深度仍较为有限。因此，我们仍会不断地以攻促防；

难点2是“黑、白名单进程的不确定性”，攻击者可能会使用运维人员常用的工具实施攻击。因此，安全产品容易遭遇“误报以及漏报的矛盾”。因此，我们选择优先检测高频、确切的攻击；

难点3是“威胁数据源采集维度的模糊性”，面对繁多的威胁数据源获取方法，获取精炼的威胁数据殊为不易。因此，我们也在加大对安全大数据算法的研发力度；

难点4是“业务机资源占用的不稳定性”，若对业务机的异常行为进行持续性监控，可致资源占用过高。因此，我们秉承“业务稳定性优先”的原则，在产品中运用“轻客户端、重云端”的架构。

图2-9

2.8安全狗ATT&CK落地情况

在研发云工作负载保护平台过程中安全狗研发团队也应用了ATT&CK。

在（云）主机安全方面，“威胁检测”功能模块现已内置数百条规则，覆盖了ATT&CK攻击矩阵中14个阶段高频攻击战术的入侵检测，特别是针对目前主流的WEB中间件或者像“永恒之蓝”这样的主机RCE漏洞的检测能力覆盖；

在容器安全方面，借鉴主机安全的经验，通过异常进程、异常文件操作及异常命令等角度覆盖K8s运行时安全的高频攻击场景，正在进行基于“默认网络设置”、“Secret资源对象”及“编排平台的脆弱性”等方面的场景覆盖。

2.9ATT&CK运用在威胁检测过程的不足

对于“ATT&CK运用在威胁检测过程的不足”这一问题，笔者认为ATT&CK运用在威胁检测过程中有以下3点不足，如图2-10所示。

其一是“攻击技战术行为难以判定”，仅凭“子技术”本身，难以直接判定攻击者所使用的战术；

其二是“入侵溯源难以推理”，仅凭“ATT&CK”框架本身，难以直接推理攻击者的入侵过程；

其三是“应用在防御时难以实现自动化”，仅凭机器单点，难以在复杂的攻防场景实现完整的入侵检测自动化，这往往需要介入人工和设备做大量分析。

图2-10

攻防实战案例

在第3章，我们将基于上述“以攻促防”的方法、经验，介绍针对云工作负载环境的JBoss反序列化漏洞、Tomcat任意文件上传漏洞&文件包含漏洞、Java内存马无文件攻击、Powershell无文件攻击、容器逃逸、镜像投毒等典型ATT&CK攻击场景的入侵威胁检测的实战案例。

3.1JBoss反序列化漏洞

案例1是对“JBoss反序列化漏洞”的攻防实战过程；在这个场景中，攻击者可通过“JBoss的反序列化远程代码执行漏洞”获取主机权限；图3-1可以反映该案例中的红蓝对抗。

图3-1

我们可以从左边的“红队视角”看到攻击者的关键攻击步骤，从右边的“蓝队视角”看到蓝队所推断的ATT&CK技战术，以及关键的检测方法。

在红方视角，可通过JBoss的反序列化漏洞获取靶机的交互式shell；在蓝方视角，可以判断红方使用的ATT&CK技战术为“利用面向公众的应用”以及“利用命令行工具及脚本解释器”；并且，蓝方可在靶机的进程行为中找到相应的攻击特征。比如发现：红方获取到的shell bash进程是由Java调用创建的，并且红方可能正使用ping工具进行内网探测，或者还可推断该shell的权限和Java进程是平级的。

为了对这一攻击场景进行威胁检测，蓝方可将“数据源”设定为“进程命令行”，并在该JBoss容器的进程树中添加对应的进程行为规则。以期监控Java进程调用创建ncat、whoami、net等系统敏感进程，及时地识别红方攻击者的入侵行为。进程监控结果如图3-2所示。

图3-2

值得补充说明的是，由于Tomcat、Weblogic等主流Java Web中间件的进程名均为“Java”，这样的配置方式可有效地检测出多种Java Web中间件的远程命令执行漏洞。

3.2Tomcat任意上传漏洞&文件包含漏洞

案例2是对“Tomcat任意上传漏洞&文件包含漏洞”的攻防实战过程；在这个场景中，攻击者可通过Tomcat的文件操作漏洞上传并利用网页后门Webshell。图3-3可以反映该案例中的红蓝双方的对抗。

我们可以从左边的“红队视角”看到红方针对任意文件上传漏洞和文件包含漏洞的攻击利用，将网页后门Webshell或是恶意代码落地到系统磁盘当中，从右边的“蓝队视角”看到攻击者使用ATT&CK技战术也为“利用面向公众的应用”。

图3-3

对于文件操作类的漏洞，我们可将“数据源”设定为“文件监控”。

那么，基于以上文件攻击的行为特征，我们可对WEB容器的敏感目录开启“文件完整性监控”，以期识别该敏感目录是否有异常的“新增文件”行为，如图3-4所示。

图3-4

综合案例1和案例2我们可以得出：虽为同类的红队技战术，蓝队可以分析其特点，选择合适的数据源进行监控、研判。

3.3Java内存马无文件攻击

案例3是对“内存马无文件攻击”的攻防实战过程；在这个场景中，攻击者在获取Webshell后可植入内存木马，达到权限维持的目的。内存马无文件攻击技术是实现持久化常见的战术之一，其“无文件落盘”的特性规避了传统引擎的查杀。图3-5可以反映该案例中的红蓝对抗。

图3-5

我们可以从左边的“红队视角”看到红方注册、植入了Java型内存木马，从右边的“蓝队视角”看到攻击者使用ATT&CK战术为“持久化”；基于这一攻击利用方式的特性，蓝队可将数据源设定为“Java虚拟机”以及“进程行为”。

通过JVM运行时的字节流，蓝队可以提取其中的class字节码，并通过算法检测其中的内存木马特征，实现内存马的查杀。

3.4Powershell无文件攻击

案例4是对“powershell无文件攻击”的攻防实战过程；在这个场景中，攻击者在可获取宿主机的Powershell执行权限前提下，加载恶意的Powershell脚本，做进一步的后渗透操作。图3-6可以反映该案例中的红蓝双方的对抗。

我们可以从左边的“红队视角”看到红方利用远程加载恶意的powershell攻击脚本实施无文件攻击，达到系统密码查看和远程代码执行的目的，从右边的“蓝队视角”看到攻击者使用ATT&CK技战术为“执行”；因此，蓝队可将数据源设定为“powershell日志”和“进程行为”，如图3-6所示。

图3-6

基于上述分析，我们可以在系统中开启Powershell日志分析，并借此对此类攻击做研判；Powershell日志详情如图3-7所示。

图3-7

此外，由于Powershell也是属于系统进程，因此蓝队也可基于进程行为进行检测；进程角度的威胁检测结果3-8所示。

图3-8

3.5容器逃逸

案例5是对“Docker容器逃逸”的攻防实战过程；在这个攻击场景中，攻击者可以在获取容器的权限的前提下，扩大战果。在云上容器ATT&CK矩阵中，“权限提升”是攻击者实施“容器逃逸”的关键且高频的技战术。图3-9可以反映该案例中的红蓝双方的对抗。

图3-9

我们可以从左边的“红队视角”看到，红方利用Docker容器内核隔离性不足的特点“逃逸”出自身拥有的权限，实现对宿主机或宿主机上其他容器的恶意操作，从右边的“蓝队视角”看到红方可能从ATT&CK矩阵中的初始访问、执行、持久化与权限提升等方面逐步入手，实施容器逃逸。

以Docker容器逃逸漏洞CVE-2019-5736为例，蓝队可以在事前、事中、事后找到异常的进程特征（比如替换bash命令的解释器路径）、文件特征（比如修改runc的版本），如图3-10所示；

图3-10

因此，蓝队可将数据源设定为“异常进程”和“异常文件操作”，并有效检测出容器逃逸的子步骤，部分威胁检测结果如图3-11所示。

图3-11

3.6镜像投毒

案例6是对“Docker镜像投毒”的攻防实战过程；在这个攻击场景中，攻击者可以部署含有恶意代码的镜像，进行供应链攻击。图3-12可以反映该案例中的红蓝双方的对抗。

图3-12

我们可以从左边的“红队视角”看到，红方通过镜像投毒，在Docker镜像中植入了网页后门Webshell，并在受害者由镜像启动容器后，对容器Webshell进行远控，接着实施了容器逃逸攻击，从右边的“蓝队视角”可分析出红方可以基于ATT&CK矩阵中的“持久化”以及“权限提升”等技战术入手，如图3-13所示。

图3-13

因此，我们可将数据源设定为“镜像扫描结果”“异常文件操作”“异常命令操作”等角度，镜像扫描角度的威胁检测结果如图3-14所示。

图3-14

总结和展望

ATT&CK对安全行业产生了深刻、广泛的影响。因其兼顾系统性以及详细性，并且有很高的社区活跃度，有助于评估、强化产品的安全检测能力，安全狗数年来一直很重视ATT&CK的落地工作。目前，“基于ATT&CK以攻促防”的方法和经验已在（云）主机、K8s环境取得了良好的效果。

在接下来的工作中，我们仍计划在产品检测能力中着力覆盖ATT&CK的攻防场景，并针对ATT&CK的落地难点及框架的自有缺陷，对产品架构做进一步升级改造，对产品体系的安全事件分析能力做进一步强化。

很高兴通过本文和大家分享安全狗的“ATT&CK威胁检测技术在云工作负载的实践”，希望能和读者朋友们一起交流、学习！

参考链接

1. https://www.secrss.com/articles/30965

2. https://attack.mitre.org/resources/updates/

3. https://medium.com/mitre-attack/defining-attack-data-sources-part-i-4c39e581454f

4. https://static.anquanke.com/download/b/security-geek-2019-q4/article-3.html