[SYS] HACKAACADEMY FIELD TERMINAL v5.3.0
[INTEL] Ghost Protocol admin panel — role checks on UI only — API unprotected
[FIND] /api/admin/* endpoints — no server-side role verification
[WARN] GATEKEEPER monitoring — anomaly detection on login events only
[HANDLER] RAVEN — Ghost Protocol Phase 1 — channel secured
[PRIORITY] OPERATION FORCED ENTRY // OP-11 // CAMPAIGN 3 BEGINS
[TARGET] The door says Staff Only. Walk through it. Nobody checks inside.
[SYS] Welcome back, Agent Shadow. The Ghost Protocol starts now.
«
‹
HACKAACADEMY
OP-11 // FORCED ENTRY // BROKEN ACCESS CONTROL // CAMPAIGN 3
0
XP
R1
RANK
0%
DET
↻
RESET
🔐
CAMPAIGN 3 — OPERATION FORCED ENTRY
BROKEN ACCESS CONTROL // TARGET: GHOST PROTOCOL ADMIN PANEL
11
OWASP A01:2021 — #1 MOST COMMON

BROKEN
ACCESS CONTROL

PRIVILEGE ESCALATION // UNAUTHORISED API ACCESS // FORCED BROWSING
OPERATION FORCED ENTRY
📡

SITUATION REPORT

CLASSIFIED
The first phase is over. NEXUS is down. But the people who trained and funded it are still breathing — the Syndicate, operating behind a clean corporate skin called Vantage Systems. Their nerve centre runs out of an Amsterdam data-haven, and Revenant has found the way in: an admin panel that controls the entire infrastructure.

GATEKEEPER built the panel. He is proud of the login system — strong passwords, rate limiting, two-factor authentication. The login page is a fortress.

But once you are logged in as any user, the panel has a fatal mistake. The role restrictions only exist in the browser. The server shows you a menu with items greyed out based on your role. But the underlying API endpoints — the ones the buttons call — have no role check at all.

We are going to log in as a normal user and call the admin API endpoints directly. No one will stop us because no one checks.
THE CONCERT WITH NO BACKSTAGE CHECKS
CHILD-LEVEL EXPLANATION
Imagine a theater with strict ticket checks at the entrance. Once inside, there are many restricted doors leading to backstage areas. But those backstage doors have no guards.

Now imagine someone enters normally with a valid ticket, but then walks into restricted areas freely. Because nothing inside the system continues checking what they are allowed to access.
If the staff door only has a sign and no one checking behind it — what stops a regular ticket holder from walking through?
INTERCEPTED — GATEKEEPER COMMS
09:14 UTC
GATEKEEPER
"Tell Director Kane the panel's airtight. The admin login has MFA, rate limiting, and bcrypt password hashing. Only authenticated users can even reach the panel. The role permissions are enforced in the dashboard dropdown."
RAVEN
Shadow — GATEKEEPER just described broken access control perfectly without knowing it. He secured the front gate completely. He put the role restrictions in the browser dropdown — which is just HTML and JavaScript that we control. The API endpoints behind those buttons have no checks. We walk straight through the staff door.
MISSION OBJECTIVES
01
TARGET: The Ghost Protocol admin panel and its /api/admin endpoints — they hide buttons in the browser but never re-check your role server-side
02
EXPLOIT: Skip the UI and call the admin endpoint directly with a normal user's cookie — trigger an admin-only data export
03
SWEEP: Classify every access control implementation in play — flag which checks are real (server-side) and which are fake (browser-side)
04
WIN: Capture the field flag, then close it — the one change that makes access control real on every request
⚠ ETHICAL NOTICE: Broken Access Control is OWASP A01:2021 — the most common web vulnerability. It is covered by CEH, OSCP, PortSwigger Web Academy, and every professional security certification. All interactions here are fully simulated. Real testing requires explicit written authorisation.
THE ATTACK — STEP BY STEP
Broken access control — the UI hides a button, but the API endpoint behind it has no authorization check. Call it directly:
// Admin button hidden in HTML for regular users // But the endpoint itself is unprotected: POST /api/admin/export-all-data Cookie: session=REGULAR_USER_SESSION // Or promote yourself by calling the role-update endpoint: POST /api/user/update-role {"userId": "MY_USER_ID", "role": "admin"}
Horizontal privilege escalation — access another user's data at your privilege level:
// Modify the user_id parameter in any request: GET /api/account/settings?user_id=OTHER_USER_ID DELETE /api/messages/999 // delete another user's message
COMMON VARIATIONS
1. Forced browsing — directly navigate to URLs that the app never links to for your role:
https://victim.com/admin/dashboard https://victim.com/api/v1/users/export https://victim.com/debug/env
2. Method override — some frameworks honour X-HTTP-Method-Override headers, letting you turn a GET into a DELETE:
GET /api/user/123 X-HTTP-Method-Override: DELETE
3. Parameter pollution — send the same parameter twice; some frameworks use the second value, others the first:
POST /api/transfer amount=100&amount=99999
HOW TO DEFEND
Enforce authorization in middleware on every state-changing endpoint — never rely on the UI to hide access:
// Express.js middleware pattern function requireRole(role) { return (req, res, next) => { if (!req.user) return res.status(401).json({ error: 'Unauthenticated' }); if (req.user.role !== role) return res.status(403).json({ error: 'Forbidden' }); next(); }; } // Apply to every protected route: app.post('/api/admin/export-all-data', requireRole('admin'), exportHandler); app.delete('/api/user/:id', requireRole('admin'), deleteUserHandler);
Deny by default — if a route is not explicitly permitted, reject it. Log all 403s for monitoring.
⚡ CYBER RANGE — ACTIVE ENVIRONMENT
LIVE
TARGET
ghost-protocol-admin.ghost-capital.int
IP ADDRESS
10.47.1.11
OS / SERVER
Ubuntu 22.04 · nginx/1.20.0
KEY SERVICES
Node.js/18.x · Express.js · JWT auth · Admin API
ATTACK SCOPE
/admin/* · /api/admin/* — forced browsing in scope
ATTACKER NODE
shadow@sigma9 · 10.99.0.1
📋 ROOM TASKS
01
✓
Understand the difference between authentication and authorisation
02
▶
Access admin-only endpoints as a regular authenticated user
03
○
Classify access control failures vs safe implementations
04
○
Identify the deny-by-default middleware fix
05
○
Submit the capture-the-flag token
🚩
CAPTURE THE FLAG
Complete the exploit lab. The flag appears in the terminal output. Copy and submit it here for +50 XP.
PHASE 01
CALL THE ADMIN ENDPOINT
MCQ
RAVEN
ENCRYPTED
You logged in as a plain user — no admin rights, the admin buttons greyed out and hidden in the page. So you ignored the button and called the endpoint behind it directly with your own cookie:

POST /api/admin/export-all-data

The server checked one thing: are you logged in? Yes. Is there a role check? No. It handed you the full data export — an admin-only action, triggered by a regular account.

The JavaScript hid the button. The server never asked who you were.

You just walked through a door that looked locked. Now make the call: why did hiding the button protect nothing?
MENDAX — HOW THIS IS ACTUALLY DONE
LIVE
MENDAX
The real method needs no exploit at all — just an authorised tester and their own login. The greyed-out admin button is only hidden in the page. The endpoint behind it is wide open. I skip the UI entirely and call the API directly with my normal user cookie:
$ curl -X POST -b "session=$MY_COOKIE" \ "https://nexus.int/api/admin/export-all-data" # no admin role required — the server only checked we were logged in { "exported": 14213, "file": "all_users.json" }
MENDAX
A regular account just triggered an admin-only action. The browser hid the button; the server forgot to. Access control has to live on the server, checked on every request. First — explain why the hidden button was never protection.
TAP AN ANSWER — EXPLANATION APPEARS IMMEDIATELY
RAVEN — HINT (−20 XP)
Think about the concert analogy. Hiding the button in the browser is like putting a "Staff Only" sign on a door. The sign is visible — but can someone who knows the door address walk through it anyway? Can they reach the API URL without clicking any button at all?
✓
BROWSER-SIDE CONTROLS CANNOT PROTECT APIS
The browser is a tool the attacker controls. They can open a terminal and call any API endpoint they know the URL for — no button click needed. Hiding a button in HTML or disabling it with JavaScript does nothing. The API endpoint still exists. The server still responds.

Simple version: Putting a "Staff Only" sign on a door stops people who follow signs. It does not stop someone who just opens the door and walks through.

Access control must live on the server — checking every request before returning data.
Real world: In 2019, Facebook had a broken access control vulnerability where any user could remove other users from groups they administered. The button was hidden — but the API endpoint was not protected. Over 100 million groups affected.
PHASE 02
ROLE PERMISSION MATRIX — SET THE POLICY
INTERACTIVE
GATEKEEPER had no policy — every authenticated user could reach every endpoint. Before the next op, define what the correct policy should have been.
MISSION OBJECTIVESet the correct allow/deny for every cell in the Role Permission Matrix — four roles, five actions. Apply least privilege: each role gets only the minimum permissions needed to do its job. Tap CHECK POLICY when done.
RAVEN
ENCRYPTED
We need to understand what the correct access policy should have been. If GATEKEEPER had done this properly — which roles should have which permissions?

Below is the Role Permission Matrix for the Ghost Protocol admin panel. Four roles: Guest, Analyst, Operator, Admin. Five actions: View Reports, Edit Records, Transfer Funds, Delete Records, Manage Users.

Tap each cell to cycle through: ALLOW ✓ → DENY ✗ → back to ?

When you are ready, tap CHECK POLICY. The system will show you which cells are correct and which break the principle of least privilege.
ALLOW
DENY
Not set
Permission GUEST ANALYST OPERATOR ADMIN
Tap cells to configure. Tap CHECK POLICY when ready.
RAVEN — HINT (−20 XP)
Use the principle of least privilege — give each role only what it needs and nothing more. Guests should see nothing sensitive. Analysts can view reports but not change anything. Operators can edit records but not delete or manage users. Only Admins get everything. Transfer Funds and Delete Records should only ever be Admin.
✓
CORRECT ACCESS CONTROL POLICY CONFIGURED
The matrix now enforces the principle of least privilege. Every role has exactly what it needs — and nothing more. Transfer Funds and Delete Records are Admin-only because the consequences of those being accessible to any other role are catastrophic.

Simple version: A junior staff member at the concert can open general doors. Only a senior manager can open the safe. The sign alone was never enough — you need someone checking.
Why this matters: GATEKEEPER had all this logic in the browser dropdown. A viewer with a normal account could call POST /api/admin/transfer-funds directly and it would succeed. The matrix is only useful if it is enforced on the server — not displayed in HTML.
PHASE 03
WHICH ACCESS CONTROLS ARE REAL?
CLASSIFY
The policy is set. Now test your eye — GATEKEEPER's codebase is full of controls that look real. Some are enforced on the server. Others are just decoration in the browser, bypassed by deleting a line of JavaScript.
RAVEN
ENCRYPTED
RAVEN found a list of access control implementations across Ghost Protocol servers. Some are genuine server-side controls — an attacker cannot bypass them. Some are fake client-side controls — an attacker bypasses them in seconds.

Tap a control to select it. Mark it REAL if it enforces access on the server, or FAKE if it only exists in the browser and can be bypassed.

Simple rule: if the check runs in the browser (JavaScript, HTML attributes, CSS) — fake. If the check runs on the server before returning data — real.
TAP A CONTROL — THEN CLASSIFY IT
Select an access control above
✓ REAL
✗ FAKE
RAVEN — HINT (−20 XP)
Ask: where does the check actually run? JavaScript hide/show, disabled HTML attributes, CSS display:none — all run in the browser. The attacker controls the browser. Server-side middleware that checks the session role before processing the request — that runs where the attacker has no control.
✓
ALL ACCESS CONTROLS CORRECTLY CLASSIFIED
Every browser-side control is fake from a security perspective. The attacker owns the browser — they can run any JavaScript, remove any HTML attribute, and call any API URL directly without the browser at all.

Real access controls live on the server and check every request before any data is returned or any action is taken.
The most dangerous phrase in web development: "We hide that feature for non-admin users." Hidden is not protected. Disabled is not protected. Only server-side verified is protected.
PHASE 04
CLOSE THE DOOR — THE RIGHT FIX
DEFENSE
GATEKEEPER is down. The fix is one architectural choice — deny by default, enforce server-side. Pick the implementation that makes every bypass we ran today return 403 Forbidden.
RAVEN — FINAL DEBRIEF
LAST PHASE
GATEKEEPER is in custody. The Ghost Protocol admin panel is offline.

RAVEN: "Shadow — last question. The replacement system is being designed right now. Which single change would have stopped every access control bypass we used today? The panel still needs roles. The fix just needs to make those roles real."
WHICH FIX STOPS BROKEN ACCESS CONTROL?
RAVEN — HINT (−20 XP)
The attack worked because the server never checked the role before processing the request. The fix adds that check on the server — before any data is returned, before any action is taken. Which option enforces the role check on the server for every request?
► INTEL — OP-11 // OPERATION FORCED ENTRY
TARGET: NEXUS Internal API Gateway
Classification: TOP SECRET // Campaign 3 Ghost Protocol
MENDAX — CHANNEL BRIEFING
PRE-OP
MENDAX
The API checks for a valid session token (authentication) but not whether that session has permission to the requested resource (authorisation). Any valid token reaches any endpoint.
📓

OWASP CLASSIFICATION

INTEL
A01:2021 — Broken access control occurs when authentication is enforced but authorisation is not. Vertical escalation: regular user reaches admin functions. Horizontal: user A accesses user B's data.
⚖
GLOSSARY TERMS: Broken Access Control, Vertical Privilege Escalation, RBAC, ABAC, Authorisation, JWT Claims. All terms auto-logged to your Field Manual as you encounter them.
ACADEMY — BROKEN ACCESS CONTROL
HIDDEN IS NOT PROTECTED.
THE SERVER MUST CHECK EVERY REQUEST.
BEGINNERWhat Is Broken Access Control?›
Access control is the set of rules that decide who can do what inside a system. Broken access control means those rules are either missing, wrong, or only enforced in the wrong place.

The most common mistake: putting role checks in the browser (hiding buttons, greying out menus) instead of on the server (checking the role before processing any API request).

The browser is something the attacker controls. They can call any API endpoint directly — no button click required. If the server does not check, it responds.
Real world: Broken Access Control is OWASP number 1 — the most common vulnerability found in web applications. In 2023, 94% of applications tested by OWASP had at least one broken access control flaw. It affects every type of system: banking apps, healthcare portals, government systems, social networks.
INTERMEDIATEAttack Techniques›
Forced browsing:
Navigate directly to a URL the application never showed you: /admin/dashboard, /api/admin/users. If no server check exists — you get in.

Privilege escalation via parameter tampering:
Change role=viewer to role=admin in a request. If the server trusts the client-supplied role — you are now admin.

IDOR (Insecure Direct Object Reference):
Change /api/records/42 to /api/records/43. If no ownership check — you read someone data.

Missing function-level access control:
A feature exists in the API but is hidden in the UI. Call the API endpoint directly — it works for any authenticated user regardless of role.

HTTP method tampering:
The GET endpoint checks roles. The POST endpoint to the same URL does not. Use POST instead of GET to bypass the check.
EXPERTDefences and CVEs›
The correct fix — server-side role verification on every endpoint:
Every API endpoint checks the authenticated session role before processing the request. Middleware approach: a single function wraps every protected route and returns 403 Forbidden if the role does not match.

Code example (Node.js middleware):
function requireRole(role) {
  return (req, res, next) => {
    if (req.session.role !== role) return res.status(403).json({error: 'Forbidden'});
    next();
  };
}
app.post('/api/admin/transfer', requireRole('admin'), handler);

Defence in depth:
Log all access denials — they indicate probing
Rate limit repeated 403 responses from the same IP
Use an allowlist approach: default deny, explicitly allow
Regular access control audits — check every endpoint

Notable CVEs:
CVE-2019-5736 — runc container escape, broken access to host
CVE-2021-41773 — Apache HTTP Server path traversal, CVSS 9.8
CVE-2022-0492 — Linux cgroups privilege escalation
2023 — MOVEit Transfer: A broken access control vulnerability allowed unauthenticated users to access the admin API. Over 2,000 organisations affected. 95 million individuals had data exposed. Total damages estimated at $10 billion. One missing role check on one API endpoint.
REAL-WORLD TOOLS — BROKEN ACCESS CONTROL
WHAT PROFESSIONALS USE
🔍
Burp Suite
FREE TIER
Intercept requests as a low-privilege user. Use Repeater to replay the same requests with a high-privilege session cookie replaced — or just replay the original request without the cookie. Watch if the server enforces role checks.
Proxy → Intercept → Send to Repeater → Change session cookie → Compare responses
🔌
Autorize (Burp Extension)
FREE / OPEN SOURCE
Automatically tests access control. Logs in as admin, captures all requests, then replays each one with a low-privilege session. Flags any response that returns the same data — meaning the endpoint is not enforcing roles.
Install via BApp Store → Configure low-privilege session → Browse as admin → Review flagged endpoints
🔐
DirBuster / ffuf
FREE / OPEN SOURCE
Brute-force hidden admin paths. Many apps hide admin panels at predictable URLs. Enumerate them without needing to know they exist — then test if role checks are enforced.
ffuf -w wordlist.txt -u https://target.com/FUZZ -mc 200,302 -fc 404
🌊
OWASP ZAP
FREE / OPEN SOURCE
Active scan tests for broken access control automatically. Forced browsing scanner discovers hidden endpoints. Good for initial reconnaissance before manual testing.
Active Scan → Access Control Testing → Forced Browse → View alerts
⚡
XP EARNED
+0
FIRST ATTEMPT
RANK: RECRUIT