Le SMS de code de vérification Binance qui utilise un vrai lien Binance

Revérification à 30 jours — enregistrements bruts

Vérifié le 2026-09-29. Les deux serveurs WHOIS de ces domaines ne disent pas la même chose, et cet écart est précisément la correction ci-dessus.

Le WHOIS du registraire renvoie un seul mot et aucun enregistrement. Voici l'intégralité du corps de réponse de whois.ownregistrar.com pour chacun des trois :

Terminated

Aucun champ, aucun code de statut, rien de conforme à la RFC. « Terminated » relève du vocabulaire produit d'OwnRegistrar, pas d'un état du registre — un tel statut EPP n'existe pas. Nous l'avons cité comme s'il décrivait le registre, ce qu'il ne fait pas.

Le WHOIS du registre renvoie le véritable enregistrement. Depuis whois.verisign-grs.com, de forme identique pour les trois :

Domain Name: COM73184.COM
Registrar: OwnRegistrar, Inc.          Registrar IANA ID: 1250
Registrar Abuse Contact: abuse@ownregistrar.com  +1.2124016235
Creation Date:      2026-08-21T21:45:28Z
Updated Date:       2026-08-26T09:10:06Z
Registry Expiry:    2027-08-21T21:45:28Z
Domain Status: clientDeleteProhibited
Domain Status: clientHold
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Domain Status: clientUpdateProhibited
Name Server: A.DNSPOD.COM
Name Server: C.DNSPOD.COM
DNSSEC: unsigned

cdn378129.com   créé 2026-08-20T13:31:11Z   expire 2027-08-20T13:31:11Z   modifié 2026-08-26T09:10:06Z
bnbshort.com    créé 2026-08-22T08:14:03Z   expire 2027-08-22T08:14:03Z   modifié 2026-08-26T09:10:05Z
com73184.com    créé 2026-08-21T21:45:28Z   expire 2027-08-21T21:45:28Z   modifié 2026-08-26T09:10:06Z

Trois choses découlent de cet enregistrement, que « résilié » masquait.

clientHold est la raison de l'absence de DNS. La délégation est intacte — les deux serveurs de noms DNSPod figurent toujours dans l'enregistrement. Le registraire a retiré le domaine de la zone plutôt que de supprimer l'enregistrement : la résolution échoue donc tandis que l'enregistrement lui-même se poursuit. Il est à un changement de statut de résoudre à nouveau. L'opérateur ne peut pas opérer ce changement : clientUpdateProhibited et clientTransferProhibited l'excluent de ses propres domaines.

La suspension est délibérément taillée pour survivre à la campagne. clientRenewProhibited et clientDeleteProhibited signifient qu'ils ne peuvent être ni renouvelés ni libérés par anticipation : ils restent gelés jusqu'à l'expiration, puis tombent. Les supprimer aurait été la mesure la plus faible, car un nom supprimé revient au pool disponible en environ 75 jours. Gelés jusqu'à l'expiration, ces trois-là sont hors marché jusqu'aux 20–22 août 2027. Celui qui a décidé cela a choisi l'option la plus forte.

L'action a eu lieu quatre jours avant notre vérification. Les trois valeurs Updated Date tiennent dans une seconde — 09:10:05 et 09:10:06 UTC le 2026-08-26. Nous avons daté le résultat du 30 août en laissant entendre que c'était le moment des faits. C'était en réalité scripté, appliqué aux trois d'un coup, et déjà vieux de quatre jours quand nous avons regardé.

Ce qui reste non résolu

Le Mini Program appId xoqXxUSMRccLCrZNRebmzj — le composant qui a survécu à tous les domaines, et la raison pour laquelle cet article porte sur un mécanisme et non sur trois adresses. Les deux pages mp-cms nommées dans les indicateurs répondent HTTP 202 à toute requête non authentifiée, ce qui est une protection anti-robot et non une page. Son activité n'est observable que depuis une application Binance connectée ; nous ne pouvons donc affirmer ni l'un ni l'autre quant à la fermeture de ce chemin. Trente jours après, cela reste la question ouverte — et c'est celle qui compte.

Un utilisateur nous a transféré deux messages texte arrivés à quelques heures d’intervalle. Tous deux ressemblaient à une alerte de sécurité de Binance. Tous deux contenaient un lien sur un domaine qui appartient réellement et incontestablement à Binance.

Nous avons démonté la chaîne. Ce qui se trouve au bout n’est pas une fausse page de connexion. C’est un script qui, s’il vous atteint dans l’application Binance alors que vous êtes connecté, rachète votre épargne, convertit en Bitcoin chaque solde que vous détenez et dépose une demande de retrait vers une adresse codée en dur par l’attaquant. Il ne vous demande jamais de mot de passe, de code ni de phrase de récupération, car il n’en a besoin d’aucun.

Cet article documente toute la chaîne, car le conseil habituel — « vérifiez le domaine » — ne vous protège pas ici. Le domaine est réel.

Les messages

Ce sont les deux premiers. Deux autres sont arrivés trente-six heures plus tard, depuis le même Binance Mini Program, après la rédaction de tout ce qui suit — ils figurent dans Il est revenu, et rien n’avait changé.

Deux éléments méritent déjà d’être relevés.

Les codes sont différents — 780641 et 366812 — mais le lien est identique. Un véritable code à usage unique est lié à une véritable demande. Ceux-ci sont décoratifs, générés à chaque envoi pour que le message ressemble à quelque chose que vous avez déjà reçu.

Le deuxième message est rédigé en cantonais familier, et non en chinois écrit standard. Quelqu’un l’a délibérément localisé pour les lecteurs de Hong Kong. Nous y reviendrons, car la charge utile elle-même est aussi localisée, ce qui nous indique le public visé par la campagne.

