Wallet Drain Playbook
Wallet drains are rarely “one bug.” They’re usually a fast chain of small failures: approvals left around, phishing that gets one signer, weak monitoring, and slow incident response. This guide is an operations-first checklist you can actually run.
This guide focuses on direct wallet-loss scenarios and shows how prevention, detection, and response controls connect in real operations.
What counts as a wallet drain?
In practice, “wallet drain” is any unauthorized movement of assets initiated via approvals, signatures, compromised keys, malicious dApp interactions, or hijacked sessions. The attacker doesn’t need a protocol exploit to cause real damage; they just need a reliable path to authorization.
- EOA compromise (seed phrase, private key, session token, or signing device).
- Malicious approvals (ERC-20 approvals, Permit2 allowances, token approvals via fake UIs).
- Signature abuse (EIP-712 signatures for approvals/transfers).
- Compromised multisig signer(s) or unsafe signing flows.
- Infrastructure compromise (CI secrets → deploy key → release of malicious front-end).
What Is the At-a-Glance Wallet Drain Response Timeline?
| Window | Goal | Actions | Owner |
|---|---|---|---|
| 0–15 min | Stop further loss | Freeze approvals where possible, isolate compromised endpoints, revoke sessions, notify internal incident channel. | Security lead |
| 15–60 min | Contain + identify | Identify attack path (approval vs key compromise vs front-end), confirm impacted wallets, collect on-chain tx set. | Sec + Eng |
| 1–6 hrs | Stabilize operations | Rotate keys/tokens, validate deployment integrity, publish customer-facing guidance if needed, open forensics workstream. | Eng lead |
| 6–72 hrs | Root cause + prevention | Document timeline, implement controls, harden approvals/signing flow, add detections and test incident playbooks. | Security + PM |
Which Prevention Checklist Should Teams Run Weekly to Reduce Wallet Drain Risk?
This is not “best practices.” It’s a short list of controls that consistently reduce drain impact. If you can’t do everything, do the top items first.
1) Reduce authorization surface
- Minimize hot wallets: keep only what you can afford to lose online.
- Prefer multisig for treasury and operational wallets with non-trivial balances.
- Set approval policies: no infinite approvals on high-value wallets.
- Use dedicated wallets per role (ops, deploy, treasury, research).
2) Lock down signing flows
- Hardware signing for privileged wallets.
- Explicit domain verification for EIP-712 signatures (train operators).
- Block “random” signature requests during routine workflows.
- Separate signers from browsers used for general web access.
3) Protect your front-end supply chain
- Restrict who can merge/deploy. Require review on UI code touching approvals.
- Pin dependencies and monitor for malicious package updates.
- Use environment segregation for staging vs production.
- Audit build artifacts and ensure integrity checks for deploy outputs.
4) Monitoring that actually matters
- Alert on new approvals and large transfers on high-value wallets.
- Alert on Permit2 allowance changes for sensitive wallets.
- Detect unusual spender contracts (new, unverified, recently deployed).
- Track “first seen” destinations and rapid asset routing patterns.
What Is the Printable Incident Response Checklist for Wallet Drain Events?
The goal is to avoid chaos: decide quickly, contain, preserve evidence, communicate, and then harden.
A) Triage (first 15 minutes)
- Confirm the event: on-chain tx hash set + affected wallet(s).
- Decide classification: approval-based vs key compromise vs front-end compromise.
- Lock comms: create a single incident channel and a single incident lead.
- Preserve evidence: export wallet connection logs, browser history (if safe), and deployment audit trails.
B) Containment (15–60 minutes)
- Revoke approvals (where feasible) for the impacted wallet(s).
- Rotate credentials: GitHub tokens, cloud secrets, deploy keys, and API keys.
- If front-end compromise suspected: freeze deploy pipeline and roll back to last known-good release.
- Notify affected internal owners and block further signing until verified clean.
C) Stabilization (1–6 hours)
- Map asset flow: which tokens, which routes, which destination addresses.
- Coordinate with partners/exchanges if asset off-ramping is detected.
- Update user guidance (if public users are impacted) with clear, minimal steps.
- Start root-cause timeline and assign a forensics owner.
D) Root cause + hardening (6–72 hours)
- Document the exact authorization path that enabled the drain.
- Implement long-term controls (signing, approvals, deploy governance, monitoring).
- Run a post-incident tabletop simulation to validate the fixes.
- Define detection coverage for the same path so it’s noisy next time.
Which Wallet Drain Failure Modes Are Most Common, and What Should Teams Do?
| Failure mode | What it looks like | Fix |
|---|---|---|
| Infinite approvals | A single malicious spender drains multiple tokens over time. | Approval policy + scheduled allowance reviews. |
| Signer uses the same browser for everything | Phishing or malicious extensions compromise sessions. | Dedicated signing environment + device hardening. |
| Weak deploy governance | A compromised token merges malicious UI that requests approvals. | Protected branches + review + deployment audit trail. |
| No alerting on approvals | You learn from users or after assets are gone. | Approval + allowance monitoring on high-value wallets. |
Which Detection Signals Should You Wire Up for Early Wallet Drain Detection?
Monitoring needs to be specific. “Large transfer” alerts alone are too late. In drain scenarios, the earliest reliable signal is often a new approval or a new spender. Below is a practical set of signals to implement. Even partial coverage is valuable.
| Signal | Why it matters | Noise control |
|---|---|---|
| New token approval / allowance increase | Most drains require approval or a permissioned path first. | Scope to high-value wallets and unknown spenders. |
| Permit2 allowance changes | Permit2 can centralize allowances across tokens. | Alert on first-time allowance for a spender. |
| First-time destination address | Drains usually route funds to new, untrusted addresses. | Ignore known counterparties/bridges you already use. |
| Rapid multi-token movements | Attack scripts sweep assets quickly across tokens and chains. | Trigger when multiple assets move within minutes. |
Tip: don’t route these alerts into the same channel as normal ops. Use a dedicated high-signal incident channel with an explicit on-call owner.
What Runbook Template Can Teams Copy-Paste for Wallet Drain Incidents?
When an incident hits, the first 10 minutes are mostly communication and decision-making. A pre-written runbook reduces confusion. Use the template below and tailor it to your team.
Incident name: Wallet Drain – [YYYY-MM-DD] – [Wallet/Protocol]
Incident lead: [Name]
Status: Investigating / Contained / Monitoring / Resolved
Impacted assets: [Token list + rough amounts]
Initial hypothesis: approval-based / key compromise / front-end compromise
Immediate actions: revoke approvals, rotate credentials, freeze deploys, notify partners
Public comms owner: [Name] (only one person posts externally)
Next update time: [Time]
If you run a multisig treasury, add a separate checklist for signer verification and emergency transaction policy (who can propose, who can sign, what requires out-of-band confirmation).
Which Sources and References Support This Wallet Drain Playbook?
A short list of references used to inform this playbook:
What Should Teams Do Next to Turn This Guide into an Internal Runbook?
If you want this to work under pressure, turn it into an internal runbook: define owners, links to tooling, and a template message for users and partners. The best time to write an incident plan is before the incident. For persistent pairing risk and revocation strategy, see WalletConnect Session Hijacking Defense.