hunt-auth-bypass
The hunt-auth-bypass skill identifies authentication bypass vulnerabilities across SSO, SAML, OAuth, JWT, and XMLRPC implementations by applying patterns from 12 documented bug bounty cases including signature stripping, parser differentials, token confusion, and algorithm confusion attacks. Use this skill when hunting authentication weaknesses in enterprise SaaS platforms, admin panels, partner portals, WordPress plugins, and federated identity systems where auth flaws typically command high bounty payouts.
git clone --depth 1 https://github.com/elementalsouls/Claude-BugHunter /tmp/hunt-auth-bypass && cp -r /tmp/hunt-auth-bypass/skills/hunt-auth-bypass ~/.claude/skills/hunt-auth-bypassSKILL.md
## Crown Jewel Targets Auth bypass is consistently one of the highest-paying vulnerability classes in bug bounty because it directly violates the most fundamental security control. High-value targets include: - **SSO/SAML implementations** at enterprise SaaS companies (Slack, Okta, OneLogin integrations) — payouts regularly in the $5K–$25K+ range - **Admin panels and partner/internal portals** — subdomain-separated admin surfaces like `partners.shopify.com`, `admin.company.com` - **Third-party auth plugin integrations** — WordPress plugins (OneLogin, WP-SAML-Auth), Drupal SSO modules, any CMS with pluggable auth - **XMLRPC endpoints** on WordPress — often forgotten, bypasses standard WP auth flows entirely - **OAuth callback flows** — state parameter mishandling, redirect_uri mismatches - **API authentication layers** — especially where auth was bolted on after the fact **Asset priority:** Targets with federated identity (SAML, OAuth, OIDC) connected to large user populations. Partner/reseller portals are particularly juicy because they often have elevated permissions and less security scrutiny than the main product. --- ### SSH certificate-authority trust forgery (Git-hosting / enterprise platforms) When an org or instance registers an SSH certificate authority, cert `principals` may not be bound server-side to the requesting identity — a member can mint a cert asserting another user's principal and authenticate as them (e.g. modify another user's resource given only its URL). Add SSH-CA trust to the auth-surface list on Git-hosting targets; niche/platform-specific. Disclosed: reports/1901040. ## Attack Surface Signals **URL patterns to hunt:** ``` /xmlrpc.php /wp-login.php /saml/ /sso/ /auth/saml/callback /oauth/callback /partners.* /admin.* /?wc-api= /api/v*/auth /login?redirect= /accounts/login ``` **Response headers signaling SSO:** ``` X-Frame-Options: SAMEORIGIN (common on SSO portals) Set-Cookie: SAMLResponse= Location: https://idp.company.com/saml WWW-Authenticate: Bearer realm="partners" ``` **JS patterns indicating federated auth:** ```javascript // Look for in page source samlRequest RelayState SAMLResponse onelogin shibboleth okta passport.js authenticate ``` **Tech stack signals:** - WordPress + any SSO plugin → check XMLRPC separately - Shopify Partner API exposure → cross-tenant privilege escalation risk - Any app advertising "SSO enabled" or "Login with [Enterprise IdP]" - Separate subdomains for admin/partner that share session cookies with main domain - Applications using `SimpleSAMLphp`, `ruby-saml`, `python-saml` **Burp passive scan triggers:** - `SAMLResponse` in any POST body - `openid_connect` or `id_token` in responses - Cookie domains set to `.company.com` (wildcard) --- ## Step-by-Step Hunting Methodology 1. **Map all authentication entry points** - spider the target for every login surface: main login, admin login, API login, partner portal, mobile API endpoints - check `robots.txt`, JS files, and the wayback machine for forgotten endpoints like `/xmlrpc.php` 2. **Identify the auth mechanism per entry point** - Is it forms-based, SAML, OAuth, API key, session token? - For WordPress: always probe `/xmlrpc.php` even if the main login is SSO-protected 3. **Test XMLRPC independently of SSO** - If site uses SSO (e.g., OneLogin), manually POST to `/xmlrpc.php` - XMLRPC uses WordPress-native credentials, not SSO — test with `system.listMethods` first, then `wp.getUsersBlogs` 4. **Enumerate SAML implementation** - Capture a valid SAMLResponse via Burp - Decode the Base64 payload, inspect the XML - Test signature stripping, comment injection, and XML wrapping attacks - Test if SP validates the signature at all (send unsigned assertion) 5. **Test cross-portal session/token reuse** - Log into `partners.shopify.com` type portals - Attempt to use the issued token/cookie against the main admin portal - Look for shared cookie domains, shared JWT secrets, or API tokens that work across contexts 6. **Fuzz auth parameters** - Null/empty passwords, `password[]=array`, SQL in username field - Try `admin`/`admin`, `test`/`test` on staging subdomains - Modify `role`, `is_admin`, `user_type` in JWTs (none algorithm, weak secret) 7. **Check redirect and state parameters** - Does removing `state` from OAuth break anything? - Can you change `redirect_uri` to an open redirect target? - Does the `RelayState` in SAML get validated? 8. **Verify impact by escalating privileges** - Don't stop at login — prove you can access admin functions, other users' data, or sensitive configuration - Screenshot the highest-privilege action you can perform --- ## Legacy-Protocol Matrix (Probe These First on Any Custom-Branded Login) When a target has a custom, branded login UI (e.g. `customlogin.aspx`, `/auth/signin`, `/account/login`), **always probe the platform's legacy protocol endpoints with native credentials** in parallel. These endpoints frequently outlive the custom UI's protections and accept native credentials with NO rate limit, NO MFA challenge, NO CAPTCHA, NO anti-automation. This is the WordPress XMLRPC pattern generalised across CMS / portal / framework stacks. | Target tech | Legacy endpoint(s) to probe | Native-cred bypass surface | |---|---|---| | **WordPress** | `/xmlrpc.php` (`system.listMethods`, `wp.getUsersBlogs`, `system.multicall`) | Native WP user/pass; bypasses SSO, MFA, IP-allow rules on `/wp-login.php` | | **WordPress (REST)** | `/?rest_route=/wp/v2/users`, `/wp-json/wp/v2/users` | User enumeration anonymously even when login page is hardened | | **SharePoint (any version)** | `/_vti_bin/Authentication.asmx` (`Mode` + `Login` SOAP ops) | Native Forms-auth credential; FedAuth cookie returned; no rate limit on this endpoint observed on SP2013 farms — **this is the canonical SP equivalent of the WP XMLRPC bypass** | | **SharePoint legacy** | `/_vti_bin/_vti_aut/author.dll`, `/_vti_bin/_vti_a
End-to-end Android APK red-team pipeline — automated APK acquisition (Play Store + apkpure + apkmirror fallback), jadx decompilation, secret/URL/JWT/Firebase grep, pinned-cert extraction, exported-component enumeration, Frida runtime instrumentation templates, intent-injection probes. Built from an authorized external red-team engagement where 7 APKs were pulled manually, 4 download attempts truncated, and a hardcoded JWT + 30 internal API endpoints were recovered from one of the apps. Use when target has a mobile app catalogue (Play Store developer page), when you find an APK URL hosted on a web server, or when post-recon mentions "mobile app" in scope.
Run autonomous hunt loop on a target — scope check → recon → rank surface → hunt → validate → report with configurable checkpoints. Usage: /autopilot target.com [--paranoid|--normal|--yolo]
Local-tooling companion to the bug-bounty orchestrator — carries the SAME complete bug-bounty workflow, but reach for THIS variant when you also need to resolve where tools, wordlists, and clones are installed on the local machine (jhaddix, SecLists, trufflehog, ffuf, dalfox, ghauri); for pure orchestration/routing use the bug-bounty skill. Workflow it covers — recon (subdomain enumeration, asset discovery, fingerprinting, HackerOne scope, source code audit), pre-hunt learning (disclosed reports, tech stack research, mind maps, threat modeling), vulnerability hunting (IDOR, SSRF, XSS, auth bypass, CSRF, race conditions, SQLi, XXE, file upload, business logic, GraphQL, HTTP smuggling, cache poisoning, OAuth, timing side-channels, OIDC, SSTI, subdomain takeover, cloud misconfig, ATO chains, agentic AI), LLM/AI security testing (chatbot IDOR, prompt injection, indirect injection, ASCII smuggling, exfil channels, RCE via code tools, system prompt extraction, ASI01-ASI10), A-to-B bug chaining (IDOR→auth bypass, SSRF→cloud metadata, XSS→ATO, open redirect→OAuth theft, S3→bundle→secret→OAuth), bypass tables (SSRF IP bypass, open redirect bypass, file upload bypass), language-specific grep (JS prototype pollution, Python pickle, PHP type juggling, Go template.HTML, Ruby YAML.load, Rust unwrap), and reporting (7-Question Gate, 4 validation gates, human-tone writing, templates by vuln class, CVSS 3.1, PoC generation, always-rejected list, conditional chain table, submission checklist). Use when you need the local install path of a tool / wordlist / clone for a hunt, or as the full-workflow variant when operating from this local toolkit; for general routing use the bug-bounty skill. 中文触发词：漏洞赏金、安全测试、渗透测试、漏洞挖掘、信息收集、子域名枚举、XSS测试、SQL注入、SSRF、安全审计、漏洞报告
Use at the START of any bug bounty hunting session, when switching targets, or when feeling lost about what to do next. Master orchestrator that combines the 5-phase non-linear hunting workflow with the critical thinking framework (developer psychology, anomaly detection, What-If experiments). Routes to all other skills based on current hunting phase. Also use when asking "what should I do next" or "where am I in the process.
Complete bug bounty workflow — recon (subdomain enumeration, asset discovery, fingerprinting, HackerOne scope, source code audit), pre-hunt learning (disclosed reports, tech stack research, mind maps, threat modeling), vulnerability hunting (IDOR, SSRF, XSS, auth bypass, CSRF, race conditions, SQLi, XXE, file upload, business logic, GraphQL, HTTP smuggling, cache poisoning, OAuth, timing side-channels, OIDC, SSTI, subdomain takeover, cloud misconfig, ATO chains, agentic AI), LLM/AI security testing (chatbot IDOR, prompt injection, indirect injection, ASCII smuggling, exfil channels, RCE via code tools, system prompt extraction, ASI01-ASI10), A-to-B bug chaining (IDOR→auth bypass, SSRF→cloud metadata, XSS→ATO, open redirect→OAuth theft, S3→bundle→secret→OAuth), bypass tables (SSRF IP bypass, open redirect bypass, file upload bypass), language-specific grep (JS prototype pollution, Python pickle, PHP type juggling, Go template.HTML, Ruby YAML.load, Rust unwrap), and reporting (7-Question Gate, 4 validation gates, human-tone writing, templates by vuln class, CVSS 3.1, PoC generation, always-rejected list, conditional chain table, submission checklist). Use for ANY bug bounty task — starting a new target, doing recon, hunting specific vulns, auditing source code, testing AI features, validating findings, or writing reports. 中文触发词：漏洞赏金、安全测试、渗透测试、漏洞挖掘、信息收集、子域名枚举、XSS测试、SQL注入、SSRF、安全审计、漏洞报告
Bugcrowd-specific reporting tactics complementing report-writing: VRT category search-and-fallback strategy when no exact match exists, manual severity override when VRT defaults underrate impact, severity-request paragraph as first body section, OOS-clause rebuttal templates (rate limiting on auth-flow endpoints, debug-info framing, user-enumeration with sensitive PII, theoretical-issue counter), chained-finding cross-reference patterns, target selection for QA-vs-prod programs, researcher-side hygiene (Bugcrowdninja email alias, account state restoration, friendly-tester posture). Use when filing a Bugcrowd submission, when VRT default seems wrong, when triager closes as OOS or downgrades severity, when chaining linked submissions, or when scope distinguishes production from QA. Pairs with report-writing and triage-validation.
Build an exploit chain — given bug A, finds B and C to combine for higher severity and payout. Knows common chain patterns: IDOR→ATO, SSRF→cloud metadata, XSS→ATO, open redirect→OAuth theft, S3→bundle→secret→OAuth. Usage: /chain
Cloud IAM red-team attack chain across AWS, Azure, GCP — focused on EXTERNAL exploitation paths and post-credential-discovery privilege analysis. Covers IAM enumeration (aws iam, az role, gcloud iam), STS/AssumeRole chaining, Azure Managed Identity abuse (via SSRF/leak), GCP service account JSON abuse, IMDSv1/v2 attacks via SSRF, K8s ServiceAccount token privilege analysis once held (token discovery / cluster exposure is owned by hunt-k8s), role-trust-policy confused-deputy, cross-account assume-role enumeration, IAM privilege escalation patterns (24+ AWS, 8+ Azure, 6+ GCP), and AWS Cognito Identity Pool unauthenticated-role attack chain (GetId → GetCredentialsForIdentity → IAM role abuse). Built for the case where recon yields a credential (key, JSON, token) and you need to know what it grants and how to escalate. Use when an AWS key / Azure secret / GCP service account JSON / K8s SA token surfaces from a code repo, JS bundle, APK, breach corpus, or SSRF chain.