Crypto Exchange Breach Response: The First Hours

The short answer

In the first hours of an active hot-wallet or custody compromise, a crypto exchange has to do five things, largely in parallel rather than strictly in sequence: confirm which signing path or credential is actually compromised, cut that path immediately rather than waiting to scope the whole platform, sweep any remaining balance in the affected wallet to a clean cold-storage address, start on-chain tracing and freeze requests with a chain-analytics provider and any destination exchange before funds move further, and screen any address involved against OFAC's sanctions list before considering any negotiation. Regulatory notification — DORA's incident-reporting clock for a MiCA-licensed operator — starts running the moment you classify the incident, independent of how contained it is.

Who this is for

This is for a Head of Security, CISO, or on-call lead at a crypto exchange or other custody-holding platform who has just confirmed — or strongly suspects — that funds are moving out through a compromised signing key, custody-provider credential, or admin account, and needs to know what to do in the next few hours. It is not the detection layer that should have caught this before it drained a meaningful balance — that's covered in building a SOC for a crypto exchange from scratch. It is also not the staffing decision behind who's on call when this alert fires — see 24/7 SOC coverage models for a crypto exchange for that. And it isn't the equivalent checklist for a licensed casino's ransomware incident, which runs on a different clock and different regulator — see ransomware response for an online casino: the first hours for that adjacent scenario.

Which layer is actually compromised

The response differs sharply depending on which path the attacker is using, and getting this wrong in the first minutes wastes the time that matters most:

Compromise vector	What's actually happening	First action specific to it
Hot-wallet signing key exposed	An automated withdrawal signer is executing attacker-controlled outbound transactions	Revoke or disable the signing key/HSM session itself — halt the automated withdrawal service, not just the customer-facing withdraw button, which the compromised signer doesn't need anyway
Custody-provider API credential compromised	The attacker holds a valid API key or session against your third-party custodian, not against your own infrastructure	Contact the custody provider's security or ops line directly — they can usually suspend the credential and hold pending transfers faster than anything you can do from your own side
Admin/ops panel account compromised	The attacker can approve manual withdrawals, raise limits, or override a control rather than sign transactions directly	Revoke the account's session and any API tokens it holds, then audit every action it took during the compromise window — not just the one large withdrawal that triggered the alert
Trading-UI code injection (wallet-drainer)	User-connected wallets are being drained through malicious front-end JavaScript — your own treasury isn't necessarily touched	Pull the affected front-end deployment immediately; this is a customer-facing disclosure incident, not a treasury one, and the response and notification differ accordingly

The first-hours sequence

Confirm and scope which vector this is, and whether it's still active. Use the table above. The single most important fact to establish in the first minutes is whether funds are still moving right now or the compromise has already run its course — that answer decides whether the next step is "cut this path immediately" or "the damage is already done, move to sweeping and tracing."
Cut the compromised path itself, not the whole platform by default. Disable the specific signing key, API credential, or admin session identified in step 1. A live drain doesn't get the luxury of a slow, careful, don't-tip-off-the-attacker isolation the way a ransomware incident does — every additional minute is funds leaving the platform, so the compromised path gets cut first and forensic completeness gets sorted out after, not before.
Sweep whatever remains in the affected wallet to a fresh cold-storage address the attacker's key or credential never touched. Waiting to "assess further" while a balance stays reachable through the same compromised path is how a partial drain turns into a total one. This step doesn't wait for step 4.
Preserve what you can without slowing steps 2 and 3 down. Pull and hash API access logs, the HSM or signing audit trail, and admin session logs once the immediate bleeding has stopped — not instead of stopping it. This is the one place the sequence looks like the ransomware playbook's confirm-then-preserve discipline; the difference is that containment can't wait for it here the way it can when the threat is encryption rather than an active transfer.
Start on-chain tracing and freeze coordination in parallel with containment, not after it. Identify the attacker's receiving address or addresses, put in a call to your chain-analytics provider's incident line (Chainalysis, TRM Labs, Elliptic, and similar firms run 24/7 hotlines for exactly this), and alert any centralized exchange the funds appear to be flowing toward. A freeze request made while funds sit at a known deposit address has a real chance of working; the same request made after the funds have moved through a mixer or across a bridge mostly doesn't.
Screen before any negotiation. If the attacker offers a partial return, frames it as a "white-hat" bug-bounty claim, or sets a countdown, screen the receiving address against OFAC's Specially Designated Nationals list before agreeing to send anything. A sanctioned recipient makes any payment — however framed — a separate federal compliance exposure on top of the theft, and that answer needs to be known before a negotiation deadline forces a decision.
Activate incident response, and start the regulatory clock the moment you classify the incident — not once containment is finished. Loop in law enforcement, banking and liquidity partners, and your users if the loss is material. If you're a MiCA-licensed crypto-asset service provider, DORA's incident-reporting timeline applies and starts at classification; the full requirement is covered in NIS2 and DORA without the consultant theatre rather than repeated here.

