Web3 and Crypto Security Guide

The largest crypto thefts rarely break a blockchain: they compromise the people, keys, signing interfaces and web infrastructure that sit around it. Chainalysis, in its own 2025 research, counted over $3.4 billion stolen from January to early December 2025 and attributed at least $2.02 billion of it to North Korean hackers, with the Bybit theft alone accounting for $1.5 billion. This guide is for security teams at exchanges, custodians, protocol teams, DAOs, fintechs and corporates that hold or build on digital assets. It covers the web3 threat landscape, key management and custody, operational security for teams, front-end and DNS protection, monitoring and incident response, and the regulatory touchpoints that shape controls. It is defensive throughout: it explains failure modes at the level needed to stop them, not to reproduce them.

Key takeaways

• Keys and signers are the crown jewels. Bridge, exchange and treasury losses mostly trace to stolen or misused private keys and to signers approving something other than what they intended.
• Developers are the primary target. The FBI warns that North Korean actors run long, tailored recruitment and investment lures against crypto staff, often ending in a "coding test" that installs malware.
• Your web front-end is part of the protocol. A hijacked domain, registrar account or third-party script can drain users without touching a single contract.
• Detection speed decides the loss. Ronin's bridge was drained on 23 March 2022 and the theft was found six days later because large outflows were not monitored.
• Regulation now expects these controls. MiCA authorisation, the FATF Travel Rule and OFAC sanctions screening turn custody, monitoring and record-keeping into compliance obligations, not optional good practice.

How web3 changes the security model

Web3 systems settle value on a distributed ledger, where transactions are final once confirmed and code runs exactly as deployed. That removes the reversals, chargebacks and fraud holds that conventional payments rely on, so prevention and very fast containment carry most of the weight.

The web3 threat landscape

Two patterns stand out. First, North Korea dominates by value: the FBI attributed Bybit (on or about 21 February 2025, approximately $1.5 billion) to activity it calls "TraderTraitor", and Chainalysis says North Korean attacks accounted for 76% of service compromises in 2025. Second, losses are highly concentrated: Chainalysis reports that the top three hacks of 2025 made up 69% of all service losses, so a single failed control at a large custodian outweighs years of smaller incidents. For actor background, see the Threat Actor Groups Guide.

Key management and custody

Every on-chain action is authorised by a private key, so custody design is the core control. The general principles of generation, storage, rotation and destruction apply. See the Cryptographic Key Management Guide.

• Tier by exposure: cold storage for most assets, warm wallets for scheduled movements and a hot wallet sized to a few hours of withdrawals. Refill hot wallets through a documented, approved process.
• Remove single points of control: use m-of-n on-chain multisig or multi-party computation (MPC). Thresholds should reflect what a set of keys can move; the Security Alliance (SEAL) multisig framework advises matching thresholds to blast radius and separating proposer, signer and executor roles.
• Protect key material in hardware: FIPS 140-validated HSMs for service keys, hardware wallets for human signers, and documented key ceremonies with witnesses for generation and backup.
• Verify what is signed, not where it was proposed: SEAL's guidance is to check the calldata itself, not only a hash, and to rehearse emergency and backup signing paths. Ban blind signing on treasury and admin keys.
• Encode policy: destination allowlists, per-transaction and daily limits, time delays on large movements and on changes to signer sets or thresholds.
• Prove solvency carefully: exchanges increasingly publish proof of reserves, typically on-chain asset attestations plus a Merkle-tree proof that lets customers check their balance is included in liabilities. It is a point-in-time snapshot and does not prove that all liabilities were disclosed, so treat it as a transparency measure, not a security control.

A small company with modest balances should usually use a qualified custodian or a simple multisig with hardware signers in different teams. Larger operations need policy engines, separation between people who request and people who approve, and 24/7 monitoring. Individual-level wallet and drainer defences are covered in the Crypto Scam and Drainer Guide.

Where identity fits

In web3, most keys that can move money or ship code are non-human identities, and most compromises reach them through a human first. Bybit, Ronin and Ledger Connect Kit all followed that path: a person was phished or a workstation compromised, then a cloud session, validator node or publishing account was used.

