In December 2025, I participated in the Yukthi CTF 2.0 cybersecurity competition. Competing against a highly skilled field, I secured the 75th rank out of 321 participants (Top 23%).

As a System Administrator transitioning into Penetration Testing, I approach CTFs a bit differently. I don't just look for the flag; I look at why the infrastructure failed. This CTF was a masterclass in exploiting poor architectural trust boundaries.

Below is a detailed technical walkthrough of my methodology, payloads, and the fundamental patterns used to solve the core Web and Cryptography challenges.

1. Web: Client-Side Trust & JS Obfuscation

The Vulnerability: Trusting the client-side browser to enforce security boundaries.Tools Used: Chrome DevTools, curl

The Setup: The challenge presented a login portal that appeared to perform validation entirely on the client side. Looking at the network tab, no backend requests were being made during failed login attempts.

The Methodology: I inspected the page source and found custom.js. The developers had heavily obfuscated the JavaScript to hide the validation logic and the flag data. Instead of trying to brute-force the UI, I formatted the obfuscated code in DevTools and set breakpoints on the validation functions. By stepping through the execution flow, I reversed the obfuscation routine in memory.

The Bypass: Once I extracted the hidden validation parameters generated by the frontend, I bypassed the web UI entirely. I crafted a direct curl request to the backend using the intercepted parameters, entirely circumventing the obfuscated client-side checks and retrieving the flag.

2. Web: Logic Abuse & IDOR (Insecure Direct Object Reference)

The Vulnerability: Failure to implement Object-Level Authorization.Tools Used: Burp Suite, Manual Browser Testing

The Setup: A dashboard allowed authenticated users to view their own records, but administrative records were restricted.

The Methodology: While proxying traffic through Burp Suite, I noticed an API endpoint fetching user data via a sequential integer parameter:GET /api/profile?id=40 HTTP/1.1

I sent this request to Burp Repeater and began manual parameter manipulation. I incremented the ID to 41. The backend application checked if I was authenticated, but failed to verify if my session was authorized to view object ID 41.

The Payload:

HTTP

GET /api/profile?id=41 HTTP/1.1
Host: web-challenge.yukthi.ctf
Cookie: session=user_standard_token

Response: 200 OK (Leaking administrative data and the flag).

3. Misc: Custom Encoding Recognition

The Vulnerability: Confusing custom encoding with actual encryption.Tools Used: CyberChef, Python

The Setup: We were provided a massive sequence of integers. Initial entropy checks proved it was not standard Base64, Hex, or AES encryption.

The Methodology: Manual testing in CyberChef revealed that the numeric groups fell within specific boundaries, indicating a non-standard 7-bit / decimal encoding scheme. Because the dataset was too large for manual translation, I shifted from manual analysis to automation.

The Exploit Script: I wrote a quick Python script to parse the numeric groups, apply the modulo/ASCII logic, and reconstruct the string.

Python

# Conceptual Decoding Snippet
def decode_yukthi_cipher(numeric_sequence):
    decoded_flag = ""
    for num in numeric_sequence:
        # Applying 7-bit ASCII boundary logic
        char_code = (int(num) % 128) 
        decoded_flag += chr(char_code)
    return decoded_flag

Executing the script translated the numbers directly into the flag string.

4. Advanced Web: HTTP Request Smuggling to Internal Trust Bypass

The Vulnerability: Frontend/Backend parsing discrepancies combined with implicit internal trust.Tools Used: Burp Suite Repeater, curl

The Setup: The target was a web application sitting behind a reverse proxy. Accessing /admin/flag directly returned a 403 Forbidden from the frontend proxy.

The Architecture & Methodology: I tested the connection for Chunked Request Smuggling. The frontend proxy and backend server calculated the Content-Length and Transfer-Encoding boundaries differently.

Plaintext

[ Attacker ] ---> [ Frontend Proxy ] ---> [ Backend Server ]
                     (Sees 1 Request)       (Parses as 2 Requests!)

By crafting a malicious HTTP payload, I smuggled a second, hidden request inside the body of the first. Because this smuggled request was processed directly by the backend — bypassing the frontend proxy entirely — I could inject internal headers that the frontend usually strips.

The Smuggled Payload:

HTTP

POST / HTTP/1.1
Host: proxy.yukthi.ctf
Transfer-Encoding: chunked
Content-Length: 114
0
GET /admin/flag?drop=1 HTTP/1.1
Host: proxy.yukthi.ctf
X-Internal-Token: admin_spoofed_trust
Connection: close

The Exploitation Chain:

  • The frontend proxy forwarded the entire packet as one POST request.
  • The backend saw the chunked terminator (0\r\n\r\n) and closed the first request.
  • The backend immediately parsed the remaining buffer as a new request (GET /admin/flag?drop=1).
  • Because I injected X-Internal-Token, the backend implicitly trusted the request as internal admin traffic.
  • The drop=1 parameter forced the admin console to write the flag to a publicly accessible directory (flag.txt), where I simply downloaded it via curl.

Conclusion & Defensive Takeaways

Yukthi CTF 2.0 was an excellent validation of my core methodology: Manual testing before automation, and protocol-level exploitation over basic app logic.

As a System Administrator, this CTF reinforced critical infrastructure lessons that I apply to my daily enterprise environments:

  • Never trust the client: JavaScript validation is not a security boundary.
  • Normalize HTTP Parsing: Ensure reverse proxies and backend servers strictly agree on HTTP RFCs (or enforce HTTP/2) to prevent socket poisoning.
  • Zero Trust Architecture: Never implicitly trust internal headers (X-Internal-Token) just because traffic originated from the proxy. Implement mTLS for backend communication.

If you are interested in more write-ups on Penetration Testing, DevSecOps, and Infrastructure Hardening, feel free to connect with me on LinkedIn or check out my GitHub for custom security tooling.