Compromised Multisig Signer with 47 Hours Left on a Timelock

Attacker position: two signatures (4, possibly 2) toward a 3-of-5 threshold, with a queued call that would drop the threshold to 1 and add an attacker-controlled owner - after which the remaining USD 48 million is a single-signature transfer. The attacker needs one more signer, or needs the defenders to do nothing for 47 hours.

What the attacker cannot do: the queue cannot execute without a third signature, and the attacker cannot prevent a cancellation - that requires any two signers, and the CEO and head of engineering are available right now.

Defenders' sequence, in order:

1. Cancel the queued transaction immediately with signers 1 and 3. This is the 'pause' the board is asking for; it costs minutes and buys back the entire window.
2. Do not assume signer 2 is hostile or safe. Two hypotheses fit the same evidence: signer 2's key is also compromised, or signer 2 signed a legitimate-looking payload that was swapped client-side. Both are handled the same way for now - treat signer 2 as untrusted until they are reachable and can prove key custody.
3. Remove signer 4 via 3-of-5 (signers 1, 3, 5). This is itself timelocked, so start it immediately; in parallel, treat the threshold-change path as still live.
4. Sweep the hot wallet now. The CFO's team administers those keys; sweep to a fresh 2-of-3 with newly generated keys on hardware the CFO has never touched. Do not wait for forensics.
5. Watch for new queued transactions every block and cancel as they appear; a compromised signer can spam the queue.

The strategic point: the timelock plus cancel-by-two is the pause function. The board's question reveals a governance gap, not a missing contract feature.

For migrating: the current signer set contains at least one known-compromised key and one unverified key; a 3-of-5 threshold means any two compromised signers plus one lapse is fatal. A fresh contract lets you change threshold, signer diversity, and timelock length in one step. Migration under duress has a real cost, though - a rushed ceremony with new keys generated in a hurry, on devices nobody has verified, is exactly how treasuries get lost without an attacker.

Against migrating tonight: a migration transaction is itself a value-moving operation requiring three signatures from a set that includes a possibly hostile member; if signer 2 is compromised and the migration uses the existing signer set, the attacker can observe and potentially front-run the destination. A botched ceremony risks permanent loss. Meanwhile the immediate threat is already contained by the cancellation, and the attacker needs a third signature they do not have.

Conditions I would set:

• Migrate only after the cancellation is confirmed and signer 4 is removed, so the migration is authorised by a clean 3-of-4.
• New keys generated on freshly acquired, separately sourced hardware, in a witnessed ceremony, with the entropy source and firmware hash recorded.
• Destination address verified independently by two people against the ceremony transcript before signing.
• New parameters: 4-of-7, signer keys from at least three vendors, 72-hour timelock with a guardian veto role, and a documented emergency-cancel path.
• No reuse of any address, seed phrase, or device that has ever been associated with a compromised signer.

If those conditions cannot be met within 48 hours, keep the funds in the existing contract with signer 4 removed and signer 2 suspended, and migrate on a planned schedule.

The incident was detected by luck - a monitoring alert on a queued call - not by a control designed for it. Fix the control stack, not just the signer list.

Detection:

• Real-time alerting on any queue event (submission, signature added, cancellation, execution), routed to all signers on a channel the CFO cannot mute; threshold and owner-set changes should page immediately, not appear in a daily digest.
• A policy monitor that flags anomalous signing context: signer 4 signing outside business hours, from a new device, or within minutes of an email/calendar interaction.
• Independent reconciliation of hot-wallet balances against expected desk positions every 15 minutes.

Governance:

• Signer roles separated from operational key custody; the CFO should not simultaneously control treasury signing keys and hot-wallet administration.
• A documented signing ceremony with out-of-band verification of the payload hash (read it aloud from two independent devices), so a client-side payload swap cannot get two signatures.
• Pre-agreed incident runbook with named decision rights: who can cancel, who can sweep, who speaks to counterparties, all exercisable at 02:00 without a board call.
• Quarterly tabletop using a scenario in which two signers are compromised, not one, because one-compromise scenarios are too easy to pass.
• Post-incident review published to the board with the specific control failures, and a hard deadline for hardware refresh of every signer device touched by the same phishing campaign.