Pourquoi « vérifier le domaine » échoue

La personne qui nous l’a signalé connaît bien le DNS et l’infrastructure des domaines, et a bien failli cliquer. C’est ce qu’il faut prendre au sérieux : elle a effectué les bonnes vérifications, et elles ont toutes réussi :

• L’hôte est s.binance.com. Il s’agit d’un sous-domaine de binance.com, le domaine enregistrable authentique.
• Il ne s’agit pas d’un homographe de domaine internationalisé. Chaque caractère est en ASCII simple. Comparée lettre par lettre, la chaîne est bien la vraie.
• Le WHOIS de binance.com renvoie l’enregistrement de Binance. Aucun registraire ressemblant, aucune date de création récente, rien d’anormal.
• La connexion TLS se termine sur un certificat valide. Le cadenas est réel.

Tout cela est vrai, et rien de cela n’aide, car l’attaquant n’a jamais eu besoin de contrôler un domaine Binance. s.binance.com est le propre raccourcisseur de liens de Binance. L’attaquant a placé sa charge utile ailleurs et s’est servi de l’infrastructure de Binance pour pointer vers elle.

Comparez-le à la version que vous pouvez repérer

Voici le même prétexte sous sa forme ordinaire — un autre message qui nous a été signalé, et la forme que prennent encore la plupart de ces campagnes :

Celui-là est repérable. La chaîne binance.com se trouve bien dans le lien, mais elle est placée avant un signe arobase, et dans une URL, tout ce qui se trouve entre le schéma et le @ constitue des identifiants, pas un nom d’hôte. Un navigateur l’interprète ainsi : se connecter à l’hôte 0691[.]app, en présentant le nom d’utilisateur « binance.com ». La véritable destination est un domaine jetable à quatre chiffres. La marque sert de leurre dans le champ du nom d’utilisateur.

Quiconque connaît cette règle le repère en une seconde. De nombreux clients de messagerie et de courrier signalent ou réécrivent désormais directement ce motif. C’est de l’obscurcissement, et l’obscurcissement peut s’enseigner, se détecter et se filtrer. Il échoue également précisément face à la personne qui a signalé ces deux messages.

Le message s.binance.com relève d’une autre catégorie de problème et doit être traité comme tel. Rien n’y est dissimulé :

• Aucune astuce avec l’arobase. L’hôte est bien l’hôte.
• Aucun homographe, aucun punycode, aucun sosie en caractères cyrilliques.
• Aucune faute d’orthographe dans la chaîne visible.
• Aucun registraire suspect, aucun domaine récent, aucun certificat autosigné.
• Rien sur quoi un filtre de liens puisse se fonder, car il s’agit d’un lien qu’un utilisateur légitime de Binance pourrait réellement vous envoyer.

Il n’imite pas la crédibilité de Binance. Il emprunte la vraie — le domaine, le certificat, le transfert vers l’application et l’interface qui affiche les mots « Protégez votre compte ». La tromperie ne commence qu’une fois que vous êtes déjà dans l’application, lorsqu’il ne reste plus de barre d’adresse à inspecter.

C’est pourquoi celui-ci mérite un article et le premier non. La connaissance suffit à déjouer le message avec l’arobase. Elle ne suffit pas ici, car chaque vérification que vous savez effectuer renvoie « authentique » — et tout est authentique jusqu’au moment où une application de confiance confie son canal de requêtes à un domaine enregistré le matin même.

La chaîne, décodée

Le lien court répond par une simple redirection HTTP :

HTTP/2 302
location: https://app.binance.com/en/mp-cms/app/3cb3235
          ?_dp=<base64>
          &description=Protect+Your+Account
          &title=Binance
          &utm_campaign=app_mini_program_share_link
          &utm_source=mini_program

Toujours Binance. Toujours authentique. Les éléments intéressants sont les balises de campagne : app_mini_program_share_link et mini_program. Il s’agit d’un lien de partage Binance Mini Program — l’artefact obtenu lorsque vous partagez une mini-application depuis l’application Binance. Rien n’a été piraté. L’attaquant a publié ou détourné un Mini Program et utilisé la fonction de partage comme elle a été conçue.

Remarquez également description=Protect Your Account. La phrase d’ingénierie sociale voyage dans l’URL ; c’est donc l’interface de Binance elle-même qui affiche ces mots rassurants.

Le paramètre _dp est en base64. Une fois décodé :

bnc://app.binance.com/mp/app
    ?appId=xoqXxUSMRccLCrZNRebmzj
    &startPagePath=L3BhZ2VzL2Jyb3dzZXIvaW5kZXg
    &startPageQuery=<base64>
    &sceneValue=1300

bnc:// est le schéma d’URL personnalisé de l’application Binance. Sur un téléphone où l’application est installée, il transmet la demande à l’application au lieu d’ouvrir un onglet de navigateur.

startPagePath est de nouveau en base64 et se décode en /pages/browser/index — la page de navigateur intégrée à l’application du Mini Program. Le lien profond demande donc à l’application Binance d’ouvrir ce Mini Program et d’accéder à son écran de navigateur. L’adresse à charger est encodée en base64 une troisième fois, dans startPageQuery :

url=https%3A%2F%2Faccounts.authenticated.binancc.cdn378129.com%2Fauth8%2F

La voici. Lisez attentivement l’hôte :

accounts . authenticated . binancc . cdn378129 . com
└──────────── decoration ────────────┘ └── real ──┘

Le domaine enregistrable est cdn378129[.]com. Tout ce qui se trouve à sa gauche est du texte libre choisi par l’attaquant — y compris binancc, avec deux c, qui n’est pas tant une faute de frappe dans la marque qu’une quasi-correspondance délibérée qui résiste à un coup d’œil. Sur un téléphone, dans une webview, la majeure partie de cette chaîne est de toute façon hors écran.

