Hot Tracking 036 | Un faux entretien ouvre Binance, 6,3 Md$ volés

Quel s’est passé

Selon le rapport sur l’incident avec Binance (transmis par The Register), la chaîne d’attaque se divise en cinq étapes :

1. L’alerte de juin. Un ingénieur de Binance a téléchargé un paquet Homebrew malveillant, ce qui constitue une attaque de chaîne d’approvisionnement. L’équipe de sécurité l’a détecté, et les équipements ont été remplacés, les identifiants affectés ont été renouvelés. Cependant, selon Binance, les informations sur le rôle du ingénieur A et ses collègues de l’équipe d’infrastructure de la carte de paiement ont été exposées aux hackers.

2. Les entretiens de septembre. Un autre ingénieur a été contacté sur un site de recrutement officiel par une personne prétendant être le directeur de projet, qui a organisé une série d’entretiens. Lors du premier entretien vidéo, le faux RH a partagé avec l’ingénieur une compte sur les réseaux sociaux, utilisant des photos et des vidéos personnelles pour gagner sa confiance. Binance rapporte que cette méthode de social engineering était plus sophistiquée et trompeuse que celles vues précédemment. Le deuxième entretien a été mené par un faux PDG sur une application de chat social populaire, avec l’ingénieur invité à télécharger un « travail », un répertoire contenant du code malveillant. Ce travail a été exécuté sur son ordinateur de travail.

3. Que font les scripts malveillants. Pendant le processus de setup du « travail », le répertoire contenant le code Homebrew a remplacé pyenv 2.8.0 par une version malveillante : d’abord, pyenv_ (3 414 octets) a été écrit, puis pyenv légitime (3 344 octets) a été supprimé, la version malveillante a été renommée pour remplacer celle-ci, et enfin /opt/homebrew/bin/pyenv a été supprimé, le lien symbolique a été reconstruit et zsh a été lancé. Binance indique que les outils de sécurité des endpoints n’ont pas détecté immédiatement ce logiciel malveillant, et les attaquants ont également adopté des mesures pour cacher les scripts et éviter les détecteurs.

4. Le déploiement horizontal le 20 octobre. Les attaquants ont utilisé cet ordinateur contrôlé, ainsi que l’outil AI interne de Binance, pour obtenir le droit d’accès aux ordinateurs de l’ingénieur DevOps A et d’un autre ingénieur de logiciels de carte de paiement C.

5. Le déroulement le 29 octobre. Les attaquants ont accédé à l’ordinateur de l’ingénieur C, utilisant les droits de déploiement des containers de l’ingénieur A pour déployer des tokens, déclenchant ainsi des scripts visant à voler de l’argent.

Le rapport liste cinq aspects de l’attaque : les entretiens de septembre utilisant des techniques de social engineering, le téléchargement malveillant, l’outil AI interne malveillant, la prise en charge des endpoints, ainsi qu’une méthode avancée d’autorisation des transactions (la mise en œuvre n’a pas été détaillée). Binance est catégorique : il s’agit d’une action complexe en plusieurs étapes, ni une intrusion ponctuelle, ni une simple fraude.

L’alerte de juin n’a pas fermé la porte d’octobre

Les critiques ne soulignent pas que c’est le hackeur qui est trop rusé, mais plutôt qu’il s’agit d’une vérification des procédures, visant à détecter les points faibles dans le processus.

Premièrement, une détection réussie ne signifie pas que la situation a été résolue. Le paquet malveillant a été détecté en juin, les équipements ont été remplacés, les identifiants ont été renouvelés, les actions ont été effectuées, mais le point le plus crucial n’a pas été pris en compte : la surface d’exposition n’a pas été éliminée. L’ennemi connaissait déjà qui était l’ingénieur A, quel était son poste, et qui faisait partie de l’équipe. Ce qui a été détecté était une intrusion au niveau des fichiers, mais ce qui a été révélé étaient les informations sur les relations organisationnelles. Le déploiement horizontal quatre mois plus tard s’est déroulé en suivant cette voie. Si l’on se base sur la condition « le logiciel malveillant a été éliminé », juin est considéré comme satisfaisant ; si l’on se base sur la condition « ce que l’ennemi a obtenu est annulé », alors cette résolution n’a pas été complétée.

