Recon and Mapping the Application Attack Surface

What You'll Build

In this phase you will perform reconnaissance on the capstone's vulnerable application and produce an attack-surface map: an inventory of its pages, parameters, endpoints, technologies, and authentication mechanisms. This map is the foundation for every later phase, since you can only test what you have discovered, and it becomes a documented section of your final report.

Analogy🏏Cricket

💪 Think of it like fitness: Assessment day is when the training gets tested for real, you take the map of your programme and put each targeted lift under load to see which strengths hold and which weaknesses are genuine, recording every number. Just as the measured test turns a plan into proven results, using your attack-surface map to probe injection, authentication, and API authorization, and confirming each real flaw with captured evidence, turns recon into demonstrated findings. This reveals where knowledge becomes proof: you deliberately load each mapped weakness and record exactly what gives way.

The aim is to think systematically rather than poke around at random. You will enumerate the visible surface, discover hidden endpoints, identify the technology stack, and understand how authentication works, recording each finding in your engagement log. By the end you will know the application's shape well enough to plan targeted exploitation in the next phase.

Analogy🏏Cricket

🏏 Think of it like cricket: A disciplined bowling attack does not spray deliveries everywhere and hope; guided by the scouting report, it targets each batter's flagged weakness, confirms the ball is doing what was planned, and records every dismissal for the analysts. Just as that planned, evidence-backed attack turns a dossier into wickets rather than wasted overs, working your test plan area by area, confirming each real flaw by safely triggering it, and documenting it rigorously turns recon into evidenced findings. This reveals the method: targeted, confirmed, and recorded beats spray-and-pray every time.

Prerequisites

The capstone vulnerable application running locally, plus a browser with developer tools and an HTTP client.
Completion of Lesson 31, so you understand the rules of engagement and are working strictly in scope.
An engagement log started, ready to record each action, request, response, and piece of evidence.
An understanding that all reconnaissance here targets only your local capstone app, never any third-party or live system.

Setup & Project Structure

Run the capstone application locally and open your browser's developer tools alongside an HTTP client. Prepare your attack-surface map with sections for pages, parameters, endpoints and APIs, technologies, and authentication. Keep your engagement log open so every discovery is timestamped and evidenced as you make it, rather than reconstructed later.

Analogy🏏Cricket

📷 Think of it like photography: A professional does not trust memory on a shoot; every frame is captured with its settings, the aperture, the shutter, the exact scene, so the shot can be reproduced and proven later. Just as that per-frame metadata makes each image a self-contained, repeatable record, working your test plan area by area and capturing the exact request, the response that proves impact, the reproduction steps, and the affected endpoint makes each finding a self-contained record. This reveals the discipline: evidence recorded at the moment of capture is what makes a finding stand up in the report.

bash

# Start the target locally and prepare to record
cd capstone-app && node app.js        # serves on http://localhost:3000

# Prepare attack_surface.md with sections:
#   ## Pages   ## Parameters   ## Endpoints/APIs   ## Tech stack   ## Auth
# Keep engagement_log.csv open (from Lesson 31) and record as you go.
# Everything below targets ONLY http://localhost:3000 (your machine).

Step 1 — Foundation: Map the Visible Surface

Begin with what any visitor sees. Browse the whole application, noting every page, form, and link, and watch the developer tools Network tab to capture the requests each action generates, along with their parameters. Check common informational files that often reveal structure. Record each page, request, and parameter in your map; this visible surface is your baseline before you probe for what is hidden.

Analogy🏏Cricket

🎮 Think of it like gaming: When you first enter a new area, you walk every visible path, open each obvious door, and read the signs on the walls before you go hunting for secret rooms. Just as clearing the obvious layout gives you the baseline before you probe for what is hidden, browsing every page, form, and link while watching the Network tab and checking common informational files gives you the visible surface before you dig deeper. This reveals the sequence: catalogue everything on plain display thoroughly before you start searching for the concealed.

bash

# Capture the visible surface and common info files
curl -s http://localhost:3000/robots.txt        # often lists hidden paths
curl -s http://localhost:3000/sitemap.xml
curl -sI http://localhost:3000/                  # response headers = tech hints

# In the browser: click every link/form, watch the Network tab, and record
# each URL + its parameters into attack_surface.md under ## Pages / ## Parameters.

Step 2 — Core Logic: Discover Hidden Endpoints

Now look beyond the linked pages. Applications often expose endpoints, admin routes, and API paths that are not linked in the interface but are still reachable. Inspect the client-side JavaScript, which frequently references API URLs, and use content discovery against a wordlist of common paths, staying within your local target. Add every newly discovered endpoint to your map, marking which require authentication.

Analogy🏏Cricket

🍳 Think of it like cooking: A great cook does not judge a kitchen only by what sits on the counter; they open the drawers, check the walk-in fridge, and read the supplier list to find ingredients that were never on display. Just as the hidden stores reveal what the visible counter does not, inspecting the client-side JavaScript and running content discovery reveals endpoints, admin routes, and APIs that are never linked in the interface. This reveals why recon digs deeper: the most interesting attack surface is often the part the application never advertises.

