Recon Is Where Bugs Are Found, Part 2: Advanced Recon for 2027

Everyone runs subfinder now. When a thousand hunters feed the same wildcard into the same tools, they get the same list of hosts, and the easy bugs on it are reported within hours of a program going live.

The hunters still finding criticals going into 2027 do recon differently. They map the whole organisation rather than one domain, find the servers hiding behind the CDN, read code and JavaScript in depth, track the new AI attack surface, and run recon continuously so they test new assets before anyone else sees them.

This is Part 2 of our recon series. Part 1, Recon Is Where Bugs Are Found, covered the five-stage pipeline: subdomains, live hosts, URLs, JavaScript and fuzzing. This part assumes you know subfinder, httpx and ffuf, and covers what to do after them. As before, every command uses example.com, and every technique here is for targets you are authorized to test.

1. Map the organisation, not the domain

A wildcard scope tells you one domain. The company usually owns many more: other root domains, acquired brands, its own IP ranges, and servers that answer on an IP with no DNS name at all. Pivot from what you know to what you don’t.

# The company's own IP ranges (ASNs registered to it)
asnmap -org "Example Corp" -silent > ranges.txt

# Hostnames from TLS certificates on those ranges: names DNS never told you about
naabu -list ranges.txt -p 443,8443 -silent | tlsx -san -cn -silent -resp-only | sort -u > cert_names.txt

# Favicon hash: find every host serving the same app, whatever its name
httpx -u https://login.example.com -favicon -silent
# then search Shodan with:  http.favicon.hash:<hash>

Pivots that keep paying off:

Check every new root domain and IP range against the program’s scope before testing. A company owning a domain does not put it in scope; the program’s policy decides.

2. Look behind the CDN

Most targets now sit behind Cloudflare, Akamai or a cloud load balancer, so the WAF sees every request you send. The origin server behind it often answers directly, with no WAF and sometimes an older build.

Finding the origin

# Drop IPs that belong to CDNs, keep the rest
dnsx -l subs_all.txt -a -resp-only -silent | cdncheck -silent -exclude > non_cdn_ips.txt

# Test whether a candidate IP serves the real site when given the right Host header
curl -sk https://203.0.113.10/ -H "Host: www.example.com" | grep -i "<title>"

Good places to find candidate IPs: historical DNS records from before the site moved behind the CDN, certificates for the domain seen on non-CDN IPs in Censys, mail servers (MX and SPF records often name the hosting provider), and subdomains that were never put behind the CDN.

Virtual hosts

One IP can host many sites that DNS never mentions. Fuzz the Host header against every non-CDN IP.

ffuf -u https://203.0.113.10/ -H "Host: FUZZ.example.com" -w vhosts.txt -ac -rate 20

Cloud storage and SaaS tenants

Third-party platforms are usually out of scope. What counts is the company’s own configuration on them, such as an open Jira service desk that leaks customer tickets, and only where the program allows it.

3. Read the code they already published

Companies leak more through code than through servers: public repos, employees’ personal repos, CI logs, published packages and container images. None of it needs a single request to the target’s infrastructure.

# Verified secrets across a company's public GitHub repos and their history
trufflehog github --org=example-corp --results=verified

# Secrets left in the layers of a public container image
trufflehog docker --image=examplecorp/api:latest --results=verified

Where to look beyond the official org:

• Employees’ personal repos. Search GitHub code for internal hostnames ("internal.example.com"), the company’s API key prefix, or its Slack webhook domain. Dotfiles and side projects often carry work credentials.
• CI workflows. In .github/workflows, a pull_request_target trigger that checks out the pull request’s code can hand an outsider the repo’s secrets. Public build logs sometimes print tokens.
• Dependency confusion. Internal package names show up in package.json files, lockfiles and JavaScript bundles. If a name like @example/billing-utils is not registered on the public registry, an attacker could publish it. Report that the name is unclaimed; do not publish a package unless the program explicitly allows it.
• Container images. Old tags on Docker Hub keep layers that were deleted later, including .env files and SSH keys.

A verified secret is the start of a report, not a licence to use it. Confirm what it can access with the least invasive call possible, stop there, and report it.

4. Go deep into the JavaScript

The web UI shows you the API a company wants users to see. Its full JavaScript bundle shows the API the developers actually built, including admin and legacy routes.

# URLs and secrets parsed from the code itself, not just regex matches
jsluice urls main.js > js_urls.txt
jsluice secrets main.js

# Rebuild original source from an exposed source map
sourcemapper -url https://www.example.com/static/js/main.js.map -output src/

• Lazy-loaded chunks. Webpack and Vite apps load admin and settings code only when a user opens that screen. Crawlers miss these chunks; find their names in the main bundle’s chunk map and download them directly.
• Source maps give you the original code with comments, feature flags and internal route names.
• GraphQL with introspection turned off still often suggests field names in error messages (“Did you mean…”). Clairvoyance uses those suggestions to rebuild most of the schema, and graphw00f identifies the GraphQL engine so you know which known issues apply.

graphw00f -f -t https://api.example.com/graphql
clairvoyance https://api.example.com/graphql -o schema.json

5. The AI attack surface

