How to Read These Case Studies
A short guide to the Case Studies strand: what each walkthrough teaches, why every scenario is fictional and illustrative, and the anonymisation discipline that real reports demand.
On this page
Learning objectives
- Explain what a phased case study is meant to teach versus what it is not
- Recognise that every scenario in this strand is fictional and illustrative
- Apply an anonymisation discipline when writing about real engagements
- Read each case for the decision points, not just the exploit
Welcome to the Case Studies strand. Each entry here is a narrated, phased walkthrough of a security engagement, taken from the first hour of scoping through to the remediation the client shipped. They are written to be read in order within a case, because the point is rarely a single clever trick. The point is the chain: how a small, ordinary weakness becomes a large impact when nobody has looked at the whole path at once, and how a disciplined tester walks that path without ever losing control of it.
Before you read a single one, understand what these cases are and what they are not.
Every scenario here is fictional
This is the rule that governs the entire strand, so it comes first. Every company name, every finding, every hostname, every recovered credential, and every remediation in these case studies is invented. There is no real client behind any of them. We wrote them from scratch precisely so they can be shared openly, without the risk of leaking any organisation's exposure or breaking any confidentiality agreement.
Illustrative and fictional. Each case in this strand is a teaching scenario invented for instruction. Any resemblance to a real organisation, engagement, or finding is coincidental.
The techniques, on the other hand, are real. Broken access control, indirect prompt injection, over-permissioned cloud roles, and Active Directory delegation abuse are all things that happen in the field every week. What we have fictionalised is the wrapper: the who, the where, and the exact numbers. That lets you study the mechanics honestly without any of the detail pointing at a real target.
What a case study is meant to teach
A good walkthrough is not an exploit recipe. If you finish a case having memorised the commands but missed the reasoning, you have read it wrong. Read instead for the decision points. Watch for the moment the tester confirms scope in writing. Watch for the moment an AI copilot drafts a state-changing action and a human stops to approve it. Watch for the moment a promising path is dropped because the evidence did not hold up. Those moments are the real curriculum.
Each case follows the same rough shape so you learn to look for the same things every time:
- Situation. Who hired the tester, what was in scope, and what question the client actually wanted answered.
- Approach. How the work was framed, where AI helped, and where the human stayed in the loop.
- The chain. The ordered steps from first foothold to full impact, with each link explained.
- Impact. What the flaw actually let an attacker do, proven to a bounded standard rather than pushed to maximum damage.
- What was fixed. The remediation the client shipped, and why it broke the chain.
- The lesson. The one idea worth carrying into your own work.
The safety discipline runs through all of them
You will see the same guardrails in every case, because they are not optional extras. Testing happens only inside a written, authorised scope. Any action that changes state, resets a password, writes a delegation, sends a crafted document, waits behind an explicit human decision. And anything an AI tool produces, a ranked path, a drafted payload, a summary of a permission graph, is treated as a hypothesis to verify against ground truth, never as a fact to act on blindly. When you read a case that seems to move fast, look again: the speed comes from good tooling, not from skipping the gate.
The anonymisation discipline you will need for real reports
One day you will write up a real engagement, and the habits this strand models are the ones that keep you out of trouble. Real reports live under contracts, disclosure terms, and a duty of care to the client. Before anything you write about real work leaves the room, strip it down to the pattern and the lesson. Remove or alter the client name, live hostnames, IP ranges, real usernames, screenshots with identifying detail, and anything that would let a reader fingerprint the target. Keep only what teaches: the shape of the flaw, the chain, and the fix.
The reason our fictional cases read like real ones is that we applied this discipline to its logical end. We did not anonymise a real engagement; we invented a clean one. When you cannot fully anonymise something, that is your signal to fictionalise it further or leave it out. The goal is a write-up that could be pinned to a public wall without a single person being able to say "that was us."
Read on. Start with whichever case matches the work you do, and pay attention to the pauses more than the payloads.
Knowledge check
Answer without AI. This is your own recall. 70% to pass.
1.Every company, finding, and detail in this strand is drawn from real engagements. True or false?
2.When writing about a real engagement you actually ran, which of these belongs in a shareable teaching write-up?
3.What should you focus on most when reading each phased walkthrough?