Runbook: Smart Contract Exploit
🔑 Key Takeaway: For active smart-contract exploits, confirm scope, pause or contain if possible, preserve evidence, and coordinate recovery using your protocol-specific commands—not the placeholders in this example.
This is an example runbook. Review and customize for your protocol before use. Fill in the placeholder commands, add your specific contracts and addresses, and test during a tabletop exercise.
Quick Reference
| Field | Value |
|---|---|
| Typical Severity | P1 |
| Primary Responder | Smart Contract SME |
| Last Updated | [Date] |
| Owner | [Name] |
Identification
Symptoms
- Unexpected fund movements
- On-chain monitoring alerts
- Unusual transaction patterns
- Community reports of lost funds
- Abnormal contract state changes
Alerts
- [Your on-chain monitoring tool]
- [Blockchain explorer alerts]
Differentiation
- If funds moving to known addresses (multisig, treasury) → likely authorized
- If single user affected → might be phishing, not protocol exploit
- If UI shows wrong values but chain is correct → frontend issue
Immediate Actions
Step 1: Assess Scope
Why: Understand what's at risk before acting
- Check total funds at risk
- Identify affected contracts
- Determine if exploit is ongoing
Step 2: Contact SEAL 911
Why: Get immediate expert support for active exploits
See SEAL 911
Step 3: Pause if Possible
Why: Stop the bleeding
If your contracts have pause functionality:
[Document your pause procedure here]
If no pause function: Consider other containment options (front-running, rescue operations).
Step 4: Preserve Evidence
Why: Needed for investigation and potential recovery
- Screenshot/save relevant transactions
- Note block numbers
- Save mempool data if available
- Document attacker addresses
Investigation
Key Questions
- What vulnerability was exploited?
- How much was taken/at risk?
- Is the exploit still possible?
- Are other contracts affected?
- Was this reported via bug bounty first?
Information to Gather
| Data | Source |
|---|---|
| Exploit transactions | Block explorer |
| Attacker addresses | On-chain analysis |
| Vulnerability details | Code review |
| Affected user count | Contract state |
Mitigation
Option A: Pause Contracts
When: Pause functionality exists Impact: Users cannot interact until unpaused
- Execute pause function
- Verify pause is effective
- Communicate to users
Option B: Emergency Upgrade
When: Upgrade mechanism exists Impact: Requires governance or multisig action
- Prepare patched contract
- Execute upgrade
- Verify fix
Option C: Rescue Operation
When: Funds can be moved to safety before attacker Impact: Complex, requires coordination
- Coordinate with security researchers
- Prepare rescue transactions
- Execute with proper sequencing
Escalation
Contact immediately:
- Decision Makers
- Security Partners
- Legal if significant fund loss
Post-Exploit
- Determine fix approach
- Plan for affected users (if any)
- Prepare public communication
- Consider disclosure timeline
- Engage with law enforcement if appropriate
Common Root Causes
| Cause | Signs | Prevention |
|---|---|---|
| Reentrancy | Recursive calls in tx | CEI pattern, reentrancy guards |
| Access control | Unauthorized caller | Proper modifiers |
| Oracle manipulation | Price deviation before exploit | TWAP, multiple sources |
Further reading
- Runbooks overview: how the runbooks in this section fit together
- Key Compromise: the adjacent scenario when admin keys are involved
- Safe Harbor: the whitehat rescue framework during an active exploit
- Incident Response Policy: severity levels, roles, and escalation