Hidden Doesn't Mean Protected

This pack is built from a beginner's learning journal. The useful part was never the tool — it was the habit: try something, get stuck, read the error, write down what happened, try again. Security skill is mostly accumulated troubleshooting.

• Work in small loops: one question, one experiment, one note.
• Write down the exact command or request, and the exact response. Vague notes teach nothing later.
• Treat being stuck as the normal state, not a sign you don't belong.
• Separate what you observed from what you concluded — this is the same discipline a SOC ticket needs.

Offensive security means deliberately thinking like an attacker so weaknesses are found by your side first. It is a perspective, not a permission slip. The entire value depends on scope: an authorized target, an agreed window, and a written rule of engagement.

• Authorized training ranges and intentionally vulnerable apps: fine.
• Your employer's systems, with written approval and a defined window: fine.
• Anything else, including 'just checking' a stranger's site: not fine, and in many places illegal.

The lab in the source journal uses FakeBank, a simulated banking application published by TryHackMe as part of its Offensive Security Intro room. It is a fake application in a contained, legal practice environment, built to be found and poked at. Nothing about it exists in the real world, and no real customer data is involved.

A web application's navigation shows you what the designers wanted you to see. It is not a complete map. Admin panels, old upload forms, backup files, internal reports and half-finished features frequently exist at URLs nothing links to.

Content discovery is the practice of asking a server about paths that are not linked, one after another, and reading the answers. Conceptually it is simple: take a dictionary of common path names — admin, login, backup, uploads, config — request each one, and watch which responses differ from the 'not found' baseline.

Analogy: walking down a hotel corridor and noting which doors exist. Knowing room 402 is there is not the same as having a key — and it is certainly not the same as the door being unlocked.

The current TryHackMe Offensive Security Intro room instructs learners to use DIRB. Kali's documentation defines DIRB as a web content scanner: it looks for existing, often hidden, web objects by launching dictionary-based requests and analysing the responses.

• DIRB is a content scanner. It finds paths.
• DIRB is not a vulnerability scanner. It does not assess authorization, logic or injection flaws.
• A DIRB hit is an input to an investigation, never a finding on its own.

dirb http://fakebank.thm

In the lab, this surfaces a page the site never links to: /bank-transfer. Hold that thought — the next sections are about what that discovery does and does not prove.

Authentication (AuthN)

Who are you? Proving identity — password, passkey, MFA, session token.

Authorization (AuthZ)

What are you allowed to do? Deciding, per request, whether this identity may read or change this specific resource.

A system can authenticate perfectly and still authorize terribly. Logging you in correctly, then letting you open someone else's transfer page because you typed the URL, is an authorization failure — the login worked exactly as designed.

Analogy: the badge reader at reception checks your face against your badge — that's authentication. The lock on the server-room door decides whether your badge opens it — that's authorization. Two different controls, two different ways to fail.

Broken Access Control is the number one category in the OWASP Top 10:2025. It explicitly includes force browsing: modifying the URL, or requesting a path directly, to reach a page or function that should require authentication or higher privilege.

1. Discovery: /bank-transfer exists
2. Access attempt: request it as an unauthorised user
3. Server decision: deny (control works) or serve (control broken)
4. Only the 'serve' branch is the vulnerability

This is why 'we renamed the URL to something nobody will guess' is not a security control. Obscurity can slow an attacker down; it never decides a request. Only server-side authorization decides a request.

Content discovery

Asking a server about paths that aren't linked anywhere, to see which exist.

Wordlist

A dictionary file of likely path or file names used to drive discovery.

Force browsing

Typing or requesting a URL directly to reach a page you weren't shown.

Endpoint

A specific URL the application responds to, such as /bank-transfer.

Enumeration

Systematically listing what exists — users, paths, services.

Security through obscurity

Hoping something stays safe because it is hard to find. Not a control.

What happened: a learner ran a dictionary-based scanner against a deliberately vulnerable practice bank and found a page the site never links to.

Why it matters: real applications hide sensitive functions the same way, and plenty of them rely on that hiding instead of a real permission check. When the check is missing, anyone who guesses the URL gets the function.