• Inventory privileged keys and tokens: signer keys, contract owner and upgrade keys, validator keys, deployer keys, npm and PyPI publishing tokens, CI secrets, cloud sessions for front-end hosting, and RPC or blockchain API keys. Assign each an owner. See the NHI Ownership Guide.
• Revoke on change, every time: Ronin's post-mortem records that a temporary allowlist letting Sky Mavis sign for the Axie DAO validator was discontinued in December 2021 but "the allowlist access was not revoked", which supplied the fifth signature. Ledger notes that leavers have "access revoked from every Ledger system", yet a former employee's npm account still published the malicious code.
• Short-lived deployment credentials: federated CI identities instead of static cloud keys or npm tokens. See the CI/CD Pipeline Identity Security Guide and the Secrets Management Guide.
• Privileged human access: phishing-resistant MFA and just-in-time elevation for anyone who can touch signing infrastructure, hosting, DNS or package registries. See the Privileged Access Management Guide.

Operational security for web3 teams

FBI PSA I-090324-PSA (3 September 2024) describes North Korean actors researching staff on professional networking and job sites, building rapport over long conversations, impersonating recruiters with fake company websites, and then asking targets to run "pre-employment tests" or debugging tasks using unfamiliar packages, scripts or repositories. Radiant Capital's own incident update describes the result: a DPRK-linked actor posing as a former contractor sent a zipped file over Telegram that installed a macOS backdoor, and compromised developer devices then signed malicious transactions while "front-end interfaces displayed benign transaction data". Radiant put the loss at approximately $50M.

• Isolate untrusted code: candidate tests, sample repositories and "fix this bug" requests run only in disposable virtual machines on non-company hardware, never on signer or developer machines with credentials.
• Dedicate signer devices: hardware used for signing has no email, chat, browsing or development tools. Ronin's remediation included work-only devices for employees.
• Verify identities out of band: confirm recruiters, investors, contractors and "former colleagues" through a separate, known channel before opening files. Re-verify remote hires periodically; SEAL maintains a dedicated framework on DPRK IT workers.
• Restrict and allowlist: limit access to code repositories, pipelines and internal documentation, and allowlist permitted software on company endpoints, as the FBI recommends. See the Application Allowlisting Guide.
• Keep secrets off connected devices: the FBI advises never storing seed phrases, private keys or wallet credentials on internet-connected devices.
• Train for the real lure: awareness content should show fake job offers, investor approaches and "unlock the video call" scripts, not generic phishing. See the Security Awareness and Human Risk Management Guide.

Front-end, DNS and dependency security

Users interact with a protocol through a decentralised application (dApp) website and a wallet connector. If either is altered, users sign transactions to an attacker even though the contracts are untouched.

• Registrar and DNS: use a registrar that supports registry lock, enforce phishing-resistant MFA on registrar and DNS provider accounts, sign zones with DNSSEC, publish CAA records to limit which certificate authorities may issue for the domain, and alert on any change to NS, A, AAAA and CNAME records. See the DNS Security Guide.
• Subresource Integrity: pin third-party scripts and stylesheets with the integrity attribute (sha256, sha384 or sha512) plus crossorigin; on a mismatch the browser refuses to load the resource. The Integrity-Policy header can require integrity for scripts and styles, and has a report-only mode for testing.
• Content Security Policy: restrict script sources and connection targets so an injected script cannot load a drainer or call an unknown endpoint.
• Package publishing: publish SDKs and wallet connectors only from CI with build provenance, require MFA for maintainers, and pin dependency versions in front-end builds. Ledger's fix after Connect Kit included connecting its build pipeline to npm distribution and rotating publishing secrets. Treat hosting and CDN consoles the same way. See the SLSA and Build Provenance Guide and the Open Source Security Guide.

Monitoring and incident response

Ronin's post-mortem states the team had no proper system for monitoring large bridge outflows. On-chain monitoring is the web3 equivalent of a SIEM, and it needs the same tuning and on-call discipline.

• What to watch: treasury and bridge outflows above thresholds, signer-set or threshold changes, ownership transfers, proxy upgrades, role grants, pauses, oracle deviations, new token approvals from corporate wallets, and DNS or front-end file changes.
• Pause mechanisms: a narrowly scoped pause role, held by a small emergency multisig, lets a protocol stop deposits or withdrawals within minutes. SEAL's multisig guidance is that "Bypass paths should do the minimum necessary and nothing more."
• Security councils: some protocols appoint a council multisig with limited emergency powers (pause, cancel a queued proposal, emergency upgrade) and on-chain disclosure of every use. Define what it cannot do as carefully as what it can.
• External help: SEAL describes SEAL 911 as "24/7 cryptocurrency incident response for the crypto ecosystem", and its Safe Harbor framework offers "Legal protection for whitehat rescues during active exploits." Adopt Safe Harbor terms before an incident if you want rescuers to act.

