Piratage de Binance : un PC portable, 6,3 milliards de dollars volés

Faisons le calcul. Le 29 octobre à 20 h 05 UTC, l'argent commence à quitter les wallets de Binance. Environ 6,36 milliards de dollars au total, dont l'essentiel part en une vingtaine de minutes.

Ça fait en moyenne 300 millions de dollars par minute. Cinq millions de dollars par seconde. Le temps que tu lises ce paragraphe, quelqu'un aurait pu s'acheter une petite île. Avec des palmiers.

Je l'avoue : quand je lis l'analyse d'un hack, je m'attends en général à un scénario de film. Une zero-day, un exploit de génie, un hacker en sweat à capuche. Celui-ci est bien plus banal, et c'est justement ce qui le rend plus effrayant. Selon le premier récit de Binance elle-même, tout est parti du PC portable d'un seul ingénieur.

Pas de la blockchain. Pas de la cryptographie. D'un PC portable. Peut-être exactement comme le tien.

En bref : le piratage de Binance est une attaque dans laquelle les intrus ont utilisé le PC portable compromis d'un ingénieur DevOps pour atteindre l'infrastructure interne de l'exchange et faire signer à la plateforme elle-même des transferts vers leurs adresses. D'après Binance, aucune clé privée n'a fuité. Les attaquants n'en avaient pas besoin : le système signait sagement tout ce qu'on lui demandait de signer.

Voyons comment ça fonctionne, qui est derrière, et surtout pourquoi cette histoire concerne toutes les personnes qui écrivent du code ou qui apprennent tout juste à le faire.

Chronologie du piratage de Binance : 36 heures de préparation, 20 minutes d'action

Le plus frappant dans cette attaque, ce n'est pas le montant. C'est son calme et sa méthode. Les analystes de TRM Labs l'ont reconstituée à partir des données de la blockchain, presque minute par minute.

• Matinée du 28 octobre. Le wallet de l'opérateur est alimenté par trois petits montants via Tornado Cash, un mixer qui rend l'origine des coins impossible à tracer. Disons que c'est l'argent de poche pour payer les frais de gas.
• 29 octobre. L'opérateur déploie le code de l'attaque et le teste sur deux wallets de test. Puis il répète la version finale sur un troisième et se renvoie l'argent de test à lui-même. Très soigné.
• Environ quatre heures plus tard, le code répété apparaît sur un hot wallet de Binance.
• De 20 h 05 à 20 h 23. L'argent s'écoule de dix blockchains à la fois : XRP, Bitcoin, Solana, Tron, Ethereum et d'autres. Le wallet Bitcoin à lui seul cède 18 270 BTC en une seule transaction.
• De là jusqu'à minuit, le wallet Ethereum de l'exchange « remet » encore plusieurs fois des fonds tout juste arrivés à l'adresse de l'attaquant.

La préparation a pris au moins 36 heures. Avec des tests, une répétition générale et un rollback des fonds de test. Si chaque release était testée avec autant de soin, la moitié des incidents de prod de la planète disparaîtraient tout simplement.

Pour l'échelle : le record précédent était le piratage de Bybit, 1,5 milliard de dollars, en février 2025. Binance a perdu environ quatre fois plus.

Comment un PC portable se transforme en milliards

Pour comprendre ce qui s'est passé, il faut savoir une chose sur les exchanges.

Chaque plateforme d'échange crypto a des cold wallets (portefeuilles froids) : un stockage hors ligne où dort la majeure partie de l'argent. Et elle a des hot wallets (portefeuilles chauds) : connectés au réseau et automatisés. Ce sont eux qui gèrent les retraits quotidiens des clients. Tu cliques sur « Retirer », le service de l'exchange vérifie la demande, signe la transaction, et l'argent part.

Un hot wallet, c'est comme un guichetier de banque avec un tampon. Le guichetier ne prend aucune décision. Il tamponne tout ce qu'on lui glisse par le bon guichet.

D'après le premier récit de Binance, le parcours de l'attaquant ressemblait à ceci :

