hunt-auth-bypass

---

name: hunt-auth-bypass description: Hunting skill for auth bypass vulnerabilities. Built from 12 public bug bounty reports across SAML XSW / parser-differential (GitHub Enterprise CVE-2025-25291/25292), SAML signature stripping (Uber, Rocket.Chat, samlify CVE-2025-47949), SAML domain enforcement bypass via control characters (HackerOne 2024), partner-portal cross-IdP assertion reuse (Slack), WordPress XMLRPC bypassing SSO (Uber), JWT alg-confusion HS256/RS256 (Jitsi), JWT signature-validation skip (Linktree, Newspack), and token-audience confusion (Argo CD CVE-2023-22482). For standalone JWT signature/crypto forging (alg:none, key confusion, kid/jku) see hunt-jwt-crypto; this skill covers JWT only inside SSO/SAML/token-trust bypass chains. SAML assertion-layer attacks (XSW, comment injection, signature stripping, XXE-in-assertion) are owned by hunt-saml; this skill owns the broader cross-protocol auth-bypass taxonomy. Use when hunting auth bypass — see the Legacy-Protocol Matrix for branded-UI vs legacy-endpoint patterns. sources: github, hackerone_public, github_security_lab, projectdiscovery_research report_count: 12

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, 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_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 headers + paths (use hunt-misc Attack Surface Signals).
2. Find the row above that matches.
3. Probe the legacy endpoint anonymously to confirm it's reachable and not 403/404.
4. Test with synthetic credentials to confirm it accepts native credential format and returns differential responses (success vs failure).
5. Verify there is no rate limit, no lockout, no CAPTCHA — burst 10 requests at the same user, confirm uniform timing.
6. Report as Critical / High depending on chain to ATO: an anonymous + unlimited credential brute-force endpoint is consistently Critical on bug-bounty programs.

Lesson from a authorized engagement: A an enterprise dealer portal on SharePoint 2013 had a custom branded customlogin.aspx. The hunt-auth-bypass skill was loaded but the matrix above did not exist in this document — and the WordPress XMLRPC pattern was not connected to the SharePoint equivalent. /_vti_bin/Authentication.asmx was reachable anonymously, accepted unlimited credential attempts with no rate limit and no lockout, and was the highest-impact finding in the engagement. Walking this matrix on the first pass would have surfaced it immediately.

---

Payload & Detection Patterns

XMLRPC auth probe (bypasses SSO):

curl -s -X POST https://target.com/xmlrpc.php \
  -H "Content-Type: text/xml" \
  -d '<?xml version="1.0"?>
<methodCall>
  <methodName>system.listMethods</methodName>
  <params></params>
</methodCall>'

# If 200 with method list → XMLRPC is enabled, test auth:
curl -s -X POST https://target.com/xmlrpc.php \
  -H "Content-Type: text/xml" \
  -d '<?xml version="1.0"?>
<methodCall>
  <methodName>wp.getUsersBlogs</methodName>
  <params>
    <param><value><string>admin</string></value></param>
    <param><value><string>password</string></value></param>
  </params>
</methodCall>'

SAML signature stripping (send unsigned assertion):

import base64, re

# Decode captured SAMLResponse
saml_b64 = "BASE64_FROM_BURP"
saml_xml = base64.b64decode(saml_b64).decode()

# Strip the Signature element entirely
stripped = re.sub(r'<ds:Signature.*?</ds:Signature>', '', saml_xml, flags=re.DOTALL)

# Re-encode and submit
print(base64.b64encode(stripped.encode()).decode())

SAML XML comment injection (username confusion):

<!-- Original NameID -->
<NameID>attacker@evil.com</NameID>

<!-- Injected