Admin Panel Recon for Bug Bounty: Forgotten Hosts and Endpoints
Admin surfaces are where authorization bugs cluster: impersonation, user lookup, feature flags, refund tools. Finding them is half the engagement. The other half is proving access control fails — but you cannot test what you never discover.
Stay inside scope. Recon without blasting unrelated corporate ranges.
Clues in the main app
Before DNS fireworks, read what the product already hands you:
- JavaScript bundles mentioning
/admin,/backoffice,staff,impersonate - Source maps (when exposed) with internal route tables
- Mobile apps and desktop clients with alternate API hosts
- Emails and password resets linking to
admin.ormanage.hosts - Error messages that quote internal panel URLs
A single string in a chunk file often beats a week of blind content discovery.
Host and vhost angles
From in-scope root domains, enumerate plausible admin names: admin, adm, internal, ops, dashboard, cms, grafana, kibana, phpmyadmin — but only on hosts the program listed or that clearly belong to the same asset group. Check TLS certificates and HTTP title hashes to confirm ownership.
Virtual hosts on the same IP sometimes serve a different app when you change the Host header. That trick is powerful and easy to get wrong legally; use it only when the IP/host pair is clearly in scope.
Path discovery that does not burn ASNs
Prefer wordlists tuned for the stack (Django admin, Rails /admin, WordPress /wp-admin, Next.js /api/admin). Throttle. Prefer HEAD/GET with low concurrency. Record interesting status flips (401/403 vs 404) — a 401 on /admin is a finding lead, not yet a vulnerability.
robots.txt and sitemap.xml still occasionally name private paths. So do old marketing sites and status pages.
Forgotten endpoints
Look for:
- Old API versions (
/api/v1/...still live besidev3) - Debug routes (
/__debug__,/actuator,/jmx,/server-status) - Metrics and health UIs with data beyond “ok”
- GraphQL introspection left on in production
- Swagger/OpenAPI hosted on public URLs
GraphQL and OpenAPI docs are maps. Download them early and diff against what the UI uses.
From discovery to bug
Recon alone rarely pays. Once you find a panel:
- Try your normal user session — any access?
- Try unauthenticated — default creds only if policy allows and you stay gentle.
- Test IDOR and role bypass on admin APIs discovered in JS.
- Check whether SSO bypasses local lockout controls.
Historical asset lists help: archived status pages, old job posts naming internal tools, and Wayback captures of /admin paths that still respond on a forgotten subdomain.
Frame impact around privileged actions, not “I found /admin returns 401.”
Defensive asks
Recommend separate admin origins with stronger auth (SSO + hardware keys), IP allowlists where practical, no public debug endpoints, and inventory scans that alert on new admin-like routes.
Pair methodology with OWASP information gathering and treat exposed management UIs under CWE-200 when they leak sensitive configuration.
Good recon is quiet, scoped, and always ends in an authorization test — not a trophy screenshot of a login form.