1. Le PC portable d'un ingénieur DevOps est compromis. Comment exactement, l'exchange ne l'a pas encore révélé.
2. Par ce biais, l'attaquant entre dans un conteneur de service, un environnement isolé où tourne l'un des services internes de l'exchange.
3. De l'intérieur, il soumet des demandes de retrait que le système considère comme les siennes et signe.

Autrement dit, l'attaquant n'a pas eu besoin de voler le tampon. Il lui a suffi de se présenter au bon guichet.

Binance a ensuite indiqué avoir trouvé d'autres points d'entrée, et le co-CEO de l'exchange, Richard Teng, a souligné qu'il ne s'agissait pas d'une « action en un clic » et que l'attaquant ne s'était pas contenté des permissions d'un seul ingénieur. L'exchange a promis un rapport technique une fois l'enquête bouclée. TRM Labs, en voyant des signatures valides apparaître sur dix blockchains en moins d'une demi-heure, estime que l'explication la plus probable est une compromission de l'infrastructure de signature des hot wallets elle-même.

Mais le point d'entrée que Binance a cité en premier reste le même. Un PC portable.

EIP-7702 expliqué : comment le wallet s'est mis à travailler pour quelqu'un d'autre

La partie la plus technique et, honnêtement, la plus élégante de l'attaque s'est jouée sur Ethereum. C'est là qu'EIP-7702 entre en scène.

En bref : EIP-7702 est un mécanisme d'Ethereum qui permet à un wallet ordinaire d'« enfiler » temporairement le code d'un smart contract et d'exécuter sa logique. Il est arrivé avec la mise à jour Pectra en mai 2025. L'idée est bonne : regrouper plusieurs actions dans une seule transaction, laisser quelqu'un d'autre payer les frais à la place de l'utilisateur, rendre les wallets plus simples à utiliser.

Mais pour qu'un wallet « enfile » le code de quelqu'un d'autre, il lui faut une autorisation signée. Et cette autorisation contient un nonce, le numéro de séquence des transactions du wallet. Le wallet envoie une nouvelle transaction, le numéro avance, et l'ancienne autorisation ne correspond plus.

Le hot wallet d'un exchange envoie des transactions sans arrêt. Deviner à quel numéro il en sera à la seconde précise est quasi impossible. Alors comment l'attaquant a-t-il résolu le problème ?

Il a préparé 50 autorisations pour 50 nonces consécutifs. Toutes signées par le wallet de Binance. Comme un cambrioleur qui se présente à la porte non pas avec une clé, mais avec un trousseau de cinquante : il y en aura bien une qui ira.

Une est allée. Un peu plus de trois minutes plus tard, le wallet avait cédé tout son solde : 167 464 ETH plus 63 autres tokens, dont plus de 1,6 milliard d'USDT.

Et puis est arrivé le plus vicieux. L'autorisation est restée active. Le wallet exécutait désormais un code « aspirateur » qui n'obéissait qu'à l'attaquant. Chaque fois que de l'argent frais arrivait sur l'adresse de Binance, l'attaquant le raflait aussi. C'est comme mettre en place un suivi de courrier sur la boîte aux lettres de quelqu'un d'autre : les gens continuent d'écrire au propriétaire, mais c'est toi qui lis les lettres.

La leçon pour les développeurs : chaque fonctionnalité puissante est aussi un moyen puissant de faire des dégâts. EIP-7702 n'est pas une « faille ». Il fonctionne exactement comme prévu. Le problème, c'est qui a eu l'occasion de s'en servir.

La course à l'argent : gels contre swaps

Dès que l'attaque a été découverte, la course a commencé.

Les stablecoins ont une particularité que Bitcoin n'a pas : les entreprises qui les émettent peuvent geler les tokens sur une adresse précise. Tether, Circle, Ripple et d'autres ont commencé à bloquer les adresses de l'attaquant. L'Arbitrum Security Council a déplacé de force des fonds hors du wallet de l'attaquant. Selon l'estimation de Binance, environ 3 milliards de dollars ont été gelés.

