AWS Pentesting

AWS 云环境渗透测试方法论

AWS 是全球最大的公有云平台，承载了大量企业核心业务系统。其超过 200 项服务构成了庞大的攻击面——IAM 策略配置错误、S3 Bucket 暴露、EC2 元数据泄露、Lambda 函数 URL 未鉴权等问题在实际评估中频繁出现。本技能以攻击阶段（Phase）为主线，组织从"零凭据"到"完全控制"的完整渗透路径，并通过决策树引导到专项技能深入。

深入参考

识别到具体攻击阶段后，加载对应参考文档获取完整技术细节：

• 未授权枚举技术清单（25+ 服务） → 读 references/unauthenticated-enum.md
• 持久化技术清单（22+ 服务） → 读 references/persistence-techniques.md

Phase 0: 攻击面判断

拿到一个 AWS 相关目标后，首先判断当前手持的资产类型，决定进入哪个攻击阶段：

当前持有什么？
├── 无任何凭据
│   ├── 有目标域名/IP → Phase 1（未授权枚举）
│   ├── 有 SSRF 漏洞 → 直接打元数据服务获取凭据 → Phase 2
│   └── 仅知道组织名称 → OSINT + Phase 1
│
├── 有 AWS AK/SK（AKIA 开头 = 长期密钥）
│   └── → Phase 2（凭据验证与权限评估）
│
├── 有临时凭据（ASIA 开头 + SessionToken）
│   └── → Phase 2（注意：有效期通常 1-12 小时，需快速行动）
│
├── 在 EC2/Lambda/ECS 实例内部
│   └── → 通过元数据获取绑定的 IAM Role 凭据 → Phase 2
│
└── 有 AWS SSO Token / IAM Identity Center 会话
    └── → Phase 2（需额外确认可访问的账户和角色）

AWS 凭据类型速查

Canary Token 检测

在使用获取到的凭据前，应先判断是否为蜜罐令牌（Canary Token）。使用蜜罐凭据会立即触发告警。常见特征：

• AccessKeyId 与已知蜜罐服务（如 Thinkst Canaries、SpaceCrab）的格式匹配
• 来自异常渠道（故意暴露的配置文件、过于明显的泄露点）
• 可通过 aws sts get-access-key-info --access-key-id AKIA... 查询所属账户，与已知蜜罐账户比对

Phase 1: 未授权枚举

在没有任何 AWS 凭据的情况下，仍可对目标进行大量信息收集。AWS 有 25+ 服务存在未授权枚举面。

高价值枚举目标

S3 快速枚举流程

# 1. 检查 Bucket 是否存在并可列出
aws s3 ls s3://TARGET-BUCKET --no-sign-request

# 2. 如果可列出，递归下载敏感文件
aws s3 cp s3://TARGET-BUCKET/ ./loot/ --recursive --no-sign-request \
  --exclude "*" --include "*.env" --include "*.pem" --include "*.key" \
  --include "*credentials*" --include "*config*"

# 3. 通过 Bucket 反查 Account ID
pip install s3-account-search
s3-account-search arn:aws:iam::YOUR_ACCT:role/YOUR_ROLE s3://TARGET-BUCKET

Cognito 快速利用

# 如果发现 Identity Pool ID（格式：region:guid），获取未认证凭据
aws cognito-identity get-id --identity-pool-id "us-east-1:xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx"
aws cognito-identity get-credentials-for-identity --identity-id "us-east-1:yyyyy"

# 如果发现 User Pool Client ID，尝试注册
aws cognito-idp sign-up --client-id CLIENT_ID --username test@test.com --password 'P@ssw0rd123!'

→ 完整的 25+ 服务枚举清单，读 references/unauthenticated-enum.md

Phase 2: 凭据验证与权限评估

获取凭据后，第一步是验证有效性并评估权限范围。

2.1 凭据验证

# 身份确认（最基础的检查）
aws sts get-caller-identity

# 返回示例：
# Account: 123456789012
# UserId: AIDA...
# Arn: arn:aws:iam::123456789012:user/developer

# 判断凭据类型
aws sts get-access-key-info --access-key-id AKIA...

2.2 权限枚举

# 方法一：直接查询 IAM 策略（需要 iam 读权限）
aws iam get-user
aws iam list-attached-user-policies --user-name USERNAME
aws iam list-user-policies --user-name USERNAME
aws iam list-groups-for-user --user-name USERNAME

# 方法二：如果是 Role
aws iam list-attached-role-policies --role-name ROLENAME
aws iam list-role-policies --role-name ROLENAME

# 方法三：暴力枚举权限（无需 IAM 读权限）
# enumerate-iam 工具会尝试调用大量 API 来探测可用权限
pip install enumerate-iam
enumerate-iam --access-key AKIA... --secret-key ...

2.3 权限评估决策树

