Most security tools teach you to attack. I wanted to build something that teaches you to investigate.
There’s something strange in how cybersecurity is taught.
CTFs, labs, HackTheBox, TryHackMe: they’re all great. But almost all of them focus on the offensive perspective. Find the vulnerability, exploit it, capture the flag. Which makes sense. Offensive security is concrete, gameable, and satisfying.
But the reality of most security work is different. Most people working in security spend their time on the blue team: reading logs, correlating events, writing incident reports, deciding whether a suspicious request is a false positive or the beginning of a breach. That work is harder to gamify. It’s also harder to learn.
I wanted to fix that. So I built NightCity Tracer: an open-source, browser-based forensics simulator set in a cyberpunk universe.
What it actually is
You play a SOC analyst in Night City. A breach happened, or is happening right now.
You get the evidence: access logs, vulnerable source code, network maps, config files, email chains, git histories, memory dumps. You investigate, reconstruct the attack, and file an incident report.
No flags. No shell to pop. Just evidence and judgment.
The game scores you on precision (did you identify the right vulnerability?), defense efficiency (did you take the right action?), and in live scenarios, speed (how much damage did you contain before it was too late?).
At the end, you get a debrief with a replay of the attacker’s exact path.
Two radically different modes
The most important design decision was splitting scenarios into two temporal modes.
Post-mortem: the breach already happened. All evidence is present from the start. You’re reconstructing a past attack from whatever was left behind. This is closer to digital forensics: patient, methodical, no time pressure.
Live: the attack is in progress. Logs arrive in real time. A countdown is ticking. A data exfiltration is on-going. You have minutes to read the code, identify the vulnerability, and submit your report before the attacker succeeds.
These two modes feel like different games. The live mode creates genuine pressure: players report making mistakes under the time constraint that they wouldn’t make with unlimited time. Which is exactly the point.
The scenario system
Every scenario in NightCity Tracer is a self-contained TypeScript config file. The engine reads it and assembles a completely different experience: different panels, different evidence, different scoring weights, different narrative identity.
A scenario declares:
- Which evidence panels to display: log_stream, code_editor, network_map, db_viewer, terminal and more. The UI builds itself dynamically from this list.
- The event timeline (live mode): when each batch of logs appears, when alerts fire, when game over triggers. Payloads can be randomized to prevent memorization.
- Scoring dimensions and weights: a post-mortem forensics scenario weights precision heavily; a live incident scenario weights speed and defense efficiency. Each scenario defines what “a good answer” looks like.
- The incident report fields: a stored XSS scenario asks about the injection point and the sanitization fix. A social engineering scenario might ask for a decision (cut access now, or monitor?) rather than a technical finding.
- Corporate identity: each scenario belongs to a megacorp or faction with its own UI accent colors, briefing tone, and narrative voice.
This means scenarios can be radically different: not just in attack technique, but in what the player is actually being asked to do.
The four scenarios shipping in V1
Trauma Team Dispatch: Token Forgery (tutorial, post-mortem, beginner)
A medical response API was compromised via JWT algorithm confusion. You have post-breach logs and the source code. Designed to teach the investigation loop before any time pressure starts.
Operation Med-Assist Override (post-mortem, beginner)
An AI triage dispatch system was manipulated via prompt injection. The question isn’t just “what happened” but “what did the model do that it shouldn’t have, and why.”
Watson District: Samurai on Air (post-mortem, intermediate)
94 billboards. One attacker. Three seconds of footage that cost NeonGrid Systems their biggest advertiser and triggered a police investigation. Figure out how a single file upload brought down an entire district’s display network.
NightOps Platform (live, intermediate)
Active operator identities, drop locations, client names: everything on the platform is being exfiltrated right now. Every second you spend reading the code is a merc whose cover is blown. Stop it before the damage is irreversible.
Why cyberpunk?
The aesthetic isn’t decoration. It does real work.
Framing a JWT misconfiguration as “a Trauma Team dispatch system was compromised mid-emergency” changes how players engage with it. The scenario isn’t an exercise anymore: it has stakes, a world, a narrative identity.
Each faction creates a completely different feel. Arasaka scenarios feel corporate and precise, with cold system messages and red accents. A Netwatch scenario would feel more covert, like you’re working inside a surveillance apparatus. The aesthetic lets the same underlying mechanics feel like different experiences.
The tech stack
100% static. React 19 + TypeScript + Vite + Tailwind v4, hosted on GitHub Pages. No backend, no accounts, no analytics.
The attacker state machine
Live scenarios have an attacker that isn’t just a timer: it’s an actual state machine. The attacker progresses through phases (recon, exploit, exfil), each phase unlocking new log batches and changing the threat level. Players can interact: blocking an IP delays the attacker, patching a code vulnerability can stop the exfil entirely.
This creates a feedback loop that’s closer to real incident response: your actions have consequences, and the attacker progresses based on what you do or fail to do.
What I’m looking for
The project is open source and the scenario library is the thing that makes or breaks it.
Writing a scenario doesn’t require deep React knowledge: the config format is documented in the README with a schema walkthrough. If you know a real-world attack technique that would make a good investigation (a misconfigured S3 bucket, a malicious npm dependency, a phishing chain reconstruction, an insider threat), issues are open.
UI work, new panel types, and engine improvements are equally welcome.
GitHub: thomassimmer/nightcity-tracer
The Game: thomassimmer.github.io/nightcity-tracer/
Top comments (0)