Use Gobuster path discovery to ask a narrow question about your own authorized lab, then verify the response before calling the path a finding. The nine patterns below are candidates and interpretation exercises. They are not a verified list of paths present in every Kioptrix, DVWA or Metasploitable installation.
No machine was scanned for this revision. There is no personal client story, promised completion time, exam-point prediction or claim that a directory listing leads to administrator control.
What This Walkthrough Can Establish
The useful result is an explainable observation: which URL was requested, in which access context, and how the response differed from the lab’s baseline. A longer path list does not establish greater coverage or higher severity.
Keep the specific release and deployment in view. The Kioptrix release catalogue contains distinct releases. The DVWA project is a deliberately vulnerable web application, while Rapid7’s Metasploitable 2 documentation describes an intentionally vulnerable Ubuntu VM. Those names do not establish one common web root or identical installed applications.
Record the Actual Lab and Application Base URL
Record the image or project revision, target address, expected web port, scheme, application base path and authentication state. Identify the target from its own configuration, not from a private address copied from a walkthrough.
For DVWA, check whether your deployment places the application at the root or under a path such as /dvwa/. These are deployment examples, not universal defaults. For any named virtual host, use the configured lab URL; an IP-address request may reach a different site.
Confirm the lab boundary and permission for automated path requests. DVWA’s own instructions warn against internet-facing deployment. Keep vulnerable guests away from everyday devices, and inspect all enabled adapters and routes. For a fuller first-run checklist, use the Nikto and Gobuster first-check guide.
Prepare a Small, Reproducible Path Query
Start with the help for your installed version:
gobuster dir --helpThe Kali tool reference distinguishes directory mode from DNS and virtual-host modes. This exercise uses only directory/file candidates on one approved web endpoint.
Create lab-paths.txt as a plain-text file with one candidate per line. For an illustrative root-level exercise, a small file could contain:
admin
test
phpmyadminProposed command, only after you independently identify your authorized target:
gobuster dir -u http://192.168.56.101/ -w lab-paths.txt -t 1 --delay 1s -o gobuster-paths.txtThe maintainer’s usage reference documents directory mode, wordlists, output, threads and delays. This example uses a small list and modest concurrency; it is not a safe-rate guarantee. Keep the exact options with the result, and use a new output name for a later run.
Do not interpret the three list entries as exactly three total requests or a fixed duration. Preliminary behavior, responses and settings can add work. The earlier duration calculator has been removed because its arithmetic could be mistaken for actual runtime.
Kioptrix: Three Candidate Patterns to Verify
These candidate names are retained as learning prompts, not as confirmed discoveries on Kioptrix Level 1 or any other release.
1. /phpmyadmin: check the actual application identity
A name resembling an administration tool does not prove which application is installed, its version or whether an account can access it. Record the actual response and compare it with a nonexistent path.
2. /admin: separate a sign-in page from protected access
If the response leads to authentication, report that observation. Do not call the administrative area accessible without evidence of the permitted access context.
3. /test: ask what is being served
A test-like name may return a generic page, a redirect or a deliberately prepared lab resource. Confirm its content and intended role before describing it as forgotten or sensitive.
DVWA: Three Path and Access-Context Checks
4. /dvwa/: confirm the base path
If your deployment already uses http://lab-host/dvwa/ as its base URL, do not blindly add dvwa again. Write the final requested URL in your notes so a duplicated path is visible.
5. /dvwa/login.php: distinguish discovery from authentication
This is an illustrative candidate for a path-based installation. A sign-in response does not establish valid credentials or access to exercises behind it. Record whether the query was authenticated and what was actually returned.
6. /config: limit the claim to the evidence
A candidate name does not prove configuration-file disclosure. In a prepared lab, use a harmless marker to study access behavior; do not assume that a status line authorizes collecting secrets.
Metasploitable: Three Application-Name Candidates
The following names are comparison candidates from the earlier article, not a promise about your particular image. Check the actual web index and installed applications before assigning them a role.
7. /mutillidae: verify the application and route
Confirm that the response belongs to the intended lab application rather than a catch-all page. Keep application identity separate from any claim that a vulnerability has been demonstrated.
8. /twiki: check the response before researching a version
A matching name is a starting question. Do not select an exploit from a guessed product or a path string. Record what the page actually identifies and what remains unconfirmed.
9. /phpMyAdmin: preserve case and access context
Record the requested spelling exactly, including capitalization. Do not silently treat it as equivalent to another candidate. A product-like path does not establish database access, an unsafe configuration or compatibility with a Metasploit module.
Interpret Matches Against a Control Response
Before increasing a list, compare three responses in the same session context: a resource you know should exist in your lab, a deliberately nonexistent path, and a candidate result. Record status, redirect destination and relevant content differences.
If many unrelated paths return the same page or sign-in response, investigate that baseline. Do not filter out inconvenient results merely to make a list look cleaner. Explain why any response-length or status filter is appropriate, and preserve what it excludes.
Hypothetical note: “The candidate and nonexistent path both redirected to the same sign-in page. The run did not demonstrate that the candidate exposes distinct protected content.” This is a reporting example, not a finding from one of the named VMs.
A missing result also has limits: the candidate may not have been requested, may fall outside selected filters or may behave differently for another base URL or session. Record collection limits rather than claiming the application is secure.
Keep Evidence and Stopping Conditions
Monitor the lab during the exercise and keep request scope, errors and elapsed time in your record. Stop when the target becomes unstable, activity leaves scope or you cannot explain where requests are going.
Do not turn a path-discovery exercise into password guessing, data extraction or a live exploitation attempt without a separate, appropriate scope. Preserve only the evidence needed for the task and protect any sensitive details.
Tools and checklists do not determine insurance coverage, liability or a professional fee. The earlier universal cost and insurance statements have been removed rather than treated as consequences of running Gobuster.
Build a Repeatable Lab Record
This checklist has no submission action and does not start a scan. Suggested note fields are: target, version, base URL, date/time zone, command, list contents, session assumptions, response evidence, limits and next permitted check.
A Short Path-Validation Workflow
- Confirm the specific deployment and approved activity.
- Choose a small candidate set for one question.
- Review help and record the requested URL.
- Compare candidate and control responses.
- Write the observation, uncertainty and next step.
Common Path-Discovery Questions
Should all nine paths appear on every lab?
No. They are illustrative candidates and interpretation prompts. Releases, application layout and configuration vary.
Why does the same path behave differently after I sign in?
Keep access contexts separate in your notes. A result obtained in one session is not evidence of the same access for another account or an unauthenticated visitor.
Does a reported path mean I can exploit it?
No. Discovery, access and vulnerability are different claims. Validate only the next question permitted by the exercise.
How many threads will always be safe?
There is no universal value. Agree on activity and stopping conditions, start with a small exercise and inspect target behavior. A modest setting is not proof of harmlessness.
Do I need a full scan to learn something useful?
No. A controlled comparison of a few responses can teach a clear interpretation lesson. Choose the collection from your question rather than a desired number of findings.
Your Next Practice Task
Identify one target and base URL, select one candidate and write what would distinguish it from a baseline response. Preserve the evidence and avoid claiming more than it shows.
Reviewed October 16, 2026. Lab descriptions and selected tool meanings were checked against the linked original project and vendor documentation. No independent scan of these releases was performed for this review. Path names, commands and reporting examples are illustrative; retained images are not proof of a personal test or successful exploitation.
