Skip to main content

Hit by ransomware? Isolate affected systems now. Do not reboot or reformat.

SheMo Noransom舍末无勒

Industry solution

Blockchain & Crypto

For blockchain firms, exchanges and custodians, mining operations and node providers, the attack surface sits almost entirely off-chain: nodes, index databases, KYC records and signing hosts are what actually get hit. This page covers the threat paths, a recovery approach built around key-custody audit and on-chain/off-chain reconciliation, and hardening priorities.

Critical business systems

  • Full nodes, archive nodes and validator or signing nodes
  • RPC gateways, block explorers and on-chain data index databases
  • Matching, clearing and deposit/withdrawal accounting databases
  • Hot wallet signing hosts, HSMs and key management systems
  • KYC/AML identity records and government-ID image repositories
  • Risk control, market data and public API services
  • Code repositories, CI/CD pipelines and development environments
  • Office network, virtualization platforms and backup systems

Threat landscape

For blockchain and crypto businesses the attack surface is almost entirely off-chain. Nobody needs to break consensus: take out the handful of servers running the nodes, the index databases and the matching and accounting systems, and the business stops. Public reporting shows three paths recurring over the past two years:

  • Insiders and outsourced roles with legitimate access. In May 2025 Coinbase disclosed, in an SEC Form 8-K and a company statement, that overseas outsourced support agents had been bribed to copy customer names, addresses, partial identity details and government-ID images; breach notifications filed with regulators put the number affected at 69,461. The attackers demanded a 20 million USD ransom; the company refused and offered a reward of the same amount instead. Nothing was encrypted, yet the high-value data was already gone.
  • Supply chain and developer endpoints. In February 2025 around 1.5 billion USD was moved out of Bybit, an incident the FBI attributed via an IC3 advisory to the North Korea-linked TraderTraitor (Lazarus) group. According to the post-mortem published afterwards by Safe and Mandiant, the attackers first compromised a developer machine at the third-party multisig wallet service Safe, then injected script into the signing interface so that what the signers saw differed from what they actually signed.
  • Routine targeting by mainstream ransomware crews. Crypto and blockchain companies get no special treatment here; the crews reuse the entry points they use on everyone else. INC Ransom, Akira, Qilin and LockBit mostly come through unpatched Citrix, SonicWall or Fortinet edge devices and VPNs without MFA, while Medusa favours remote-management and file-transfer components such as ScreenConnect and GoAnywhere. Once inside, the pattern is the same: destroy the backups, encrypt the ESXi estate and the databases. The joint Medusa advisory (AA25-071A), updated by CISA, the FBI and partners in August 2026, records more than 500 victims as of April 2026 across medical, education, legal, insurance, technology and manufacturing sectors.

Chainalysis's 2026 report puts traceable on-chain ransom payments for 2025 at roughly 820 million USD, down about 8% year on year, while claimed leak-site victims rose around 50% and the share of victims paying fell to about 28%. As fewer victims pay, crews lean harder on data theft and harassment — which is a particularly bad trade for a company holding large volumes of KYC material.

Business impact

  • On-chain data can be rebuilt; off-chain data cannot. Block data resyncs from the network, but KYC images, support tickets, risk rules and the matching and deposit/withdrawal ledgers have no second source once lost. That is where recovery effort belongs.
  • Index and service rebuilds carry a real time cost. Block explorers, RPC and analytics services depend on local index databases, and a full archive-node resync commonly runs from several days to several weeks, with public queries and APIs degraded meanwhile.
  • Encryption is often the side effect, not the objective. The same access that encrypts servers may also reach signing hosts, key backups and internal transfer workflows, so funds and key exposure must be investigated in parallel with recovery, never queued behind it.
  • Compliance and notification pressure arrives at once. Customer identity records are highly sensitive personal data, and exposure triggers regulatory reporting and user notification duties; meanwhile the ransom is demanded in cryptocurrency, so paying raises sanctions screening and anti-money-laundering exposure of its own.
  • Trust and withdrawal-run risk. Trading, deposits, withdrawals and settlement going down is amplified quickly by users and media and can trigger a rush of withdrawals, compressing the room to respond.

Our response plan

  1. Contain, and freeze the funds and signing paths first

    Contain zone by zone — office network, development and CI, nodes and indexers, business databases, signing and key infrastructure — but the first move is the funds and signing path: suspend automated withdrawals, raise multisig and manual review thresholds, and freeze changes to withdrawal address allowlists. Image servers read-only and preserve memory and logs before any recovery work, and do not rush to rebuild node hosts: the index data on those disks is also evidence.

  2. Audit key custody and verify funds on-chain

    Reconcile access and operation records across HSMs, multisig signers, hot and cold wallets and signing hosts, matching every on-chain transfer against internal approval item by item. Forensically examine signing hosts separately, looking for script injection, clipboard substitution and front-end tampering. If private key or seed exposure cannot be ruled out, rotate keys, replace multisig signers and migrate funds per the existing plan — that decision does not wait for recovery to finish, and does not rest on anything the attacker claims.

  3. Trace the entry point and settle KYC exfiltration early

    Identify the family and the intrusion path, concentrating on edge devices and VPNs, outsourced support and operations accounts, code repositories and CI tokens, and third-party front ends and SDKs. Start the exfiltration assessment with KYC and customer records: anomalous egress traffic and its destinations, staged archives, object storage and external transfer records, and bulk export or search behaviour on accounts. State the basis and confidence of the conclusion, since it underpins regulatory reporting and user notification decisions.

  4. Recover in layers, then reconcile three ways

    Run two recovery tracks in parallel: on-chain data resyncs from the network or is accelerated from a trusted snapshot, while off-chain databases are restored from backup and integrity-checked. Suggested order: identity and network infrastructure, then core accounting and matching databases, then nodes and RPC, then indexers and the block explorer, then risk control and reporting. Acceptance rests on a three-way match — on-chain balances and transfers, internal ledgers and deposit/withdrawal records, and user-visible balances reconciled item by item, with discrepancies logged and explained before withdrawals reopen in stages.

  5. Harden, notify and rewrite the playbook

    Remediation covers a separately networked signing zone with separated duties, integrity verification for developer endpoints and the software supply chain, least-privilege outsourced access with alerting on bulk exports, edge-device patching and MFA everywhere, and offline or immutable backup copies. In parallel, support regulatory reporting and user notification, then write the timeline, entry point and residual risk into the incident playbook and schedule the next recovery drill including on-chain/off-chain reconciliation.

