Introduction

The Web-RTA (Web Red Team Analyst) certification by CyberWarFare Labs is a fully hands-on, black-box web application penetration testing exam. No multiple choice, no theory — just two live web applications and 16 flags to capture.

The exam covers real-world web vulnerabilities: JWT attacks, SQL injection, XXE, SSRF, OAuth misconfigurations, and brute force. If you’ve worked through OWASP Top 10 and done some CTF-style web challenges, you’ll recognize the patterns immediately.

This writeup documents the complete attack chain I used to pass — step by step, flag by flag.

⚠️ Disclaimer: This writeup is published after passing the exam. Exact flag values and credentials are not disclosed in full. The methodology is shared for educational purposes, as is standard practice in the security community.

WebApp 01

Reconnaissance

Starting with the provided IP, the first step is directory enumeration:

bash

feroxbuster -u http://<WEBAPP01_IP>:<PORT> -w /usr/share/wordlists/dirb/common.txt

The root page redirects to a login page. Note the URL structure — the /dashboard endpoint will matter shortly.

Flag 5 — Anonymous User Role

Navigating to the login page, there’s a CAPTCHA + username/password form. Skip trying to brute force it for now.

Instead, go directly to /dashboard without logging in. The application loads and reveals your current role in the UI:

• Flag 5: The role allocated to unauthenticated users → anonymous
• Flag 6: The endpoint where events are available → /dashboard

JWT Token Manipulation

While on the dashboard as an anonymous user, open Burp Suite and inspect the cookies. There’s an access_token_cookie - paste it into jwt.io.

The decoded payload reveals:

json

{
  "role": "anonymous",
  "username": "anonymous"
}

The token uses algorithm: none - meaning there's no signature verification. This is a classic JWT vulnerability.

Modify the payload:

json

{
  "role": "user",
  "username": "user"
}

Remove the signature entirely (keep the trailing dot), update the cookie in your browser (Storage tab in DevTools or via Burp), and reload the page.

You’re now authenticated as a user-role account. The dashboard now shows an event:

Flag 7 — Event Name

The event visible to authenticated users:

• Flag 7: Masquerade Ball

Flag 8 — Admin Username Discovery

The event details show it was created by a specific user. That username is:

• Flag 8: notatypicalsysadmin

SQL Injection — Admin Login Bypass

Log out and return to the login page. Enter notatypicalsysadmin as the username. Leave the password empty for now - but fill in the CAPTCHA correctly first.

Key insight: The application validates the CAPTCHA before checking credentials. If the CAPTCHA is correct, the response will confirm whether the username exists. This is an information disclosure vulnerability that lets you enumerate valid usernames.

Once you’ve confirmed the username is valid, exploit the SQL injection:

• Flag 10: The value of the flag in WebApp 01 → flag (the username found in /etc/passwd)

Flags 11, 12 & 13 — SSRF via Check Outage

Click Check Outage → Check Our Status. The application makes an internal request and returns service health data. Observing the response, it’s hitting:

• Flag 11: Internal URL for fetching secrets → http://127.0.0.1:8000/health

Now scroll down to the Fetch Status section. There’s a “Service URL” input field and a Fetch Secret button — a classic SSRF endpoint.

Step 1: Enter http://127.0.0.1:8000 and submit. The server returns a 418 status code (I'm a teapot) - the service is alive but rejects plain requests.

Step 2: URL-encode the target URL and resubmit:

http%3A%2F%2F127.0.0.1%3A8000

This time the server returns an encoded response with the label “hidden in layers”.

• Flag 12: The encoded data returned → a hex-encoded Base64 string

Step 3: Decode it — it’s hex that, when decoded, gives Base64. Decode the Base64:

bash

echo "<hex_string>" | xxd -r -p | base64 -d

The final decoded output contains credentials: a username and password.

• Flag 13: The plaintext version of “hidden in layers” → the decoded credentials (username:password pair)

WebApp 02

Reconnaissance

Using the second IP provided, navigating to the root returns a 404. Time to enumerate:

bash

feroxbuster -u http://<WEBAPP02_IP>:<PORT> -w /usr/share/wordlists/dirb/common.txt

Flag 14 — Login Endpoint Discovery

Directory fuzzing reveals a non-standard login path:

• Flag 14: WebApp 02 login endpoint → /client/login

Flag 15 — Client ID (IDOR)

Use the credentials extracted from WebApp 01’s SSRF exploitation (the “hidden in layers” plaintext) to log into /client/login.

You’re now logged in as a client account. The application displays your Client ID:

• Flag 15: Client ID allocated to the exfiltrated credentials → client_1337

OAuth Scope Manipulation + OTP Brute Force

After logging in, explore the available permissions/scopes. Attempting to access elevated features returns a permission error. Intercept the authorization request in Burp Suite.

In the request, find the scope parameter - currently set to read. Change it to admin:

scope=admin

Forward the modified request. The application now shows admin-level scope — but requires an OTP (One-Time Password) to confirm the privilege escalation.

The vulnerability: The application sends the same OTP code every time, making it trivially brute-forceable.

Send the OTP request to Burp Intruder:

1. Mark the OTP field as the payload position
2. Set payload type: Numbers
3. Range: 100–999 (3-digit OTP)
4. Start attack

The correct OTP is identified by a different response (redirect or 200 instead of error). In the exam environment, the OTP was 176 - but this may vary per lab instance.

Once the OTP is confirmed:

1. Copy the correct OTP
2. Go back to the application (not Burp)
3. Enter the OTP in the UI
4. Follow the redirect → Admin Dashboard

Click Go to Admin Panel.

Flag 16 — Bob’s Credit Card Number

The admin panel contains sensitive user data. Navigating through the admin interface reveals a user named Bob with his financial information exposed:

• Flag 16: Bob’s Credit Card number → (found in admin panel user data)

Key Lessons Learned

1. Always check JWT algorithm first.
none algorithm is a well-known vulnerability but still appears in real applications. Check jwt.io immediately whenever you see a JWT cookie.

2. CAPTCHA bypass ≠ brute force.
The CAPTCHA here wasn’t bypassed — it was used strategically. Solving it correctly to enumerate valid usernames, then using SQLi for the actual bypass, is cleaner than fighting the CAPTCHA itself.

3. Multi-layer encoding is intentional.
The hex → Base64 → plaintext chain in the SSRF response is designed to make you think before you decode. Know your encoding formats: hex, Base64, URL encoding.

4. OAuth scope parameters are user-controlled.
Never trust client-side scope values. Changing read to admin in a request shouldn't work - but it does in misconfigured systems. Always test scope escalation in OAuth flows.

5. OTP brute force only works if the OTP doesn’t change.
The application’s fatal flaw was issuing the same OTP code repeatedly. In a secure implementation, OTPs expire and change with each request. This is a real-world vulnerability class, not just a CTF trick.

Final Thoughts

Web-RTA is a solid entry-level web security certification. The attack chain is realistic — JWT manipulation, SQLi, XXE, SSRF, and OAuth abuse are all vulnerabilities you’ll encounter in real bug bounty targets and penetration tests.

It’s not the hardest exam. But it tests whether you can chain vulnerabilities together under a black-box scenario — and that skill is what separates someone who’s memorized OWASP Top 10 from someone who can actually exploit it.

If you’re preparing: be comfortable with Burp Suite, understand JWT structure deeply, and practice SSRF + XXE payloads from PortSwigger Web Security Academy. Everything else in this exam flows naturally from those skills.