Le domaine malveillant n’est donc jamais visible dans le message. Il est en base64 dans un paramètre de requête, lui-même dans une autre charge utile en base64, à l’intérieur d’une URL Binance authentique, derrière un raccourcisseur Binance authentique.

L’infrastructure n’a que quelques heures

Registres publics, vérifiés pendant la rédaction :

• cdn378129[.]com a été enregistré à 13:31 UTC le 20 août 2026, auprès d’OwnRegistrar, Inc., avec le DNS délégué à DNSPod.
• Son certificat Let's Encrypt porte un notBefore fixé à 12:35 UTC le même jour. Let's Encrypt antidate ce champ d’environ une heure, de sorte que l’émission a eu lieu approximativement quatre minutes après l’enregistrement. Le certificat couvre ce seul nom d’hôte et rien d’autre.
• L’hôte se résout vers 107.189.17.50, dans une plage attribuée à RouterHosting LLC au sein de FranTech Solutions.
• Le domaine n’est pas signé — pas de DNSSEC.

Un domaine enregistrable vieux de moins d’un jour, un certificat créé quelques minutes après, et un nom d’hôte à usage unique. Rien de cela n’est visible depuis le SMS, et rien de cela n’est visible non plus depuis s.binance.com — ce qui est précisément le but du passage par le raccourcisseur.

Ce que la page fait réellement

Nous avons récupéré le point de terminaison dans un bac à sable isolé, sans l’exécuter. La première surprise est ce qui ne s’y trouve pas :

• Aucun formulaire. Pas un seul élément <form>.
• Aucun champ de saisie. Pas un seul <input>.
• Aucune demande de mot de passe, aucune demande de code à usage unique, aucune demande de phrase de récupération, aucun bouton de connexion de portefeuille.

Tous les réflexes qu’on a appris aux gens — ne saisissez pas votre mot de passe sur une page étrange, ne saisissez jamais votre phrase de récupération, regardez ce que vous signez — ne servent à rien ici, car la page ne vous demande jamais quoi que ce soit.

Elle contient à la place un script obscurci dont la configuration apparaît en clair au début :

var WITHDRAW_COIN     = "BTC";
var ATTACKER_ADDRESS  = "bc1qnwhg6za5m0adlny6t4xx6qa2heyrntsvk8pw4f";
var WITHDRAW_NETWORK  = "BTC";
var FEE_RESERVE       = 0.00007;
var MIN_COIN_AMOUNT   = 0.01;

Et les messages d’erreur que l’obscurcateur n’a pas réussi à masquer nomment directement le mécanisme :

"bridge interface not found (window.bn.miniProgram missing)"
"bridge did not appear within "
"bridge request timed out after 10s"

window.bn.miniProgram est le pont JavaScript que l’application Binance injecte dans les webviews des Mini Programs. Le script attend qu’il apparaisse, puis envoie ses requêtes par son intermédiaire. C’est toute l’astuce : il n’a pas besoin de vos identifiants et n’a pas besoin de contourner la politique de même origine, car l’application remet un canal de requêtes de confiance à toute page affichée par le navigateur du Mini Program — et on a demandé à ce navigateur d’afficher la page de l’attaquant.

Le pipeline de retrait

La récupération de la table de chaînes révèle les points de terminaison privés de Binance appelés par la charge utile, dans l’ordre où la logique les utilise :

1. /bapi/accounts/v1/private/account/get-user-base-info — identifier la victime. La page vous accueille par votre nom : « Bienvenue, … ».
2. /bapi/kyc/v2/private/certificate/user-kyc/get-current-kyc-status-lite — vérifier le statut de vérification, car les retraits en dépendent.
3. /bapi/asset/v3/private/asset-service/asset/get-wallet-asset — énumérer chaque solde du compte.
4. /bapi/earn/v1/private/lending/daily/redeem — racheter l’épargne flexible, afin que l’argent qui produit un rendement devienne disponible.
5. /bapi/margin/v1/private/new-otc/get-quote et …/execute-quote — convertir tous les autres actifs en Bitcoin, en ignorant les soldes inférieurs au minimum et en réservant une petite somme pour les frais.
6. /bapi/capital/v4/private/capital/withdraw/apply — déposer la demande de retrait vers l’adresse codée en dur.

Pendant l’exécution, l’écran affiche une courte suite d’états rassurants, repris du propre balisage de la page :

Chargement de votre compte · Nous recueillons vos informations de manière sécurisée · Bienvenue, … · Vérification de l’autorisation… · Reconnexion à Binance

« Reconnexion à Binance » accomplit beaucoup de choses. Cette phrase explique une pause, explique pourquoi l’application est occupée et vous prépare à attendre une étape d’authentification.

La partie habile, c’est le faux code

Voici ce qu’il nous a fallu un moment pour comprendre. Le faux code de vérification du SMS n’est pas l’appât. Le lien est l’appât. Le code est une inoculation.

Un retrait depuis un véritable compte de plateforme d’échange exige normalement une vraie confirmation — un lien par e-mail, un code d’authentificateur, une approbation push. Cette confirmation est la dernière barrière entre la victime et la perte, et elle est censée être alarmante.

Mais la victime a déjà reçu un code Binance qu’elle n’a pas demandé, et le message lui-même lui a déjà montré à quoi ressemble un code non sollicité. Elle se trouve maintenant dans un flux intitulé « Vérification de l’autorisation » sur un écran qui l’a accueillie par son nom. Lorsque la véritable confirmation arrive, elle n’est pas perçue comme une alarme. Elle paraît être l’étape suivante de la vérification de sécurité que la victime croit effectuer.