Common ransomware families

Hardening recommendations

  • Keep signing and key infrastructure off the office and production networks. Signing hosts, HSMs and key backups get their own network segment and credentials, multisig signers are split across separate devices and people, and withdrawals are gated by address allowlists, value thresholds and manual review.
  • Verify the transaction itself before signing. Public cases show front-end interfaces can be tampered with, so large transfers should have their destination address and call data checked on an independent device rather than trusting what the web page displays.
  • Manage developer endpoints and the supply chain to production standards. Least privilege and regular rotation for repository and CI tokens, integrity verification for third-party front ends, SDKs and dependencies, and developer machines under EDR and patch management.
  • Funnel outsourced and support access. Expose customer records on a need-to-know basis, alert and log on bulk exports, out-of-scope lookups and off-hours access, and forbid shared accounts.
  • Edge devices and VPNs are the main door for ransomware crews. Patch Citrix, SonicWall, Fortinet and similar promptly, reduce exposed surface, and enable MFA on every remote and privileged account.
  • Treat on-chain and off-chain backups differently. Index databases are rebuildable but slow, so keep a snapshot that imports quickly; irreplaceable data such as KYC records, ledgers and tickets needs an offline or immutable copy held outside the production domain.
  • Segment the network and drill regularly. Strictly separate office, development, node, database and signing zones, and run a quarterly recovery drill that includes on-chain/off-chain reconciliation, recording real RTO and RPO.

Emergency response

Data already encrypted? Stop and let an engineer look first

We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.

Related scenarios

FAQ

Frequently asked questions

  • Our data is on the blockchain — how can it be lost?

    What lives on chain is transaction and state data, which can be resynced from the network — but most of what actually runs the business does not live there. What becomes unrecoverable after encryption is typically KYC records and ID images, user and ticketing systems, risk rules and models, matching and deposit/withdrawal ledgers, internal approval and reconciliation records, and the index databases built for query performance.

    An index database can in principle be rebuilt from chain data, but a full archive resync is expensive. In practice we plan it as "rebuildable but slow", keep a snapshot that imports quickly, and spend the offline and immutable backup budget on the off-chain data that has no second source.

  • Our signing hosts and hot wallets were in the affected segment — are the keys still safe?

    Treat them as potentially exposed until forensics says otherwise. We check whether tooling was dropped on the signing hosts, whether script injection or clipboard substitution is present, the access times on key backups and seed files, HSM and multisig operation logs, and whether every on-chain transfer maps to an internal approval.

    Wherever an access or transfer cannot be explained, rotate keys, replace multisig signers and migrate funds per the plan rather than waiting for recovery to finish. An attacker's assurance that they "only encrypted files and did not touch the wallets" has no evidentiary value and cannot be used as a basis for that judgement.

  • Customer KYC data may have been taken — what should we do first?

    Move the exfiltration assessment to the front of the engagement rather than waiting for systems to come back. Forensics establishes whether data left, which fields were involved and how many people are affected — from anomalous egress traffic and destinations, staged archives, object storage and external transfer records, and bulk export or search behaviour on accounts — and states the basis and confidence.

    That conclusion drives the content of regulatory reporting and the scope of user notification. In parallel, note that once ID images, addresses and phone numbers are exposed, the most common follow-on harm is not the data itself but impersonation scams aimed at your users; public cases show these follow closely, so user warnings and support scripts should be prepared at the same time.

  • We work in crypto anyway — isn't paying the ransom easy for us?

    Technically easy, and for exactly that reason riskier — and we do not make payments or negotiate on a client's behalf. For a licensed or regulated crypto business, transferring funds to an extortion crew runs straight into sanctions screening and anti-money-laundering duties. Where US business, US dollar clearing or a US-connected party is involved, the US Treasury's OFAC advisory on potential sanctions risks for facilitating ransomware payments, updated in 2021, identifies such payments as a sanctions risk and applies strict liability, so liability can attach even without knowledge, and some ransomware brands have links to sanctioned entities. Whether and how far that applies to a given business is a question for counsel in its own jurisdiction. The transfer also stays on chain as a durable, searchable record.

    It is a poor trade on results too. Chainalysis's 2026 report puts the share of victims paying in 2025 at about 28%, meaning most organisations completed recovery through backups and incident response. Payment neither retrieves KYC data that has already been exfiltrated nor prevents a second extortion attempt.

  • How long until our nodes and block explorer are serving again?

    It depends on three things: whether you have a trustworthy recent snapshot, which chain and client you run, and how deep your indexes go. With a clean snapshot, a node usually catches up to the chain head after import and can serve RPC fairly quickly. Without one — a full archive resync from genesis — public experience generally runs from several days to several weeks, and the archive data volume on major chains also sets the hardware and bandwidth floor.

    Our practice is to restore public capability in tiers: get query RPC and basic endpoints available first, then fill in historical depth and analytics, rather than keeping the door shut until indexing is fully caught up. We give a range with its reasoning after assessment rather than committing to a single number.

Updated