1. Contain: pause affected contracts, revoke compromised signers, rotate exposed keys and tokens, and take down hijacked front-ends.
2. Coordinate: contact exchanges, bridges and stablecoin issuers that may be able to freeze funds, and law enforcement (IC3 in the US). After Bybit, the FBI asked RPC node operators, exchanges, bridges and analytics firms to block transactions linked to attacker addresses.
3. Communicate: warn users on every official channel, name the affected domain or contract, and state what users must not do.
4. Preserve evidence: transaction hashes, signer device images, DNS and hosting logs. See the Incident Response Guide and the Digital Forensics (DFIR) Guide.
5. Recover: redeploy from known-good builds and keys generated in a fresh ceremony, and run a post-mortem with remediation owners.

Regulatory touchpoints

This is a summary of where regulation touches security controls, not legal advice.

Rolling out a web3 security programme

1. Inventory: wallets, signers, thresholds, admin and upgrade keys, validators, bridges, oracles, domains, registrars, publishing accounts and third-party scripts.
2. Fix the highest-value keys first: move treasury and admin keys to multisig or MPC with hardware signers, dedicated devices and documented verification steps.
3. Harden the perimeter around signers: registrar lock, MFA on registrar, hosting and package accounts, SRI and CSP on the front-end.
4. Deploy monitoring in alert-only mode: tune thresholds for two to four weeks on live traffic, then attach automated responses such as pausing only after false positives are understood.
5. Rehearse: run a tabletop and a live drill of pause, signer rotation and backup-interface signing on a test network. Roll back any automated pause rule that triggers on legitimate activity by returning it to alert-only while thresholds are adjusted.
6. Review quarterly: signer offboarding, threshold changes, key ceremony records and sanctions screening results.

Measuring whether it works

• Hot wallet exposure: share of total assets held in hot wallets, against an agreed ceiling.
• Signer hygiene: percentage of signers using dedicated devices and hardware clear signing, and days from a role change to signer removal.
• Detection time: minutes from an anomalous outflow or admin change to a human acknowledging the alert.
• Pause readiness: time to execute an emergency pause in the latest drill.
• Front-end integrity: share of third-party scripts covered by SRI, and DNS changes made without a matching change ticket (target zero).
• Credential lifetime: number of long-lived publishing tokens and static cloud keys with access to front-end or signing systems (target zero).

Common failure patterns

• Trusting the interface: signers approve what a web page shows them. At Bybit and Radiant the displayed transaction was not the one signed.
• Too few, too related keys: Ronin's attacker needed only five keys, four of them held by one company.
• Temporary access that never ends: Ronin's unrevoked allowlist and Ledger's former employee's npm account both outlived their purpose.
• Running a stranger's code: developers completing "tests" from recruiters on machines with production credentials.
• Registrar accounts treated as admin trivia: the Compound hijack shows that DNS is as critical as a contract owner key.
• No one watching: outflow alerts absent or unstaffed, as in Ronin's six-day gap.

Framework mapping

Practitioner checklist

• Keep hot wallet balances to a defined ceiling and refill through an approved process.
• Put treasury, admin and upgrade keys behind multisig or MPC with hardware signers in separate teams.
• Verify calldata on a trusted device before every signature and ban blind signing on privileged keys.
• Give signers dedicated devices with no email, chat or development tools.
• Forbid running candidate tests or unsolicited code on company hardware.
• Lock domains at the registry, enforce phishing-resistant MFA on registrar, hosting and package accounts, and alert on DNS changes.
• Apply SRI and CSP to every third-party script on wallet-facing pages.
• Remove signers, allowlists and publishing access the same day a role ends.
• Monitor outflows, admin changes and oracle deviations 24/7 with a rehearsed pause procedure.
• Screen addresses for sanctions exposure and act on law enforcement blocking requests.

Standards and references

• FBI IC3: North Korea Responsible for $1.5 Billion Bybit Hack
• FBI IC3: North Korea Aggressively Targeting Crypto Industry with Well-Disguised Social Engineering Attacks
• Security Alliance (SEAL): Multisig for Protocols Framework
• US Treasury OFAC: Sanctions Compliance Guidance for the Virtual Currency Industry
• ESMA: Markets in Crypto-Assets Regulation (MiCA)
• FATF: Targeted Update on Implementation of the FATF Standards on Virtual Assets and VASPs
• MDN Web Docs: Subresource Integrity
• Ronin: Back to Building, Ronin Security Breach Post-Mortem

Related NHI Mgmt Group resources: Crypto Scam and Drainer Guide · Cryptographic Key Management Guide · Privileged Access Management Guide · DNS Security Guide · Threat Actor Groups Guide