hunt-auth-bypass

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.

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

How to use:

1. Identify the tech stack from hea