FUZZING

01 • MISSION BRIEFING

The Hidden Surface

The exercise begins with a deceptively small web application. The objective is not to attack the application blindly, but to map its exposed surface, identify an overlooked endpoint, and understand how a missing server-side parameter can turn a normal error response into a source of sensitive diagnostic data.

The supplied workflow starts in the TryHackMe environment, using the target instance together with a browser, Burp Suite and FFUF. The investigation follows a progressive path: inspect client-side material for credentials, enumerate web content, review robots.txt and index.php, inspect the discovered error endpoint, and then fuzz the parameter space.

INVESTIGATION PRINCIPLE

Enumeration establishes the attack surface. Parameter fuzzing then tests how application behavior changes when the server receives values it expects but the interface does not visibly expose.

Initial Reconnaissance

FFUF was used against the target with a common content wordlist. The enumeration output showed multiple response classes: accessible content returning HTTP 200, a redirect returning HTTP 301, and restricted resources returning HTTP 403. This distinction is important because a forbidden response is still evidence that a resource exists.

What the Enumeration Revealed

The next step focused on index.php and robots.txt. The robots.txt response exposed both disallowed paths and an explicitly allowed error-related resource. This created a concrete lead rather than requiring continued blind directory discovery.

02 • SURFACE ANALYSIS

From robots.txt to error.php

Reviewing robots.txt produced a useful application map. Among the listed directives was an allowed /error.php resource. Opening that endpoint produced a structured JSON response rather than a conventional HTML error page.

KEY TRANSITION

The message "Missing required system parameter" is the turning point of the investigation. It confirms that the endpoint is parameter-driven and that the required input is not being supplied through the normal request.

Parameter Fuzzing Phase

With the endpoint identified, FFUF was used to test candidate parameter names. The supplied evidence shows the request being shaped around error.php with a fuzzing position in the query string. Most candidates did not materially change the response, but one parameter produced a distinct result.

The discovery of the debug parameter changed the investigation from endpoint enumeration to application-behavior analysis. The parameter was then examined directly through the browser/Burp workflow.

03 • EVIDENCE & IMPACT

Debug Mode Exposes the Internal Picture

Supplying the discovered parameter caused the endpoint to return substantially more information about the application and its server-side environment. The response contained system information, internal logs, loaded modules, and other implementation details that would normally remain behind the application boundary.

Why the Response Matters

The issue is not merely that an extra field is returned. The debug response demonstrates an information-disclosure condition: internal operational data becomes available through a client-controlled parameter. Log entries in the response provide a particularly strong indicator of the impact because they can reveal implementation behavior, internal paths, request context, and security-relevant events.

The supplied screenshot also shows the sensitive flag embedded within the leaked debug information. This confirms that the parameter was not only syntactically valid but reached a privileged diagnostic path that exposed data outside the intended user-facing interface.

SECURITY IMPACT

Excessive debug output can disclose server configuration, internal paths, framework behavior, logs, session-related details, and other operational metadata. In a production system, such leakage can materially assist further exploitation.

Flag Recovery

After reviewing the returned debug information, the flag was located in the internal log data. The supplied source records the recovered value as:

FLAG{DEBUG_LOG_SENSITIVE_LEAK}

04 • VALIDATION & CLOSURE

Lab Completion

The final stage was to submit the recovered flag to the TryHackMe task interface. The supplied evidence shows the flag entered into the answer field and the platform returning a green "Correct Answer" confirmation.

Professional Finding Summary

Defensive Takeaway

Debug functionality should be disabled or strongly restricted outside controlled development environments. Server-side diagnostics must not be activated solely by an untrusted client parameter, and error responses should return only the minimum information required for the user-facing workflow. Internal logs, configuration values and implementation metadata should remain inaccessible to unauthenticated or unauthorized clients.

COMPLETION STATUS

LAB OBJECTIVE ACHIEVED • Hidden endpoint identified • Parameter discovered • Sensitive debug data recovered • Flag validated