ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

Docker 容器取证分析实战:基于 Anthropic-Cybersecurity-Skills 的镜像分层、运行态证据采集与入侵调查指南

Docker 容器取证分析实战:基于 Anthropic-Cybersecurity-Skills 的镜像分层、运行态证据采集与入侵调查指南 Docker 容器取证分析实战基于 Anthropic-Cybersecurity-Skills 的镜像分层、运行态证据采集与入侵调查指南【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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 ATTCKT1610、T1611、T1612、T1613部署容器、逃逸到宿主机、容器资源发现、容器与资源发现相关行为详见 mappings/mitre-attack/coverage-summary.md 中Container Escape (T1611)的归集说明NIST CSF 2.0RS.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_IDabc123def456 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 21 # 采集运行进程若容器仍在运行 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.mddocker export container_id container_fs.tar或docker export container_id | gzip container_fs.tar.gz导出容器文件系统docker commit container_id forensic-evidence:case001docker 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-diffcurl -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 \ --typefile --typeapt --typehistory --json \ /cases/case-2024-001/docker/container_diff.json根据 references/api-reference.mdcontainer-diff支持四种差异维度分别对应不同的取证关注点差异类型说明取证价值file文件系统差异定位新增/删除/修改的文件aptAPT 软件包差异识别攻击者额外安装的工具链pipPython 包差异识别恶意 Python 依赖historyDocker 构建历史差异排查可疑 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_KEYMEDIUM以 root 用户运行。这里涉及的关键概念技能文档有明确的术语定义概念说明Image layers只读文件系统层叠加组成容器镜像overlay2Docker 默认存储驱动基于联合文件系统组织各层Container diff运行时文件系统变更与原始镜像的差异对比Privileged mode拥有宿主机全部能力的容器绕过大部分隔离Docker socket控制 Docker daemon 的 Unix 套接字/var/run/docker.sockContainer 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(fFiles Added: {len(added)}) print(fFiles Changed: {len(changed)}) print(fFiles 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-truncJSON 化列出全部容器inspect_container()— 调用docker inspect获取完整配置analyze_security_config()— 安全配置审计特权/能力/挂载/命名空间/环境变量get_filesystem_changes()— 调用docker diff并归类 A/C/Ddetect_suspicious_files()— 模式匹配可疑文件export_container()— 导出文件系统并计算 SHA-256get_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展示运行/停止容器的文件系统变更diveDocker 镜像交互式分层分析container-diffGoogle 出品的镜像内容对比工具Trivy容器镜像与文件系统漏洞扫描docker-explorerDocker 工件离线取证分析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 离线分析的强有力补充。常见取证场景技能文档给出了四个高频实战场景可直接套用五步工作流场景 1Web 应用容器被入侵导出容器文件系统 → 在 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 ATTCK 覆盖统计 mappings/mitre-attack/coverage-summary.md、NIST CSF 对齐映射 mappings/nist-csf/csf-alignment.md 以及 mappings/attack-navigator-layer.json 中的 ATTCK Navigator 图层可在跨框架检索与合规审计时直接复用。【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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),仅供参考
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进