Pendant ce temps, l'attaquant convertissait frénétiquement ses stablecoins en ETH, qu'on ne peut pas geler. Et d'après les calculs de TRM, il a payé plus de 10 % au-dessus du prix du marché pour le faire. Quand Tether te colle aux basques, pas le temps de marchander.

Binance a suspendu les dépôts et les retraits et promis de combler le trou avec son fonds d'assurance SAFU et ses fonds propres : « Ces pertes ne seront pas répercutées sur les utilisateurs. » Au 1er novembre, l'exchange disait avoir couvert environ 95 % du montant concerné et annonçait une réouverture progressive des retraits.

On dirait que les clients vont s'en sortir. Et la question « qui a fait le coup ? » a déjà une réponse.

TraderTraitor et le groupe Lazarus : des hackers qui piratent des humains, pas du code

Le 31 octobre, le FBI a officiellement déclaré que la Corée du Nord était derrière le piratage, plus précisément le groupe TraderTraitor. On le connaît aussi sous les noms de Lazarus Group, Jade Sleet et APT38. TRM Labs et Chainalysis étaient arrivés à la même conclusion encore plus tôt. Binance, de son côté, n'a pas encore désigné publiquement les auteurs.

Regarde les précédentes attaques retentissantes de ce groupe, et tu verras un schéma se dessiner.

Bybit, février 2025, 1,5 milliard de dollars. Les attaquants ne se sont pas attaqués à l'exchange lui-même, mais à son fournisseur de wallets, Safe{Wallet}. Le Mac d'un développeur de Safe a été infecté via un projet Docker au nom anodin, un simulateur d'investissement en bourse, apparemment avec l'aide d'ingénierie sociale. Ensuite : accès à AWS, vol de tokens de session, et JavaScript trafiqué dans l'interface, qui montrait aux signataires de Bybit une transaction « normale ».

DMM Bitcoin, mai 2024, 308 millions de dollars. D'après le FBI, l'attaquant s'est fait passer pour un recruteur sur LinkedIn et a envoyé à un employé de Ginco, l'entreprise japonaise qui gérait les wallets, un script Python déguisé en test technique préalable à l'embauche. L'employé a lancé le script. Game over.

Tu vois le schéma ? La Corée du Nord ne casse pas la cryptographie. C'est lent et coûteux. Il est bien plus simple de pirater une personne qui a des accès : un développeur, un ingénieur DevOps, un admin. Et le moyen le plus sûr de pousser un développeur à exécuter le code de quelqu'un d'autre, c'est de lui proposer le job de ses rêves.

Comment exactement le PC portable de l'ingénieur de Binance a été infecté, on ne le sait toujours pas, et personne ne peut affirmer qu'il s'agissait d'un faux test technique. Mais le mode opératoire de ce groupe est bien documenté. Et il concerne directement toutes les personnes qui cherchent un emploi dans la tech.

Faux entretiens d'embauche et malwares : le test technique le plus dangereux de ta vie

Dès 2023, des chercheurs de Palo Alto Networks ont décrit une campagne nord-coréenne au nom on ne peut plus explicite : Contagious Interview. Le dispositif n'a fait que se perfectionner depuis, et ses victimes ne sont plus seulement des employés d'exchanges, mais des développeurs ordinaires en recherche d'emploi.

Voici à peu près comment ça se passe :

1. Un « recruteur » te contacte sur LinkedIn, Telegram ou par e-mail. L'entreprise a l'air sérieuse, le salaire est agréablement au-dessus du marché, et le process est rapide.
2. Après un court appel, tu reçois un test technique. Il faut télécharger un repo, « lancer le projet en local et corriger deux ou trois bugs ». Ou installer « notre application de visio ».
3. Tu lances npm install ou un script Python. Et à cet instant, le code de quelqu'un d'autre s'exécute sur ta machine, sans que tu en aies vu une seule ligne. Son auteur, en revanche, a soigneusement réfléchi à chacune d'elles.