Qui est visé

La charge utile embarque une table de traductions comportant exactement deux locales non anglaises : zh et ko. Elle lit navigator.language et se localise. Associée à un leurre rédigé en cantonais de Hong Kong, elle révèle une campagne conçue pour des utilisateurs parlant chinois et coréen, et non une diffusion en anglais qui aurait atteint l’un d’eux par hasard.

L’adresse de destination ne comportait aucune transaction lorsque nous l’avons vérifiée dans deux explorateurs de blocs indépendants — rien de confirmé, et rien en attente dans le mempool non plus. D’après la chaîne, cette adresse n’a encore reçu les fonds d’aucune victime.

Nous avions d’abord trouvé cela encourageant. C’était une lecture erronée, comme nous l’a dit une personne à qui cela est arrivé. Une adresse de paiement vide ne signifie pas que personne n’a été piégé. Elle signifie que l’argent n’a pas atteint la dernière étape. Tout ce qui précède cette étape peut quand même s’être exécuté — et, sur au moins un compte approvisionné, cela s’est produit. Voir Ce qu’une adresse vide dissimule réellement ci-dessous.

Ce que cela signifie en revanche, c’est qu’il reste du temps, raison pour laquelle il faut publier vite plutôt qu’avec soin.

Ce qui vous protège réellement

L’inspection du domaine ne fonctionne pas contre cette attaque. Voici ce qui fonctionne :

• Définissez un code anti-phishing auprès de votre plateforme d’échange, et vérifiez sa présence. Binance vous permet de définir un identifiant qui apparaît dans ses messages authentiques, y compris les SMS. Les messages ci-dessus n’en comportent aucun. Son absence est l’indice, et c’est le plus fiable dont dispose une personne ordinaire.
• Considérez « si vous n’êtes pas à l’origine de ceci, appuyez ici » comme l’attaque, pas comme le remède. Les avis de sécurité légitimes vous demandent d’ouvrir vous-même l’application. L’urgence et le lien constituent la charge utile.
• N’accédez jamais à votre plateforme d’échange depuis un message. Ouvrez l’application depuis votre écran d’accueil. Cette seule habitude déjoue toute cette chaîne, car rien n’y survit si vous ne cliquez pas.
• Définissez une liste blanche d’adresses de retrait. Avec une liste blanche active et un délai pour les nouvelles adresses, un script qui dépose une demande de retrait vers une nouvelle adresse n’a nulle part où l’envoyer.
• Lisez ce que dit réellement une confirmation. Une véritable confirmation de retrait indique une cryptomonnaie, un montant et une adresse de destination. Si un écran vous a dit qu’il « vous reconnectait », ce texte est celui d’un retrait.
• Méfiez-vous d’un lien qui ouvre une application. Un lien qui vous envoie directement dans une application a contourné le navigateur, et avec lui la barre d’adresse et tous les avertissements de navigation sécurisée que vous auriez autrement reçus.

Si vous avez appuyé dessus

1. Ouvrez directement l’application de la plateforme d’échange et vérifiez d’abord l’historique des retraits et les retraits en attente. Annulez tout ce que vous n’avez pas lancé.
2. Vérifiez si des positions d’épargne flexible ont été rachetées et si des soldes ont été convertis en Bitcoin. Les deux opérations ont lieu avant le retrait et constituent donc des alertes plus précoces.
3. Ne vous fiez pas à votre historique de connexion — il paraîtra normal. La charge utile s’exécute dans la session que vous avez déjà ouverte et ne crée donc aucun nouvel événement de connexion. Un compte vidé de cette manière ne montre rien d’inhabituel dans l’activité de connexion au moment des faits.
4. Vérifiez spécifiquement votre historique de conversion, et non votre historique de transactions. Un Convert n’apparaît pas parmi les ordres au comptant. Une personne qui cherche une transaction inexpliquée trouvera une liste vide et conclura qu’il ne s’est rien passé.
5. Révoquez les sessions et appareils actifs, puis changez votre mot de passe et renouvelez l’authentification à deux facteurs.
6. Activez la liste blanche des adresses de retrait.
7. Signalez-le. Binance accepte les signalements d’escroquerie par l’intermédiaire de son centre d’assistance, et un signalement contenant le lien court, l’identifiant du Mini Program et l’adresse de destination permet bien davantage d’agir qu’une capture d’écran.

Indicateurs

Neutralisés et publiés afin que les défenseurs puissent les bloquer et les corréler — pas pour que quiconque les consulte.

WAVE 2 (2026-08-22)
Shorteners     hxxps://s.binance[.]com/DwOKKciE
               hxxps://s.binance[.]com/hOD42AgF
Mini program   appId xoqXxUSMRccLCrZNRebmzj  (mp-cms e3efa5b, scene 1300)
Final host     accounts.authentication.binance.com73184[.]com  /auth-1334/
Registrable    com73184[.]com   registered 2026-08-21 21:45:28 UTC
SOL address    H2RMUS1nhiqtwToUfLzCdUB94rmHrFDzyrnJaNKiMGr2

WAVE 1 (2026-08-20)
Shortener      hxxps://s.binance[.]com/speZiskQ
Mini program   appId xoqXxUSMRccLCrZNRebmzj  (sceneValue 1300)
Deep link      bnc://app.binance.com/mp/app?...startPagePath=/pages/browser/index
Final host     accounts.authenticated.binancc[.]cdn378129[.]com
Path           /auth8/
Registrable    cdn378129[.]com   registered 2026-08-20 13:31 UTC
Registrar      OwnRegistrar, Inc.        DNS: DNSPod
IP             107.189.17.50   (RouterHosting LLC / FranTech Solutions)
TLS            Let's Encrypt, single-SAN, issued same day
BTC address    bc1qnwhg6za5m0adlny6t4xx6qa2heyrntsvk8pw4f

