Docker 容器取证分析实战：基于 Anthropic-Cybersecurity-Skills 的镜像分层、运行态证据采集与入侵调查指南
【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills
本文围绕开源仓库 Anthropic-Cybersecurity-Skills 中的analyzing-docker-container-forensics技能展开，系统讲解针对被入侵 Docker 容器与容器主机的取证流程，涵盖证据保全、镜像分层分析、主机工件检查、文件系统变更比对与漏洞/敏感信息扫描五大环节。读者读完本文后，可以掌握从docker ps/docker inspect证据固定到dive/container-diff/Trivy深度研判的完整实战能力，并理解底层调用链与自动化取证 Agent 的实现思路。
技能定位：何时启动容器取证
容器化环境已成为攻击者的重点目标——恶意镜像投毒、Web 应用容器被植入 Webshell、利用危险挂载或特权模式逃逸到宿主机、以及容器内挖矿（Cryptojacking）等场景在应急响应中越来越常见。本技能适用于以下典型场景：
- 调查已受损的 Docker 容器或容器主机；
- 分析从镜像仓库拉取的恶意 Docker 镜像；
- 处置容器化应用被入侵的安全事件；
- 排查容器逃逸（Container Escape）尝试或权限提升行为；
- 审计容器配置、识别配置缺陷（Misconfiguration）。
该技能在仓库中被映射到多个主流框架，便于 Agent 与安全团队快速定位其战术价值：
| 框架 | 映射项 | 语义 |
|---|---|---|
| MITRE ATT&CK | T1610、T1611、T1612、T1613 | 部署容器、逃逸到宿主机、容器资源发现、容器与资源发现相关行为（详见 mappings/mitre-attack/coverage-summary.md 中"Container Escape (T1611)"的归集说明） |
| NIST CSF 2.0 | RS.AN-03、DE.AE-02、RS.MA-01 | 事件响应分析、异常活动检测、缓解措施 |
从仓库的映射数据看，Container Escape / T1611被归入 Privilege Escalation（权限提升）战术，与detecting-container-escape-attempts、detecting-container-escape-with-falco-rules等技能构成"攻击侧利用—防御侧检测"的完整闭环。
取证前置条件
在进入工作流之前，需要确认以下能力与权限：
- 取证工作站上具备 Docker CLI 访问权限；
- 能够访问 Docker 主机的文件系统（取证镜像或在线宿主机均可）；
- 理解 Docker 分层文件系统（overlay2、aufs）的运作方式；
- 安装镜像分析工具：
dive、docker-explorer或container-diff； - 了解 Docker daemon 配置与 socket 安全；
- 安装漏洞扫描工具：
Trivy或Grype。
五步取证工作流
技能文档给出了从证据保全到报告生成的标准五步流程，下面逐步骤展开并结合仓库中的 API 参考与自动化脚本进行深化。
Step 1：保全容器状态与证据
取证的第一原则是先保全、后分析，避免破坏原始证据。以下命令将容器运行态完整落地到案件目录/cases/case-2024-001/docker/：
# 列出所有容器（含已停止），记录完整 ID docker ps -a --no-trunc > /cases/case-2024-001/docker/container_list.txt # 检视目标容器（保存完整配置与状态 JSON） CONTAINER_ID="abc123def456" docker inspect $CONTAINER_ID > /cases/case-2024-001/docker/container_inspect.json # 导出容器文件系统为 tarball（保留当前状态） docker export $CONTAINER_ID > /cases/case-2024-001/docker/container_export.tar # 将容器当前状态固化为镜像并整体保存 docker commit $CONTAINER_ID forensic-evidence:case-2024-001 docker save forensic-evidence:case-2024-001 > /cases/case-2024-001/docker/container_image.tar # 采集容器日志（带时间戳） docker logs $CONTAINER_ID --timestamps > /cases/case-2024-001/docker/container_logs.txt 2>&1 # 采集运行进程（若容器仍在运行） docker top $CONTAINER_ID > /cases/case-2024-001/docker/container_processes.txt # 采集网络连接 docker exec $CONTAINER_ID netstat -tlnp 2>/dev/null > /cases/case-2024-001/docker/container_network.txt # 拷贝关键目录/文件出容器 docker cp $CONTAINER_ID:/var/log/ /cases/case-2024-001/docker/container_var_log/ docker cp $CONTAINER_ID:/tmp/ /cases/case-2024-001/docker/container_tmp/ docker cp $CONTAINER_ID:/etc/passwd /cases/case-2024-001/docker/container_passwd # 对所有导出证据计算哈希，保证证据链完整性 sha256sum /cases/case-2024-001/docker/*.tar > /cases/case-2024-001/docker/evidence_hashes.txt关于这一步的 API 细节，可参考技能目录下的 references/api-reference.md：
docker export <container_id> > container_fs.tar或docker export <container_id> | gzip > container_fs.tar.gz：导出容器文件系统；docker commit <container_id> forensic-evidence:case001+docker save ... > evidence_image.tar：固化并保存镜像；docker logs --timestamps、docker logs --since 2024-01-15、docker logs --tail 1000、docker logs -f（实时跟随）：按需裁剪日志范围。
值得一提的是，仓库自带的取证 Agent 脚本 scripts/agent.py 中实现了export_container()函数，它在调用docker export后立即以 64KB 分块流式计算 SHA-256 摘要，将"导出即哈希"固化为代码逻辑，直接对应上述手工步骤中的证据完整性要求。
Step 2：分析容器镜像分层
镜像由只读文件系统层（Image Layers）叠加而成，攻击者投毒内容通常隐藏在某一个特定层中。分层分析的关键在于定位"哪一层引入了恶意内容"。
# 安装 dive（交互式分层分析工具） wget https://github.com/wagoodman/dive/releases/latest/download/dive_linux_amd64.deb sudo dpkg -i dive_linux_amd64.deb # 交互式分析镜像分层 dive forensic-evidence:case-2024-001 # 非交互 CI 模式 + JSON 输出（适合批量取证） dive forensic-evidence:case-2024-001 --ci --json /cases/case-2024-001/docker/dive_analysis.json # 从镜像 tar 包中解出各层 mkdir -p /cases/case-2024-001/docker/layers/ tar -xf /cases/case-2024-001/docker/container_image.tar -C /cases/case-2024-001/docker/layers/ # 查看 manifest.json，明确层的顺序与关系 cat /cases/case-2024-001/docker/layers/manifest.json | python3 -m json.tool # 逐层抽样检查内容 for layer in /cases/case-2024-001/docker/layers/*/layer.tar; do echo "=== Layer: $(dirname $layer | xargs basename) ===" tar -tf "$layer" | head -20 echo "..." done对于"对比恶意镜像与官方基础镜像差异"的需求，技能推荐 Google 的container-diff：
curl -LO https://storage.googleapis.com/container-diff/latest/container-diff-linux-amd64 chmod +x container-diff-linux-amd64 # 对比提交镜像与原始基础镜像 ./container-diff-linux-amd64 diff daemon://nginx:latest daemon://forensic-evidence:case-2024-001 \ --type=file --type=apt --type=history --json \ > /cases/case-2024-001/docker/container_diff.json根据 references/api-reference.md，container-diff支持四种差异维度，分别对应不同的取证关注点：
| 差异类型 | 说明 | 取证价值 |
|---|---|---|
file | 文件系统差异 | 定位新增/删除/修改的文件 |
apt | APT 软件包差异 | 识别攻击者额外安装的工具链 |
pip | Python 包差异 | 识别恶意 Python 依赖 |
history | Docker 构建历史差异 | 排查可疑 RUN 指令 |
dive的输出则包括逐层文件系统变更、镜像效率评分（Image efficiency score）与空间浪费分析（Wasted space），可快速发现异常膨胀的层——这在挖矿二进制植入场景中尤为明显。
Step 3：检查 Docker 主机工件
当取证目标是宿主机本身（如容器逃逸调查）或需要对离线磁盘镜像进行分析时，应直接检查 Docker 数据目录（默认/var/lib/docker/）：
DOCKER_ROOT="/mnt/evidence/var/lib/docker" # 查看 overlay2 存储驱动下的文件系统层 ls -la $DOCKER_ROOT/overlay2/ # 通过 inspect 获取容器合并视图路径（MergedDir） CONTAINER_HASH=$(docker inspect $CONTAINER_ID --format '{{.GraphDriver.Data.MergedDir}}' 2>/dev/null) # 离线场景下：在 /var/lib/docker/containers/<container_id>/config.v2.json 中手工查找 # 分析容器配置文件 cat $DOCKER_ROOT/containers/$CONTAINER_ID/config.v2.json | python3 -m json.tool \ > /cases/case-2024-001/docker/container_config.json # 检查 Docker daemon 配置（关注权限与审计相关设置） cat /mnt/evidence/etc/docker/daemon.json 2>/dev/null > /cases/case-2024-001/docker/daemon_config.json # 提取容器 JSON 日志 cat $DOCKER_ROOT/containers/$CONTAINER_ID/*.log > /cases/case-2024-001/docker/container_json_logs.txt随后用一段 Python 脚本对container_inspect.json做安全配置审计，重点检查卷挂载（可能暴露宿主机文件系统）、特权模式、危险能力、命名空间共享、运行用户与环境变量中的敏感信息：
import json with open('/cases/case-2024-001/docker/container_inspect.json') as f: data = json.load(f) inspect = data[0] if isinstance(data, list) else data print("=== CONTAINER SECURITY ANALYSIS ===\n") # 检查挂载 print("Volume Mounts:") for mount in inspect.get('Mounts', []): rw = "READ-WRITE" if mount.get('RW') else "READ-ONLY" print(f" {mount.get('Source', 'N/A')} -> {mount.get('Destination', 'N/A')} ({rw})") if mount.get('Source') in ('/', '/etc', '/var', '/root') and mount.get('RW'): print(f" WARNING: Sensitive host path mounted read-write!") # 检查特权模式 host_config = inspect.get('HostConfig', {}) if host_config.get('Privileged'): print("\nWARNING: Container was running in PRIVILEGED mode!") # 检查能力 cap_add = host_config.get('CapAdd', []) if cap_add: print(f"\nAdded Capabilities: {cap_add}") dangerous_caps = ['SYS_ADMIN', 'SYS_PTRACE', 'NET_ADMIN', 'SYS_MODULE'] for cap in cap_add: if cap in dangerous_caps: print(f" WARNING: Dangerous capability: {cap}") # 检查 PID 命名空间 if host_config.get('PidMode') == 'host': print("\nWARNING: Container shares host PID namespace!") # 检查网络模式 if host_config.get('NetworkMode') == 'host': print("\nWARNING: Container shares host network namespace!") # 检查运行用户 user = inspect.get('Config', {}).get('User', 'root (default)') print(f"\nRunning as user: {user}") # 检查环境变量中的密钥 env_vars = inspect.get('Config', {}).get('Env', []) print(f"\nEnvironment Variables: {len(env_vars)}") for env in env_vars: key = env.split('=')[0] if any(s in key.upper() for s in ['PASSWORD', 'SECRET', 'KEY', 'TOKEN', 'CREDENTIAL']): print(f" SENSITIVE: {key}=***REDACTED***")这段手工脚本与仓库 scripts/agent.py 中analyze_security_config()的逻辑高度一致，且 Agent 版的覆盖面更广、分级更细：
- CRITICAL：特权模式；敏感宿主机路径（
/、/etc、/var、/root、/home、/var/run/docker.sock）以读写方式挂载；Docker socket 被挂载进容器（意味着容器可直接控制 Docker daemon，即 Docker-in-Docker 滥用）； - HIGH：危险能力（
SYS_ADMIN、SYS_PTRACE、NET_ADMIN、SYS_MODULE、DAC_OVERRIDE、NET_RAW）；共享宿主机 PID/网络命名空间；环境变量暴露敏感信息（关键词匹配PASSWORD/SECRET/KEY/TOKEN/CREDENTIAL/API_KEY）； - MEDIUM：以 root 用户运行。
这里涉及的关键概念，技能文档有明确的术语定义：
| 概念 | 说明 |
|---|---|
| Image layers | 只读文件系统层，叠加组成容器镜像 |
| overlay2 | Docker 默认存储驱动，基于联合文件系统组织各层 |
| Container diff | 运行时文件系统变更与原始镜像的差异对比 |
| Privileged mode | 拥有宿主机全部能力的容器（绕过大部分隔离） |
| Docker socket | 控制 Docker daemon 的 Unix 套接字（/var/run/docker.sock） |
| Container escape | 突破容器隔离、逃逸到宿主机的手法 |
| Volume mounts | 暴露进容器内部的宿主机文件系统路径 |
| Image history | 构建每层所用的 Dockerfile 指令记录 |
Step 4：分析容器文件系统变更
docker diff是取证中识别恶意行为的利器——它以A/C/D三种代码标记容器相对镜像的变更：
docker diff $CONTAINER_ID > /cases/case-2024-001/docker/filesystem_changes.txt| 代码 | 含义 |
|---|---|
A | 新增文件或目录 |
C | 被修改的文件或目录 |
D | 被删除的文件或目录 |
对变更结果进行自动化研判，按模式标记可疑的新增文件与关键系统文件改动：
added = [] changed = [] deleted = [] with open('/cases/case-2024-001/docker/filesystem_changes.txt') as f: for line in f: line = line.strip() if line.startswith('A '): added.append(line[2:]) elif line.startswith('C '): changed.append(line[2:]) elif line.startswith('D '): deleted.append(line[2:]) print(f"Files Added: {len(added)}") print(f"Files Changed: {len(changed)}") print(f"Files Deleted: {len(deleted)}") # 标记可疑新增文件 suspicious = [f for f in added if any(s in f for s in ['/tmp/', '/dev/shm/', '/root/', '.sh', '.py', '.elf', 'reverse', 'shell', 'backdoor'])] if suspicious: print(f"\nSuspicious Added Files:") for f in suspicious: print(f" {f}") # 标记可疑改动文件 sus_changed = [f for f in changed if any(s in f for s in ['/etc/passwd', '/etc/shadow', '/etc/crontab', '/etc/ssh', '.bashrc'])] if sus_changed: print(f"\nSuspicious Changed Files:") for f in sus_changed: print(f" {f}")仓库 Agent 脚本中的 detect_suspicious_files() 在此基础上升级了检测规则：新增文件重点匹配/tmp/、/dev/shm/、/root/、.sh、.py、.elf、reverse、shell、backdoor、miner、xmr、.php、webshell、c2、beacon等模式；变更文件则聚焦/etc/passwd、/etc/shadow、/etc/crontab、/etc/ssh、.bashrc、/etc/sudoers、authorized_keys等持久化与认证关键路径——例如/root/.ssh/authorized_keys被修改往往意味着攻击者植入了后门公钥。
接着解包导出的文件系统做深度检查：
mkdir -p /cases/case-2024-001/docker/container_fs/ tar -xf /cases/case-2024-001/docker/container_export.tar -C /cases/case-2024-001/docker/container_fs/ # 识别 /tmp 等目录中的文件类型 find /cases/case-2024-001/docker/container_fs/tmp/ -type f -exec file {} \; # 查找晚于容器创建时间的新增 PHP 文件（常见 Webshell 载体） find /cases/case-2024-001/docker/container_fs/ -name "*.php" -newer /cases/case-2024-001/docker/container_fs/etc/hostnameStep 5：漏洞扫描与报告生成
取证分析的最后一步是对镜像与导出文件系统做自动化安全扫描：
# 扫描镜像已知漏洞（JSON 输出便于后续解析） trivy image forensic-evidence:case-2024-001 \ --format json \ --output /cases/case-2024-001/docker/vulnerability_scan.json # 扫描导出文件系统（表格输出便于人工阅读） trivy fs /cases/case-2024-001/docker/container_fs/ \ --format table \ --output /cases/case-2024-001/docker/fs_vulnerabilities.txt # 单独开启 secret 扫描器，检测镜像内硬编码凭据 trivy image forensic-evidence:case-2024-001 \ --scanners secret \ --format json \ --output /cases/case-2024-001/docker/secrets_scan.jsonTrivy 的严重性分级为CRITICAL | HIGH | MEDIUM | LOW | UNKNOWN，参考 references/api-reference.md 可组合使用trivy image --scanners vuln,secret一次完成漏洞与密钥双扫描。Agent 脚本的 scan_image_vulnerabilities() 封装了 JSON 输出格式的 Trivy 调用，便于将结果直接汇入自动化报告。
一键化：Agent 自动化取证流程
手工执行上述五步较为繁琐，仓库提供了完整的自动化实现 scripts/agent.py，其调用链清晰对应工作流的每一步：
list_containers()— 调用docker ps -a --no-trunc，JSON 化列出全部容器；inspect_container()— 调用docker inspect获取完整配置；analyze_security_config()— 安全配置审计（特权/能力/挂载/命名空间/环境变量）；get_filesystem_changes()— 调用docker diff并归类 A/C/D；detect_suspicious_files()— 模式匹配可疑文件；export_container()— 导出文件系统并计算 SHA-256；get_container_logs()— 带时间戳采集日志；generate_report()— 汇总为 JSON 取证报告。
运行方式：
# 列出所有容器 python3 skills/analyzing-docker-container-forensics/scripts/agent.py # 对指定容器执行完整取证分析 python3 skills/analyzing-docker-container-forensics/scripts/agent.py abc123def456该 Agent 是标准技能结构的"参考实现"（每类技能目录下都附带agent.py演示脚本），可直接作为自建容器取证流水线的起点，或接入 Claude Code、GitHub Copilot、Codex CLI、Cursor、Gemini CLI 等 agentskills.io 兼容平台使用。
辅助工具矩阵
技能文档整理了两张关键工具表，取证时可按需选用：
| 工具 | 用途 |
|---|---|
| docker inspect | 获取容器详细配置与状态信息 |
| docker diff | 展示运行/停止容器的文件系统变更 |
| dive | Docker 镜像交互式分层分析 |
| container-diff | Google 出品的镜像内容对比工具 |
| Trivy | 容器镜像与文件系统漏洞扫描 |
| docker-explorer | Docker 工件离线取证分析 |
| Sysdig | 容器运行时安全监控与取证 |
| Falco | 容器与 Kubernetes 运行时威胁检测 |
其中docker-explorer适合离线场景，可直接对/var/lib/docker目录操作：de.py -r /var/lib/docker list列容器、de.py -r /var/lib/docker mount <container_id> /mnt/forensic挂载容器文件系统、de.py -r /var/lib/docker history <container_id>查看历史，是前文 Step 3 离线分析的强有力补充。
常见取证场景
技能文档给出了四个高频实战场景，可直接套用五步工作流：
场景 1：Web 应用容器被入侵导出容器文件系统 → 在 Web 根目录识别 Webshell → 分析访问日志定位利用尝试 → 检查新增文件与配置修改 → 检查网络连接是否指向 C2 → 审查容器能力判断提权路径。
场景 2：恶意镜像引发的供应链攻击用dive定位"哪个层引入了恶意内容" → 用container-diff与官方基础镜像比对 → 检查镜像构建历史中的可疑 RUN 指令 → 扫描内嵌后门与挖矿程序 → 回溯镜像仓库拉取日志。
场景 3：容器逃逸调查确认容器是否以特权模式或携带危险能力运行 → 检查宿主机文件系统挂载点是否存在未授权访问 → 审查 Docker socket 挂载导致的 Docker-in-Docker 滥用 → 分析宿主机系统日志中的逃逸迹象 → 排查内核漏洞利用痕迹（对应 MITRE T1611）。
场景 4：容器环境挖矿（Cryptojacking）识别高 CPU 容器 → 导出并分析镜像中的挖矿二进制 → 检查仓库中未授权镜像 → 审查容器创建事件中的恶意部署 → 检查网络连接中的矿池通信。
标准化的取证报告格式
技能文档规定了统一的输出格式，确保不同分析师/Agent 产出的报告结构一致、可直接归档：
Docker Container Forensics Summary: Container: abc123def456 (nginx-app) Image: company/web-app:v2.1 Status: Running (started 2024-01-10 09:00 UTC) Host: docker-host-01.corp.local Security Configuration: Privileged: No Capabilities Added: NET_ADMIN (WARNING) Volume Mounts: /var/log -> /host-logs (RW) Network Mode: bridge User: root (WARNING) Filesystem Changes: Added: 23 files (5 suspicious) Changed: 12 files (2 suspicious) Deleted: 0 files Suspicious Findings: /tmp/reverse.sh - Reverse shell script (Added) /var/www/html/.hidden/shell.php - PHP webshell (Added) /etc/crontab - Modified (persistence cron entry added) /root/.ssh/authorized_keys - Modified (unauthorized key added) Vulnerability Scan: Critical: 3 (CVE-2024-xxxx in base image) High: 12 Medium: 34 Evidence: /cases/case-2024-001/docker/Agent 脚本中的 generate_report() 生成的 JSON 报告字段（容器 ID/名称、镜像、安全发现、文件系统变更统计、可疑文件清单、UTC 时间戳）与该文本格式一一对应，可直接做结构化入库。
适用前提与限制说明
需要说明的是：本文所有命令、工具版本与映射信息均以当前仓库实际内容为准。dive、container-diff、Trivy等外部工具需在取证工作站上单独安装；docker inspect、docker diff、docker export等操作需要相应的 Docker API 权限。对于容器逃逸等高风险行为，务必仅针对你拥有或获得明确书面授权的系统执行，并遵守相关法律与交战规则（参考仓库 SECURITY.md 与 CODE_OF_CONDUCT.md 中的使用约束）。
该技能在仓库中的完整配套还包括：index.json中的技能索引条目、MITRE ATT&CK 覆盖统计 mappings/mitre-attack/coverage-summary.md、NIST CSF 对齐映射 mappings/nist-csf/csf-alignment.md 以及 mappings/attack-navigator-layer.json 中的 ATT&CK Navigator 图层，可在跨框架检索与合规审计时直接复用。
【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
