hunt-auth-bypass

> **⚠️ AUTHORIZED USE ONLY**

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> **Mandatory confirmation gate**

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

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:**

// 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,