Ensuite, le malware part à la recherche de tout ce qui traîne : mots de passe du navigateur, cookies de session, clés SSH, tokens cloud, wallets crypto. Si c'est un PC portable professionnel avec accès à la prod, félicitations : ta machine vient de devenir la porte d'entrée de l'entreprise de quelqu'un d'autre.

Le pire, c'est qu'un test technique est l'appât parfait. Tu as envie de le lancer. Le stress monte, tu te dépêches, et la dernière chose à laquelle tu penses, c'est ce qui se cache dans package.json.

Signaux d'alerte :

• Le salaire est nettement au-dessus du marché et le process étrangement rapide : « passons directement au test technique ».
• Le test doit être exécuté, pas simplement écrit de zéro.
• On te demande d'installer une « application spéciale pour l'appel » au lieu de Zoom ou Google Meet.
• Le repo contient des scripts d'installation bizarres, du code obfusqué ou des dépendances avec des fautes de frappe dans leur nom.
• On te presse : « il nous le faut aujourd'hui, ce poste doit être pourvu au plus vite ».

Comment lancer un test technique en toute sécurité et dormir sur tes deux oreilles :

• Jamais sur ton PC portable professionnel. Surtout pas sur une machine qui a accès à la prod, au cloud ou à l'argent des autres.
• En isolation. Une machine virtuelle ou un conteneur Docker sans accès à ton dossier personnel. Si tu sais lancer un conteneur pour le projet de quelqu'un d'autre, tu as déjà une couche de protection que le développeur de Safe n'avait pas. Dans le cours Docker, c'est l'une des premières choses que tu fais en pratique.
• Lire d'abord, lancer ensuite. Ouvre package.json et regarde la section scripts, en particulier preinstall et postinstall. Pour la première installation, il y a npm install --ignore-scripts.
• Aucun wallet ni aucune clé à proximité. Un wallet crypto, des clés SSH de prod et un test technique envoyé par des inconnus ne devraient jamais cohabiter sur la même machine.
• Renseigne-toi sur l'entreprise. Le site web, de vrais employés sur LinkedIn, l'historique de l'offre d'emploi. Cinq minutes de recherche sur Google peuvent valoir plus que cinq ans de salaire.

Et une remarque spéciale pour 2026 : si tu confies un test technique à un agent IA, n'oublie pas que l'agent peut lui aussi lancer npm install. Le malware se fiche de savoir qui a appuyé sur Entrée, toi ou Claude Code. Laisser un agent exécuter du code venant d'un repo inconnu demande la même isolation que si tu le faisais toi-même.

Si tu as déjà accès à la prod

Pour toutes les personnes qui travaillent en DevOps, en backend ou au support de l'infrastructure, la leçon de Binance frappe encore plus fort : ton PC portable fait partie du périmètre de l'entreprise. Pas « mon ordinateur perso sur lequel il se trouve que je bosse aussi », mais littéralement une porte vers la prod.

Concrètement, ça veut dire :

• Sépare tes environnements. Ta machine de travail sert au travail. Projets perso, tests techniques, jeux et extensions de navigateur douteuses : n'importe où ailleurs.
• Moindre privilège. Tu as besoin d'accéder exactement à ce sur quoi tu travailles maintenant, et seulement pendant que tu y travailles. Des droits admin permanents « au cas où », c'est un cadeau pour les attaquants.
• Clés matérielles et sessions courtes. Dans l'affaire Bybit, les attaquants ont contourné l'authentification à deux facteurs en volant des tokens de session déjà actifs. Plus une session est courte, moins celui qui l'a volée a de temps pour s'en servir.
• Les opérations critiques exigent au moins deux paires d'yeux. Aucun compte ne devrait pouvoir, à lui seul, retirer de l'argent ou pousser des changements dans le pipeline de paiement.

Rien de tout ça n'est sorcier. Et c'est justement pour ça que c'est si souvent laissé de côté.

Ce que ça signifie si tu apprends encore à coder

On pourrait lire cette histoire comme un thriller sur des milliards et la Corée du Nord. Mais pour un développeur, la leçon est ailleurs.

