Operations 11 and 12 gave us access to the Ghost Protocol admin panel and configuration server. What we found inside pointed to something bigger — the Syndicate's central vault, racked in a Tallinn data-haven: the storage layer that holds everything Vantage Systems sells. API keys, database credentials, the personal data of people the Syndicate surveils, and the encryption keys to all of it.
SCRIBE manages the Ghost Protocol data layer. She is meticulous about access control — but she made a fundamental mistake: she protected the doors while leaving the windows open.
The sensitive data is there. Some of it sits in plaintext in configuration files. Some travels across the network without encryption. Some is stored in cloud buckets that were configured as public by default and never changed. No attack needed. No exploit required. Just look, and take.
THE DIARY LEFT IN THE LOBBY
CHILD-LEVEL EXPLANATION
Imagine a diary stored in a locked box for safety. But copies of the same diary are left in other places that are not protected at all.
Now imagine someone finds one of the exposed copies. They do not need to break the lock. The information is already available somewhere else.
If you lock your bedroom but leave your diary in the lobby — which lock matters?
INTERCEPTED — SCRIBE COMMS
11:58 UTC
SCRIBE
"The Director wants assurances, so here they are: all admin interfaces require authentication and the data access logs are monitored 24 hours. We have never had an unauthorised access event."
RAVEN
Shadow — SCRIBE monitors admin interface logins. She does not monitor direct access to the storage buckets, the plaintext config files, or the unencrypted API traffic. She has never had an unauthorised access event because she is not logging the places where data can actually be taken.
EXTRACT: Read the exposed secret in the captured config — API keys, DB credentials, plaintext passwords
03
SWEEP: Inspect all five storage locations and pull every secret left unprotected
04
WIN: Capture the field flag, then lock it down — the one principle that protects data at every layer
⚠ ETHICAL NOTICE: Sensitive Data Exposure is OWASP A02:2021. It is covered by CEH, OSCP, PortSwigger Web Academy, and every professional security certification. All interactions are fully simulated. Real data security testing requires explicit written authorisation.
🔧 UNDER THE HOOD▼
THE ATTACK — STEP BY STEP
When passwords are stored as MD5 or plain SHA1 hashes (no salt), they are crackable in seconds using rainbow tables or GPU cracking:
// MD5 of "password123": 482c811da5d5b4bc6d497ffa98491e38
// Cracking with hashcat:
hashcat -a 0 -m 0 hash.txt rockyou.txt
// Cracks in <1 second on a modern GPU
// SHA1 of "letmein": b7a875fc1ea228b9061041b7cec4bd3c52ab3ce3
hashcat -a 0 -m 100 hash.txt rockyou.txt
Unsalted hashes allow identical passwords to produce identical hashes — crack one, crack all. Reversed with pre-built lookup tables at crackstation.net.
Reversible encryption used for passwords (AES with a stored key) means anyone who gets the key AND the database gets all passwords in plaintext.
COMMON VARIATIONS
1. Database in transit without TLS — credentials transmitted in plaintext between app server and database, capturable by anyone on the network.
2. Credit card data stored in plaintext — PCI-DSS violation; full card numbers in a database column with no encryption.
3. Weak encryption key or hardcoded IV — AES-CBC with a hardcoded IV of all zeros means identical plaintexts produce identical ciphertexts:
// WRONG — hardcoded IV reveals patterns:
const iv = Buffer.alloc(16, 0);
cipher = crypto.createCipheriv('aes-256-cbc', key, iv);
// The same password encrypted twice gives the same ciphertext —
// an attacker can detect when two users have the same password
HOW TO DEFEND
Always use bcrypt or Argon2 for passwords — they are deliberately slow and include built-in salting:
You're holding live database credentials and an API key. Anyone with server access — a developer, a CI job, or you — can read this.
You just took it. Now make the call: what is the fundamental mistake that handed it to you?
MENDAX — HOW THIS IS ACTUALLY DONE
LIVE
MENDAX
This isn't a clever attack — it's reading what was left in the open. On this authorised, fictional target I grep the application files for secrets, and I watch the login traffic to see if it's even encrypted in transit:
$ grep -ri "password\|api_key\|secret" /var/www/.env
DB_PASS=Gh0st_Pr0t0c0l_2024 API_KEY=sk-live-4f8a9b2c...
$ tcpdump -i eth0 -A 'port 80' | grep -i pass
POST /login pwd=hunter2 # sent over plain HTTP, no TLS
MENDAX
Plaintext on disk, plaintext on the wire. No decryption needed because nothing was ever encrypted. The fix is encryption at rest and TLS in transit, with secrets in a vault — not a file. First, name the fundamental mistake.
TAP AN ANSWER — EXPLANATION APPEARS IMMEDIATELY
RAVEN — HINT (−20 XP)
Think about the diary in the lobby. The problem is not the password strength or the file format. The problem is that the secret is sitting in a place where it can be read. If you can read a file that contains a password — what can you do with that password?
✓
SENSITIVE DATA EXPOSURE UNDERSTOOD
The password could be 64 characters of random characters and it would not matter — it is sitting in a readable file in plaintext. The moment an attacker reads the file, the credential is compromised. The vulnerability is the exposure of the data itself, not its format or strength.
Simple version: A 50-character combination lock code written on a sticky note on the safe door. The complexity is irrelevant — it is readable by anyone who can see the note.
Real world: In 2019, researchers found over 200,000 API keys and credentials exposed in public GitHub repositories. Developers had committed .env files, config files, and hardcoded credentials to public repos. Automated scanners find these within seconds of a push. Average time to exploitation after public exposure: 4 minutes.
🔓
WHAT COUNTS AS SENSITIVE DATA
Sensitive data is anything that provides access, reveals private information, or enables harm if exposed. Categories: credentials (passwords, API keys, tokens, certificates), personal data (names, emails, health records, financial data), encryption keys (if you expose the key, the encryption is worthless), session tokens (anyone with your token can be you), internal infrastructure details (IP addresses, hostnames, database schemas).
Many developers think about sensitive data only in terms of user data — credit cards, health records. But credentials and API keys are equally sensitive. A leaked API key for a cloud provider gives an attacker the ability to spin up infrastructure, access storage, and run compute — often costing the victim thousands of dollars before detection.
PHASE 02
STORAGE INSPECTOR — FIND THE EXPOSURE
INTERACTIVE
The config file is just the start. SCRIBE's data layer spans five storage locations. The secret is somewhere inside each one — you just have to open them and look.
RAVEN
ENCRYPTED
Five Ghost Protocol storage locations are accessible. Each one holds data that SCRIBE believes is protected.
Open each location. Read what is stored there. Answer the question about what is dangerously exposed and why. All five must be completed to proceed.
MISSION OBJECTIVETap each storage location to open it. Read the contents. Answer the question about what is dangerously exposed. Complete all five to unlock the next phase.
LOCATIONS INSPECTED
0 of 5 inspected
RAVEN — HINT (−20 XP)
Look for three things: credentials or keys stored in plaintext, data transmitted without encryption, and storage configured with public access. Any one of these makes the data readable by an attacker without needing to bypass authentication.
✓
ALL STORAGE LOCATIONS INSPECTED
You found sensitive data exposure across every layer — plaintext credentials in config files, unencrypted traffic on the network, public cloud storage, and encryption keys stored alongside the data they protect. SCRIBE monitored the admin interface while the data sat unprotected in five different locations.
Simple version: The diary was in the lobby. The office. The hallway. The garden. Every room except the locked bedroom.
Why encryption keys stored with encrypted data defeats the purpose: Encrypting data and storing the key in the same location is equivalent to locking a box and leaving the key on top of it. The encryption adds complexity without adding protection. Keys must be stored separately — ideally in a dedicated secrets management service.
💾
SECRETS MANAGEMENT
Production systems should never store secrets in config files, source code, or environment variables that are committed to version control. Dedicated secrets managers — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager — store secrets encrypted, provide audit logs of every access, allow automatic rotation, and inject secrets into applications at runtime without the application ever storing them on disk.
The principle is zero-persistence: the secret should exist in memory only while it is being used, retrieved fresh from the secrets manager on each use. It should never touch disk, never appear in logs, and never travel across the network in plaintext.
PHASE 03
WHICH PRACTICES EXPOSE DATA?
CLASSIFY
Five locations. Five exposures. The pattern is clear — but SCRIBE's team might use these same mistakes across other systems. You need to be able to name them on sight.
RAVEN
ENCRYPTED
A list of data handling practices from Ghost Protocol codebases. Some protect sensitive data. Some expose it.
Tap a practice to select it. Mark it SAFE if it protects data, or EXPOSED if it risks sensitive data exposure.
TAP A PRACTICE — THEN CLASSIFY IT
Select a data practice above
🔒 SAFE
⚠ EXPOSED
RAVEN — HINT (−20 XP)
Safe practices: data encrypted at rest and in transit, secrets in a dedicated manager, minimum data collected, hashed passwords with salt. Exposed practices: plaintext storage, HTTP instead of HTTPS, hardcoded credentials, logging sensitive values, unencrypted backups.
✓
ALL PRACTICES CORRECTLY CLASSIFIED
Sensitive data exposure is not always a hack — it is often just data sitting in the wrong place without the right protection. Every exposed practice you identified shares the same root: data that should be protected being stored, transmitted, or logged without appropriate encryption or access control.
The minimum viable principle: Do not store data you do not need. Do not store it longer than you need it. Encrypt everything you do store. Use TLS for everything you transmit. Hash passwords — never store them. These five rules prevent the vast majority of sensitive data exposure incidents.
📜
DATA MINIMISATION
The most effective protection for data you do not have is not needing it in the first place. Data minimisation means collecting only what is strictly necessary, retaining it only as long as necessary, and deleting it securely when done. Under GDPR, data minimisation is a legal requirement — you must be able to justify every piece of personal data you store.
Many breaches expose data that the organisation did not even know they had — old databases, forgotten backups, test environments with production data copies. A data inventory — knowing exactly what sensitive data you hold and where — is the foundation of any data protection programme.
PHASE 04
PROTECT THE DATA — NOT JUST THE DOOR
DEFENSE
You've seen the exposure. You know how to classify it. One question left: what single principle, applied to every layer, would have made everything you found today unreadable?
RAVEN — FINAL DEBRIEF
LAST PHASE
SCRIBE is in custody. The Ghost Protocol storage layer is offline.
RAVEN: "Shadow — SCRIBE built excellent access control on the admin interfaces. She just never applied any protection to the data itself. Which single principle, applied consistently across every storage location, would have made every piece of data you found unreadable even if the storage was accessible?"
WHICH PRINCIPLE STOPS SENSITIVE DATA EXPOSURE?
RAVEN — HINT (−20 XP)
SCRIBE protected the doors — but not the data behind them. The right principle protects data regardless of whether an attacker reaches it. Even if they read the file, access the bucket, or intercept the network traffic — which approach makes the data unreadable anyway?
► INTEL — OP-13 // OPERATION DATA GHOST
TARGET: NEXUS Cloud Storage Infrastructure
Classification: TOP SECRET // Campaign 3 Ghost Protocol
MENDAX — CHANNEL BRIEFING
PRE-OP
MENDAX
A public S3 bucket nexus-backups-prod contains unencrypted database exports. Application logs contain API keys in plaintext. Database stores passwords as MD5 without salt.
📓
OWASP CLASSIFICATION
INTEL
A02:2021 — Cryptographic failures include exposed sensitive data via insecure storage, cleartext transmission, and broken/weak encryption algorithms.
⚖
GLOSSARY TERMS: auto-logged to your Field Manual as you encounter them.
📚 FIELD MANUAL — KEY TERMS
Sensitive Data Exposure
When an app fails to protect private data (passwords, keys, personal info) — so an attacker can simply read it rather than having to break in. OWASP A02.
S3 Bucket Misconfiguration
A cloud storage container (AWS S3) accidentally set to “public”, letting anyone on the internet list and download its files with no login.
Plaintext Credentials
Passwords or API keys stored or sent as readable text instead of being encrypted or hashed — usable instantly by anyone who sees them.
Encryption at Rest
Scrambling data while it sits in storage, so a stolen disk or database is useless without the key. The fix for this whole mission.
TLS
Transport Layer Security — encrypts data in transit (the padlock in HTTPS), so traffic tapped on the wire is unreadable.
HSTS
HTTP Strict Transport Security — a rule that forces browsers to always use HTTPS for a site, blocking downgrade-to-HTTP interception.
ACADEMY — SENSITIVE DATA EXPOSURE
PROTECT THE DATA. NOT JUST THE DOOR TO THE DATA.
BEGINNERWhat Is Sensitive Data Exposure?›
Sensitive data exposure happens when confidential information — passwords, API keys, personal data, encryption keys — is accessible without proper protection. This includes data stored in plaintext files, transmitted without encryption, or placed in publicly accessible storage.
The critical insight: this is not always a hack. Often the data was simply never protected in the first place. An attacker does not need to defeat encryption they never encounter.
Real world: In 2019, Capital One had 100 million customer records exposed. The data was in an S3 bucket. The bucket access control was misconfigured. No encryption bypass needed — the data was accessible to anyone who knew the URL. The breach was discovered when an attacker bragged about it online.
INTERMEDIATEAttack Techniques›
Public cloud storage:
AWS S3, Azure Blob, GCP Storage buckets set to public by default or misconfigured. Tools like GrayhatWarfare index public buckets. Simple HTTP GET retrieves data with no credentials.
Plaintext credentials in code:
Hardcoded passwords, API keys, and tokens committed to Git repositories. GitHub Dorks and tools like TruffleHog, GitLeaks scan repos automatically. Average detection time by attackers after public exposure: 4 minutes.
Unencrypted network traffic:
HTTP instead of HTTPS. Database connections without TLS. API calls on port 80. Wireshark or network sniffing on the same network captures credentials in plaintext.
Verbose error messages:
Stack traces revealing database connection strings, internal hostnames, and credentials. Common in development configurations left running in production.
EXPERTDefences and CVEs›
Encryption at rest: AES-256 for stored data. Encryption keys managed separately — HSM or dedicated secrets manager, never the same server as the data.
Encryption in transit: TLS 1.2+ on all connections. HSTS preloading. Certificate pinning for mobile apps. No HTTP fallback.
Secrets management: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault. No credentials in config files, env files committed to git, or source code.
Password hashing: bcrypt, scrypt, or Argon2. Never MD5, SHA-1, or unsalted SHA-256. Never store plaintext passwords under any circumstances.
Data minimisation: Do not collect data you do not need. Delete data when no longer required. Separate production and development data.
Notable incidents:
2019 Capital One — 100M records, misconfigured S3
2021 Twitch — 125GB source code + credentials leaked
2023 Samsung — GitHub repos with AWS credentials publicly exposed
2020 — Twitch: An anonymous actor published 125 gigabytes of Twitch internal data including full source code, internal security tools, and creator payout data. Investigation found credentials hardcoded in internal tools that had been committed to internal repositories — then accessed when those repositories were compromised. The credentials were the entry point.
REAL-WORLD TOOLS — SENSITIVE DATA EXPOSURE
WHAT PROFESSIONALS USE
🐍
TruffleHog
FREE / OPEN SOURCE
Scans Git repositories for secrets — API keys, passwords, tokens — using entropy analysis and pattern matching. Checks every commit in history, not just the current state.
Fast Git secret scanner. Used in CI/CD pipelines to block commits containing credentials before they reach the repository.
gitleaks detect --source . --verbose
☕
GrayhatWarfare
FREE TIER
Search engine for public cloud storage buckets (S3, Azure, GCP). Finds buckets containing sensitive files without any authentication — same as an attacker would.
Search: site:s3.amazonaws.com target-company
📷
Wireshark
FREE / OPEN SOURCE
Capture and inspect network traffic. Find unencrypted HTTP requests containing credentials, API keys, or session tokens travelling in plaintext.