The order across steps 2 through 5 is closer to parallel than sequential, and that's the real difference from a ransomware response: encryption sits still once it's happened, so a casino can afford to scope carefully before it isolates. An active wallet drain doesn't sit still. Every minute spent deciding is a minute the attacker is still moving funds, which is why cutting the compromised path and starting the on-chain trace happen at the same time rather than one after the other.

What an incident-response engagement delivers from this point

Once Incident Response is engaged, the work that carries the containment above through to closure is triage and eradication of any remaining attacker access (a rotated signing key doesn't help if the attacker also has a foothold in the infrastructure that generated it), a full forensic timeline showing exactly how the credential or key was obtained, recovery on a hardened custody architecture rather than a like-for-like restore of the compromised setup, and a regulator-ready incident report that supports whatever notification timeline your license or MiCA/DORA status actually carries.

Limitations

This is a response sequence for the first hours of a confirmed or strongly suspected active compromise, not a custody architecture design guide — the priority order for hardening custody and signing infrastructure before an incident is covered in hardening a crypto exchange: what comes first. It isn't legal advice: whether a specific negotiation, disclosure, or notification action is permitted depends on your jurisdiction, your license conditions, and the specific facts of the case, and OFAC screening in particular should involve counsel before any payment is made, not just a database lookup. And this guide doesn't promise a fund-recovery outcome — on-chain tracing and freeze requests improve the odds of recovery, they don't guarantee it, and the outcome depends heavily on how fast steps 5 and 6 above start relative to when the funds first moved.

What to do next

If a hot-wallet or custody compromise is active right now, the sequence above is the order to work through; get an IR retainer in place once it's contained so the next one starts at containment, not at the access-provisioning delay a cold engagement spends its first hour on. If you're not mid-incident and want the detection layer that should catch this earlier next time, start with building a SOC for a crypto exchange from scratch.

Frequently asked questions

Should we ever pay a ransom or a "white-hat return" cut to whoever drained our hot wallet? Not before screening the receiving address against OFAC's Specially Designated Nationals list. Sending funds — even a negotiated partial return fee — to a sanctioned address or entity is a separate compliance exposure layered on top of the theft itself, and it applies regardless of whether you're the victim making the payment. Screen first; that answer, not the attacker's deadline, decides whether any negotiation is even legally possible.

What's the difference between this and our SOC's custody-outflow detection rules? Detection is what fires the alert — a SOC runbook watches hot-wallet outflow velocity, replenishment timing, and withdrawal-destination risk so a compromise gets caught fast. This is what happens after that alert is confirmed real: the containment, sweep, tracing, and notification sequence for the hours that follow. See our crypto exchange SOC runbook for the detection side.

Should we freeze the whole exchange or just the compromised wallet? Just the compromised signing path or wallet, if you can scope it that fast — disable the specific API credential, HSM session, or admin account rather than halting every withdrawal platform-wide. A platform-wide freeze you didn't need extends the user-facing outage and the reputational cost without adding safety, once the actual compromised path is cut. If scoping takes too long to be confident, a broader precautionary freeze while you scope is the safer default — the point is scoping decides the blast radius, not a reflexive full shutdown or a reflexive narrow one.

How fast do freeze requests to other exchanges actually need to happen? Within the same window as containment, not after it — ideally minutes, not hours. Stolen funds that reach a centralized exchange's deposit address can usually still be frozen if that exchange is alerted before the attacker withdraws or moves them onward; once funds pass through a mixer or cross a bridge, the trail gets harder to follow and freeze requests lose most of their leverage. Identify receiving addresses and contact your chain-analytics provider and any destination exchange in parallel with internal containment, not as a follow-up task.

Does MiCA or DORA change our regulatory notification obligations here? If you're a MiCA-licensed crypto-asset service provider, DORA's ICT-incident reporting framework applies to you as a financial entity — initial notification within 4 hours of classifying an incident as major, an intermediate report within 72 hours, and a final report within a month. That clock starts at classification, independent of whether containment is finished. The full control-by-control breakdown is covered in NIS2 and DORA without the consultant theatre — this article doesn't repeat it.

Sources and review

The pause-withdrawals-and-quarantine-to-cold-storage sequence and the on-chain-tracing/exchange-freeze-coordination guidance reflect published incident-response practice from two independent industry sources: Chainalysis's analysis of exchange hack response (pausing withdrawals as the decisive first action, automated quarantine to cold storage) and the Crypto-ISAC's on-chain incident response guidance (fund tracing starting immediately on actionable on-chain intel, contacting chain-analytics firms and destination exchanges for freeze requests before funds move further). DORA's ICT-incident notification timeline (4-hour initial notification, 72-hour intermediate report, 1-month final report) is codified in EU Regulation (EU) 2022/2554, as previously cited in NIS2 and DORA without the consultant theatre. OFAC sanctions-screening guidance reflects the U.S. Treasury's published Specially Designated Nationals list requirement, not an AnySec-specific process. No unverified third-party loss figures, customer results, or SLA numbers are cited. Author: AnySec Engineering. Published 2026-08-29; last reviewed 2026-08-29.