Deuxièmement, personne ne s’oppose à l’utilisation de code inconnu sur l’ordinateur de travail. Les ingénieurs ont exécuté des tâches personnelles pour le recrutement en utilisant l’équipement de l’entreprise, et les outils de point de contrôle n’ont pas détecté et remplacé les scripts de pyenv. Les commentaires se divisent en deux camps : d’un côté, on est choqué par le fait que les ingénieurs utilisent leur ordinateur de travail pour des tâches personnelles de recrutement ; de l’autre, on se demande quelle sorte de chose étrange c’est, car de nombreux collègues font des choses sans rapport au travail. Ce comportement est courant, et il ne faut pas construire une ligne de défense sur la conscience individuelle. Les limites du BYOD et les droits d’accès minimal sont des problèmes anciens, et l’amende de cette fois est d’environ 6,3 milliards de dollars.

Troisièmement, les outils d’IA internes sont devenus une nouvelle cible pour les attaques. Les attaquants ont utilisé les outils d’IA internes de Binance pour accéder aux ordinateurs des deux ingénieurs des portefeuilles. Dans le réseau interne de l’entreprise, les outils d’IA sont de nouveaux membres ayant un niveau de droits très élevé, et la voie d’attaque n’a peut-être pas été prévue dans les modèles de menaces traditionnels.

Quatrièmement, les plateformes de recrutement ont externalisé le coût de l’authentification des identités à chaque postulant. Des recruteurs imposteurs ont fonctionné sur les plateformes de recrutement officielles pendant plusieurs semaines à plusieurs mois, entrant en contact en septembre et réussissant leur mission en octobre, jusqu’à ce que l’incident devienne évident. Plusieurs commentaires sur HN indiquent que les plaintes des recruteurs imposteurs sur LinkedIn n’ont pas reçu de réponse (selon les déclarations des commentateurs). Si la plateforme ne vérifie pas les personnes qui entrent, chaque utilisateur doit alors se charger de vérifier ceux qui s’approchent.

Cinquièmement, la mécanisation du processus de recrutement a engendré cette escroquerie. Les entretiens avec des personnes réelles sont devenus rares, et les postulants ont perdu leur vigilance envers les « vrais » personnes qui se présentent volontairement. Les escrocs n’ont pas brisé la ligne de défense, mais ils sont entrés par les portes laissées ouvertes par elle-même.

Les déclarations des différentes parties ne concordent pas

Les montants sont présentés séparément : le FBI et The Register indiquent 6,3 milliards de dollars ; TRM Labs indique 6,36 milliards, dont la majeure partie a été transférée en environ 20 minutes ; Elliptic indique près de 6,43 milliards, et a confirmé que 2,85 milliards de dollars de fonds volés ont été gelés ou saisis. Les chiffres des différentes agences ne concordent pas, et cet article ne prend pas de valeur précise comme conclusion.

Toutes les alertes du FBI sont rapportées selon la version officielle : les alertes publient une liste des adresses des portefeuilles concernés, appelant les bourses, les sociétés d’analyse blockchain et les prestataires de services pour les actifs virtuels à intercepter ; les hackers ont commencé à convertir les fonds volés en Ethereum, et les enquêteurs prévoient que les fonds seront transférés via des plateformes DeFi et des services de conversion instantanée, pour augmenter la difficulté de la traçabilité. TRM Labs et Elliptic, deux sociétés d’information blockchain, avaient déjà fait des déclarations similaires avant que le FBI ne prenne position.

Selon l’article du FBI publié par The Register, les retraits des clients concernés par l’attaque par Binance ont été rétablis, et la bourse a déclaré avoir compensé environ 95 % des fonds volés, le reste étant difficile à compenser en raison de la faible liquidité ; le co-CEO Richard Teng a promis que les clients ne subiraient pas de pertes. L’épigraphe de l’article indique que pendant que la bourse complétait urgentement les fonds, les clients ont retiré des dizaines de milliards de dollars. Tout cela est conforme à la version officielle de l’article.