Les preuves ont expiré, et personne ne s’en est aperçu

Environ un jour après l’enregistrement du domaine, nous avons revérifié chaque lien de la chaîne. Tous renvoient désormais des 404s — le lien court comme la charge utile qui se trouvait au bout.

Le premier réflexe est le soulagement. Ce réflexe est erroné, et comprendre pourquoi est la chose la plus utile de cet article.

Rien n’a été démantelé

Regardez ce qui est encore en place :

Domain status     ok            (not clientHold, not serverHold)
WHOIS updated     unchanged since the moment of registration
DNS               still resolves to 107.189.17.50
Web server        nginx still running, still answering
Certificate       still valid, unrevoked, good until November
Payload           gone
BTC address       still zero transactions, mempool included

Une suspension par le registraire modifie le statut du domaine et empêche la résolution du nom. Une suspension par l’hébergeur empêche le serveur de répondre. Rien de cela ne s’est produit. Nous voyons ici un serveur toujours actif, sur un nom qui se résout toujours, muni d’un certificat que quelqu’un continue de payer — mais dont les fichiers ont été supprimés manuellement.

Ce n’est pas un démantèlement. C’est un opérateur qui fait le ménage. Et le fait que le lien de diffusion soit devenu inactif au même moment peut signifier que la plateforme l’a révoqué ou que le même opérateur l’a retiré ; depuis l’extérieur, ces situations sont indiscernables, ce qui constitue en soi le problème.

Aucune partie n’a reconnu quoi que ce soit

Il n’existe aucun numéro de dossier. Aucun avis. Aucune note publiée indiquant qu’un Mini Program a été désactivé, aucune action du registraire, aucune entrée dans une liste de blocage, aucune déclaration de quiconque. Nous n’avons trouvé aucune reconnaissance publique par quelque partie que ce soit du fait que cela s’est même produit.

La campagne n’a donc pas été arrêtée. Elle a été achevée, par la personne qui la menait, selon son calendrier, son infrastructure intacte et sa réputation auprès de tous les registraires et hébergeurs du monde entièrement préservée.

Pourquoi cela rend le signalement presque impossible

Tous les canaux de signalement accessibles au public supposent que le contenu est actif :

• Un classificateur de liste de blocage récupère l’URL pour trancher. Il trouve une page 404 nginx standard et refuse de l’inscrire.
• Le service des abus d’un registraire qui reçoit « ce domaine a servi au phishing » pour une URL qui ne renvoie désormais plus rien clôt le ticket comme contenu supprimé, aucune action requise.
• Le service des abus d’un hébergeur fait de même.

La période pendant laquelle il était possible d’agir sur tout cela s’est refermée alors que l’analyse était encore en cours de rédaction. Ce n’est pas une critique des services des abus — vérifier une attaque active est praticable, en juger une qui est terminée ne l’est pas. C’est la description d’une lacune structurelle : le système de signalement fonctionne plus lentement que l’attaque qu’il est censé détecter.

La preuve est volatile, et c’est toute l’astuce

Voici ce sur quoi il vaut la peine de s’arrêter. Une opération de phishing qui dure vingt-quatre heures produit des preuves dont la durée de conservation est de vingt-quatre heures. L’attaquant n’a pas besoin de détruire quoi que ce soit, de couvrir ses traces ni de déjouer quiconque. Il lui suffit de survivre au délai de signalement — et un domaine qui coûte dix dollars, transformé en arme quatre minutes après son enregistrement, y parvient aisément.

Après cela, la situation devient symétrique et inutile pour tout le monde. Nous ne pouvons rien prouver à un service des abus, car son étape de vérification consiste à récupérer la page. Il ne peut pas vérifier, car il n’y a rien à récupérer. Les destinataires ne peuvent pas la signaler, car le lien dans leur message ne mène désormais nulle part et ressemble à une erreur. Et l’opérateur peut tout recommencer la semaine suivante avec un nouveau domaine et une nouvelle identité de mini program, sans avoir payé aucun prix ni laissé aucune trace.

C’est pourquoi la technique importe et le domaine n’a jamais importé. Rien dans le mécanisme n’a changé. Une page de navigateur de mini program accepte toujours une destination comme paramètre. Le pont reste accessible à tout ce que cette page charge. La fonction de partage continue de créer des liens sur un domaine authentique avec un certificat valide. Un nouvel identifiant et un nom d’hôte dont personne n’a entendu parler permettent de reproduire chaque mot de cet article en un après-midi.

Si l’un d’eux vous parvient

La conséquence pratique : capturez d’abord, signalez ensuite. Ce qui existe pendant la première heure est la seule chose qui existera jamais.

• Avant toute autre chose, faites une capture d’écran du message, y compris de l’expéditeur.
• Si vous en êtes capable, consignez la chaîne de redirections sans la suivre — ne demandez que les en-têtes, depuis une machine sur laquelle l’application n’est pas installée. L’en-tête location du premier saut est l’artefact le plus précieux de toute la chaîne, et le premier à disparaître.
• Ne l’ouvrez pas sur un appareil où l’application est installée. Ce n’est pas un test, c’est l’attaque.
• Notez les heures. L’intervalle entre l’enregistrement d’un domaine et le premier message constitue une preuve à part entière, et il subsiste quand le contenu, lui, a disparu.

Tout ce que nous avons capturé figure dans cet article précisément pour cette raison : la chaîne de requêtes, le lien profond décodé, les points de terminaison appelés par la charge utile et l’adresse vers laquelle elle allait envoyer les fonds. Plus rien ne peut être récupéré. Cet article constitue désormais l’archive, et un compte rendu qui aurait attendu un jour de plus pour obtenir une confirmation plus nette n’aurait plus rien contenu.

