How to Find Exposed Admin Panels on Your Network
What asset inventory do you need before scanning?
Before scanning, establish what you’re scanning. List every domain, subdomain, and IP range your organisation owns or operates. This includes:
- Primary domains and all subdomains (including those delegated to third parties)
- Cloud provider IP ranges (AWS, Azure, GCP elastic IPs)
- CDN and SaaS endpoints configured for your domains
- IP addresses allocated to your organisation (check your ARIN/RIPE records)
If your inventory is incomplete - and it usually is - subdomain enumeration and certificate transparency log analysis will reveal assets you’ve missed. Our subdomain enumeration guide covers this in detail.
How do you manually discover exposed admin panels?
Port scanning with Nmap
Start with a broad port scan of your external IP ranges, targeting ports where admin panels commonly live:
nmap -sV -p 80,443,2083,2087,3000,5601,8080,8443,8888,9090,9200,9443 your-ip-range
The -sV flag performs service version detection, which helps identify what’s running behind each open port. A response on port 3000 with a Grafana version header is actionable information.
Path brute-forcing
For web servers on standard HTTP/HTTPS ports, check common management paths. Tools like ffuf and Gobuster automate this:
ffuf -u https://example.com/FUZZ -w /path/to/admin-panels-wordlist.txt
Common paths to check:
/admin,/administrator,/wp-admin,/wp-login.php/phpmyadmin,/pma,/adminer/jenkins,/manage/grafana,/kibana/cpanel,/webmail/_panel,/_admin,/_dashboard
Google dorking
Google indexes admin login pages. Search operators can surface your own exposed panels:
site:example.com inurl:adminsite:example.com inurl:loginsite:example.com intitle:"dashboard" OR intitle:"admin"
Replace example.com with your domain. Check all subdomains, not just the primary domain.
Shodan and Censys
These search engines index internet-facing services, including management interfaces. Query for your organisation’s IP ranges or domains:
- Shodan:
org:"Your Company" http.title:"login" - Censys:
services.http.response.html_title: "phpMyAdmin" AND ip: your-range
These engines scan the internet continuously, so they often find panels before your own security team does.
Why is continuous automated scanning essential?
Manual methods work for point-in-time assessments, but attack surfaces change constantly. New panels appear when:
- A developer deploys a staging environment
- Operations installs a monitoring tool
- A cloud instance is provisioned with default security groups
- A contractor sets up a project management tool on a subdomain
Continuous automated scanning catches these exposures as they appear, not at the next quarterly pen test.
How SurfaceLoop handles this
SurfaceLoop combines subdomain discovery, port scanning, and panel fingerprinting into continuous automated scans. When a new admin panel appears on your attack surface, you’re notified with the exact URL, panel type, and recommended remediation - within hours, not months.
See Exposed Web Panels feature →What should you do when you find an exposed panel?
When you discover an exposed admin panel, the response priority is:
-
Restrict network access immediately. Add firewall rules or security group rules to block public access. This is the fastest way to eliminate the risk - even before addressing credentials or patching.
-
Check for compromise. Review access logs for the panel. Look for successful logins from unexpected IP addresses, especially if the panel used default credentials.
-
Rotate credentials. Change all passwords for accounts on the panel. If the panel had access to other systems (database credentials, API keys), rotate those too.
-
Investigate root cause. Why was the panel exposed? Misconfigured firewall? Default cloud security group? Developer shortcut? Fix the process that created the exposure to prevent recurrence.
-
Document the finding. Record the panel, how it was exposed, how long it was exposed, and whether compromise indicators were found. This feeds your risk management process and helps justify investment in continuous scanning.
How do you build a repeatable admin panel discovery process?
Ad-hoc panel hunting is better than nothing, but sustainable security requires a process:
- Weekly automated scans of all domains and IP ranges for management ports and paths
- Alerting on new findings - every newly discovered panel should trigger a review
- Ownership mapping - every panel should have an identified owner responsible for its security
- Baseline and exceptions - some panels must be internet-accessible (e.g., customer-facing portals). Document these as accepted risks with compensating controls (MFA, IP restriction, WAF)
Frequently asked questions
- What tools can I use to find exposed admin panels? +
- For manual checks, Nmap with HTTP scripts, Nikto, and Aquatone can identify management interfaces. For continuous automated discovery, EASM platforms like SurfaceLoop scan your domains for known panel paths, login fingerprints, and default configurations.
- Which ports should I scan for admin panels? +
- Beyond standard HTTP ports (80, 443), check common management ports: 8080 (Jenkins, Tomcat), 8443 (alternative HTTPS), 2083/2087 (cPanel/WHM), 3000 (Grafana), 5601 (Kibana), 9090 (Prometheus), 9443 (Portainer), and 8888 (Jupyter).
- How often should I scan for exposed panels? +
- At minimum weekly. New panels appear whenever your team deploys services, spins up cloud instances, or installs tools. Daily scanning catches exposures before they persist long enough for attackers to find and exploit them.
- Can Google find my exposed admin panels? +
- Yes. Google indexes admin login pages that are not blocked by robots.txt or authentication. Using search operators like site:example.com inurl:admin or site:example.com intitle:dashboard can reveal panels that are publicly indexed and visible to anyone.
- What should I do immediately when I find an exposed admin panel? +
- Restrict network access first by adding firewall or security group rules to block public access. Then check access logs for signs of compromise, rotate all credentials associated with the panel, investigate why the panel was exposed, and document the finding for your risk management process.
- Do I need to scan internal networks for admin panels too? +
- Yes. Internal admin panels with default credentials are exploited for lateral movement after an attacker gains initial access through phishing or a VPN vulnerability. Internal panels should follow the same hardening requirements as external ones - unique credentials, MFA, and access logging.
Get SurfaceLoop security briefings
No spam, just findings that matter. Fortnightly.