Every breach is a lesson someone paid for
Every major cyber incident ends the same way: with a report. Vendor advisories, government alerts, researcher write-ups, court filings and post-incident reviews piece together what happened, often in remarkable detail. Taken together, they are the most valuable training material the security industry has.
And yet most of us only ever read them.
Reading a post-mortem tells you what happened. It doesn't tell you whether you would have spotted it, what you would have decided with half the evidence in front of you, or how your design would have held up when the attacker found the gap nobody was watching. That is the difference between knowing about an incident and learning from it.
ScenarioLab exists to close that gap. We take real-world incidents and turn them into scenarios you can step inside.
It starts with what really happened
Every scenario begins with open-source reporting on a real incident — the public record that investigators, vendors and researchers have published. We bring those sources together and reconstruct the story from the attacker's side: how they got in, how they stayed hidden, where they moved next, and what the defenders could actually see at each stage.
That last part matters most. A scenario is only realistic if the evidence is. So the alerts, log entries, configuration details and "something looks off" moments you work through are modelled on what defenders genuinely had in front of them — not on the tidy summary written months later with the benefit of hindsight.
If it happened in the wild, it can happen in your environment
Real attacks, fictional names
Here's the twist: the organisations, products and people in our scenarios are fictional.
The attack chain stays faithful to the real incident — the techniques, the sequence, the blind spots, the pressure. But the company you are defending has a different name, its systems are its own, and the cast stays consistent from the first step to the last.
We do this for two reasons. First, it keeps you focused on the decisions rather than on trivia — you can't simply recall the headline or search for the answer. Second, it puts you where the original defenders were: in the middle of an unfolding situation, without knowing how it ends.
Variation is where the learning happens
A real incident happened exactly once. A scenario built from it doesn't have to.
From one incident we create several scenarios, each looking at the story from a different angle and at a different depth:
- Different levels. Foundation scenarios ask you to spot an architectural weakness and propose a fix. Intermediate ones give you incomplete evidence and competing explanations. Advanced ones put you where security, operations and legacy constraints pull in different directions, with no clean answer.
- Different decisions. Scenarios branch. The choices you make shape what you see next, and there is rarely a single right path — only better and worse judgment.
- Mid-scenario surprises. New evidence arrives part-way through and may prove an earlier decision wrong. Recognising that and adapting is a skill in itself.
- An AI analysis to challenge. Many scenarios hand you an AI-generated assessment that sounds confident and is partly wrong. Telling the difference is one of the most important skills in modern security work.
- Your own reasoning, in writing. Most scenarios end by asking you to explain your design or decision in your own words, because being able to justify a call is part of making it.
The result is a set of scenarios that feel like the real attack, yet still surprise you.
Same attacker playbook, different lessons
What you can play today
Our first role is the Security Architect. The library already covers a range of the most instructive incidents of recent years, including:
- A software supply-chain compromise in the style of SolarWinds, where trust in a signed update becomes the attacker's way in.
- Mass exploitation of a managed file-transfer platform, as seen with MOVEit.
- The Log4Shell vulnerability and the scramble to contain it across complex dependency chains.
- The abuse of a trusted third-party SaaS integration and its access tokens, as in the Salesloft Drift breach.
Most incidents already come with scenarios at all three levels, with more on the way, and your results build into a capability profile — showing where your judgment is strongest across areas like trust-boundary reasoning, control design and failure analysis, and where to focus next.
Built to be trusted
Every scenario is checked before it reaches you: that the attack story stays true to the public record, that the decisions are genuinely meaningful, and that the lesson holds up. Content that doesn't meet the bar doesn't ship.
What's next
The library is growing all the time. New scenarios are added regularly — fresh variations on the incidents already covered, the remaining levels for newer ones, and entirely new incidents, from cloud and SaaS compromises to attacks on industrial systems.
As each new incident enters the public record, it becomes a candidate for the next set of scenarios. So the more the threat landscape changes, the more there is for you to practise on.
Try one yourself
The best way to understand a ScenarioLab scenario is to play one. Free scenarios need no account — just an email address for your result. You can also take on our SolarWinds Security Architect competition, where the top three scorers win a free year of individual access, or create a free account to track your progress.
Start at scenariolab.co/scenarios — and find out what you would have done.