01 Header Sleuth

Flag:

FLAG{cwa2026_0cef5e17574204d2}

The brief, taken at face value

A regional payment gateway diagnostic endpoint was exposed during a rollout. The web server emits sensitive debugging flags and authorization headers inside its HTTP response metadata. The suggested approach is to inspect the exchange headers.

On that reading the flag would reside in a response header. Pursuing that reading directly produced no result.

What the target actually was

ch-001.ctf.africa resolves to a single address. Port 80 returned nothing at all, not even a reset, so the effort went to HTTPS, which the challenge listing places first and which responded on the first attempt.

The root returns:

HTTP/2 200
content-type: text/html
last-modified: Mon, 28 Sep 2026 15:09:47 GMT
server: SimpleHTTP/0.6 Python/3.11.16
content-length: 169

The body is one sentence, Endpoint operational. The Server header carries the useful detail. A SimpleHTTP banner indicates Python's http.server module serving a directory of files, which establishes that the "diagnostic endpoint" is a static file rather than a route with logic behind it, and which in turn makes filename enumeration an effective technique here.

Pursuing the header theory, and its failure

Attempts to make the server emit additional response metadata all returned nothing:

• Forty-plus guessed paths, covering every diagnostic synonym considered, plus payment and gateway themed sets, plus rollout and infrastructure sets. All 404.
• Debug-triggering request headers, X-Debug: 1, Debug: 1, X-Request-Debug: 1, X-Internal: 1 and several others. Nothing appeared in the response.
• Query parameters on root, debug=1, diag=1, show=headers, verbose=1. Nothing.
• Forcing HTTP/1.1 rather than HTTP/2 over TLS, in case the extra metadata was version specific. The same five headers were returned.
• HEAD and OPTIONS on root. OPTIONS returned 501 with nothing extra.

Filename enumeration produced the result. common.txt returned exactly one hit, index.html, which indicated that the directory held a single obvious file and therefore that the file of interest had a name absent from the wordlist. Extensionless directory listings are the obstacle, so names were crossed with extensions: thirty-five diagnostic and infrastructure words against fifteen suffixes, 525 candidates.

ffuf -u https://ch-001.ctf.africa/FUZZ -w paths.txt -fs 335 -t 25 -s -k

One hit:

flag.txt

Fetching it returned:

HTTP/2 200
content-type: text/plain
content-length: 31

FLAG{cwa2026_0cef5e17574204d2}

The flag was in the response body of a plain text file. It belongs to the exchange metadata of the request only in the loosest sense, and not to any header.

Assessment of the dead ends

Treating the brief as a precise specification, and response headers as the only possible location for a flag, was the error. It never held. Every diagnostic-looking path returned 404 and every debug header sent was ignored. Both outcomes were read as evidence of a subtler trigger rather than as evidence that the brief described a different surface. File enumeration taken earlier would have reached the same result without the detour.

Effort was also spent disproportionately on the HTTP port 80 that the challenge listing described as available. It answered nothing on any attempt. For this host, HTTPS responded immediately and plain HTTP never did.

The generated candidate list is in recon/paths.txt and the wordlist hits are in recon/ffuf-paths.txt, so the sweep is reproducible rather than a lucky guess.