The fastest-growing recon target going into 2027 is AI infrastructure: self-hosted models, MCP servers that give AI agents tools, and chatbots wired into company data. Much of it was shipped quickly and without authentication.

The numbers so far:

• Exposed model servers. Cisco found 1,139 exposed Ollama instances in 2025, 214 of them actively hosting models, most answering on the default port 11434.
• Exposed MCP servers. Trend Micro counted 1,467 exposed MCP servers in April 2026, nearly triple the 492 it found in July 2025. Some exposed tools such as execute_sql.
• Attackers already scan for this. A SANS Internet Storm Center analysis in July 2026 logged probes from 49 different IPs sending MCP handshakes to one small web host, alongside requests for AI assistant config and credential files.

If attackers check these paths, you should too:

# Does this host answer as an MCP server?
curl -s -X POST https://ai.example.com/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"recon","version":"1.0"}}}'

If it answers, list its tools with tools/list and stop. A tool that runs SQL, reads files or calls internal APIs without authentication is the finding; you do not need to call it on real data to prove that.

AI features inside the product are recon targets too. Search JavaScript for /chat, /assistant, /completions and streaming endpoints to find every feature backed by a model. Then ask what that model can reach: other users’ records, internal documents, or tools that act with the user’s permissions. Those connections, not clever prompts, are where the serious bugs are.

Check the program’s policy before testing AI features. Many programs have separate rules for prompt injection, and every prompt you send costs the company money, so never automate prompts at volume.

6. Run recon continuously

The biggest edge in 2027 is timing. A new host, endpoint or JavaScript file has had the least testing, and the first hunter to look at it usually finds what’s there. Run recon on a schedule and get alerted only about what changed.

1. 01Schedulecron · every 6 hours
2. 02Enumeratesubfinder · dnsx · httpx
3. 03Diffanew · only new lines
4. 04Alertnotify · Discord · Slack
5. 05Testby hand, within hours
6. ↺Update baselineseen files grow each run

The loop needs only a few lines. anew prints lines it has never seen before and saves them, so each run reports only new assets.

#!/usr/bin/env bash
# monitor.sh: report only new subdomains and hosts
cd ~/recon/example.com
subfinder -d example.com -all -silent | dnsx -silent \
  | anew subs_seen.txt > new_subs.txt
httpx -l new_subs.txt -sc -title -td -silent \
  | anew hosts_seen.txt > new_hosts.txt
# Send new hosts to Discord or Slack, configured in notify's provider file
[ -s new_hosts.txt ] && notify -silent -bulk -data new_hosts.txt

# crontab -e: run every 6 hours
0 */6 * * * /home/hunter/recon/monitor.sh

Extend the same loop to JavaScript: store a hash of each JS file and alert when one changes. A changed bundle often means a new feature, and new features ship with new endpoints. Keep the schedule light and rate-limited; continuous recon is passive-heavy by design.

7. Use AI to read the output, not to replace you

Advanced recon produces more output than a person can read: thousands of hosts, tens of thousands of URLs, megabytes of JavaScript. AI models are good at the reading part, and that is where they save the most time.

Where AI helps:

• Ranking hosts. Give a model your httpx output (titles, status codes, tech) and ask which 20 hosts look like admin panels, staging copies or outdated software, with a reason for each.
• Reading JavaScript. Ask it to list every API route in a bundle, which ones take an ID, and which look admin-only.
• Explaining diffs. Summarise what changed between today’s run and last week’s in plain language.
• Target-specific wordlists. Build fuzzing wordlists from the target’s own words: product names, internal terms and route patterns from its JavaScript.

Rules we follow at SecureDX:

• Client data stays private. Recon output from a pentest is client data. Use a local model or an account whose terms exclude training on your inputs, as your contract allows. Never paste live secrets into any AI tool.
• Scope is enforced in code. If an agent runs tools for you, it gets the scope file and a filter that drops anything outside it. A model’s judgement is not a scope check.
• A person sends every active test. AI ranks and explains. Requests that could change data or load the target are made by a human who has read them.
• Verify everything. Models invent endpoints and misread responses. A finding exists only once you have reproduced it yourself.

8. Where to test first

Advanced recon pays off when it leads you somewhere other hunters haven’t been. Test in this order:

1. New assets from your diff, within hours of them appearing.
2. Origin servers and virtual hosts that skip the WAF, especially ones running an older build.
3. Acquired brands and other root domains that are in scope but rarely tested.
4. Routes found only in source maps and lazy-loaded chunks, called with a low-privilege session.
5. AI endpoints and MCP servers, for missing authentication and for what the model can reach.
6. Verified secrets from code, confirmed with one harmless call and reported quickly.

Tools change every year. The method doesn’t: find what others missed, prove impact without causing harm, and write it up so a developer can fix it in one sitting.

Next: Part 3: Recon for Defenders turns these techniques around so you can find your own exposures first.

SDX Society is SecureDX’s invite-only community of bug bounty hunters. If you already recon like this and want access to private programs, request an invite at securedx.in/society.

Sources

• Cisco: Detecting exposed LLM servers: a Shodan case study on Ollama (September 2025)
• Trend Micro: Update on exposed MCP servers: the threat widens to the cloud (April 2026)
• SANS Internet Storm Center: Someone is scanning for your MCP servers and AI assistant credentials (July 2026)