Ce qu’une adresse vide dissimule réellement

Le cas d’un compte touché par la première vague nous a depuis été décrit. Ses registres montrent que l’étape de conversion de cette charge utile a effectivement été exécutée. La personne concernée a demandé à rester anonyme, et toute donnée susceptible de l’identifier — soldes, avoirs, adresses, numéros d’ordre — est délibérément absente ci-dessous. Aucune n’est nécessaire. La preuve réside dans la forme des événements, pas dans leur ampleur.

Voici son récit, recoupé avec des mesures que nous avions déjà effectuées indépendamment. Nous ne décrivons pas qui est cette personne, où elle se trouve ni ce qu’elle détenait, et nous ne le ferons pas.

Ce sur quoi nous nous sommes trompés

Nous avions indiqué que l’adresse de paiement ne comportait aucune transaction et en avions déduit que la campagne n’avait pas réussi. Cette déduction ne tient pas. Sur ce compte, l’étape de conversion s’est achevée : la totalité du solde, répartie entre deux portefeuilles distincts, a été convertie en un seul actif par une seule action que le titulaire du compte n’a pas effectuée et dont il n’a aucun souvenir. C’est le retrait qui a échoué — les fonds sont restés sur le compte.

Une adresse de paiement vide ne signifie donc pas que personne n’a été piégé. Elle signifie que les contrôles de retrait de la plateforme d’échange ont tenu à la dernière étape, après que tout ce qui la précédait s’était déjà exécuté. Ce sont des faits très différents, et nous avons publié le plus rassurant.

Trois détails qui correspondent exactement à la charge utile

Nous avons extrait MIN_COIN_AMOUNT = 0.01 du script obscurci par analyse statique, deux jours après que ce compte a été touché. Sur le compte :

• Un solde d’exactement 0.01 dans le deuxième portefeuille a été converti — précisément au seuil.
• Deux autres avoirs, tous deux inférieurs à 0.01, sont restés intacts.
• Les deux portefeuilles ont été vidés par la même action, ce qui correspond à l’étape d’énumération qui lit chaque solde plutôt que le seul portefeuille principal.

Une constante récupérée dans le code, et un compte actif dont les reliquats se situent exactement de part et d’autre de celle-ci. C’est la confirmation qui manquait lorsque nous avons écrit ceci.

Pourquoi cela n’a pas pu être fait manuellement

Les deux branches des portefeuilles ont été converties à un taux verrouillé identique, à environ une seconde d’intervalle. Un taux verrouillé est coté pour un instant précis ; un taux identique pour les deux branches signifie donc qu’elles ont été cotées ensemble, dans un seul lot.

Effectuer cela manuellement exige de sélectionner la paire, d’afficher un aperçu et de confirmer avant la fin d’un compte à rebours — séparément, pour chaque portefeuille. Deux conversions manuelles complètes à une seconde d’intervalle, sur deux portefeuilles différents, à un même taux coté, ne sont pas physiquement réalisables par une personne. Le timing révèle une exécution automatisée, visible dans les propres registres du compte.

Le constat qui change les conseils

C’est celui qu’il faut retenir, et il invalide un conseil que nous donnons couramment, comme tout le monde.

L’attaque ne laisse aucun événement de connexion. Il n’y a aucune connexion au moment où la conversion s’exécute. Il y a une connexion parfaitement ordinaire plusieurs minutes auparavant, depuis l’appareil et l’adresse du titulaire du compte, parce que c’était exactement ce dont il s’agissait. La charge utile s’est ensuite exécutée dans cette session déjà authentifiée, par l’intermédiaire du pont de l’application.

Par conséquent, l’instruction habituelle — vérifiez dans votre historique de connexion la présence de sessions que vous ne reconnaissez pas — renvoie un résultat normal pour un compte auquel cela est arrivé. Il n’y a rien à reconnaître. C’était sa session.

Le deuxième piège tient à l’endroit où la victime regarde ensuite. La conversion n’apparaît pas dans l’historique des transactions, car un Convert n’est pas une transaction dans le carnet d’ordres. Une personne qui cherche dans ses ordres au comptant la transaction ayant vidé son compte trouve une liste vide et en conclut raisonnablement qu’elle l’a imaginée. L’opération est enregistrée, mais uniquement dans l’historique des conversions — un autre écran, que personne ne pense à ouvrir.

Entre les deux, un compte peut subir des modifications substantielles tandis que tous les endroits qu’une personne prudente consulterait paraissent normaux. Ce n’est pas une lacune dans la vigilance de la victime. C’est une lacune dans ce que le compte est capable de lui révéler, et c’est la même lacune par laquelle cet article commençait : le registre côté plateforme qui permettrait de trancher — quel mini program a généré l’ordre — existe, mais le titulaire du compte ne peut pas le consulter.

Ce que nous avons modifié ci-dessus

Les étapes de récupération présentées plus haut dans cet article indiquent maintenant de consulter l’historique des conversions plutôt que celui des transactions, et précisent clairement que l’activité de connexion paraîtra normale. Sur ces deux points, notre texte précédent était erroné d’une manière qui aurait rassuré quelqu’un à tort.

Il est revenu, et rien n’avait changé

Tout ce qui précède a été écrit en supposant que la campagne était terminée. Environ trente-six heures plus tard, deux autres messages sont arrivés. Même prétexte, même raccourcisseur, codes différents :

Nous avons de nouveau capturé toute la chaîne pendant la première heure. Une seule ligne importe plus que tout le reste de cet article :

Wave 1  2026-08-20   appId xoqXxUSMRccLCrZNRebmzj
Wave 2  2026-08-22   appId xoqXxUSMRccLCrZNRebmzj   <-- identical

