An educational ethical-hacking game for young learners — built by a father for his 12-year-old son.
Cyber Flags CTF is a browser-based Capture The Flag (CTF) game that teaches the basics of ethical hacking (penetration testing) in a safe, fully simulated environment.
There is no real hacking, no real network, and no real attack code. Everything is a simulation designed to show how attacks work — and just as importantly, how to defend against them.
The player takes the role of a White Hat hacker hired by a company (Cyber-Corp) to find security weaknesses before real criminals do. The objective: reach and take control of the company's internal ERP system by working through 5 stages of a realistic attack chain, capturing a flag at each stage.
I created this project for my son, who is 12 and curious about how computers and the internet really work. I wanted to give him a hands-on way to learn cybersecurity — not just theory from a book, but by actually doing it in a game.
The goal is to spark interest in ethical hacking, security thinking, and the idea that technology can be used to protect people, not just attack them.
- Kids aged 12+ who are curious about cybersecurity
- Parents and teachers who want an engaging introduction to hacking ethics
- Beginners of any age who want to understand how attacks work before learning to defend
No prior knowledge required. Every technique has an "Explain this to me" button that describes it in simple terms.
| Stage | Technique | Flag |
|---|---|---|
| 1 | Brute Force — crack the public Helpdesk portal | FLAG{H3lpd3sk_Br0k3n_1nt0} |
| 2 | SQL Injection — bypass the HR portal login and dump employee emails | FLAG{SQL_1nj3ct10n_HR_0wn3d} |
| 3 | Phishing + C2 — email a fake fix, get bots calling back | FLAG{Ph1sh_B0t_C2_F00tH0ld} |
| 4 | Internal Scan + Brute Force — pivot inside, crack SSH on the ERP server | FLAG{BR3ACH_SSH_R00T_4CC3SS} |
| 5 | Privilege Escalation — read plaintext creds, log into ERP as admin | FLAG{ERP_0WN3D_M1SS10N_C0MPL3T3} |
[STAGE 1] Scan public IPs -> Brute force Helpdesk portal -> get first foothold
[STAGE 2] Helpdesk reveals HR portal -> SQL injection -> dump employee emails
[STAGE 3] Start web server + C2 -> phishing campaign -> 2 bots connect back
[STAGE 4] Scan internal network via bot -> brute force SSH -> crack root on ERP server
[STAGE 5] SSH pivot -> read erp_config.php -> log into ERP portal as admin
Every stage ends with a defensive lesson — the fix a company should apply.
| Technique | Concept |
|---|---|
| Network Scanning | Discovering open ports and the attack surface |
| Brute Force | Trying many passwords; why usernames matter too |
| SQL Injection | How a broken login exposes a whole database |
| Phishing | How fake emails trick people into running malware |
| Command & Control (C2) | How attackers remotely control hacked machines |
| Pivoting / Lateral Movement | Using one hacked machine to reach another |
| Privilege Escalation | Finding credentials left in config files |
- Scanner — probe IP ranges, list open ports; each port has BROWSE / BRUTE FORCE actions
- Browser — visit simulated web portals; login forms, SQLi, screenshots
- Terminal — a simulated Linux shell (30+ commands, tab-autocomplete, command history)
- Brute Force — attack any service; you choose the username (this matters!)
- C2 Server — receive reverse shells from phished bots, scan and pivot from inside
- Phishing — host a fake download, send a campaign from a compromised sender
- Notes — with 4 tabs:
- Notes — auto-logged findings
- Loot Vault — captured credentials, reusable for login or as phishing sender
- Flags — every captured CTF flag
- Evidence — auto-generated PoC screenshots for your report
- Open
index.htmlin any browser — no installation needed. - Click the Mailbox, read the mission briefing (it contains the authorized scope).
- Press Accept Mission to reveal the target company map.
- Use the toolbar tools to progress through the 5 stages.
- Collect a CTF flag at the end of each stage (saved automatically in Notes -> Flags).
- Reach and control the ERP system to complete the mission.
Each tool has an "Explain this to me" button if you want to understand what it does first.
- Scope of work — the scanner starts empty; you must read the mission email and enter the authorized IP ranges yourself. A White Hat only tests what they're authorized to test — browsing out-of-scope URLs is blocked.
- Username-aware brute force — you must supply a valid username, not just a password. The helpdesk portal even hints at its default account name, teaching why exposing usernames is a risk.
- Credential reuse — creds you steal go into the Loot Vault and can be used to log in elsewhere or as a trusted phishing sender.
- Rabbit holes — most internal hosts are dead ends with realistic reasons (Kerberos, SSH keys, account lockout, IP whitelisting), so the player has to think.
- Evidence collection — key wins auto-generate PoC screenshots, just like documenting a real pentest.
- Single self-contained HTML file (~380 KB)
- No backend, no server, no dependencies
- Works offline once loaded
- Pure HTML + CSS + JavaScript
- The company map is pixel art
This game is a 100% offline simulation. No real action of any kind is performed.
- No network requests to any external server
- No connections to any IP shown in the game (203.0.113.x and 10.0.0.x are documentation ranges that do not exist on the internet)
- No commands executed on any real system
- No files downloaded or uploaded
- No data stored in the browser — no cookies, localStorage, sessionStorage, or IndexedDB
- No analytics, tracking, or telemetry
- Everything runs in memory; closing the tab clears it all
The only outbound request is a Google Fonts load when the page opens. To run fully offline, download the fonts locally and remove the <link> tag.
Safe to run on any device, in any classroom, with any age group.
If you open the browser developer tools or read the HTML source, you'll find everything — the passwords, the flags, the credentials. There is no backend, no encryption, nothing hiding the answers.
This is intentional, and it's part of the lesson.
A 12-year-old who thinks to look at the source code has already shown exactly the kind of analytical thinking that makes a good security engineer. They've also learned something real: security controls must be enforced on a server, never trusted to client-side code.
The point of this game is not "can you find the password." It's about understanding the mindset:
- How does an attacker think?
- Why does SQL injection work?
- What makes a password (or a username) weak?
- Why is storing credentials in a config file dangerous?
If your child looks at the source to find the flags — celebrate it. That curiosity is the first step.
The full attack chain exploited 5 separate weaknesses. Fixing any single one would have stopped the whole attack:
- Account lockout + strong passwords + MFA -> helpdesk brute force fails
- Parameterized queries on the HR login -> SQL injection fails
- Security awareness training -> staff don't run the fake file, no bots
- Network segmentation + MFA + strong SSH passwords -> the internal pivot fails
- No plaintext credentials in config files (use a secrets manager) -> even with root, no ERP admin access
That's the real lesson: never rely on a single lock.
Omar Mezrag — Co-Founder & CTO, Realistic Security
A cybersecurity firm based in Algeria, specialized in penetration testing, red teaming, DFIR, and detection engineering.
Shared for educational purposes. Feel free to use it to teach your own kids or students. Attribution appreciated.