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
2. spider the target for every login surface: main login, admin login, API login, partner portal, mobile API endpoints
3. check robots.txt, JS files, and the wayback machine for forgotten endpoints like /xmlrpc.php

1. Identify the auth mechanism per entry point
2. Is it forms-based, SAML, OAuth, API key, session token?
3. For WordPress: always probe /xmlrpc.php even if the main login is SSO-protected

1. Test XMLRPC independently of SSO
2. If site uses SSO (e.g., OneLogin), manually POST to /xmlrpc.php
3. XMLRPC uses WordPress-native credentials, not SSO — test with system.listMethods first, then wp.getUsersBlogs

1. Enumerate SAML implementation
2. Capture a valid SAMLResponse via Burp
3. Decode the Base64 payload, inspect the XML
4. Test signature stripping, comment injection, and XML wrapping attacks
5. Test if SP validates the signature at all (send unsigned assertion)

1. Test cross-portal session/token reuse
2. Log into partners.shopify.com type portals
3. Attempt to use the issued token/cookie against the main admin portal
4. Look for shared cookie domains, shared JWT secrets, or API tokens that work across contexts

1. Fuzz auth parameters
2. Null/empty passwords, password[]=array, SQL in username field
3. Try admin/admin, test/test on staging subdomains
4. Modify role, is_admin, user_type in JWTs (none algorithm, weak secret)

1. Check redirect and state parameters
2. Does removing state from OAuth break anything?
3. Can you change redirect_uri to an open redirect target?
4. Does the RelayState in SAML get validated?

1. Verify impact by escalating privileges
2. Don't stop at login — prove you can access admin functions, other users' data, or sensitive configuration
3. 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_adm/admin.dll, /_vti_bin/owssvr.dll | FrontPage RPC; sometimes still wired to credential validators | | SharePoint REST | /_api/contextinfo (POST), /_api/$metadata | Anonymous FormDigest issuance; full API surface enumeration | | Atlassian (Jira / Confluence) | /rest/auth/1/session (basic-auth), /rest/api/2/myself, legacy /rest/api/1.0/ | Native credentials accepted on /rest/auth/1/session even when Atlassian Crowd / Atlassian Access SSO is enforced on the UI | | Drupal | /jsonapi/, /user/login?_format=json | JSON POST endpoint that accepts native passwords; separate from SSO middleware | | Drupal (D7 legacy) | /?q=user/login, /services/, /rest/ | Older REST modules with independent auth | | Joomla | /administrator/index.php?option=com_login, /api/index.php/v1/users | Native Joomla credentials accepted on admin entry independent of any front-site SSO | | Exchange / OWA | /EWS/Exchange.asmx, /Autodiscover/Autodiscover.xml, /Microsoft-Server-ActiveSync | NTLM / Basic; bypasses OWA UI restrictions (MFA, IP-allow). The classic CVE-2020-0688 / CVE-2021-26855 surface | | Citrix NetScaler | /vpn/index.html, /cgi/login, /nf/auth/doAuthentication.do | Native AD credentials; independent of MFA wrappers | | F5 BIG-IP | /mgmt/tm/util/bash, /tmui/login.jsp | Native admin credentials | | Generic ASP.NET app | .asmx?WSDL, .svc?WSDL, trace.axd, elmah.axd, .disco | Find every web service; many take credentials independently of the WebForms login | | Spring Boot | /actuator/, /management/, /api/v1/auth/login, /api/v1/swagger-ui | Actuator endpoints sometimes anonymously enumerable | | Jenkins | /jnlpJars/jenkins-cli.jar, /script, /manage, /computer/(master)/script | API tokens + native auth | | GitLab | /api/v3/ (deprecated but still on old installs), /api/v4/users, /api/v4/projects | Personal Access Tokens with looser scoping than UI session | | TeamCity | /app/rest/users, /login.html?username=&password= (GET-form-login) | Native admin credentials | | Apache Tomcat | /manager/html, /host-manager/html, /manager/text/list | Native Tomcat realm credentials independent of any front auth | | WebLogic | /console/login/LoginForm.jsp, /wls-wsat/ | Native admin | | Oracle EBS / PeopleSoft | /OA_HTML/AppsLogin, /psp/*/?cmd=login | Native ERP credentials |

How to use:

1. Identify the tech stack from hea