Security Misconfiguration Tutorial — Default Credentials & Debug Endpoints

🔧

CAMPAIGN 3 — OPERATION OPEN DOOR

SECURITY MISCONFIGURATION // TARGET: GHOST PROTOCOL CONFIG SERVER

12

OWASP A05:2021

SECURITY
MISCONFIGURATION

DEFAULT CREDENTIALS // DEBUG MODE // EXPOSED SERVICES // VERBOSE ERRORS

OPERATION OPEN DOOR

📡

SITUATION REPORT

CLASSIFIED

Operation Forced Entry gave us access to the Ghost Protocol admin panel. What we found inside led to a bigger discovery — a configuration server, racked in a Reykjavik bulletproof facility, that manages every Syndicate service Vantage Systems quietly runs.

CASTLE, the server administrator, deployed this configuration server three months ago. He chose a popular open-source framework, installed it, and moved on. He changed nothing from the factory settings.

Default admin password — still set. Debug mode — still on, exposing internal file paths and stack traces. Directory listing — still enabled, showing every file on the server. Error messages — verbose, revealing database names, software versions, and internal infrastructure.

This is not a clever attack. There is no payload to craft. No vulnerability to exploit. Someone left every window open and every door unlocked. We are going to walk in.

THE HOUSE WITH EVERY WINDOW OPEN

CHILD-LEVEL EXPLANATION

Imagine a house built with strong locks and alarms. But the owner never activates them properly. Some doors are left unlocked and some protections are left in default state.

Now imagine someone arrives and simply tries the doors. They find many protections are not actually active. So nothing needs to be broken — access is already open.

If every window in a house is open because the owner never closed them — is that a problem with the windows, or with the owner?

INTERCEPTED — CASTLE COMMS

10:33 UTC

CASTLE

"The Director audits me personally, so spare me the lecture. The configuration server runs the latest version of the framework — no known CVEs. I run weekly vulnerability scans. The software is clean."

RAVEN

Shadow — CASTLE scans for known CVEs. He does not check configuration. The framework is clean — nobody disputes that. But debug mode is on, the admin password is still "admin", and the server lists its own file directory publicly. We do not need a CVE. We need a browser.

MISSION OBJECTIVES

01

TARGET: The Ghost Protocol config server, run by CASTLE — fully patched, zero CVEs, but still running factory defaults

02

EXPLOIT: Claim admin with the default login, then use the Config Auditor to scan the live config and toggle off every dangerous setting

03

SWEEP: Classify every configuration setting in play — flag which ones expose the server and which are safe

04

WIN: Capture the field flag, then close it — the process that stops misconfiguration ever shipping to production

⚠ ETHICAL NOTICE: Security Misconfiguration is OWASP A05:2021. It is covered by CEH, OSCP, PortSwigger Web Academy, and every professional security certification. All interactions here are fully simulated. Real security audits require explicit written authorisation.

🔧 UNDER THE HOOD▼

THE ATTACK — STEP BY STEP

Security misconfiguration — exposed sensitive files and debug endpoints left on by default. Check for common exposures:

// Exposed .env file — contains secrets in plaintext: GET /.env // Returns: DB_PASSWORD=supersecret, JWT_SECRET=abc123, STRIPE_KEY=sk_live_... // Debug/admin endpoints left enabled in production: GET /debug/stack-trace GET /_debug/vars GET /console (e.g. Django debug console, Rails error page) GET /actuator/env (Spring Boot — dumps all env vars)

Directory listing enabled on web server — browse source files:

GET /uploads/ // shows all user-uploaded files GET /backup/ // backup files with database dumps

COMMON VARIATIONS

1. Default credentials left unchanged — admin/admin, admin/password on routers, databases, and admin panels:

// Common targets: http://target/phpmyadmin // MySQL admin (root with no password) http://target:8080/manager // Tomcat (admin:admin) http://target:5601 // Kibana (no auth by default)

2. Error messages leaking stack traces — full stack traces reveal framework, file paths, line numbers, and sometimes source code.

3. Exposed git repository — the .git folder left accessible reveals full source code history:

GET /.git/config // repo config GET /.git/HEAD // current branch // Tool: gitdumper.py to reconstruct entire repo