bash

# Discover endpoints not linked in the UI
# 1) Read the app's own JavaScript for API references:
curl -s http://localhost:3000/main.js | grep -oE '/(api|admin)[a-zA-Z0-9/_-]*'

# 2) Content discovery against common paths (LOCAL target only):
#    ffuf -u http://localhost:3000/FUZZ -w common-paths.txt -mc 200,301,302,401
# Record each hit in ## Endpoints/APIs and flag those returning 401 (auth-gated).

Step 3 — Integration & Enhancement: Fingerprint Tech and Auth

Next, identify the technology stack and understand authentication, both of which shape your exploitation strategy. Response headers, error pages, cookie names, and framework signatures reveal the stack. Then map the authentication flow: how you log in, what token or cookie is issued, how sessions are represented, and which endpoints are protected. Knowing the stack and auth model lets you choose techniques suited to this specific application.

Analogy🏏Cricket

🎵 Think of it like music: A trained ear can name the instruments in a track and hear how the arrangement is built, and that recognition tells the producer exactly how to work with it. Just as identifying the parts and structure shapes every production choice, reading response headers, error pages, cookie names, and framework signatures identifies the technology stack, and tracing how login issues a token maps the authentication flow. This reveals why fingerprinting matters: knowing the stack and the auth model lets you choose techniques tuned to this specific application rather than generic probing.

bash

# Fingerprint the stack and map authentication
curl -sI http://localhost:3000/ | grep -iE 'server|x-powered-by|set-cookie'
# Note framework hints, cookie names, and security flags (or their absence).

# Trace the auth flow: log in and capture what's issued
curl -si http://localhost:3000/login -d 'user=demo&pass=demo' | grep -iE 'set-cookie|token'
# Record: login endpoint, token/cookie type (session id? JWT?), and which
# endpoints returned 401 pre-login in Step 2 (the protected surface).

Step 4 — Testing & Verification: Consolidate the Map

Finally, consolidate everything into a clear attack-surface map and use it to plan the next phase. Organise the pages, parameters, endpoints, technologies, and authentication model you discovered, and for each area note the vulnerability classes worth testing, injection on parameters, authorization on object endpoints, JWT flaws if tokens are used. Verify your map is complete by cross-checking it against your engagement log. This map directs the exploitation phase.

Analogy🏏Cricket

💼 Think of it like business: A market researcher does not hand over a pile of raw notes; they consolidate the findings into a briefing that pairs each opportunity with a recommended action and cross-checks it against the source data. Just as that consolidated briefing turns scattered research into a plan the company can execute, organising your pages, parameters, endpoints, stack, and auth into one attack-surface map, and pairing each area with the vulnerability classes worth testing, turns scattered recon into a plan. This reveals the deliverable's purpose: a map that cross-checks against your log and directs the exploitation phase.

markdown

# Consolidated attack_surface.md — the deliverable of this phase
#
# ## Pages: /, /login, /dashboard, /profile, /orders
# ## Parameters: /search?q=, /profile?id=, /orders?id=, login user/pass
# ## Endpoints/APIs: /api/orders/:id (auth), /api/users/:id (auth),
#                    /admin/config (401 pre-login)
# ## Tech stack: Express (X-Powered-By), session cookie 'sid' (no HttpOnly?)
# ## Auth: form login -> JWT in Authorization header; /admin/* gated
#
# ## Test plan (feeds Lesson 33):
#   - /search?q=      -> SQLi, reflected XSS
#   - /api/orders/:id -> BOLA (object authorization)
#   - JWT             -> alg/none, weak secret
#   - /admin/config   -> function-level authorization

Warning: Perform all reconnaissance, including content discovery and fingerprinting, only against your local capstone application. Directory brute-forcing, endpoint enumeration, and fingerprinting against systems you do not own are intrusive and often illegal. Keep every request pointed at localhost, and never run these techniques against a live or third-party site as practice.

Extension Challenge: Deepen your recon three ways. Diff the authenticated and unauthenticated views of the app to reveal functionality that only appears after login. Enumerate the API by requesting an OpenAPI or schema endpoint if one exists, comparing it to what you found by hand. Finally, map trust boundaries explicitly on your surface map, marking each point where untrusted input crosses into the application, to guide the exploitation phase.

Reconnaissance builds an attack-surface map — pages, parameters, endpoints, technologies, and authentication — that is the foundation for every later phase.
You can only test what you discover, so recon proceeds systematically from the visible surface to hidden endpoints rather than probing at random.
Hidden endpoints, admin routes, and APIs often appear in client-side JavaScript and via content discovery even when they are not linked in the interface.
Fingerprinting the technology stack and mapping the authentication flow let you choose exploitation techniques suited to this specific application.
Every discovery is recorded contemporaneously in the engagement log with evidence, so the map is complete, credible, and reusable in the report.
The consolidated map includes a test plan pairing each surface area with the vulnerability classes worth probing, directing the exploitation phase.