Les actions effectuées après l’incident par Binance sont rapportées dans le rapport : reconstruction du système de portefeuilles attaqué et des outils d’IA internes ; remplacement de tous les équipements affectés ; annulation de toutes les identifications et tokens des ingénieurs concernés ; coopération avec les autorités, les sociétés d’information blockchain et les chercheurs en sécurité pour traquer et geler les actifs ; embauche d’experts indépendants en sécurité informatique pour l’évaluation ; annonce de la création d’un fonds de recherche en sécurité, axé sur la sécurité des AI dans le environnement blockchain. Le rapport mentionne ce qui a été fait, mais il n’y a pas de réponses aux deux questions clés : pourquoi les mesures prises en juin n’ont-elles pas couvert la vulnérabilité de l’organisation, et quel est le modèle de droits des outils d’IA internes.

Qu’en dit la section des commentaires

Plus de 300 commentaires sur HN, dont les positions les plus populaires sont résumées en cinq points :

I. La réflexion structurelle sur l’écosystème de recrutement occupe la première place. Le commentaire le plus apprécié affirme que la véritable tristesse réside dans le fait que les candidats aspirent tellement à un entretien en personne qu’ils abandonnent la bonne logique ; les employeurs se plaignent de ne pas pouvoir recruter et de rencontrer des candidats escrocs, mais c’est leur propre faute : ils alourdissent les processus, trient avec avidité, transformant le contact humain en une ressource rare. Certains ironisent : les entreprises technologiques font en sorte que les candidats doivent passer par diverses étapes automatisées avant de pouvoir voir un interlocuteur en personne, et voilà le résultat. D’autres se remémorent comment dans les années 90, à Manhattan, on leur demandait d’abord de passer un test écrit avant de pouvoir passer à l’entretien, et ils refusaient tout de suite.

II. Les rancunes accumulées sur les plateformes de recherche de emploi. Certains racontent avoir affiché leur recherche d’emploi sur LinkedIn pour être contactés par plusieurs entreprises fictives qui proposaient des entretiens fictifs, et après s’être inscrit à une entreprise consultative, ils ont reçu des publicités inappropriées. Un autre dit qu’un usurpateur a longtemps trompé en se faisant passer pour un recruteur de son entreprise, et après avoir signalé des centaines de fois sans réponse, il a finalement rencontré un employé de LinkedIn lors d’une soirée et obtenu une identification par l’intermédiaire interne. Un autre commentateur est encore plus dur : LinkedIn est un terrain vague, et le personnel dirigeant de Microsoft a probablement oublié qu’il possède cette plateforme. Tous ces commentaires proviennent des auteurs du texte.

III. La controverse sur les limites de l’ordinateur de travail. Certains se demandent comment les ingénieurs utilisent leur ordinateur de travail pour effectuer des tâches de recherche d’emploi personnelles ; d’autres répondent que cela n’a rien d’étrange ; d’autres encore proposent une solution technique : ces tâches devraient au moins être exécutées dans des containers Docker, et il faut contrôler les accès à Internet et le montage de disques.

IV. Ironie et blagues. Certains disent que si cette tâche était un test pour un poste de sécurité, l’ironie serait maximale.

V. Le changement dans les actions de sécurité des entreprises. Certains ont remarqué que plusieurs entreprises transfèrent leurs ressources de gestion de la sécurité pour examiner les candidats, sous prétexte que le monde extérieur est dangereux.

Trois choses que les utilisateurs ordinaires peuvent faire

1. Exécuter les tâches d’entretien uniquement dans un environnement isolé. Toute demande de téléchargement de questions de test, de dépôts de code ou d’outils de test ne doit pas être considérée comme une entrée crédible : exécutez-les dans des machines virtuelles ou des containers, contrôlez les accès à Internet et le montage de disques, puis détruisez l’environnement une fois terminé ; ne laissez jamais ces tâches sur des ordinateurs contenant des données réelles et des identifiants, surtout pas sur l’ordinateur de travail. La méthode est d’exécuter les tâches une seule fois.

2. Vérifier le recruteur en retour, ne croyez pas aux documents d’identité fournis. Des RH fictifs préparent des comptes sociaux avec photos et vidéos pour gagner en crédibilité, mais cela n’est pas réel. Vérifiez : utilisez le domaine officiel pour trouver le site web ; utilisez l’adresse e-mail ou le numéro de téléphone officiels pour confirmer la personne responsable du recrutement ; recherchez le nom de l’entreprise avec des mots-clés pour fraudes pour voir les exemples précédents ; plus le recruteur insiste pour que vous téléchargez les tâches, plus il faut s’arrêter.