La sécurité n'est pas un métier à part, quelque part au loin. C'est comprendre ce que fait vraiment le code que tu exécutes. Ce qui se passe quand tu lances npm install. Ce qu'est un conteneur et pourquoi il n'isole pas toujours comme tu le crois. Où sont stockés les tokens et pourquoi un cookie de session vaut plus qu'un mot de passe.

Ce sont les fondamentaux. Aucune IA ne peut les remplacer : elle t'écrira un Dockerfile en une seconde, mais décider si tu peux faire confiance au repo d'un « recruteur », ça reste ton boulot.

Où apprendre tout ça

Pour lire ce genre d'histoire comme une chaîne d'étapes claire plutôt que comme de la magie, il te faut les fondamentaux.

Dans le cours Docker, tu construis des conteneurs de tes propres mains et tu comprends ce qu'ils isolent et ce qu'ils n'isolent pas. Python et Java te donnent une vraie compréhension du fonctionnement du code que tu lances, y compris celui qui arrive dans un fichier zip envoyé par ton « recruteur de rêve ». Et Web t'explique comment fonctionnent ces fameux packages npm et le JavaScript côté front.

Et si tu prépares des entretiens en ce moment (des vrais, pas la version nord-coréenne), on décortique ce qu'on demande vraiment en entretien Java en 2026 dans notre guide des questions d'entretien Java.

Il suffit aux hackers d'une seule personne négligente avec des accès. Fais en sorte que ce ne soit pas toi.

FAQ sur le piratage de Binance

Que s'est-il passé lors du piratage de Binance en octobre 2026 ? Le 29 octobre 2026, environ 6,3 milliards de dollars ont été volés dans les hot wallets de Binance sur dix blockchains, ce qui en fait le plus gros vol de l'histoire de la crypto. Selon le récit préliminaire de l'exchange, l'attaque a commencé par le PC portable compromis d'un ingénieur DevOps, que l'attaquant a utilisé pour atteindre un service interne et soumettre des demandes de retrait non autorisées.

Qui a piraté Binance ? Selon le FBI, l'attaque a été menée par le groupe nord-coréen TraderTraitor, aussi connu sous les noms de Lazarus Group, Jade Sleet et APT38. Les analystes de TRM Labs et de Chainalysis sont arrivés à la même conclusion. Le même groupe était derrière le piratage de Bybit à 1,5 milliard de dollars en 2025.

Les utilisateurs de Binance sont-ils touchés par le piratage ? Binance a promis de tout couvrir elle-même, avec son fonds d'assurance SAFU et ses fonds propres, sans répercuter les pertes sur les clients. Environ 3 milliards de dollars ont été gelés avec l'aide des émetteurs de stablecoins. Au 1er novembre, l'exchange annonçait une réouverture progressive des retraits.

Qu'est-ce que EIP-7702 ? C'est un mécanisme d'Ethereum introduit en mai 2025 qui permet à un wallet ordinaire de confier le contrôle de ses opérations au code d'un smart contract. Lors du piratage de Binance, il a servi à faire exécuter au hot wallet de l'exchange le code de l'attaquant et à lui transférer même les nouveaux fonds entrants.

Comment repérer le test technique d'un faux recruteur ? Méfie-toi si le salaire est nettement au-dessus du marché, si le process est étrangement rapide, si le test doit être exécuté plutôt qu'écrit, ou si on te demande d'installer une application spéciale pour l'appel. N'exécute le code de quelqu'un d'autre que dans une machine virtuelle ou un conteneur, jamais sur ton PC portable professionnel, et vérifie d'abord les scripts d'installation.

Un agent IA de code peut-il lancer un malware caché dans un test technique ? Oui. Si un agent exécute des commandes comme npm install dans un repo inconnu, les scripts d'installation malveillants se déclencheront exactement comme si un humain les avait lancés. C'est pour ça qu'il ne faut laisser un agent travailler sur le code de quelqu'un d'autre que dans un environnement isolé.