HOW TO DEFEND

Turn off debug mode and block sensitive files in production config:

# Nginx — block sensitive files location ~ /\. { deny all; return 404; } location ~* \.(env|git|log|bak|sql)$ { deny all; return 404; } # Node.js — disable debug endpoints in prod if (process.env.NODE_ENV === 'production') { app.use('/debug', (req, res) => res.status(404).end()); } # Express — disable error stack traces in prod app.use((err, req, res, next) => { res.status(500).json({ error: process.env.NODE_ENV === 'production' ? 'Server error' : err.stack }); });

Scan for exposed secrets with tools like truffleHog or git-secrets before every deploy.

⚡ CYBER RANGE — ACTIVE ENVIRONMENT

LIVE

TARGET

ghost-config.ghost-capital.int

IP ADDRESS

10.47.1.12

OS / SERVER

Ubuntu 22.04 · nginx/1.20.0

KEY SERVICES

Spring Boot/3.1 · Actuator endpoints · Admin panel

ATTACK SCOPE

/admin/* · /.env · /actuator/* — full config surface in scope

ATTACKER NODE

shadow@sigma9 · 10.99.0.1

📋 ROOM TASKS

01

✓

Understand how default credentials expose infrastructure

02

▶

Gain admin access via default credentials and exposed panels

03

○

Classify dangerous vs safe configuration settings

04

○

Identify the hardening checklist 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

CLAIM THE DEFAULT LOGIN

MCQ

RAVEN

ENCRYPTED

You just logged into the Ghost Protocol config server as admin — no exploit, you simply typed admin / admin and it let you in. The factory defaults were never changed:

ADMIN_PASSWORD = "admin"
DEBUG_MODE = true
DIRECTORY_LISTING = enabled
ERROR_DETAIL = verbose

CASTLE swore the server was secure — deployed three months ago, weekly CVE scans, zero known vulnerabilities in the software. And you walked straight in anyway.

You just claimed admin with the factory password. Now make the call: why is a fully-patched server still wide open?

MENDAX — HOW THIS IS ACTUALLY DONE

LIVE

MENDAX

No exploit needed — misconfiguration just leaves the doors open. Standard recon on this authorised, fictional target: I check the obvious admin path and try the vendor's documented default password. People forget to change it:

$ curl "https://nexus.int/admin/"        # directory listing is ON
Index of /admin/  →  config.bak  users.db  .env
$ curl -u admin:admin "https://nexus.int/admin/console"
200 OK — Welcome, administrator (default credentials)

MENDAX

The software had zero CVEs and it still fell in seconds — default password, listed directories, exposed backups. The fix is hardening: change defaults, turn off listings, hide error detail. First, you say why a patched server can still be wide open.

TAP AN ANSWER — EXPLANATION APPEARS IMMEDIATELY

RAVEN — HINT (−20 XP)

Think about the house analogy. CASTLE checked whether the windows were manufactured correctly — no defects in the glass. But he never checked whether they were open or closed. A CVE is a defect in the glass. Default settings are the windows being left open. They are separate problems.

✓

MISCONFIGURATION UNDERSTOOD

Software vulnerabilities (CVEs) and configuration vulnerabilities are completely different things. A CVE scanner checks the code. It does not check whether the admin password is still "admin" or whether debug mode is switched on. The software can be perfectly written and still deployed in a way that hands attackers everything they need.

Simple version: The house alarm was checked by the manufacturer — no defects. But the owner never turned it on and left every window open. The alarm being perfect does not make the house secure.

Real world: In 2017, a default Elasticsearch instance with no authentication was found to contain 1.4 billion stolen credentials — left open to the public internet with factory settings. No CVE was exploited. The software worked exactly as designed. The configuration was just never changed.

PHASE 02

CONFIG AUDITOR — FIX THE SERVER

INTERACTIVE

You're in. CASTLE's admin credentials accepted without hesitation. Now the real work: the config file is live and every dangerous setting is still at factory default. Time to see exactly what the server is broadcasting to the world.

RAVEN

ENCRYPTED

We have read access to the Ghost Protocol config server. The configuration file is live below.

You are the security auditor. Read each setting. Tap any dangerous setting to highlight it. When you have identified all the dangerous ones, tap FIX ALL DANGEROUS to harden the server.

The threat score shows how exposed the server is right now. Get it to zero.

MISSION OBJECTIVEScan the live config file. Tap any setting tagged DANGER to flag it. Then hit FIX ALL DANGEROUS to harden the server. Success = threat score drops to zero.

SERVER THREAT SCORE

10 / 10 dangerous settings active — server fully exposed

ghost-protocol-config.yaml — LIVE

RAVEN — HINT (−20 XP)

Look for: default passwords (admin, password, 123456), debug or verbose modes set to true, features that expose internal details (directory listing, stack traces, version headers), and open access settings (allow_all_origins, anonymous access). These all need to be off or changed in production.

✓

SERVER HARDENED — THREAT SCORE ZERO

Every dangerous default setting is now corrected. The server no longer exposes its internals through debug pages, verbose errors, or open directory listings. The default admin password is replaced. The threat score is zero.

Simple version: We closed every window, locked the back door, and changed the key under the mat. The alarm was always capable — we just switched it on properly.

Why this matters in production: Every minute a server runs with default settings in production is a minute it is fully exposed. Scanners like Shodan index misconfigured servers automatically. Attackers search for them continuously. A server deployed with defaults is compromised faster than most organisations can detect the intrusion.

PHASE 03

WHICH SETTINGS ARE DANGEROUS?

CLASSIFY

Server hardened, threat score zeroed. But CASTLE has nine more Ghost Protocol nodes. You need to be able to spot a misconfigured setting on sight — before the next one goes live.

RAVEN

ENCRYPTED

RAVEN found a list of configuration settings across Ghost Protocol servers. Some are dangerous in production. Some are fine to keep.

Tap a setting to select it. Mark it DANGEROUS if it should never be active on a production server, or SAFE if it is fine to leave on.

Simple rule: if a setting reveals internal information, removes authentication, or enables development-only features — it is dangerous in production. If it is a security feature or a neutral operational setting — it is safe.

TAP A SETTING — THEN CLASSIFY IT

Select a configuration setting above

⚠ DANGEROUS

✓ SAFE

RAVEN — HINT (−20 XP)

Production servers should be hardened — debug off, errors minimal, authentication enforced, internal details hidden. Ask: does this setting help an attacker learn about the system, bypass authentication, or access things they should not? If yes — dangerous. If it is a security feature or neutral — safe.

✓

ALL SETTINGS CORRECTLY CLASSIFIED

You can now identify dangerous production configuration at a glance. Development features, default credentials, verbose error modes, and open access settings all belong in development environments only. They have no place on a production server facing real users and real attackers.

The hardening principle: Production servers start with everything disabled. Features and access are added only when needed and justified. This is the opposite of development — where everything is enabled for convenience. The transition from development to production must include a deliberate hardening step.

PHASE 04

CLOSE THE DOOR — THE RIGHT PROCESS

DEFENSE

You can classify dangerous settings cold. Now the final question: what single process in the deployment pipeline stops misconfiguration from ever reaching production in the first place?

RAVEN — FINAL DEBRIEF

LAST PHASE

CASTLE is in custody. The configuration server is offline.

RAVEN: "Shadow — last question. The replacement server is being deployed now. CASTLE ran CVE scans every week. He just never looked at the configuration itself. Which single process would have caught every dangerous setting before the server went live?"

WHICH PROCESS PREVENTS MISCONFIGURATION?

RAVEN — HINT (−20 XP)

CASTLE checked for software vulnerabilities — but never checked the configuration itself. The right process checks configuration specifically and consistently, before deployment. Which option does that?

► INTEL — OP-12 // OPERATION OPEN DOOR

TARGET: NEXUS Production Web Server

Classification: TOP SECRET // Campaign 3 Ghost Protocol

MENDAX — CHANNEL BRIEFING

PRE-OP

MENDAX

Deployed with default credentials (admin/admin), debug endpoints live at /debug/env and /debug/phpinfo, server version exposed in headers, directory listing enabled on /static/.

📓

OWASP CLASSIFICATION

INTEL

A05:2021 — Security misconfiguration is the most widespread issue. Every layer can be misconfigured: OS, framework, database, server, custom application code.

⚖

GLOSSARY TERMS: Security Misconfiguration, Default Credentials, Debug Endpoint, Information Disclosure, HSTS, Security Headers. All terms auto-logged to your Field Manual as you encounter them.

ACADEMY — SECURITY MISCONFIGURATION

THE SOFTWARE IS FINE.
NOBODY READ THE SETUP GUIDE.

BEGINNERWhat Is Security Misconfiguration?›

Security misconfiguration happens when software is deployed with insecure default settings, unnecessary features enabled, or inadequate hardening applied. The software itself may be perfectly written — no bugs, no CVEs — but the way it is configured creates vulnerabilities.

Common examples: default admin passwords, debug mode left on in production, directory listing enabled, error messages that reveal internal details, unnecessary services running, and overly permissive access controls.

It is OWASP A05:2021 and one of the most common vulnerabilities found in real-world assessments — because it requires no coding mistake. Just a configuration step that was skipped.

Real world: In 2019, Capital One suffered a breach exposing 100 million customer records. Part of the root cause was a misconfigured Web Application Firewall — an SSRF vulnerability (from Op 10) was exploitable because the WAF was not configured to restrict outbound metadata requests. Two vulnerabilities combined — the code bug and the configuration mistake.

INTERMEDIATECommon Misconfiguration Patterns›

Default credentials:
admin/admin, admin/password, root/root — still found in production databases, routers, admin panels worldwide

Debug mode in production:
Django DEBUG=True, Laravel APP_DEBUG=true — exposes full stack traces, environment variables, database credentials in error pages

Directory listing enabled:
Apache/Nginx with autoindex on — attacker can browse every file on the web server

Verbose error messages:
Full stack traces reveal framework version, database type, file paths, internal hostnames

Unnecessary services:
Admin interfaces reachable from the internet (phpMyAdmin, Kibana, Redis, Elasticsearch with no auth)

Open CORS:
Access-Control-Allow-Origin: * — any website can make authenticated requests to the API

EXPERTDefences and CVEs›

The correct process — security hardening checklist before every deployment:
A written checklist of every setting to verify before a server goes live. Applied by a second person, not the developer who built it. Automated where possible using Infrastructure as Code security scanners.

Specific hardening steps:
Change all default credentials immediately on deployment
Disable debug mode, verbose errors, and directory listing in production
Remove all sample applications, default pages, and test endpoints
Restrict admin interfaces to internal networks only
Use security headers: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options
Run automated config scanners: Lynis (Linux), ScoutSuite (cloud), Trivy (containers)

Notable incidents:
2017 — MongoDB default open access — 27,000 databases wiped and ransomed in 2 weeks
2019 — Elasticsearch default open — 1.2 billion records exposed publicly
2020 — Twitch source code leaked via misconfigured internal server

2017 — MongoDB Ransomware Wave: Attackers wrote a script that searched Shodan for MongoDB instances with no authentication (the default). They wiped the databases, left a ransom note, and moved on. 27,000 databases were affected in 2 weeks. No CVE. No sophisticated attack. Default settings, automated targeting, mass destruction.

REAL-WORLD TOOLS — SECURITY MISCONFIGURATION

WHAT PROFESSIONALS USE

🌎

Shodan

FREE TIER

Search engine for internet-connected devices. Find servers running with debug mode on, databases with no authentication, and services with default certificates. Both attackers and defenders use it to find exposed assets.

shodan search "product:MongoDB" port:27017 --facets country

🔥

Nikto

FREE / OPEN SOURCE

Web server scanner that checks for dangerous default files, misconfigured headers, debug endpoints, and unnecessary services. Covers over 6,700 potentially dangerous files and outdated software.

nikto -h https://target.com -output report.html

📜

Lynis

FREE / OPEN SOURCE

Linux security auditing tool. Runs on the server itself and checks hundreds of configuration settings against security best practice. Produces a hardening index score and prioritised list of findings.

lynis audit system --quick

🔍

Burp Suite

FREE TIER

Intercept responses and check HTTP security headers manually. Missing headers like Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security are common misconfigurations detectable in every HTTP response.

Target → Site Map → Right-click → Scan → Active scan for headers