3. Déconnecter la recherche d’emploi personnelle du matériel de l’entreprise, et faire intégrer les outils AI dans l’audit des droits d’accès. Candidats : les entretiens personnels et les tâches personnelles ne doivent pas utiliser le matériel de l’entreprise, c’est une règle fondamentale, pas un caprice. Gestionnaires : inscrivez « exécution de code externe sur le matériel de l’entreprise » dans les stratégies d’isolement et d’approbation ; évaluer les droits des outils AI internes et les surveiller par niveau. Cette évolution horizontale suit cette voie qui n’a pas été prise en compte dans les modèles de menace.

Conclusion

Déclaration de mesure : Ce texte ne fait aucune supposition ni n’accuse personne. Le rapport complet sur l’incident de Binance n’a pas été vérifié indépendamment, les détails de la chaîne d’attaque sont tous transmis par The Register, et le texte est marqué selon les déclarations des parties concernées ; les conclusions du FBI comme étant des alertes officielles sont transmises sans citation ni interprétation ; les montants indiqués correspondent aux chiffres communiqués par chaque institution ; les identifications des plateformes de recrutement dans la section des commentaires correspondent aux dires des commentateurs. Seuls trois points peuvent être confirmés : chaque timeline a sa source ; les montants indiqués par chaque institution sont effectivement différents ; le rapport mentionne cinq aspects d’attaque, qui sont considérés comme reconnus par la bourse. La vraie question pour l’industrie concerne deux points : le processus de recrutement transforme les contacts réels en biens rares, ce qui permet aux escroqueries de s’infiltrer à travers cette rareté ; les procédures de sécurité interne traitent l’alerte de juin comme un incident unique, plutôt que comme une exposition qui a duré jusqu’en octobre.

Nous surveillons deux points clés : premièrement, la destination des fonds illicites. Le FBI a publié la liste des adresses des portefeuilles concernés, les hackers ont commencé à convertir en Ethereum, et le montant bloqué et confisqué confirmé par Elliptic s’élève à 2,85 milliards de dollars. Tout progrès significatif dans la blanchiment ou la localisation des fonds sera suivi dans cette rubrique ; deuxièmement, les mesures prises par Binance : les conclusions des experts indépendants, les détails concrets des fonds de recherche en sécurité, si l’un de ces éléments est publié, la version 2 sera lancée. La fenêtre de 48 heures se ferme autour de 14:09Z le 6 novembre, et toute action dans cette période entraînera une mise à jour de la version 2.

Sources de référence

• The Register, article détaillé (2026-11-03, Jessica Lyons ; fichier local ev1105-register-text.txt. La chaîne d’attaque en cinq étapes, le script de remplacement pyenv, et les cinq aspects d’attaque sont tous transmis par cet article du rapport de Binance, selon ses propres déclarations).
• The Register, article sur l’attribution par le FBI (2026-11-02, Carly Page ; fichier local ev1105-fbi-text.txt. Les alertes du FBI sont des transcriptions des déclarations officielles ; les données bloquées de TRM Labs à 6,36 milliards, d’Elliptic à 6,43 milliards et 2,85 milliards sont citées par cet article ; Binance a rétabli les retraits, complétant environ 95 %, et les PDG conjoints ont promis de suivre les déclarations de cet article).
• Rapport sur l’incident de Binance (publié le 2026-11-03 sur le blog de binance.com ; le texte n’a pas été vérifié indépendamment : la section “Naked Grab” est vide, l’agent 401, aucun archive sur Wayback ; tous les détails de ce texte ont été transmis par The Register, sans mise à jour des déclarations).
• Hacker News story 50365755 (publié le 2026-11-04T14:09Z ; Algolia snapshot 545▲/327💬, les chiffres continuent d’augmenter, le texte utilise plus de 500▲ de déclarations ; 60 commentaires localement enregistrés dans ev1105-hn-nkbinance.json, tous cités entre guillemets).

Signé : Yongliang