当前身份权限如何？
├── 有 iam:* 或 AdministratorAccess → 已是管理员，直接 Phase 4
├── 有 iam 读权限但无写权限 → 枚举所有用户/角色/策略，寻找提权路径 → Phase 3
├── 有特定服务权限（如 s3:*、ec2:*、lambda:*）
│   ├── 检查是否有 iam:PassRole → 可能通过 PassRole 提权 → Phase 3
│   ├── 有 ec2:RunInstances + iam:PassRole → EC2 提权 → Phase 3
│   └── 可直接利用当前权限进行后渗透 → Phase 4
└── 权限极低 → 尝试暴力枚举更多权限，或回到 Phase 1 寻找更多入口

参考 aws-iam-policy-analysis 技能，进行深度策略分析

参考 cloud-iam-audit 技能，进行跨云 IAM 审计

参考 cloud-aksk-exploit 技能，获取 AK/SK 完整利用链

2.4 自动化审计工具

Phase 3: 提权

AWS 提权的核心思路：利用当前权限去获取更高权限。AWS 有数百个权限，其中很多组合可以形成提权路径。

常见提权路径概览

PassRole 提权原理

iam:PassRole 是 AWS 提权中最核心的权限之一。它允许用户将一个 IAM Role "传递"给 AWS 服务。如果用户有 iam:PassRole 加上某个服务的创建权限（如 ec2:RunInstances、lambda:CreateFunction），就可以创建一个绑定了高权限 Role 的资源，然后通过该资源间接获得高权限。

攻击者拥有: iam:PassRole + lambda:CreateFunction + lambda:InvokeFunction
    │
    ├─ 1. 创建 Lambda 函数，绑定一个拥有 AdministratorAccess 的 Role
    ├─ 2. Lambda 代码中调用 IAM API 给攻击者账户添加 Admin 策略
    └─ 3. 调用该 Lambda → 攻击者获得管理员权限

参考 aws-iam-privesc 技能，获取 46 个服务的详细提权路径

Phase 4: 后渗透与持久化

获得较高权限后，进入后渗透阶段。目标是数据获取、横向移动和建立持久化。

4.1 数据发现与获取

优先搜索哪些数据源？
├── S3 Bucket → 文档、备份、日志、配置文件
├── RDS / DynamoDB → 业务数据库
├── Secrets Manager / Parameter Store → 凭据和配置
├── EBS 快照 → 挂载后可读取完整文件系统
├── CloudWatch Logs → 应用日志中的敏感信息
└── CodeCommit → 代码仓库

4.2 横向移动

AWS 环境中的横向移动主要发生在两个维度：

跨账户移动：

• 利用 OrganizationAccountAccessRole（管理账户 → 成员账户）
• 利用跨账户角色信任策略（sts:AssumeRole）
• 利用共享资源（S3 Bucket Policy、KMS Key Policy）

跨服务移动：

• EC2 实例上的 SSM Agent → SSM RunCommand 横向到其他实例
• ECS/EKS 任务角色 → 容器逃逸到宿主机
• Lambda 函数角色 → 修改函数代码执行任意操作

4.3 持久化技术概览

→ 完整的 22+ 服务持久化技术清单，读 references/persistence-techniques.md

参考 aws-post-exploit 技能，获取数据窃取与横向移动深度指南

附录: AWS 速查

常用 AWS CLI 命令

# 身份与权限
aws sts get-caller-identity                           # 当前身份
aws iam get-user                                      # 当前 IAM 用户信息
aws iam list-attached-user-policies --user-name USER  # 附加的策略
aws iam list-roles                                    # 列出所有角色
aws organizations list-accounts                       # 列出组织内所有账户

# 枚举资源
aws s3 ls                                             # 列出所有 S3 Bucket
aws ec2 describe-instances --region REGION             # 列出 EC2 实例
aws lambda list-functions --region REGION              # 列出 Lambda 函数
aws rds describe-db-instances --region REGION           # 列出 RDS 实例
aws secretsmanager list-secrets --region REGION         # 列出 Secrets

# 凭据操作
aws sts assume-role --role-arn ARN --role-session-name s   # 切换角色
aws sts get-session-token --duration-seconds 43200         # 获取临时凭据

# 元数据服务（从 EC2 实例内部）
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/

AWS 服务缩写对照表

注意事项

CloudTrail 审计感知： 几乎所有 AWS API 调用都会被 CloudTrail 记录。以下操作会产生高可见性日志事件：

• IAM 变更（CreateUser、AttachPolicy、CreateAccessKey）
• 角色切换（AssumeRole）
• 跨区域操作

部分 API 在 CloudTrail 中为"数据事件"（如 S3 GetObject），默认不记录但组织可能启用了。

GuardDuty 检测风险： GuardDuty 会检测以下行为：

• 凭据在异常 IP/区域使用
• EC2 实例与已知恶意 IP 通信
• S3 大规模数据导出
• IAM 异常权限变更
• DNS 隧道流量

速率限制： AWS API 有速率限制（通常每秒 5-20 次调用），暴力枚举时需注意节流，否则会触发 ThrottlingException 并可能引起告警。

区域差异： AWS 资源是区域隔离的。枚举时需遍历所有启用的区域（aws ec2 describe-regions），不要只检查 us-east-1。全球服务（IAM、Route53、CloudFront、STS）不受区域限制。