Switch to Analyst Mode for the telemetry, classification and escalation view.

10.20.4.17 - - "GET /admin HTTP/1.1" 404 0.004s
10.20.4.17 - - "GET /backup HTTP/1.1" 404 0.003s
10.20.4.17 - - "GET /config HTTP/1.1" 403 0.003s
10.20.4.17 - - "GET /uploads HTTP/1.1" 301 0.004s
10.20.4.17 - - "GET /internal HTTP/1.1" 404 0.003s
10.20.4.17 - - "GET /bank-transfer HTTP/1.1" 200 0.011s
… 1,842 further requests to unique paths within 90 seconds

Detect the behaviour, not the brand. A rule that fires on a tool's default user agent is bypassed by a single flag. A rule built on request rate, unique-path count, 404 ratio and the identity of any successful responses keeps working regardless of which tool is used.

1. Discovery
2. Access
3. Action
4. Impact

Most enumeration alerts never leave stage one. Treating every one as a breach burns the team out; treating none of them as serious means you miss the one that reached stage three.

1. Validate the source: internal range, known VPN, partner, or unknown external?
2. Identify the asset: what application is it, who owns it, what data does it hold?
3. Check approved testing windows and the authorised-scanner list.
4. Analyse the request pattern: rate, unique paths, duration, user agent variation.
5. Isolate the successful discoveries — every non-404 response.
6. Review follow-on activity, especially POST / PUT / DELETE after a successful GET.
7. Correlate authentication and session data: was there a session, and whose role was it?
8. Classify as false positive, true positive with a severity, or needs review — and record the evidence each choice rests on.

• Source IP, with geo/ASN or internal-owner context.
• Internal or external origin.
• Approved-scanner / pentest-window status.
• Request rate and total duration of the burst.
• Count of unique paths requested.
• Response-code mix (404 / 403 / 401 / 301 / 200 / 500).
• The exact list of endpoints that returned success.
• Authentication and session context for those successful requests.
• Any POST / PUT / DELETE follow-on activity and its result.
• WAF, reverse-proxy and application logs for the same window.
• Related alerts on the same source, session or asset.

Title: Possible Web Content Enumeration Followed by Sensitive Endpoint Interaction

• Observed: a single external source issued roughly 1,850 requests to unique paths on the customer portal within 90 seconds. 96% returned 404. One request to /bank-transfer returned 200.
• Inference: the request pattern is consistent with automated dictionary-based content discovery. The successful response indicates the endpoint exists and returned content to this source.
• Conclusion (provisional): unauthorised enumeration confirmed. Unauthorised access NOT yet confirmed — session context for the successful request has not been retrieved.
• Risk: if /bank-transfer is reachable without a valid, correctly-scoped session, this is an OWASP A01:2025 Broken Access Control exposure on a funds-transfer function.
• Validation required: application-side session and role for the 200 response; whether the source is on the approved-scanner list; whether any POST to /bank-transfer succeeded.
• Recommended evidence: proxy and application logs for the window, authentication logs for the session identifier, endpoint ownership from the application team.
• Escalation condition: escalate to incident if the 200 response had no authenticated session, or if any state-changing request to the endpoint succeeded.

• Enforce authorization on the server, on every request, for every protected function — never in the front end alone.
• Deny by default: a route with no explicit policy must be refused, not served.
• Check ownership and role together: 'is this user allowed this action on this specific record?'
• Log and alert on access-control failures (401/403 bursts), and treat repeated failures from one identity as a signal.
• Apply rate limits to unauthenticated and discovery-prone surfaces where it won't harm legitimate use.
• Disable directory listing and remove stale backup, archive and debug files from web roots.
• Test access controls as a first-class case: automated tests that assert a low-privilege identity gets 403 on every protected route.

14:02:11  GET /admin            404
14:02:11  GET /backup           404
14:02:12  GET /config           403
14:02:14  GET /bank-transfer    200
14:06:48  GET /bank-transfer    200
14:07:35  POST /bank-transfer   200

Question 1: what changed at 14:07:35? Question 2: what evidence do you still need before calling this a compromise?