SSRF

SECURECORP / AVATAR SYNC INCIDENT

A controlled web-security exercise in which an externally reachable application is persuaded to make a request to a service that is intended to remain internal. The investigation moves from a visible legacy feature to an HTTP request, then to a server-side pivot that exposes the lab's protected content.

SCENARIO

SecureCorp's legacy Avatar Sync feature accepts a remote URL. The application appears to fetch external resources, but the same server-side request mechanism can be redirected toward an internal endpoint.

Mission Brief

The lab begins with the previous Fuzzing task. That stage reveals credentials and internal-system information on a page. Those credentials are used to enter the SecureCorp site and reach the Avatar Sync / api_fetch.php functionality described in the original task sheet.

The first browser-level request does not visibly return the expected secret content. Instead of treating the empty result as a dead end, the investigation moves into Burp Suite, where the HTTP method and request body become the key evidence.

CORE CONCEPT

SSRF occurs when a server-side component can be influenced into requesting a resource chosen by the client. The security boundary is crossed because the request originates from the trusted server rather than directly from the tester.

Learning Path

01 ACCESS & DISCOVERY

Establish the application context before testing the server-side fetcher

The Story Moves Inside

The original task directs the tester to open the TryHackMe room and connect through the VPN or AttackBox. The room link supplied in the source worksheet is the TuteDude CyberSec room. The earlier Fuzzing task is part of the intended chain because it exposes credentials and internal information needed to log in.

SOURCE WORKFLOW

Previous Fuzzing task → leaked credentials → authenticated SecureCorp site → Avatar Sync (Legacy) / api_fetch.php → SSRF investigation.

The Attack Surface

The interface is deceptively ordinary: a URL is entered into a legacy synchronization feature and the application displays a stream-data preview. From an application-security perspective, the important question is not the visual design; it is where the URL is fetched and which network location performs that fetch.

Initial Request Path

Browser │ ▼ Avatar Sync / api_fetch.php │ │ user-controlled URL ▼ Server-side HTTP fetch │ ├── External resource └── Internal resource ← security boundary of interest

The supplied task specifically points toward api_fetch.php and a localhost request targeting /secret. The browser attempt does not display the expected result, which becomes the transition point from ordinary functional testing to request-level analysis.

EVIDENCE DISCIPLINE

Treat the visible browser result as one observation, not the final verdict. A blank or generic response can mean the application handled the request differently than the browser UI suggests.

02 BURP SUITE — REQUEST TRANSFORMATION

The decisive observation is visible at the HTTP layer

From UI Behavior to HTTP Behavior

The original worksheet records that the browser-level attempt did not show the expected content. The next step was to inspect the request in Burp Suite. The investigation then identified that changing the request from GET to POST caused the internal response to be returned.

KEY FINDING

The application's SSRF behavior was exposed by replaying the request as POST and supplying the target URL in the form-encoded request body.

Request Anatomy

Controlled Pivot

The loopback address 127.0.0.1 is significant because it resolves to the local host from the perspective of the server making the request. The tester is therefore no longer asking the browser to reach /secret directly; the application server is being induced to make that request on the tester's behalf.

BOUNDARY CROSSED

Client → application → server-side fetcher → localhost /secret. This is the defining trust-boundary transition demonstrated by the lab.

03 INTERNAL RESPONSE & FLAG

Capture the server-side response as primary evidence

The Response Reveals the Hidden Resource

Once the request is replayed through Burp Suite as POST, the response contains the protected internal content. The original evidence image shows the flag in the response together with a note that the confidential Admin Portal is located at /admin.php.

Evidence Record

Flag Verification

VERIFIED LAB RESULT

FLAG{INTERNAL_SSRF_BYPASS_SUCCESS}

04 PROFESSIONAL ANALYSIS

Convert the lab activity into a concise penetration-testing record

What the Lab Demonstrates

The exercise demonstrates a classic SSRF trust-boundary failure in a legacy server-side fetch feature. A URL supplied through the application is not sufficiently constrained to external, authorized destinations. When the request is accepted and processed server-side, loopback addressing allows the application to reach resources that are not directly exposed to the tester.

Attack Chain

1. Obtain the credentials revealed by the preceding Fuzzing task.
2. Authenticate to the SecureCorp application.
3. Locate Avatar Sync (Legacy) / api_fetch.php.
4. Attempt the supplied localhost /secret target.
5. Observe that the browser view does not expose the expected content.
6. Inspect the HTTP transaction in Burp Suite.
7. Replay the fetch as POST with the URL in the request body.
8. Receive the internal response and capture the flag.
9. Record the successful lab state as evidence.

Security Impact

• Internal resources can become reachable through a trusted application server.

• Loopback-only or network-restricted endpoints may be exposed indirectly.

• The server's network position becomes part of the attacker-controlled request path.

• Additional internal application routes may become discoverable when the fetcher is insufficiently restricted.

Defensive Controls

05 FINAL LAB RECORD

A clean, presentation-ready closeout page

Incident Narrative — Closed

The SecureCorp investigation started with a legacy synchronization feature and ended with an internal resource disclosure. The browser interface initially provided little useful feedback. Burp Suite exposed the underlying HTTP behavior, and the successful POST request demonstrated that the server-side fetcher could be directed toward localhost. The returned response disclosed the protected flag and referenced an internal Admin Portal.

OUTCOME

SSRF successfully demonstrated in the controlled lab environment. Internal response captured and flag verified.

Final Evidence Checklist

☑ TryHackMe room / AttackBox or VPN environment established

☑ Credentials from the preceding Fuzzing stage used for access

☑ Avatar Sync (Legacy) / api_fetch.php located

☑ SSRF target directed toward the server loopback interface

☑ Burp Suite used to inspect and replay the request

☑ POST-based request produced the internal response

☑ Flag captured from the response

☑ Lab submission verified as correct

Final Flag

FLAG{INTERNAL_SSRF_BYPASS_SUCCESS}