Le Mini Program n’a jamais été désactivé. Le lien court de la première vague a cessé de se résoudre, et c’est la seule chose qui ait changé du côté de la plateforme. L’identifiant qui se trouvait derrière était toujours actif, toujours accessible, toujours prêt à ouvrir sa page de navigateur et à remettre le pont à toute URL qui lui était fournie. L’opérateur a créé deux nouveaux liens courts à partir de cet identifiant et les a dirigés ailleurs.

Le reste de l’empreinte est également inchangé, ce qui exclut un imitateur : la même page de mini program (/pages/browser/index), le même sceneValue, le même description=Protect Your Account, le même serveur à 107.189.17.50, le même registraire, le même fournisseur DNS. Seuls trois éléments ont changé — les liens courts, le domaine et la cryptomonnaie.

Voici la réponse à une question sur laquelle les sections précédentes ne pouvaient que spéculer. Couper le lien de diffusion n’arrête pas l’opérateur, car ce lien est le composant le moins coûteux qu’il possède. Couper le mini program l’arrête, mais personne ne l’a fait.

Enregistré la nuit, envoi dès le matin

21:45:28Z   domain registered
21:49:06Z   TLS certificate issued        +3m 38s
23:34:00Z   first message                 +1h 48m
00:22:00Z   second message                +2h 36m
00:43:52Z   captured, payload live        +2h 58m

Moins de quatre minutes entre l’enregistrement et l’obtention d’un certificat valide, et moins de deux heures avant l’arrivée des messages sur de vrais téléphones. Exactement la même configuration que pour la première vague, à la minute près. Personne ne fait cela manuellement.

Le nouveau domaine ment mieux

accounts . authentication . binance . com73184 . com
└─────────────── decoration ──────────────┘ └─ real ─┘

Le domaine enregistrable est com73184[.]com. Lue rapidement, la chaîne complète indique …binance.com73184.com — l’œil s’arrête à binance.com et interprète les chiffres comme un nœud de cache ou une partition. C’est une nette amélioration par rapport à binancc de la première vague, qui avait au moins l’air mal orthographié.

La charge utile a été retravaillée entre-temps

Elle est passée de 24,640 à 34,335 octets. Les sept points de terminaison privés sont identiques — même énumération, même rachat de l’épargne, même conversion, même retrait — mais quatre éléments ont été ajoutés :

• Le paiement est passé de Bitcoin à Solana. Plus rapide, moins cher et plus difficile à annuler.
• Des plafonds de conversion par actif, compatibles avec le maintien de chaque conversion sous le seuil qui attire l’attention.
• Le contournement de la limitation de débit. Une chaîne qui subsiste indique Retried just under limit: — ils effectuent délibérément des réglages en fonction des limitations de la plateforme et en mesurent l’effet.
• Le portugais, ajouté au chinois et au coréen déjà présents.

Et la page contrefait désormais l’écran d’approbation

C’est le changement sur lequel il faut s’arrêter. La page affiche une fausse version d’une invite de sécurité Binance, dans quatre langues :

Nouvelle connexion détectée · Est-ce vous ? · Appareil · Emplacement · Adresse IP · [Approuver] [Refuser] · blocage automatique dans 15s

Plus haut dans cet article, en décrivant ce qui rend une approbation push digne de confiance, nous avons écrit que l’invite doit afficher l’application, le champ location et l’adresse IP — qu’une invite sans contexte ne permet pas de prendre la bonne décision. Ce sont précisément les champs reproduits ici. L’attaquant a repris la conception qui rend sûre une véritable invite de sécurité et l’a reconstruite comme décor.

Cela boucle également ce que le SMS avait commencé. Le message dit si vous n’êtes pas à l’origine de ceci, consultez ce lien. Le visiteur arrive inquiet et trouve exactement l’écran qu’une personne inquiète espère trouver : une connexion qu’elle ne reconnaît pas, les détails présentés et un bouton « Refuser ». Appuyer sur Refuser donne l’impression de reprendre le contrôle. Les deux boutons appartiennent à l’attaquant, et le compte à rebours de quinze secondes sert à empêcher quiconque d’y réfléchir pendant seize secondes.

Ce que nous avons fait cette fois

Tout a été capturé pendant la première heure et conservé avec des sommes de contrôle ; les deux charges utiles ont été gardées côte à côte afin que les différences entre les vagues soient démontrables plutôt que reconstituées de mémoire. Des signalements ont été envoyés à l’adresse de sécurité publiée de Binance, au registraire, à l’hébergeur et à deux centres de coordination anti-phishing, pendant que le site répondait encore.

Le registraire a ouvert un ticket. Au moment de la rédaction, aucune des deux adresses de destination — celle en Bitcoin de la première vague et celle en Solana de la deuxième — n’a jamais reçu de transaction.

La partie dérangeante est qu’aucun des raisonnements de la section précédente n’était erroné. Les preuves de la première vague ont bien expiré, aucune partie ne les a reconnues, et la technique est restée intacte. Ce que nous n’avions pas anticipé, c’est la rapidité avec laquelle cela serait démontré.

Troisième vague : l’opérateur n’avait désormais plus du tout besoin de Binance

Deux jours après les premiers messages, un troisième est arrivé. Même prétexte, mécanisme différent :

Relisez cet hôte. Ce n’est pas un domaine Binance. Il n’y a aucun s.binance.com, aucune redirection par app.binance.com, aucun lien profond bnc:// et aucun identifiant de Mini Program nulle part dans la chaîne. L’opérateur a enregistré son propre domaine, l’a nommé de manière à le faire passer pour un service de liens courts de Binance et y sert directement la charge utile.

La même main

