从容器 ATT&CK 的攻击技术可以得知，其攻击手段覆盖“镜像安全”“应用安全”“容器安全”“主机安全”等维 度的云原生威胁实战场景，下面就这些维度展开介绍。
镜像是容器运行的基础。容器引擎服务可使用不同的镜像启动相应的容器。在容器出错后，它能迅速通过删除容器、 启动新的容器来恢复服务，这都需要以容器镜像作为支撑技术。所以在云原生安全领域，容器镜像的安全首当其冲。 随着容器技术的成熟和流行，大部分的开源软件都提供了容器镜像及其构建脚本（如 Dockerfile）。在现实的容器化 应用开发过程中，人们很少从零开始构建自己的业务镜像，通常将公开镜像作为基础镜像，在此基础上增加自己的代码或程序，然后打包成最终的业务镜像并上线运行。 毫无疑问，这种积累和复用减少了造轮子的次数，大大提高了开发效率和软件质量，推动了现代软件工程的发展。如 今，一个较为普遍的情况是，用户自己的代码依赖若干开源组件，最后打包的业务镜像中好包含有众多冗余的开源组 件。包含的组件数量与存在的安全风险程度成正比，大量引入第三方组件的结果也 增加了漏洞被利用的风险。并且， 黑客可能将病毒木马放到镜像中大肆传播，造成大量使用该镜像的用户受到威胁。
对总结的攻防知识图谱反馈的信息可以得知，基于镜像安全扫描功能的防病毒引擎以及恶意代码特征库检测出被植入 病毒、网页后门的镜像。
又如，近日如平地惊雷般席卷整个安全圈的 Log4J2 RCE 漏洞（CVE-2021-44228），由于 Log4J2 组件在镜像中被广 泛引用，其覆盖面之广使许多用户都难逃一劫。若用户的 WEB 应用镜像里使用了受到该漏洞的影响的 Log4J2 组件， 则很可能遭受黑客攻击。由此可见，对于镜像的安全检测就显得尤为重要。 对于引入了不安全的第三方组件的检测，如含有 Log4J2 RCE 漏洞的 Log4J2 组件，可通过检索、扫描镜像中的 jar 包， 并匹配相应的特征，进而判定镜像是否受到漏洞影响。 镜像中有诸多安全风险需要检测，其核心也包括已知系统的 CVE 检测。扫描器获取到镜像后，将它分离成相应的层 和软件包，接着针对软件包进行漏洞扫描，从而判定是否存在漏洞。 对于镜像安全检测，可以将之归纳为如图 7-6 所示的流程图。
编排系统的成熟极大促进了微服务架构的云原生应用的落地实践，然而这些新型的微服务体系也同样存在各种安全风 险。云原生应用源于传统应用，因而云原生应用也就继承了传统应用的风险。因此，在云原生环境下，传统的 WEB 攻击 手段依然有效。例如，黑客若探测到某云原生应用存在前文所述的 Log4J2 组件漏洞，可以进一步利用该漏洞实施类 似传统环境下的攻击。
由于云原生应用架构的变化进而导致应用 API 交互的增多，可以说云原生应用中大部分交互模式已从 WEB 请求 / 响 应转向各类 API 请求 / 响应，因而 API 风险也进一步提升。不仅传统的常见 WEB 攻击风险同样存在与 API 之中。除 此之外，API 也面临着许多业务层面的安全威胁，例如调用参数异常，调用频率异常，调用逻辑异常等。 此外，新型的微服务体系（如无服务、服务网格）也催生出更新型的攻击手段。例如，攻击者可通过编写一段无服务 器的代码获得运行无服务程序容器的 shell 权限，进而对容器网络进行渗透。
对于应用安全的检测，可基于“软件成分分析”“SAST”“DAST”“IAST”与“RASP”等技术手段进行威胁检测。 对于存在有 Log4J2 RCE 类似的安全问题的容器，客户可通过软件成分分析规避风险。根据样本组件特征来匹配被测 程序中的特征来判断应用程序是否引用该组件，因此支持组件的数量越多，其检测率也就越高，支持的组件数量越 少，则越容易导致检测遗漏；另外检测算法和特征设计是否合理也直接影响到分析的准确性和分析效率。
在容器安全问题中，容器逃逸是最被重视的部分之一。原则上，容器环境与主机环境隔离。然而，容器的便捷性和容 器与宿主机共用内核息息相关，容器技术天然地存在内核隔离性不足的问题。因此，攻击者有机会突破容器以访问底 层主机。这可以允许攻击者从主机级别或主机本身访问其他容器化资源。 黑客在获取到容器的反弹 shell 后，会想方设法从容器 shell 逃逸到宿主机。他们可以通过多种方式逃逸到宿主机环 境中，可使用的攻击利用方式包括但不限于：“脏牛”等主机内核漏洞、不安全的容器配置（特权容器、不安全挂载）、 “Docker runC”等编排组件漏洞。
在容器逃逸成功后，黑客还可为自己提供实现后续目标的机会（例如植入后门、在环境中横向移动或在主机上建立命 令和控制通道）。 此处介绍一个利用容器应用漏洞以及容器不安全配置的“容器逃逸”实例，攻击者按以下两个步骤进行容器逃逸： （1）利用“Log4J RCE”应用漏洞对 WEB 应用进行攻击，获取到容器的远程命令执行权限； （2）利用“挂载宿主机敏感目录的容器”对宿主机进行“容器逃逸”攻击，获取到宿主机的命令执行权限，如。‘’‘’
对于步骤（1）的检测，由于应用安全与容器安全有着关联性，对外暴露的 WEB 应用安全对攻击者而言时高价值资 产，容器的本质是资源受到隔离和限制的进程，因此在攻击者通过应用漏洞获取容器 Shell 权限的阶段，可基于“容 器 WEB 进程监控”进行威胁检测。从容器进程信息中获取数据源，并跟据预设规则模板对实时数据进行分析与检测， 可实时地发现容器内 Web 中间件的异常进程行为。
对于步骤（2）的检测，可采用“基于规则”以及“基于行为模型”的方式。 其中“基于规则”的异常检测方法一直是最为经典的威胁检测实现方法。这种检测方法是直观的，步骤是清晰的，结 果是可解释的。在容器环境下，这种检测方法仍然适用于针对已知威胁的检测。 比如，对于已知的云原生漏洞来说，触发漏洞的过程会产生相应的特征，如果要准确检测某漏洞的利用行为，就要 获取入侵行为产生的特征，比如在此过程中产生的异常进程、异常文件操作等。
基于实验分析，从它所反馈的特征来看，可以基于对容器的目录开启“文件完整性监控”或“系统进程监控”进行威 胁检测。在该攻击过程中，如果在容器内出现新增文件或者宿主机出现可疑的进程，则该 K8s 环境可能正面临威胁。
基于规则的检测方式虽然能够快速、精确地检测出已知威胁，但往往无法针对未知威胁做出检测。此时，则可借助构 建行为模型的方法进行检测，通过白名单自学习的方式，可以有效检测出因未知威胁产生的进程、文件、网络等方面 的异常行为，可有效检出 0day 攻击。
横向渗透，就是在已经攻占部分内网主机的前提下，利用既有的资源尝试获取更多的凭据、更高的权限，进而达到控 制整个内网、获取最高权限，甚至发动 APT 的目的。 在横向渗透中，最先得到的主机，以及之后新得到的主机，会成为突破口、跳板。如同一个不断扩大的圆形，获得的 主机越多，圆能触及之处越大，让其周遭的“横向”部分由未知成为已知。
在一定程度上，主机安全与容器安全之间的联系是不可割裂的。主机安全影响着容器安全，容器安全影响着主机的安 全。在云原生的环境下，在发生容器逃逸以后，K8s 可能会成为黑客实施后渗透攻击的工具。黑客会在保证自己安全 的前提下将已攻占的主机最大化地利用。根据对利用方式的分类，往往可以分为数据挖掘、后门和攻击三大类。而 K8s 环境的存在使得复杂的内网环境多了一个攻击面。例如，若逃逸的宿主机是 K8s 的 Master 节点，则黑客还可利 用 K8s 的平台资源进行横向渗透。 针对主机系统服务或应用架构的多样性，攻击者可以对其实现“无文件落地”攻击。例如，攻击者可以利用公网服务 器上的恶意代码对靶机进行远程代码执行漏洞利用，通过“远程代码执行漏洞 + 系统白名单程序 + 无文件落地组合” 攻击实现更加隐蔽的渗透。对此，相应的威胁检测方法也需不断提升，做层层剖析。对于场景“主机中的 Java 中间 件应用漏洞被利用，或已被植入 Java 内存木马，且有调用系统白名单进程”，则在主机上会启动相对应的异常进程、 子进程以及异常的命令行，对此可总结出如表 7-3 所示的攻防实战图谱。
基于以上所反馈的行为特征，可以对主机开启“进程行为监控”和“内存木马”，识别主机上的“进程”行为和“Java 内存”行为。通过监控得到关键的“异常进程”和“恶意加载类”解析所命中的容器 ATT&CK 中对应的技战术和子技战术， 从而能确定所遭受的安全威胁。
