The War Room Playbook: How to Survive a Hack
A field guide from my experience in dozens of onchain war rooms, where billions hung in the balance and minutes decided outcomes.
TLDR: War rooms are inevitable if you’re building anything worth protecting onchain. Prepare now or get rekt later.
You’re solving for two things simultaneously: stop the bleeding and preserve user trust. Lose either, and recovery becomes exponentially harder.
Parallel execution wins. Sequential thinking kills. Delegate accordingly to three: Ops Lead, Security Analyst, Comms Lead.
The Call Always Comes at the Worst Time
It was 5:50pm on a Saturday in Lisbon when I messaged Alexander Angel at Primitive Finance. Two words: “U up?” His response was instant. “Don’t scare me like that.” I told him this was not a drill.
That message kicked off 48 hours of nonstop crisis management and a war room that pulled together some of the best security minds in DeFi to save over $1.2 million in user funds. I’ve been in dozens of these since founding Immunefi, and each one reinforced the same hard truth: you will never feel ready. The protocols that survive are the ones that built muscle memory before the punch landed.
Here’s everything I’ve learned about running a war room that actually works.
Before the Breach: Preparation You’ll Probably Skip but Really Shouldn’t
Have an incident response playbook written and distributed before you need it.
Know how to reach every critical party at 3am on a Sunday. If their phones have the do not disturb feature on, you need to configure exceptions.
Decide operational roles in advance. Know who knows how to do what, before you need it.
Map your entire infrastructure: every contract, every admin key, every multisig signer.
And if at all possible, run a simulation/war game first.
You probably won’t do any of this. Most teams don’t. That’s why they get rekt when the call comes.
The Primitive Finance war room succeeded in part because Alex Angel knew exactly who to pull in. He tapped the Dedaub team for deep technical analysis, me for comms and coordination, and Emiliano Bonassi for his leadership under fire. That roster was very intentional. Alex had been watching the security community, noting who showed up in previous postmortems, and who had the temperament for battle stations. There’s an important lesson here: build your war council before the war starts.
What You’re Solving For
Every war room serves two masters: stop further losses and preserve user trust. They are equally important, and they often pull in opposite directions.
Pausing contracts might stop the bleeding but triggers panic in your community. Going silent while you investigate preserves operational security but erodes confidence by the hour. Losing trust can be fatal even when funds are recovered. I’ve seen protocols survive nine-figure exploits because they communicated well, and I’ve watched smaller hacks destroy projects because the team went dark.
You need both tracks running from minute one.
Step 1: Confirm and Pause
The first thing you do is verify the exploit is or appears real in any way. If there is even a hint of reality to it, then pause affected contracts, lock down permissions, and cut off every possible drain vector. Speed matters here more than certainty. A false positive costs you some inconvenience. A slow response costs you millions.
At Primitive Finance, we confirmed the vulnerability within 15 minutes of the Dedaub team’s disclosure. But here’s what made that war room uniquely terrifying: Primitive was a truly decentralized protocol. No admin keys. No multisig. The contracts couldn’t be paused or changed. That constraint shaped every decision that followed.
Step 2: Assemble the War Room (Three Roles Only, No More)
A small, trusted group moves faster than a crowd. Every additional participant slows decision-making and increases leak risk. You need three roles. That’s it.
The Ops Lead is the conductor. They timebox decisions, manage workflows, maintain composure, and enforce frequent sync cycles. Without this discipline, the room spirals haphazardly. Arguments metastasize. Recovery stalls. Emiliano Bonassi filled this role for Primitive, and within minutes of joining he was designating players, assigning timezones, carving out responsibilities, and building the roadmap forward. No hesitation. No committee.
The Security Analyst finds the truth. Use as many analysts as you need to find the root cause. They identify the attack vector and scope, build mitigations and patches, monitor for secondary attacks, and validate readiness to unpause. At Primitive, the Dedaub team (Yannis Smaragdakis and Neville Grech) worked through the entire night building the whitehack. Yannis didn’t sleep.
The Comms Lead manages trust. Clear, calm, factual updates on a predictable cadence. No silence. Poor communication causes bank-run behavior faster than the exploit itself. I built out the full comms plan for Primitive’s disclosure while the technical team developed the whitehack in parallel. One bad tweet from the wrong person can undo hours of technical progress.
Step 3: Parallel Execution (Not Sequence)
This is where most war rooms fail. Teams instinctively want to finish forensics before making decisions, and finish decisions before communicating. That sequential thinking is catastrophic.
Everything gets parallelized to minimize response times and act fast.
Here’s your comms cheat sheet; prepare them all as soon as you can:
First, document everything. War room transparency is a key part of demonstrating professionalism and post-exploit transparency. It sends the right message. AI makes this easier than ever.
Second, make a plan for things going horribly wrong; how do you fastest stem the bleeding and communicate that your protocol is frozen? If you can’t, how do you protect users by guiding them to a near-effortless way to protect their funds? The clock is ticking, and you need to protect users as much as possible the moment you learn there is no other option.
Third, chart out the happy path, where you buy time until you can make a transparent post-mortem report to share with the broader community. That starts with messaging that inspires confidence and patience. It should go live on socials and whatever community channels you have... but only after you confirm that the exploit is mitigated.
Only having covered the immediate needs, do you begin working on long term posts like the post-mortem (using your war room documentation) and confidence-inspiring messaging.
That’s it. And you want all this messaging ready, in parallel, before you know what you need to do. If you’re lucky, you won’t end up needing any of it. If you’re not, you’ll be happy you already know exactly what to say, to whom, and how.
Remain Calm (Seriously)
This sounds obvious, but it isn’t. When you’re staring at potentially millions of dollars in exposed user funds, with no guarantee your whitehack will work, composure is by far the hardest skill to express in the room.
But it’s what you’ll need every time. You can’t make the right calls without it.
The Postmortem: 24 to 48 Hours After
Within a day or two of resolution, publish a full postmortem, which should at minimum include a root cause, attack timeline, fix applied, and prevention roadmap.
The worst postmortems I’ve read are by teams who refuse to acknowledge their own responsibility. They strip the timeline of context, blame everything on “sophisticated hackers” as if that explains away months of ignored warnings, and publish something that reads like a legal filing rather than an honest accounting. I’ve watched this pattern destroy communities faster than the original exploit.
Consider CertiK and Kraken. A security firm drained roughly $3 million from Kraken over several days, claiming it was whitehat research, when a $4 demonstration would have proven the vulnerability. Kraken called it extortion. CertiK called it responsible disclosure. That kind of postmortem theater, where neither side owns the full truth, poisons the well for everyone. Or look at Poly Network, which lost around $600 million, eventually recovered funds through a “bug bounty” offer, and then treated the whole episode as if it were a legitimate whitehat engagement from the start. Everybody knew it was theft first. It’s ok (even wise) to negotiate with hackers, but gaslighting the community didn’t help their credibility.
I helped the team at PAID Network when they suffered an exploit in 2021. The temptation was there: minimize the damage, obscure the timeline, deflect blame. I pointed out the absolute necessity of owning how they got to that point. Thankfully, they listened. They took full responsibility, reported honestly, and their community stuck with them. But many teams don’t have someone in the room who can push them toward that honesty. A postmortem that hides the truth doesn’t protect you. It guarantees that when the real story leaks (and it always leaks), the trust damage is permanent.
Primitive Finance published their postmortem within 72 hours. It named names, credited contributors, laid out the exact timeline down to the minute, and explained the vulnerability in full technical detail. That postmortem became a case study in how to rebuild trust after a crisis.
When You Need to Negotiate With Blackhats
Not every war room ends with a successful whitehack. Sometimes the attacker gets there first. When that happens, you open communication channels (onchain messages work), offer safe return paths, and structure incentives that make cooperation more attractive than running. The Safe Harbor framework that I helped create through SEAL exists specifically to formalize this process, as I wrote about in “Preventing Crypto Armageddon“.
I’ve sat on both sides of these conversations. With Cream Finance, after roughly $8 million was stolen, we identified that the hacker was based in China and negotiated the return of funds by making clear we could expose his identity. He returned the money. That one worked. But I’ll be blunt: negotiation fails far more often than it succeeds. The KyberSwap exploit is a sobering example, where the attacker demanded full governance control of the protocol in exchange for returning $50 million in stolen funds. An unhinged demand that left no room for productive resolution.
If negotiation fails, you escalate: public warnings → forensics firms → exchange freezes → legal action → criminal filings. Each step must be thoughtful and proportional. Reckless escalation burns bridges you might need later. Hackers can be convinced to return the money.
The Primitive Finance Outcome
At 1:05am on a Sunday, Alex took a deep breath and pushed the whitehack button. It worked. We then scrambled to reach the biggest depositors to reset their remaining approvals. 0xMaki from SushiSwap jumped out of dinner and bribed his cab driver to get home faster. Calvin Liu reset his approvals from the chat.
Within hours, all user funds were safe. The Dedaub team earned a $250,000 bounty through the Founders Bounty program hosted on Immunefi, plus $25,000 directly from Primitive. Emiliano received $10,000 for leading the war room. The incentives aligned, and the system worked.
This story had a happy ending. Not all war rooms do. The difference, almost every time, comes down to preparation, the right people in the room, and the discipline to execute in parallel under pressure.
Build the Muscle Before You Need It
If you’re reading this and you don’t have an incident response playbook, write one this week. If you can’t reach your key security contacts at 3am, fix that today. If you haven’t mapped your infrastructure end to end, that’s your next task.
If you need help getting ready, book a call with me and I’ll get you on the right track.
War rooms are inevitable. Your survival depends on what you built before the call came.
For more on how Immunefi protects the onchain economy and the role of bug bounties in preventing the next crisis, visit immunefi.com. And if you want the deep data on what hacks actually cost, read “The Real Impact of an Onchain Hack“ on my Substack.