En 30 secondes
- Le 29 octobre 2026 à 20h05 UTC (21h05 à Paris), un attaquant commence à vider les portefeuilles « chauds » de Binance sur dix blockchains. Total : environ 6,36 milliards de dollars, le plus gros vol crypto jamais enregistré.
- Selon Binance, le point d'entrée serait l'ordinateur portable compromis d'un ingénieur DevOps, qui a ouvert l'accès à un conteneur de service capable de soumettre des retraits. Binance parle depuis d'une « attaque complexe » avec d'autres points de compromission.
- Aucune clé privée n'aurait fuité. L'attaquant aurait fait signer ses transactions par l'infrastructure de signature elle-même, et utilisé sur Ethereum un mécanisme récent, EIP-7702, pour vider un portefeuille d'un seul coup.
- Tether, Circle, Ripple et d'autres ont gelé environ 2,7 milliards. Binance promet de couvrir l'intégralité des pertes via son fonds SAFU et ses fonds propres.
- TRM Labs attribue l'attaque avec un haut degré de confiance au groupe nord-coréen TraderTraitor, déjà derrière Bybit. Aucune autorité ne l'a encore confirmé officiellement.
L'essentiel
Il faut mesurer l'échelle. Le précédent record, le vol de Bybit en février 2025, portait sur 1,5 milliard de dollars et avait déjà sidéré le secteur. Binance, c'est quatre fois plus, en moins d'une demi-heure, sur dix réseaux différents en parallèle. Le bitcoin est passé sous les 79 000 dollars dans l'heure, le BNB a perdu plus de 6 %, et des centaines de millions de positions à effet de levier ont été liquidées dans la foulée.
Le plus instructif n'est pourtant pas le montant. C'est la méthode. Depuis dix ans, on répète que la sécurité d'une plateforme crypto repose sur la protection de ses clés privées : coffres matériels (HSM), signature multipartite (MPC), multisig, stockage à froid. Binance avait tout cela. Les clés, d'après la plateforme, n'ont pas bougé. L'attaquant s'est placé en amont de la signature, là où l'on décide ce qui mérite d'être signé.
Imaginez une banque dont le coffre est inviolable. Le voleur ne l'a pas forcé. Il s'est assis au guichet, avec un badge d'employé volé, et a rempli des ordres de virement que le système a exécutés normalement, parce qu'ils semblaient venir de l'intérieur. La serrure a tenu ; c'est la procédure qui a été trompée.
Le modèle de menace dominant des CEX traite le signataire (HSM/MPC) comme la frontière de confiance. Les incidents Bitget (septembre 2026) et Binance (octobre 2026) montrent que la vraie frontière est la chaîne d'intention : qui peut soumettre une demande de signature, comment son contenu est authentifié de bout en bout, et ce que la politique de signature accepte (types de transactions, destinataires, montants, vélocité). Un signataire parfait qui signe une intention falsifiée reste un oracle de signature au service de l'attaquant.
Chronologie minute par minute
Reconstitution à partir de l'analyse on-chain de TRM Labs et des communiqués de Binance. Heures en UTC, puis heure de Paris (UTC+1 depuis le passage à l'heure d'hiver).
- Dans la journéePréparationLe portefeuille « opérateur » de l'attaquant reçoit trois petits retraits depuis Tornado Cash, un mixeur qui brouille l'origine des fonds. De quoi payer les frais de transaction, sans laisser de trace remontant à une identité.
- Tôt le matinPréparationLe code d'attaque est déployé et testé sur deux portefeuilles, puis répété sur un troisième. L'attaquant fait une répétition générale.
- 20:05 → 20:0921:05 ParisVol233,46 millions de XRP quittent cinq portefeuilles Binance sur le XRP Ledger. Le vol commence par la périphérie.
- 20:1021:10VolLes portefeuilles Solana et Optimism sont vidés.
- 20:2021:20Vol18 270 BTC partent d'un hot wallet Bitcoin. Au même moment, la transaction EIP-7702 contenant 50 autorisations pré-signées est soumise sur Ethereum. Dans les deux minutes, 612,7 M USDT et 46,4 M TRX sont aspirés sur Tron.
- ≈ 20:2321:23VolLe hot wallet Ethereum est vidé en une seule transaction : 167 464 ETH et 63 jetons, dont 1,615 milliard d'USDT.
- 21:0122:01GelTether gèle le principal portefeuille de réception. Trois minutes plus tard, Circle gèle 823 M USDC.
- 21:2422:24BinancePremier message officiel : Binance enquête sur un « problème de sécurité potentiel », suspend les retraits sur plusieurs réseaux et affirme que les fonds des utilisateurs sont en sécurité.
- 20:41 → 23:56VolBalayages répétés sur Ethereum (20:41, 20:59, 21:04, 21:44, 22:39, 23:56) : le contrat délégué continue de ramasser tout ce qui arrive sur le portefeuille.
- 22:01 → 22:2623:01 → 23:26GelRipple gèle 40,5 M RLUSD ; World Liberty Financial gèle 27,8 M USD1.
- 23:0500:05VolSeconde vague, sur Avalanche et Polygon.
- 00:0801:08GelLe Security Council d'Arbitrum immobilise 8 426 ETH et 74,6 M ARB (≈ 30 M$).
- 02:2303:23BinanceBinance avance une première cause : un portable d'ingénieur DevOps compromis, donnant accès à un conteneur de service capable de soumettre des retraits. Impact estimé : 6,3 Md$. Aucune fuite de clé privée constatée. Pertes couvertes par le fonds SAFU.
- 04:3605:36BinanceL'incident découle de « plusieurs facteurs ». Reprise des retraits annoncée sous 48 heures.
- 08:4709:47BinanceBinance confirme le portable comme point d'entrée probable, mais indique que l'enquête a trouvé d'autres points de compromission dans une « attaque complexe ».
Hot, warm, cold : le décor
Pour comprendre l'attaque, il faut savoir comment une plateforme d'échange range l'argent de ses clients. Elle ne le garde pas dans un seul portefeuille, mais dans plusieurs niveaux, du plus accessible au plus protégé.
Le hot wallet, c'est la caisse du magasin : il faut de la monnaie disponible pour servir les clients qui retirent leurs fonds à toute heure. Le cold wallet, c'est le coffre de la banque, déconnecté d'Internet. Une plateforme bien gérée garde l'essentiel au coffre et le minimum en caisse. Le 29 octobre, la caisse contenait des milliards.
Où se trouve la clé, et qui lui parle
Dans une plateforme moderne, la clé privée d'un hot wallet ne traîne pas sur un serveur. Elle est enfermée dans un HSM (boîtier matériel inviolable) ou découpée en fragments répartis entre plusieurs machines (MPC). Personne ne peut la lire. En revanche, des services internes peuvent lui demander de signer. Toute la sécurité repose alors sur une question : qui a le droit de demander, et qui vérifie la demande ?
Le comment : la chaîne d'attaque
Mettons bout à bout ce qui est confirmé, ce qui relève de l'analyse d'experts reconnus et ce qui reste une hypothèse. La distinction compte : 24 heures après les faits, le post-mortem technique de Binance n'est pas publié.
Étape par étape
01. L'accès initial. Binance n'a pas dit comment le portable a été compromis. Mais les méthodes du groupe soupçonné sont bien documentées : fausses offres d'emploi sur LinkedIn, entretiens techniques où l'on demande au candidat d'exécuter un « test de code » piégé, paquets npm ou Python vérolés, faux outils de trading. En 2024, c'est un faux recruteur qui avait piégé un employé du prestataire de DMM Bitcoin. En 2025, c'est le poste d'un développeur de Safe{Wallet} qui avait ouvert la porte du vol de Bybit.
02-03. Du poste à la production. Un ingénieur DevOps a, par définition, des accès étendus : consoles cloud, clusters Kubernetes, pipelines de déploiement. Depuis son poste, l'attaquant a atteint un conteneur de service autorisé à soumettre des transactions de retrait. Le co-CEO Richard Teng a précisé que l'attaque relevait d'un processus plus complexe que le simple abus des droits d'un ingénieur.
04. Le cœur du problème. TRM Labs relève un fait frappant : des portefeuilles sur des chaînes différentes, avec des types de clés et des schémas de signature différents, ont tous produit des signatures valides pour l'attaquant en une demi-heure environ. Un vol de clés aurait exigé de compromettre chacune séparément. L'explication la plus simple : l'attaquant pouvait faire signer l'infrastructure de signature commune.
05. Le drain. Sur neuf chaînes, de simples transferts signés. Sur Ethereum, une technique plus fine, détaillée dans la section suivante. L'ordre des opérations (XRP et Solana d'abord, puis Bitcoin, Tron et Ethereum en rafale vers 20:20) suggère un script orchestré, pas un opérateur manuel.
T1566 / T1204 Phishing et exécution par l'utilisateur (vecteur présumé) → T1078 Comptes valides → T1609 Commandes d'administration de conteneur → T1565.002 Manipulation de données transmises (demandes de signature) → T1657 Vol financier. Le schéma rejoint celui de Bitget en septembre : un système backend compromis forge des données de transaction et déclenche le processus d'autorisation légitime. Ce qui manquait dans les deux cas : une authentification cryptographique de l'intention à la source, vérifiée indépendamment par le signataire.
Le coup EIP-7702
Sur Ethereum, l'attaquant n'a pas multiplié les virements. Il a transformé le portefeuille de Binance en aspirateur programmable qu'il était seul à contrôler, grâce à une fonctionnalité arrivée en mai 2025 avec la mise à jour Pectra.
Sur Ethereum, il existe deux sortes de comptes : les comptes « simples », contrôlés par une clé (votre portefeuille MetaMask par exemple), et les « contrats », de petits programmes. Depuis 2025, la norme EIP-7702 permet à un compte simple d'emprunter le comportement d'un programme, à condition de signer une autorisation. C'est pratique : payer les frais en USDC, regrouper plusieurs opérations en une. Mais si l'on fait signer cette autorisation au mauvais moment, le compte se met à obéir au programme de quelqu'un d'autre. C'est exactement ce qui est arrivé, et c'est aussi l'arnaque n° 1 qui vide les portefeuilles des particuliers depuis un an.
Pourquoi cinquante signatures ?
Une autorisation EIP-7702 n'est valable que pour une valeur précise du nonce, le compteur de transactions du compte. Or un hot wallet de Binance envoie des retraits en continu : son nonce avance sans cesse. L'attaquant ne pouvait pas savoir à quelle valeur il serait au moment où sa transaction serait incluse dans un bloc. Il a donc fait signer cinquante autorisations couvrant cinquante valeurs consécutives. Le protocole ignore simplement les autorisations invalides, sans faire échouer la transaction : il suffisait qu'une seule tombe juste.
Une transaction SET_CODE_TX_TYPE (0x04) porte une authorization_list de tuples [chain_id, address, nonce, y_parity, r, s]. Chaque tuple est signé par l'autorité sur keccak256(0x05 ‖ rlp([chain_id, address, nonce])). À l'exécution, le client vérifie que le nonce du tuple égale le nonce courant de l'autorité, incrémente ce nonce et écrit le désignateur de délégation 0xef0100 ‖ address dans le code du compte. Un tuple invalide est sauté, pas bloquant : d'où la stratégie « rafale de 50 ».
Point clé pour les équipes custody : une demande de signature 7702 n'est pas une transaction, c'est un message préfixé 0x05. Si la politique du signataire ne filtre que les transactions (destinataire, montant), une autorisation de délégation peut passer sous le radar. TRM note aussi que ce lot pré-signé peut indiquer un accès limité dans le temps, ou des signatures qu'il fallait demander à un système.
Un hot wallet de plateforme n'a aucune raison légitime de déléguer son code. Une règle unique, « refuser tout payload préfixé 0x05 pour les clés de conservation », aurait vraisemblablement bloqué la branche Ethereum de l'attaque, soit environ 3,8 Md$ sur 6,36. Cela n'aurait rien changé aux neuf autres chaînes, où l'attaquant a fait signer des transferts ordinaires.
Où sont partis les fonds, chaîne par chaîne
Blanchiment et course aux gels
Dès les premières minutes, une course s'engage. L'attaquant doit convertir au plus vite les actifs gelables (les stablecoins comme USDT ou USDC, dont l'émetteur peut bloquer une adresse) en actifs non gelables (ETH, BTC). En face, les émetteurs et les équipes de sécurité tentent de bloquer les adresses avant la conversion.
ABradage des stablecoins
Environ 325 M USDT revendus contre ≈ 122 300 ETH via UniswapX et d'autres contrats « à intention », avec une décote d'environ 10 %. L'attaquant accepte de perdre plus de 30 millions pour aller vite.
BEmprunts DeFi
60 M USDT déposés sur Aave en garantie pour emprunter ≈ 19 760 ETH. 300 M USDT déposés sur JustLend (Tron). Aave a gelé les marchés concernés.
CPeel chain Bitcoin
Les 18 270 BTC sont découpés en tranches rondes de 1 000 puis 100 BTC, une technique classique pour diluer la traçabilité sur de nombreuses adresses.
DÉtape suivante attendue
Ponts inter-chaînes, services de swap sans KYC et courtiers OTC, comme après Bybit. Le blanchiment complet de KelpDAO (220 M$) a pris environ six semaines.
Ce qui a été sauvé
Le gel de Tether est intervenu 56 minutes après le premier transfert. Dans ce type d'incident, l'heure qui suit vaut plus que toutes les autres.Lecture FactualRisk des horodatages TRM Labs
Les stablecoins comme l'USDT sont émis par des entreprises qui peuvent « bloquer » une adresse. C'est critiqué au nom de la décentralisation, mais ici cela a sauvé près de 2,6 milliards. Le bitcoin et l'ether, eux, ne peuvent être gelés par personne : une fois convertis, les fonds deviennent très difficiles à récupérer.
Pourquoi la Corée du Nord
Binance ne nomme personne. TRM Labs attribue l'attaque à TraderTraitor avec un haut degré de confiance ; Chainalysis va dans le même sens. Aucune autorité (FBI, Trésor américain) ne s'est prononcée à ce stade. Pour Bybit, le FBI avait officiellement attribué le vol cinq jours après les faits.
Qui est TraderTraitor
Sous-groupe de la nébuleuse Lazarus, rattachée au Bureau général de reconnaissance nord-coréen (le renseignement militaire), TraderTraitor est spécialisé dans le vol de crypto-actifs auprès des entreprises du secteur. L'agence américaine CISA lui a consacré une alerte dès avril 2022, décrivant des campagnes de spear-phishing visant les employés de sociétés crypto avec des applications de trading piégées. Les éditeurs de sécurité le suivent sous d'autres noms : Jade Sleet (Microsoft), UNC4899 (Mandiant), Slow Pisces (Palo Alto Unit 42).
Washington accuse ces groupes de financer les programmes militaires du régime ; Pyongyang dément systématiquement. Avant même Binance, les vols attribués à la Corée du Nord en 2026 approchaient le milliard de dollars.
| Indice | Ce qu'on observe chez Binance | Précédents TraderTraitor |
|---|---|---|
| Financement | Wallet opérateur alimenté par trois petits retraits Tornado Cash la veille | Même schéma chez Bybit et KelpDAO |
| Préparation | Code testé puis répété sur des wallets tiers des heures avant | Staging longtemps à l'avance |
| Exécution | Signatures obtenues à l'avance, exécutées en une rafale | Bybit, KelpDAO |
| Fonds mêlés | Chainalysis observe des fonds volés à Bitget en septembre mêlés au butin de Binance | Bitget attribué à la Corée du Nord par sa CEO |
| Cible | Infrastructure de signature d'un CEX, via le poste d'un ingénieur | DMM Bitcoin, Bybit, Bitget |
Le schéma de blanchiment diffère de Bybit, qui reposait massivement sur des ponts (THORChain notamment). Ici, conversion immédiate via des market makers à intention et du collatéral DeFi. Ce changement peut s'expliquer par la proportion exceptionnelle de stablecoins gelables dans le butin, qui imposait une conversion en minutes plutôt qu'en heures. Il ne remet pas en cause l'attribution, mais il mérite d'être suivi.
Un mode opératoire qui évolue
Binance n'est pas un coup isolé. C'est l'aboutissement d'une progression méthodique, que l'on peut lire comme une remontée le long de la chaîne de confiance : des clés, vers les interfaces de signature, puis vers les systèmes qui décident de ce qui doit être signé.
Les grands casses attribués à la Corée du Nord
| Incident | Point d'entrée | Ce qui a été trompé |
|---|---|---|
| DMM Bitcoin | Faux recruteur LinkedIn ; « test pré-embauche » Python piégé envoyé à un employé du prestataire Ginco | Une demande de transaction légitime, modifiée en cours de route |
| Bybit | Poste d'un développeur Safe{Wallet} ; JavaScript malveillant injecté dans l'interface web | Les signataires du multisig voyaient un transfert normal et signaient un changement de contrat |
| KelpDAO | Deux nœuds RPC liés au vérificateur LayerZero compromis | Les données lues par le vérificateur du pont inter-chaînes |
| Bitget | Système backend de l'infrastructure de wallets | Données de transaction falsifiées soumises au processus d'autorisation |
| Binance | Portable d'un ingénieur DevOps, puis conteneur de service | L'infrastructure de signature des hot wallets, sur dix chaînes |
Protéger vos cryptos
Si vous détenez des fonds sur Binance : la plateforme affirme que les soldes clients sont intacts et que les pertes seront couvertes par son fonds SAFU et ses fonds propres. La reprise des retraits est annoncée sous 48 heures. Votre premier risque, aujourd'hui, n'est pas le hacker de Binance : ce sont les escrocs qui exploitent la panique.
À faire cette semaine
- Suivre uniquement les comptes officiels de Binance et l'application.
- Activer le code anti-phishing Binance : il apparaît dans tous les vrais e-mails.
- Vérifier la liste blanche d'adresses de retrait.
- Attendre la réouverture officielle avant de déplacer quoi que ce soit.
À ne jamais faire
- Cliquer sur un lien « vérifiez votre compte suite à l'incident ».
- Répondre à un « support Binance » qui vous contacte en premier.
- Signer une transaction sur un site de « remboursement » ou d'« airdrop de compensation ».
- Communiquer votre phrase de récupération, à qui que ce soit.
Les 10 règles durables
01Une plateforme n'est pas un coffre
Ce que vous laissez sur un exchange n'est plus vraiment à vous : c'est une créance sur la plateforme. Gardez-y ce que vous tradez, pas votre épargne de long terme.
02Un portefeuille matériel pour l'épargne
Ledger, Trezor, Keystone, BitBox… La clé reste dans le boîtier, chaque opération se valide physiquement. Achetez-le chez le fabricant, jamais d'occasion.
03La phrase de 24 mots, sur papier ou métal
Jamais en photo, jamais dans le cloud, jamais dans un gestionnaire de mots de passe en ligne. Personne de légitime ne vous la demandera, jamais.
04Clé physique ou passkey, pas de SMS
Protégez votre compte d'exchange par une clé FIDO2 (YubiKey…) ou une passkey. Le SMS se détourne par échange de carte SIM.
05Liste blanche et délai de retrait
Activez la liste blanche d'adresses et le délai de 24 h sur toute nouvelle adresse. Un compte volé devient alors bien moins rentable.
06Lire ce que l'on signe, sur l'écran du boîtier
Les signataires de Bybit ont validé ce que leur montrait un écran falsifié. L'écran de votre portefeuille matériel est la seule source fiable : comparez l'adresse et le montant.
07Refuser toute « mise à niveau du compte »
Une demande de type « upgrade to smart account », « delegate » ou « EIP-7702 » sur un site inconnu est la porte d'entrée des sweepers. Dans le doute, refusez.
08Révoquer les autorisations
Faites le ménage régulièrement dans les approbations de jetons et les délégations accordées aux applications DeFi (outils de type revoke.cash, ou l'explorateur de votre chaîne).
09Séparer les usages
Un portefeuille « coffre » qui ne signe jamais rien sur le web, un portefeuille « chaud » avec peu de fonds pour la DeFi et les mints. Une compromission ne vide alors que la poche de test.
10Diversifier le risque de contrepartie
Répartissez entre plusieurs plateformes régulées, consultez leurs preuves de réserves et la taille de leur fonds de garantie. En Europe, privilégiez les prestataires agréés MiCA.
La règle d'or tient en une phrase : si vous ne détenez pas les clés, vous ne détenez pas les cryptos. Binance remboursera cette fois, parce qu'elle en a les moyens. Toutes les plateformes ne le pourraient pas : FTX en 2022 ou Mt. Gox en 2014 ont laissé des clients sans rien pendant des années.
Protéger l'entreprise
Cette section s'adresse d'abord aux plateformes, dépositaires, fintechs et trésoreries crypto. Mais ses leçons valent pour toute organisation qui exécute des paiements : remplacez « infrastructure de signature » par « ERP de trésorerie » ou « module de virements SWIFT », et le scénario reste le même. Un poste d'administration compromis, un service interne qui peut soumettre des ordres, un contrôle aval qui fait confiance à l'amont.
Le plan d'action, par barrière
Barrière 1. Le poste d'administration. Les ingénieurs qui touchent à la production travaillent depuis un poste d'administration dédié, durci, sans messagerie ni navigation web, conformément aux recommandations de l'ANSSI sur l'administration sécurisée des SI. Les tests de code de candidats, les dépôts GitHub reçus d'inconnus et les « exercices techniques » s'exécutent dans des machines virtuelles jetables, jamais sur le poste de travail. EDR obligatoire, avec des règles spécifiques sur l'exécution de Node.js et Python depuis des dossiers de téléchargement.
Barrière 2. L'identité et les accès. Authentification résistante au phishing (FIDO2) partout, sessions courtes liées à l'appareil, et surtout zéro accès permanent à la production : chaque élévation est demandée, justifiée, validée par un second humain et expire automatiquement. Dans Kubernetes, pas de kubectl exec sur les pods de la chaîne de paiement hors procédure « bris de glace » journalisée ; identités de charge de travail (SPIFFE/SPIRE), politiques réseau strictes, détection à l'exécution (Falco, Tetragon).
Barrière 3. L'intégrité de l'intention. C'est la leçon centrale. Le signataire ne doit pas croire le service qui lui parle : il doit pouvoir vérifier indépendamment qu'une demande correspond à un retrait client réel. Concrètement, la demande de retrait est signée dès sa création par le système qui l'a reçue (avec la session authentifiée du client), et cette signature est vérifiée par le moteur de règles et par le signataire. Un conteneur compromis au milieu ne peut alors plus fabriquer de demande crédible.
Barrière 4. La politique de signature. Elle vit au plus près de la clé (dans l'enclave du HSM ou dans chaque nœud MPC), pas dans un microservice voisin. Elle impose des plafonds par transaction et par heure, des listes de types de messages autorisés (et refuse explicitement les autorisations EIP-7702, les delegatecall et les changements de propriétaire), une vélocité maximale, et une approbation humaine au-delà d'un seuil. Le solde des hot wallets est dimensionné sur quelques heures de retraits, pas sur des jours.
Barrière 5. Détection et réponse. Surveillance on-chain de vos propres adresses avec alertes sur les signaux anormaux (nouvelle destination, transaction de type 0x04, vidage supérieur à X % du solde). Coupe-circuit automatique qui suspend les signatures sans attendre une décision humaine. Et un playbook avec les contacts d'urgence déjà établis chez Tether, Circle, les grands émetteurs, les équipes sécurité des protocoles DeFi et les sociétés d'analyse blockchain. Le 29 octobre, chaque minute gagnée valait des dizaines de millions.
| Étape de l'attaque | Contrôle prioritaire | Référentiels | Priorité |
|---|---|---|---|
| Accès initial | Sensibilisation ciblée « faux recruteurs » ; tests de code en bac à sable ; vérification d'identité renforcée des recrutements à distanceATT&CK T1566, T1204 | ISO 27001 A.6.3, A.8.7ANSSI : hygiène informatique | Critique |
| Poste compromis | Poste d'administration dédié ; EDR ; cloisonnement des usagesATT&CK T1078 | ISO 27001 A.8.1, A.8.2ANSSI : administration sécurisée | Critique |
| Pivot conteneur | Accès juste-à-temps ; pas d'exec en prod ; identités de workload ; segmentationATT&CK T1609 | ISO 27001 A.8.2, A.8.18, A.8.22 | Critique |
| Signature abusive | Intention signée à la source ; politique dans l'enclave ; refus 7702 ; quorum au-delà d'un seuilATT&CK T1565.002 | ISO 27001 A.8.24, A.8.26MiCA : garde des actifs | Critique |
| Drain massif | Plafonds et vélocité ; solde chaud minimal ; coupe-circuit automatique | ISO 27001 A.8.16DORA : résilience opérationnelle | Élevée |
| Blanchiment | Monitoring on-chain ; playbook de gel ; contacts émetteurs ; partage de renseignementATT&CK T1657 | ISO 27001 A.5.7, A.5.24 à A.5.26NIS2 / DORA : notification | Élevée |
Posez une seule question à votre équipe custody : « Si un attaquant obtient root sur le service qui soumet nos demandes de retrait, combien peut-il sortir en une heure ? » Si la réponse est « tout le solde du hot wallet », vous avez le même problème que Binance. Faites l'exercice en red team, avec un scénario de compromission de poste DevOps, et mesurez trois chiffres : le montant maximal extractible, le délai avant détection, le délai avant coupe-circuit.
Trois questions à poser à votre RSSI ou à votre DSI : 1. Nos administrateurs travaillent-ils sur des ordinateurs réservés à l'administration ? 2. Est-ce qu'un seul compte compromis peut déclencher un paiement important sans qu'un second humain le valide ? 3. En cas de virement frauduleux à 22h un jeudi, qui est appelé, en combien de minutes, et qui peut tout arrêter ?
Ce qu'on ne sait pas encore
Un bon renseignement sépare les faits des suppositions. Voici les questions ouvertes, que le post-mortem promis par Binance devra trancher.
| Question | État au 30 octobre |
|---|---|
| Comment le portable a-t-il été compromis ? | Inconnu Binance n'a rien précisé. L'ingénierie sociale reste l'hypothèse la plus probable au vu des précédents. |
| Quels étaient les privilèges du rôle DevOps ? | Inconnu Le co-CEO parle d'un processus plus complexe que l'abus d'un seul compte. |
| Quels sont les « autres points de compromission » ? | Inconnu Évoqués par Binance le 30 au matin, sans détail. |
| Comment le moteur de règles a-t-il été contourné ? | Inconnu C'est la question décisive pour tout le secteur. |
| Attribution officielle ? | En attente TRM Labs (haut degré de confiance) et Chainalysis désignent TraderTraitor ; ni Binance ni les autorités ne l'ont confirmé. |
| Montant définitif ? | Provisoire 6,3 Md$ (Binance), 6,36 Md$ (TRM). Gels : 2,7 à 3 Md$ selon les sources. |
Glossaire
- Hot wallet
- Portefeuille connecté en permanence, qui signe automatiquement les retraits courants.
- Cold wallet
- Portefeuille hors ligne, pour les réserves. Chaque mouvement exige des manipulations physiques.
- Clé privée
- Le secret qui permet de signer, donc de dépenser. Qui détient la clé détient les fonds.
- HSM / MPC
- Boîtier matériel qui garde la clé sans jamais la révéler (HSM), ou technique qui la découpe entre plusieurs machines (MPC).
- Nonce
- Compteur de transactions d'un compte, qui augmente de 1 à chaque envoi.
- EIP-7702
- Norme Ethereum de 2025 qui permet à un compte classique de déléguer son comportement à un contrat, sur simple signature.
- Sweeper
- Contrat ou script qui aspire automatiquement tout ce qui arrive sur une adresse.
- Stablecoin
- Jeton indexé sur le dollar (USDT, USDC). Son émetteur peut geler une adresse.
- Tornado Cash
- Mixeur Ethereum qui brouille le lien entre l'origine et la destination des fonds.
- Peel chain
- Découpage d'une grosse somme en petites tranches envoyées vers de nombreuses adresses successives.
- SAFU
- « Secure Asset Fund for Users », fonds d'urgence de Binance destiné à couvrir les pertes des clients.
- TraderTraitor
- Sous-groupe de Lazarus (Corée du Nord) spécialisé dans le vol de crypto-actifs, aussi appelé Jade Sleet, UNC4899 ou Slow Pisces.
Sources
- North Korea Steals USD 6.36 Billion From Binance in the Largest Hack in History TRM Labs · 29-30/10/2026
- Communiqué de Binance sur l'enquête initiale Binance sur X · 30/10/2026
- $6.3 billion Binance hack is largest crypto theft on record CNBC · 29/10/2026
- How the Binance hack happened and who was behind it Euronews · 30/10/2026
- Binance Says DevOps Laptop May Have Been the Entry Point Disruption Banking · 30/10/2026
- Binance victime d'une cyberattaque, le préjudice estimé à 6,3 milliards France 24 · 30/10/2026
- Binance victime du plus grand piratage de l'histoire des cryptomonnaies Génération NT · 30/10/2026
- La Corée du Nord derrière le piratage de Binance ? CryptoTicker · 30/10/2026
- Binance piraté : Pyongyang soupçonné d'un casse de 6,3 milliards Alliancy · 30/10/2026
- Hackers steal $351.6 million in Bitget crypto exchange hack BleepingComputer · 25/09/2026
- LayerZero links $292 million Kelp DAO bridge exploit to Lazarus Unchained · 04/2026
- TraderTraitor: North Korean State-Sponsored APT Targets Blockchain Companies (AA22-108A) CISA · 18/04/2022
- North Korea Responsible for $1.5 Billion Bybit Hack FBI IC3 · 26/02/2025
- EIP-7702: Set Code for EOAs Ethereum Improvement Proposals