菜单
Escalate SSRF to cloud credential theft via the instance metadata service (IMDS). Load when SSRF is confirmed AND the target runs on AWS/GCP/Azure. Signals: 169.254.169.254 reachable, cloud-hosted app, SSRF that can set arbitrary Host/headers, "metadata".
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/NoorQureshi/SploitAgent --skill cloud-imds-ssrf命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Attack Active Directory Certificate Services (ADCS) — ESC1–ESC8 template/CA misconfigurations to escalate to Domain Admin. Load with a domain foothold/creds where ADCS is present, on "certipy", "ESC1", "certificate template", or a CA server. Signals: Cert Publishers, pKIEnrollmentService, ports 443/135 on a CA, certipy find output.
Abuse Active Directory object ACLs/DACLs for lateral movement and escalation — GenericAll, WriteDACL, GenericWrite, WriteOwner, AddMember, ForceChangePassword, and DCSync rights. Load with domain creds + BloodHound showing an ACL edge, on "GenericAll", "WriteDACL", "DCSync", "abuse this edge".
Kerberoasting & AS-REP roasting — request/crack Kerberos tickets to recover service/user passwords offline. Load with any domain foothold or valid domain creds, on "kerberoast", "AS-REP", SPNs, service accounts, ports 88/389. Signals: domain creds in hand, SPNs set, accounts with pre-auth disabled.
正在显示 SKILL.md
| name | cloud-imds-ssrf |
| description | Escalate SSRF to cloud credential theft via the instance metadata service (IMDS). Load when SSRF is confirmed AND the target runs on AWS/GCP/Azure. Signals: 169.254.169.254 reachable, cloud-hosted app, SSRF that can set arbitrary Host/headers, "metadata". |
| domain | cloud |
| type | technique |
| stability | learning |
| modes | ["pentest","bugbounty"] |
| severity | critical |
| owasp | ["A10:2021-SSRF"] |
| cwe | ["CWE-918"] |
| mitre | ["T1552.005"] |
| tools | ["curl","awscli"] |
| schema_version | 1 |
You have SSRF and the app runs on a cloud VM/container with an attached role. The metadata endpoint hands out temporary credentials to anything that can reach it from the instance.
IMDS lives at a link-local IP (169.254.169.254) and trusts network position, not identity.
SSRF gives you that position, so the app fetches the instance's role credentials for you —
then you use them against the cloud API with the app's permissions.
http://169.254.169.254/latest/meta-data/iam/security-credentials/ → role name →
.../security-credentials/<role> returns AccessKeyId, SecretAccessKey, Token.X-aws-ec2-metadata-token header. Many SSRFs can't;
note IMDSv2 as the mitigation if it blocks you.http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
with header Metadata-Flavor: Google (needs header-setting SSRF).http://169.254.169.254/metadata/identity/oauth2/token?... with Metadata: true.aws sts get-caller-identity, s3 ls) to prove impact — don't touch data.Metadata header requirements defeat header-less SSRF — that's a finding (says v2 is on), not a dead end.sts get-caller-identity immediately as proof.169.254.170.2) instead of EC2 IMDS.aws sts get-caller-identity (or GCP/Azure equivalent) returns the instance role identity
using credentials pulled through the SSRF.
PortSwigger SSRF labs; AWS IMDSv2 docs; "SSRF to cloud takeover" write-ups.