用途
Cloud IAM Deep 是一个跨 AWS、Azure、GCP 的云 IAM 红队攻击链技能，聚焦于外部利用路径以及凭据发现后的权限分析。它用于在以下情形中被触发：云凭据浮现（密钥、secret、token、JSON 文件）；SSRF 链到达 IMDS/元数据端点；APK 或 git 泄露暴露内嵌云密钥；侦察发现具有可验证权限的公开 S3/GCS/Azure-blob；Kubernetes API 或服务账号令牌暴露；云托管实例 RCE 后向云控制面转移。
不适用场景：纯本地环境（属于 AD 攻击技能范畴，且在本技能的外部边界之外）；恰好托管在 AWS 上的 Web2 漏洞（应使用相关的 hunt-* 技能）。
凭据识别（前 60 秒）
该技能给出各平台的凭据模式：
- AWS 访问密钥：AKIA[0-9A-Z]{16}（IAM 用户长期密钥）、ASIA[0-9A-Z]{16}（STS 临时凭据）、AGPA（IAM 组）、AIDA（IAM 用户 ID）、AROA（IAM 角色）、ANPA（托管策略）；AWS secret 为 40 字符 base64-ish，需上下文判断。
- Azure：AccountKey=[A-Za-z0-9+/=]{86}（存储账号密钥）、client_secret 模式加 UUID（Azure AD 应用凭据）。
- GCP 服务账号 JSON：包含 type、project_id、private_key_id、private_key 字段。
- K8s SA token（JWT 格式，解码 kid claim 确认签发者）。
主要能力
AWS
只读验证的安全首步：export 凭据后，用 aws sts get-caller-identity 确认身份（返回 UserId、Account、Arn），尝试常见只读调用（list-users、list-roles、list-policies、list-groups），查看附加策略（list-attached-user-policies、list-user-policies、list-groups-for-user），逐服务探查（ec2 describe-instances、s3 ls、lambda list-functions、rds describe-db-instances、secretsmanager list-secrets、ssm describe-parameters），审计跨账号/外部信任。
AWS 提权模式（24+ 已记录）以“你拥有/通过何种方式提权”对照表呈现，例如：iam:CreateAccessKey → 为任意用户创建访问密钥并冒充；iam:AttachUserPolicy → 给自己附加 AdministratorAccess；iam:PassRole + ec2:RunInstances / lambda / cloudformation / glue / datapipeline / codestar → 以管理员角色运行；sts:AssumeRole → 直接权限跳跃。许多破坏性操作在外部红队中超出范围，应记录路径而非总是执行。
STS/跨账号/角色链：枚举可跨账号扮演的角色、assume-role、设置新凭据、验证、从新身份重新枚举。困惑副手模式：寻找缺少 sts:ExternalId 或信任策略允许 arn:aws:iam:::role/ 的情况。
IMDSv1/IMDSv2 滥用：IMDSv1 直接 GET 获取元数据与凭据；IMDSv2 需先 PUT 获取 token（通常缓解 SSRF），例外是自身带自定义 header 执行请求的 SSRF。
Azure
凭据验证：az login --service-principal 或 --identity；az account show；订阅列表；RBAC 角色分配；可读资源列表。
托管身份滥用：从 Azure VM 内（RCE 后或 SSRF 至等价 IMDS）访问 metadata/identity/oauth2/token 端点，可获取 Management、Key Vault、Graph 的 token；若托管身份具有 Graph 权限，可读取全部 M365 数据。
Azure 提权模式：roleAssignments/write → 自授 Owner；roleDefinitions/write → 修改角色定义；runCommand → 在 VM 上执行命令；Key Vault secrets/get → 读取密钥；storageAccounts/listkeys → 读取存储；publishxml/host listkeys → RCE；AAD 目录权限 → 自授全局管理员。
GCP
服务账号 JSON：gcloud auth activate-service-account --key-file；确认身份与项目；获取项目级 IAM 策略；逐服务列表。
GCP 提权模式：serviceAccounts.getAccessToken → 获取高权限 SA 的 token；implicitDelegation → 链式委托；signBlob/signJwt → 伪造 JWT；serviceAccountKeys.create → 创建密钥冒充；setIamPolicy → 自授冒充权；roles.update → 给现有角色加权限；cloudfunctions.functions.update → 替换代码窃取凭据；compute.instances.setMetadata → 添加 ssh-keys；setServiceAccount → 附加高权限 SA；cloudbuild.builds.create → 以项目 SA 执行代码；deploymentmanager.deployments.create。
GCP IMDS 攻击：通过 Metadata-Flavor: Google header 访问 metadata.google.internal 获取 token。
Kubernetes
检查匿名访问 API、匿名绑定、SA token 被窃取后的 kubectl 枚举（namespaces、auth can-i --list、pods -A、secrets -A）。
K8s 提权模式：pods/exec → 进入高权限 pod；pods/create + serviceaccounts/use → 创建挂载管理员 SA token 的 pod；secrets/get → 读取任意 SA token；clusterrolebindings/create → 自授 cluster-admin；roles/clusterroles escalate → 添加权限；nodes/proxy → 通过 kubelet 执行；bind verb → 绑定角色；impersonate → 冒充他人。
工具参考
Pacu（AWS 红队框架，100+ 模块）、enumerate-iam.py（AWS 暴力枚举 API 调用）、PMapper（AWS 提权路径图）、CloudFox（AWS 侦察）、Prowler（AWS/Azure/GCP 合规扫描）、ScoutSuite（多云审计）、AzureHound（Azure BloodHound 式图）、MicroBurst（Azure 侦察滥用）、ROADtools（Entra ID 枚举）、GCPBucketBrute（GCS 桶权限枚举）、gcpwn（GCP 利用框架）、Peirates（K8s 利用工具包）、kube-hunter（集群扫描）、kubectl-trace（进程追踪）。
反模式
未经明确许可不得运行写/删除操作（IAM 变更具破坏性且可审计）；不要枚举账号内全部对象；不要在非测试凭据上使用 aws * 而未确认账号；不要混淆“拥有凭据”与“凭据有效”；不要假设一个账号的 STS token 可跨账号使用；不要忽略 CloudTrail/活动日志；不要超出 SOW 深入转移。
相邻技能衔接
hunt-cloud-misconfig（发现凭据）、hunt-ssrf（SSRF→IMDS 链）、apk-redteam-pipeline（APK 密钥提取）、supply-chain-attack-recon（CI/CD 凭据）、m365-entra-attack（Azure 跨产品）、mid-engagement-ir-detection（云控制面活动监控）。
严重性评分指引
AWS 访问密钥策略为 : 确认为管理员 = 严重；GCP SA JSON 拥有生产项目 roles/owner = 严重；互联网暴露 VM 上的 Azure MI 具 Owner 角色 = 严重；生产数据存储只读泄露凭据 = 高危（视数据敏感度可能严重）；具提权路径但尚未管理员 = 高危；仅非敏感只读 = 中危；匿名公开桶仅列出 = 低/中；匿名桶写权限 = 高危。
清理纪律
若使用 sts:AssumeRole 链、创建任何 IAM 资源、读取敏感数据，需在交付物中记录角色名、时间、资源清单与确认，并说明数据已被查看但未外泄。云活动极易审计，客户会在事后发现。
AWS Cognito Identity Pool 未认证角色攻击链（2024-2026 面）
Cognito 含两个易混淆服务：User Pools（认证提供者）与 Identity Pools（联合身份→IAM 凭据）。Identity Pools 若启用“允许未认证身份访问”，任意匿名调用者可通过 cognito-identity:GetId → GetCredentialsForIdentity 获得 IAM 角色。移动应用与 SPA 会在页面 bundle 中携带 IdentityPoolId（格式为 region:UUID，属公开标识）。开发者常为未认证角色附加过宽 IAM 权限。
发现步骤：用 JS bundle/SPA 正则（针对 .js、.html、source-map）以及 APK 反编译后（jadx）的 grep 查找 identityPoolId / PoolId。