L’attaque contre Binance a commencé par… une publicité malveillante dans Google Search. Un ingé piégé par une pub search malveillante… En juin 2026, un ingénieur DevOps voulait installer un outil de codage IA sur son Mac.

En cliquant sur le lien publicitaire en question, il s’est retrouvé sur un site invitant à copier-coller un script dans le terminal pour télécharger le gestionnaire de paquets Homebrew. L’exécution du script a ouvert successivement plusieurs pop-up. La première recommandait de mettre à jour les paramètres système pour lancer l’application et présentait un champ de saisie du mot de passe.

La deuxième demandait de donner au terminal l’autorisation de contrôler le Finder. La troisième annonçait un échec : « Votre Mac ne gère pas cette application. » Pendant ce temps, l’infostealer MacSync collectait des informations, zippées dans le dossier /tmp avant envoi au serveur C2. Lire aussi : Binance piraté : ce qu'on sait sur l'origine de l'attaque et ses conséquences Avant que Binance repère l’anomalie et y remédie (remplacement de l’appareil et des identifiants), l’attaquant a pu cartographier le rôle de l’ingénieur et identifier ses collègues. … et un autre par une fausse offre d’emploi La deuxième phase a eu lieu en septembre.

Un autre ingénieur de Binance a été contacté sur un réseau professionnel par un faux directeur de projet. Celui-ci a organisé un entretien vidéo avec un prétendu responsable RH. Qui, pour créer de la confiance, a partagé un compte de réseau social avec photos et vidéos « personnelles ».

Un deuxième entretien s’est déroulé via une application de messagerie, soi-disant avec le P-DG. L’ingénieur s’est vu soumettre un « exercice technique ». Dans ce cadre, il a téléchargé, sur sa machine professionnelle, un dépôt de code piégé.

Le malware qui s’y trouvait a remplacé un composant légitime de Homebrew (pyenv), installé un lien symbolique, ouvert un shell zsh et établi une communication C2, sans que l’EDR émette d’alerte. Un troisième poste compromis pour siphonner les cryptos Ce poste de travail a servi, le 20 octobre, à compromettre la machine du premier ingénieur en passant par un outil d’IA interne. L’attaquant y a récupéré un jeton d’autorisation de déploiement de conteneurs.

Le 29 octobre, il a utilisé ce jeton sur le poste d'un troisième ingénieur, utilisé pour déclencher le script d'exfiltration de fonds. Il était environ 21 heures en France quand un premier hot wallet a envoyé quelque 233 millions de Ripple (XRP). Ont suivi près d'un million de Solana (SOL) et environ 44 millions d'Optimism (OP).

Binance a finalement reçu une alerte de volumes de transfert anormaux. L'attaque ne s'est pas pour autant arrêtée. Un autre portefeuille a, par exemple, transféré 18 270 bitcoins (BTC).

Pour établir une forme de persistance, l'attaquant a détourné un mécanisme d'Ethereum : l'EIP-7702, qui permet d'accorder à un smart contract des droits d'exécution sur un wallet sans divulguer la clé privée. Il a utilisé soumis 50 transactions de signature pour manipuler le nonce et verrouiller les autorisations sur la blockchain. Ces autorisations étaient indépendantes de l'infrastructure de retrait « normale » de Binance.

Les révoquer était d'autant plus complexe que le portefeuille concerné utilisait un système de signature multipartite. Il n'existait donc pas de clé unique utilisable immédiatement. Le dernier mouvement non autorisé (2960 ETH et quelques) a eu lieu à 0 h 56 le 30 octobre.

Il s'agissait d'une transaction déjà diffusée. Elle était en attente dans le mempool. La révocation de la délégation est intervenue à 1 h 10, par signature d'une nouvelle autorisation vers l'adresse zéro.

Illustration générée par IA