Tout ce qui identifie l’opérateur reste inchangé depuis les vagues précédentes : le même serveur, le même registraire, le même fournisseur DNS, la même version du serveur web. Seule la voie de diffusion est nouvelle.

registered      08:14:03 UTC
certificate     ~08:21 UTC     +7 minutes
first message   ~08:48 UTC     +34 minutes
captured        08:57 UTC      +43 minutes

Moins de sept minutes entre l’enregistrement et l’obtention d’un certificat valide, et moins de trente-cinq avant l’arrivée des messages sur de vrais téléphones — la même configuration que pour les deux vagues précédentes, à la minute près.

Pourquoi l’opérateur a abandonné un lien Binance qui fonctionnait parfaitement

Entre la deuxième et la troisième vague, une seule chose exactement a changé du côté de la plateforme : l’un des deux liens courts de la deuxième vague a cessé de se résoudre. L’autre fonctionnait toujours, tout comme le Mini Program qui se trouvait derrière les deux.

C’est une intervention limitée et partielle ; l’opérateur y a répondu en construisant de toutes pièces, en deux jours, un canal de diffusion de remplacement. Il vaut la peine de mesurer ce que cela implique. Il ne considérait pas la voie hébergée par Binance comme jetable. Il la jugeait assez précieuse pour la reconstruire dès qu’elle est devenue peu fiable — ce qui exprime plus clairement sa valeur que tout ce que nous pourrions avancer.

Ce qui devrait inquiéter un défenseur

Nous avons récupéré la page de la troisième vague de la même manière que les autres. Nous avons reçu 94 KB de script obscurci — presque trois fois la taille de la charge utile précédente — ne contenant aucun formulaire, aucun élément de saisie et aucun appel réseau. Deux requêtes effectuées à quelques secondes d’intervalle ont renvoyé des octets différents, car la page est générée pour chaque requête avec une nouvelle clé.

Elle contient aussi trois contrôles nommés que l’obscurcateur n’a pas réussi à masquer :

isWebDriverPresent
isPhantomOverflow
isPhantomETSL

Ceux-ci détectent l’automatisation du navigateur — exactement l’outillage employé par un scanner de sécurité. Ce que nous avons récupéré n’est pas l’attaque. C’est un sas qui décide si vous êtes une personne.

Nous pouvons être plus précis, grâce à ce que le fichier ne contient pas. Analysés de bout en bout, ces 94 KB ne contiennent aucune URL d’aucune sorte — aucun http, aucun ://, pas un seul point-com, pas même le nom du site qui le sert. Il n’y a pas non plus d’appel réseau : ni fetch, ni XMLHttpRequest, ni WebSocket. Il comporte en revanche une routine qui écrit un cookie et une clé régénérée pour chaque requête.

La séquence est donc la suivante : la page mesure le navigateur, inscrit sa conclusion dans un cookie, puis se recharge. Le serveur décide quoi envoyer ensuite. L’attaque n’est pas cachée dans le fichier — elle n’y figure absolument pas et ne peut pas y figurer. Quiconque télécharge cette page et la démonte, avec tout le soin possible, examine un portier plutôt que la pièce.

Cela doit être distingué d’un obscurcissement ordinaire. Les première et deuxième vagues livraient toute leur charge utile à une seule récupération en ligne de commande : les points de terminaison, l’adresse de paiement, la logique de conversion, tout se trouvait dans la réponse pour quiconque la demandait. La troisième vague ne livre rien, et aucune patience devant un désassembleur n’y change quoi que ce soit, car l’élément recherché n’a jamais été envoyé.

Nous pouvons dire ce que cela signifie concrètement, car cela nous est arrivé. La soumission de cette campagne à un service d’analyse automatisée a donné le résultat aucune menace détectée pour un site qui était actif et servait du contenu. Cela tenait en partie à notre propre erreur, que nous avons décrite ci-dessus. Mais une page dissimulée déjoue réellement un scanner, par conception : le scanner rapporte exactement ce qu’on lui a présenté.

Il faut donc en tirer un conseil dérangeant et l’énoncer clairement. Un résultat sain fourni par un outil de vérification automatisé ne prouve pas qu’un lien est sûr. Il prouve que ce qui a été servi à l’outil paraissait sûr. Ces deux phrases ne sont équivalentes que lorsque personne ne cherche à tromper.

Ce qui a changé et ce qui n’a pas changé

La diffusion a quitté l’infrastructure de Binance. La marque, elle, n’a pas changé — le domaine existe uniquement pour être confondu avec le sien, et le message continue d’imiter une notification de compte. Le leurre, l’opérateur, le serveur et le timing sont tous identiques.

Et l’identifiant de Mini Program qui a porté les première et deuxième vagues est, au moment de la rédaction, toujours actif. Il a désormais survécu à trois campagnes.

Pourquoi cet article ne contient aucun lien

Toutes les adresses hostiles ci-dessus sont écrites sous une forme neutralisée et aucune n’est un hyperlien. C’est délibéré. Publier un lien de phishing actif sous forme d’ancre fonctionnelle transforme l’article en redirection, prête à la campagne une part de notre réputation et demande à un moteur de recherche d’associer les deux. Décrire une attaque ne doit pas étendre sa portée.

Nous ne sommes pas affiliés à Binance. Ceci est publié parce que la technique est généralisable : un raccourcisseur officiel, un lien profond vers une application de confiance et un pont de webview qui accorde la confiance du site à une URL arbitraire forment un motif que l’on peut faire apparaître dans toute grande application grand public. Si votre produit comporte un raccourcisseur de liens, un schéma d’URL personnalisé ou un navigateur intégré qui prend une destination en paramètre, c’est cette chaîne qu’il faut aller vérifier vous-même.