El SMS con código de verificación de Binance que usa un enlace real de Binance

Revisión a los 30 días — registros en bruto

Verificado el 2026-09-29. Los dos servidores WHOIS de estos dominios no dicen lo mismo, y esa diferencia es precisamente la corrección de arriba.

El WHOIS del registrador devuelve una sola palabra y ningún registro. Este es el cuerpo completo de la respuesta de whois.ownregistrar.com para cada uno de los tres:

Terminated

Sin campos, sin códigos de estado, sin nada con forma de RFC. «Terminated» es vocabulario de producto propio de OwnRegistrar, no un estado del registro — no existe tal estado EPP. Lo citamos como si describiera el registro, y no lo hace.

El WHOIS del registro sí devuelve el registro real. Desde whois.verisign-grs.com, con forma idéntica para los tres:

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   creado 2026-08-20T13:31:11Z   expira 2027-08-20T13:31:11Z   modificado 2026-08-26T09:10:06Z
bnbshort.com    creado 2026-08-22T08:14:03Z   expira 2027-08-22T08:14:03Z   modificado 2026-08-26T09:10:05Z
com73184.com    creado 2026-08-21T21:45:28Z   expira 2027-08-21T21:45:28Z   modificado 2026-08-26T09:10:06Z

De ese registro se siguen tres cosas que «cancelado» ocultaba.

clientHold es la razón de que no haya DNS. La delegación está intacta: ambos servidores de nombres de DNSPod siguen figurando en el registro. El registrador retiró el dominio de la zona en lugar de eliminar el registro, así que la resolución falla mientras el registro en sí continúa. Está a un cambio de estado de volver a resolver. El operador no puede hacer ese cambio: clientUpdateProhibited y clientTransferProhibited lo dejan fuera de sus propios dominios.

La suspensión está deliberadamente formada para durar más que la campaña. clientRenewProhibited más clientDeleteProhibited significa que no pueden renovarse ni liberarse antes de tiempo: quedan congelados hasta la expiración y luego caen. Eliminarlos habría sido la medida más débil, porque un nombre eliminado vuelve al conjunto disponible en unos 75 días. Retenidos hasta expirar, estos tres están fuera del mercado hasta el 20–22 de agosto de 2027. Quien lo decidió eligió la opción más fuerte.

La acción ocurrió cuatro días antes de que la verificáramos. Los tres valores de Updated Date caen dentro de un segundo: 09:10:05 y 09:10:06 UTC del 2026-08-26. Fechamos el resultado el 30 de agosto dando a entender que fue entonces cuando ocurrió. En realidad fue algo con guion, aplicado a los tres a la vez, y ya tenía cuatro días cuando lo miramos.

Lo que sigue sin resolver

El Mini Program appId xoqXxUSMRccLCrZNRebmzj — el componente que sobrevivió a todos los dominios, y la razón de que este texto trate de un mecanismo y no de tres direcciones. Las dos páginas mp-cms nombradas en los indicadores responden HTTP 202 a cualquier petición no autenticada, lo cual es mitigación de bots y no una página. Su actividad solo es observable desde una app de Binance con sesión iniciada, así que no podemos afirmar en ningún sentido si esa vía está cerrada. Treinta días después sigue siendo la pregunta abierta — y es la que importa.

Un usuario nos reenvió dos mensajes de texto que llegaron con un par de horas de diferencia. Ambos parecían avisos de seguridad de Binance. Ambos incluían un enlace en un dominio que pertenece real y verificablemente a Binance.

Desmontamos la cadena. Lo que hay al final no es una página de inicio de sesión falsa. Es un script que, si llega hasta ti dentro de la aplicación de Binance mientras tienes una sesión iniciada, rescata tus ahorros, convierte en Bitcoin todos tus saldos y presenta una retirada a una dirección codificada directamente por el atacante. Nunca te pide una contraseña, un código ni una frase semilla, porque no necesita ninguno de ellos.

Este artículo documenta toda la cadena porque el consejo habitual — «comprueba el dominio» — no te salva aquí. El dominio es real.

Los mensajes

Estos son los dos primeros. Otros dos llegaron treinta y seis horas después, desde el mismo Binance Mini Program, cuando ya se había escrito todo lo que aparece a continuación — están en Volvió, y nada había cambiado.

Ya hay dos cosas que merece la pena observar.

Los códigos son distintos — 780641 y 366812 —, pero el enlace es idéntico. Un código de un solo uso real está vinculado a una solicitud real. Estos son decoración, generados para cada envío a fin de que el mensaje se parezca a algo que ya has recibido antes.

El segundo mensaje está escrito en cantonés coloquial, no en chino escrito estándar. Alguien lo adaptó deliberadamente para lectores de Hong Kong. Volveremos a ello, porque el propio payload también está localizado y revela a quién se dirige la campaña.

Por qué falla «comprueba el dominio»

La persona que nos informó de esto tiene experiencia con DNS e infraestructura de dominios, y estuvo muy cerca de hacer clic. Esa es la parte que hay que tomarse en serio, porque hizo las comprobaciones correctas y todas dieron un resultado válido:

• El host es s.binance.com. Es un subdominio de binance.com, el dominio registrable auténtico.
• No es un homógrafo de dominio internacionalizado. Todos los caracteres son ASCII simples. Comparado letra por letra, es la cadena real.
• WHOIS para binance.com devuelve el registro de la propia Binance. No hay un registrador de imitación, una fecha de creación reciente ni nada anómalo.
• TLS termina en un certificado válido. El candado es real.

Todo eso es cierto y nada de ello ayuda, porque el atacante nunca necesitó controlar un dominio de Binance. s.binance.com es el acortador de enlaces propio de Binance. El atacante alojó su payload en otro lugar y usó la infraestructura de Binance para apuntar hacia él.

Compáralo con la versión que sí puedes detectar

Este es el mismo pretexto en su forma habitual: otro mensaje que nos comunicaron y la forma que todavía adoptan la mayoría de estas campañas:

Ese sí se puede detectar. La cadena binance.com aparece claramente en el enlace, pero está antes de una arroba, y en una URL todo lo situado entre el esquema y @ son credenciales, no un nombre de host. Un navegador lo interpreta así: conéctate al host 0691[.]app, ofreciendo el nombre de usuario "binance.com". El destino real es un dominio desechable de cuatro dígitos. La marca es un señuelo colocado en el campo del nombre de usuario.

Cualquiera que conozca esa regla lo detecta en un segundo. Muchos clientes de mensajería y correo ya marcan o reescriben directamente este patrón. Es ofuscación, y la ofuscación se puede enseñar, detectar y filtrar. Además, falla precisamente contra la persona que informó de ambos.

El mensaje de s.binance.com pertenece a una categoría de problema distinta y merece tratarse como tal. No hay nada disfrazado:

• No hay truco con la arroba. El host es el host.
• No hay homógrafo, punycode ni caracteres cirílicos parecidos.
• No hay ninguna falta ortográfica en la cadena visible.
• No hay registrador sospechoso, dominio reciente ni certificado autofirmado.
• No hay nada que un filtro de enlaces pueda usar como señal, porque es un enlace que un usuario legítimo de Binance podría enviarte de verdad.

No imita la credibilidad de Binance. Toma prestada la auténtica — el dominio, el certificado, la transferencia a la aplicación y la interfaz que muestra las palabras «Protege tu cuenta». El engaño no empieza hasta que ya estás dentro de la aplicación, momento en el que no queda una barra de direcciones que inspeccionar.

Por eso este caso merece un análisis y el primero no. El mensaje con arroba se derrota con conocimiento. Este no, porque todas las comprobaciones que sabes realizar devuelven «auténtico» — y lo es, justo hasta el momento en que una aplicación de confianza entrega su canal de solicitudes a un dominio registrado esa misma mañana.

La cadena, decodificada

El enlace corto responde con una redirección HTTP simple:

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

Sigue siendo Binance. Sigue siendo auténtico. Las partes interesantes son las etiquetas de la campaña: app_mini_program_share_link y mini_program. Este es un enlace compartido de Binance Mini Program — el artefacto que se obtiene al compartir una miniaplicación desde la aplicación de Binance. No se hackeó nada. El atacante publicó o abusó de un miniprograma y utilizó la función de compartir tal como fue diseñada.

Observa también description=Protect Your Account. La frase de ingeniería social viaja dentro de la URL, por lo que es la propia interfaz de Binance la que muestra las palabras tranquilizadoras.

El parámetro _dp está en base64. Una vez decodificado:

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

bnc:// es el esquema de URL personalizado de la aplicación de Binance. En un teléfono con la aplicación instalada, esto entrega el control a la aplicación en lugar de abrir una pestaña del navegador.

startPagePath vuelve a estar en base64 y se decodifica como /pages/browser/index — la página de navegador dentro de la aplicación del miniprograma. Así, el enlace profundo le indica a la aplicación de Binance: abre este miniprograma y ve a su pantalla de navegador. La dirección que debe cargar está en base64 por tercera vez, en startPageQuery:

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

Ahí está. Lee el host con atención:

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

El dominio registrable es cdn378129[.]com. Todo lo situado a su izquierda es texto libre elegido por el atacante — incluido binancc, con dos letras c, que no es tanto una errata de la marca como una aproximación deliberada que supera una mirada rápida. En un teléfono, dentro de una webview, la mayor parte de esa cadena queda fuera de la pantalla de todos modos.

Por tanto, el dominio malicioso nunca aparece visible en el mensaje. Está en base64, dentro de un parámetro de consulta, dentro de otro payload en base64, dentro de una URL auténtica de Binance y detrás de un acortador auténtico de Binance.

La infraestructura tiene apenas unas horas

Registros públicos, comprobados mientras redactábamos esto:

• cdn378129[.]com fue registrado a las 13:31 UTC el 20 de agosto de 2026, mediante OwnRegistrar, Inc., con el DNS delegado a DNSPod.
• Su certificado de Let's Encrypt tiene un notBefore de las 12:35 UTC del mismo día. Let's Encrypt antedata ese campo aproximadamente una hora, por lo que la emisión se produjo unos cuatro minutos después del registro. El certificado solo cubre ese nombre de host y ningún otro.
• El host resuelve a 107.189.17.50, en un rango asignado a RouterHosting LLC dentro de FranTech Solutions.
• El dominio no está firmado: no tiene DNSSEC.

Un dominio registrable con menos de un día, un certificado emitido minutos después y un nombre de host con una única finalidad. Nada de eso es visible desde el SMS, y tampoco desde s.binance.com — que es precisamente el propósito de pasar por el acortador.

Lo que hace realmente la página

Recuperamos el endpoint en un entorno aislado, sin ejecutarlo. La primera sorpresa es lo que no hay:

• No hay formulario. Ni un solo elemento <form>.
• No hay campos de entrada. Ni un solo <input>.
• No hay solicitud de contraseña, de código de un solo uso ni de frase semilla, ni botón para conectar una cartera.

Todos los instintos que se ha enseñado a la gente a seguir — no escribas tu contraseña en una página extraña, nunca introduzcas tu frase semilla, observa lo que firmas — son inútiles aquí, porque la página nunca te pide nada.

Lo que contiene en su lugar es un script ofuscado cuya configuración aparece claramente en la parte superior:

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

Y las cadenas de error que el ofuscador no logró ocultar nombran directamente el mecanismo:

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

window.bn.miniProgram es el puente JavaScript que la aplicación de Binance inyecta en las webviews de los miniprogramas. El script espera a que aparezca y después emite sus solicitudes a través de él. Ese es todo el truco: no necesita tus credenciales ni superar la política del mismo origen, porque la aplicación entrega un canal de solicitudes de confianza a cualquier página que muestre el navegador del miniprograma — y se le indicó que mostrara la página del atacante.

La secuencia de retirada

Al recuperar la tabla de cadenas aparecen los endpoints privados de Binance a los que llama el payload, en el orden en que los utiliza la lógica:

1. /bapi/accounts/v1/private/account/get-user-base-info — identificar a la víctima. La página te saluda por tu nombre: «Bienvenido de nuevo, …».
2. /bapi/kyc/v2/private/certificate/user-kyc/get-current-kyc-status-lite — comprobar el estado de verificación, porque las retiradas dependen de él.
3. /bapi/asset/v3/private/asset-service/asset/get-wallet-asset — enumerar todos los saldos de la cuenta.
4. /bapi/earn/v1/private/lending/daily/redeem — rescatar los ahorros flexibles, para que el dinero que genera rendimiento se pueda gastar.
5. /bapi/margin/v1/private/new-otc/get-quote y …/execute-quote — convertir en Bitcoin todos los demás activos, omitiendo los saldos inferiores al mínimo y reservando una pequeña cantidad para las comisiones.
6. /bapi/capital/v4/private/capital/withdraw/apply — presentar la retirada a la dirección codificada directamente.

Mientras se ejecuta, la pantalla muestra una breve secuencia de estados tranquilizadores, tomados del propio marcado de la página:

Cargando tu cuenta · Estamos recopilando tus datos de forma segura · Bienvenido de nuevo, … · Comprobando la autorización… · Volviendo a iniciar sesión en Binance

«Volviendo a iniciar sesión en Binance» cumple muchas funciones. Explica una pausa, explica por qué la aplicación está ocupada y te prepara para esperar un paso de autenticación.

La parte inteligente es el código falso

Esto es lo que tardamos un momento en comprender. El código de verificación falso del SMS no es el cebo. El enlace es el cebo. El código es inoculación.

Una retirada desde una cuenta real de un exchange suele requerir una confirmación real: un enlace por correo electrónico, un código de autenticación o una aprobación push. Esa confirmación es lo último que se interpone entre la víctima y la pérdida, y se supone que debe resultar alarmante.

Pero la víctima ya ha recibido un código de Binance que no solicitó, y el propio mensaje ya le ha dicho que este es el aspecto de un código no solicitado. Ahora está dentro de un flujo titulado «Comprobando la autorización» en una pantalla que la ha saludado por su nombre. Cuando llega la confirmación auténtica, no se interpreta como una alarma. Se interpreta como el siguiente paso de la comprobación de seguridad que cree estar realizando.

A quién se dirige

El payload incluye una tabla de traducciones con exactamente dos configuraciones regionales distintas del inglés: zh y ko. Lee navigator.language y se localiza automáticamente. Combinado con un señuelo escrito en cantonés de Hong Kong, se trata de una campaña creada para usuarios que hablan chino y coreano, no de una difusión en inglés que casualmente llegó a uno de ellos.

La dirección de destino no tenía ninguna transacción cuando la comprobamos en dos exploradores de bloques independientes: nada confirmado y nada esperando tampoco en el mempool. Por lo que muestra la cadena, esta dirección todavía no ha recibido los fondos de ninguna víctima.

Al principio interpretamos eso como una señal alentadora. Era una interpretación equivocada, y nos lo dijo alguien a quien le ocurrió. Una dirección de pago vacía no significa que no atraparan a nadie. Significa que el dinero no llegó al último paso. Todo lo anterior todavía puede haberse ejecutado — y en al menos una cuenta con fondos, así fue. Consulta Lo que oculta realmente una dirección vacía más adelante.

Lo que sí significa es que hay tiempo, y por eso publicamos con rapidez en vez de hacerlo con cuidado.

Lo que realmente te protege

Inspeccionar el dominio no funciona contra esto. Estas medidas sí:

• Configura un código antiphishing en tu exchange y comprueba que esté presente. Binance permite definir un identificador que aparece en sus mensajes auténticos, incluidos los SMS. Los mensajes anteriores no incluyen ninguno. Su ausencia es la señal, y es la más fiable de la que dispone una persona normal.
• Trata «si no fuiste tú, pulsa aquí» como el ataque, no como el remedio. Los avisos de seguridad legítimos te indican que abras la aplicación por tu cuenta. La urgencia y el enlace son el payload.
• Nunca accedas a tu exchange desde un mensaje. Abre la aplicación desde la pantalla de inicio. Ese único hábito derrota toda esta cadena, porque nada de ella sobrevive si no haces clic.
• Configura una lista blanca de direcciones de retirada. Con una lista blanca activa y una demora para las direcciones nuevas, un script que presenta una retirada a una dirección nueva no tiene dónde enviarla.
• Lee lo que dice realmente una confirmación. Una confirmación de retirada auténtica indica una moneda, una cantidad y una dirección de destino. Si una pantalla te dijo que estaba «volviendo a iniciar sesión», ese texto es el de una retirada.
• Desconfía de un enlace que abre una aplicación. Un enlace que salta directamente a una aplicación se ha saltado el navegador y, con él, la barra de direcciones y todas las advertencias de navegación segura que habrías recibido.

Si lo pulsaste

1. Abre directamente la aplicación del exchange y comprueba primero el historial de retiradas y las retiradas pendientes. Cancela todo lo que no hayas iniciado.
2. Comprueba si se rescataron posiciones de ahorro flexible y si los saldos se convirtieron en Bitcoin. Ambas cosas ocurren antes de la retirada, de modo que ambas son advertencias anteriores.
3. No confíes en tu historial de inicio de sesión: parecerá limpio. El payload se ejecuta dentro de la sesión que ya abriste, por lo que no crea un evento de inicio de sesión nuevo. Una cuenta vaciada de esta forma no muestra nada inusual en la actividad de inicio de sesión cuando ocurrió.
4. Comprueba específicamente el historial de conversiones, no el historial de operaciones. Un Convert no aparece entre las órdenes al contado. Quien busque una operación inexplicada encontrará una lista vacía y concluirá que no ocurrió nada.
5. Revoca las sesiones y los dispositivos activos, cambia la contraseña y renueva la autenticación de dos factores.
6. Activa la lista blanca de direcciones de retirada.
7. Notifícalo. Binance recibe informes de estafas a través de su centro de soporte, y un informe que incluya el enlace corto, el identificador del miniprograma y la dirección de destino permite actuar mucho mejor que una captura de pantalla.

Indicadores

Desactivados y publicados para que los defensores puedan bloquearlos y correlacionarlos — no para que alguien los visite.

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

Las pruebas caducaron y nadie lo detectó

Aproximadamente un día después de que se registrara el dominio, volvimos a comprobar todos los enlaces de la cadena. Ahora todos responden como 404s: el enlace corto y el payload del final.

El primer impulso es sentir alivio. Ese impulso es equivocado, y comprender por qué es lo más útil de este artículo.

No se retiró nada

Observa lo que sigue en pie:

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

Una suspensión del registrador cambia el estado del dominio e impide que el nombre resuelva. Una suspensión del host impide que el servidor responda. No ocurrió ninguna de las dos cosas. Estamos ante un servidor que sigue funcionando, en un nombre que sigue resolviendo, con un certificado que alguien sigue pagando — y cuyos archivos se eliminaron a mano.

Eso no es una retirada. Es un operador limpiando. Que el enlace de entrega dejara de funcionar al mismo tiempo podría deberse a que la plataforma lo revocó o a que el mismo operador lo retiró; desde fuera son hechos indistinguibles, y eso constituye el problema.

Ninguna parte ha reconocido nada

No hay número de caso. No hay aviso. No hay una nota publicada que indique que se deshabilitó un miniprograma, ninguna acción del registrador, ninguna entrada en una lista de bloqueo ni declaración de nadie. No hemos encontrado ningún reconocimiento público de ninguna parte de que esto llegara a ocurrir.

Por tanto, la campaña no ha sido detenida. Ha sido concluida por quien la operaba, conforme a su calendario, con su infraestructura intacta y una reputación completamente impoluta ante todos los registradores y hosts del mundo.

Por qué esto hace casi imposible informar

Todos los canales de denuncia disponibles para una persona del público presuponen que el contenido está activo:

• Un clasificador de listas de bloqueo obtiene la URL para decidir. Encuentra un 404 estándar de nginx y se niega a incluirla.
• El departamento de abusos de un registrador que recibe «este dominio sirvió phishing» para una URL que ya no devuelve nada cierra el ticket como contenido retirado, sin requerir acción.
• El departamento de abusos de un proveedor de alojamiento hace lo mismo.

La ventana durante la que se podía actuar se cerró mientras todavía redactábamos el análisis. No es una crítica a los departamentos de abusos: verificar un ataque activo es abordable y juzgar uno extinto no lo es. Es la descripción de una carencia estructural: el sistema de denuncias funciona más despacio que el ataque que pretende detectar.

La prueba es volátil, y ese es todo el truco

Esta es la parte que merece reflexión. Una operación de phishing que dura veinticuatro horas produce pruebas con una vida útil de veinticuatro horas. El atacante no necesita destruir nada, ocultar sus huellas ni burlar a nadie. Solo necesita durar más que la latencia de las denuncias — y un dominio que cuesta diez dólares, convertido en arma cuatro minutos después de registrarse, lo consigue con holgura.

Después, la situación es simétrica y poco útil para todos. Nosotros no podemos demostrarlo a un departamento de abusos porque su paso de verificación consiste en obtener el recurso. Ellos no pueden verificarlo porque ya no hay nada que obtener. Los destinatarios no pueden denunciarlo porque el enlace de su mensaje ahora no conduce a ninguna parte y parece un error. Y el operador puede repetirlo todo la semana siguiente con un dominio nuevo y una identidad de miniprograma nueva, sin haber pagado ningún precio ni dejado registro.

Por eso importa la técnica y el dominio nunca importó. No ha cambiado ni una sola cosa del mecanismo. Una página de navegador de miniprograma todavía acepta un destino como parámetro. Cualquier contenido que cargue esa página sigue pudiendo alcanzar el puente. La función de compartir sigue creando enlaces en un dominio auténtico con un certificado válido. Un identificador nuevo y un nombre de host desconocido reproducen cada palabra de este artículo en una tarde.

Si te llega uno de estos

La consecuencia práctica: captura primero e informa después. Lo que existe durante la primera hora es lo único que llegará a existir.

• Haz una captura de pantalla del mensaje antes que nada, incluido el remitente.
• Si puedes, registra la cadena de redirecciones sin seguirla: solicita solo los encabezados, desde una máquina que no tenga instalada la aplicación. El encabezado location del primer salto es el artefacto más valioso de toda la cadena, y es lo primero que desaparece.
• No lo abras en un dispositivo que tenga instalada la aplicación. Eso no es una prueba: es el ataque.
• Anota las horas. El intervalo entre el registro de un dominio y el primer mensaje constituye una prueba por sí mismo, y perdura cuando el contenido deja de hacerlo.

Todo lo que capturamos está en este artículo precisamente por ese motivo: la cadena de solicitudes, el enlace profundo decodificado, los endpoints a los que llamó el payload y la dirección a la que iba a enviarlo. Ya no es posible obtener nada de ello. Este es ahora el registro, y un análisis que hubiera esperado otro día para obtener una confirmación más ordenada no habría contenido nada.

Lo que oculta realmente una dirección vacía

Desde entonces se nos ha descrito una cuenta afectada por la primera oleada. Sus registros muestran que la fase de conversión de este payload se ejecutó realmente. La persona pidió permanecer anónima, y todas las cifras que podrían identificarla — saldos, activos, direcciones, números de orden — se omiten deliberadamente a continuación. Nada de ello es necesario. La prueba está en la forma de lo ocurrido, no en su magnitud.

Lo que sigue es su relato, contrastado con mediciones que ya habíamos realizado de forma independiente. No describimos quién es, dónde está ni qué poseía, y no vamos a hacerlo.

La parte en la que nos equivocamos

Informamos de que la dirección de pago no tenía transacciones y lo interpretamos como que la campaña no había tenido éxito. Esa inferencia no se sostiene. En esta cuenta, la fase de conversión se completó: todo el saldo, repartido entre dos carteras distintas, se convirtió en un solo activo mediante una única acción que el titular de la cuenta no realizó y no recuerda. Lo que falló fue la retirada — los fondos permanecieron en la cuenta.

Por tanto, una dirección de pago vacía no significa que no atraparan a nadie. Significa que los controles de retirada del exchange resistieron en el último paso, después de que todo lo anterior ya se hubiera ejecutado. Son hechos muy diferentes, y publicamos el más tranquilizador.

Tres detalles que coinciden exactamente con el payload

Extrajimos MIN_COIN_AMOUNT = 0.01 del script ofuscado mediante análisis estático, dos días después de que esta cuenta fuera atacada. En la cuenta:

• Un saldo de exactamente 0.01 en la segunda cartera se convirtió — exactamente en el umbral.
• Otros dos activos, ambos por debajo de 0.01, quedaron intactos.
• Ambas carteras se vaciaron en la misma acción, lo que coincide con el paso de enumeración que lee todos los saldos en lugar de limitarse al principal.

Una constante recuperada del código y una cuenta real cuyos restos se sitúan exactamente a cada lado de ella. Esa es la confirmación que faltaba cuando redactamos esto.

Por qué no pudo hacerse a mano

Las dos partes de las carteras se convirtieron a un tipo bloqueado idéntico, con aproximadamente un segundo de diferencia. Un tipo bloqueado se cotiza para un instante, así que un tipo idéntico en ambas partes significa que se cotizaron juntas, en un solo lote.

Hacerlo manualmente exige seleccionar el par, previsualizar y confirmar dentro de un temporizador de cuenta atrás — por separado para cada cartera. Dos conversiones manuales completas con un segundo de diferencia, entre dos carteras distintas y al mismo tipo cotizado, no es algo que una persona pueda hacer físicamente. Los tiempos revelan ejecución automática y son visibles en los propios registros de la cuenta.

El hallazgo que cambia el consejo

Esta es la conclusión que conviene conservar, y deja sin validez el consejo que nosotros y todos los demás damos habitualmente.

El ataque no deja ningún evento de inicio de sesión. No hay ningún inicio de sesión en el momento en que se ejecutó la conversión. Hay un inicio de sesión perfectamente normal varios minutos antes, desde el dispositivo y la dirección del propio titular, porque eso es exactamente lo que fue. Después, el payload se ejecutó dentro de esa sesión ya autenticada, a través del puente de la aplicación.

Por tanto, la instrucción habitual — comprueba tu historial de inicio de sesión en busca de sesiones que no reconozcas — devuelve un resultado limpio para una cuenta a la que le haya ocurrido esto. No hay nada que reconocer. La sesión era suya.

La segunda trampa está en dónde mira después la víctima. La conversión no aparece en el historial de operaciones, porque un Convert no es una operación del libro de órdenes. Quien busque entre sus órdenes al contado la transacción que vació su cuenta encuentra una lista vacía y concluye razonablemente que lo imaginó. Está registrada, pero solo en el historial de conversiones, una pantalla diferente que a nadie se le ocurre abrir.

Entre ambas cosas, una cuenta puede sufrir una interferencia considerable y todos los lugares donde miraría una persona cuidadosa muestran normalidad. No es una carencia de diligencia de la víctima. Es una carencia de lo que la cuenta puede decirle, y es la misma carencia con la que comenzó este artículo: el registro del lado de la plataforma que resolvería la cuestión — qué miniprograma originó la orden — existe, pero el titular de la cuenta no puede verlo.

Lo que hemos cambiado más arriba

Los pasos de recuperación anteriores de este artículo ahora indican que se compruebe el historial de conversiones en lugar del historial de operaciones y dicen claramente que la actividad de inicio de sesión parecerá limpia. Ambas indicaciones eran erróneas de una forma que habría hecho que alguien se marchara tranquilizado.

Volvió, y nada había cambiado

Todo lo anterior se escribió suponiendo que la campaña había terminado. Aproximadamente treinta y seis horas después llegaron otros dos mensajes. Mismo pretexto, mismo acortador, códigos diferentes:

Volvimos a capturar toda la cadena durante la primera hora. Una línea importa más que todo lo demás en este artículo:

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

El Mini Program nunca se deshabilitó. El enlace corto de la primera oleada dejó de resolver, y eso fue lo único que cambió del lado de la plataforma. El identificador subyacente seguía activo, accesible y dispuesto a abrir su página de navegador y entregar el puente a cualquier URL que recibiera. El operador creó dos enlaces cortos nuevos con él y los apuntó a otro sitio.

El resto de la huella tampoco cambió, lo que descarta que fuera un imitador: la misma página del miniprograma (/pages/browser/index), el mismo sceneValue, el mismo description=Protect Your Account, el mismo servidor en 107.189.17.50, el mismo registrador y el mismo proveedor de DNS. Solo cambiaron tres cosas — los enlaces cortos, el dominio y la moneda.

Esta es la respuesta a una pregunta sobre la que las secciones anteriores solo podían especular. Cortar el enlace de entrega no detiene al operador, porque ese enlace es el componente más barato que posee. Cortar el Mini Program sí lo detiene, y nadie lo hizo.

Registrado de noche, enviando por la mañana

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

Menos de cuatro minutos desde el registro hasta obtener un certificado válido, y menos de dos horas hasta que los mensajes llegaron a teléfonos reales. La misma forma que en la primera oleada, al minuto. Nadie hace esto a mano.

El dominio nuevo es una mentira mejor

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

El dominio registrable es com73184[.]com. Lee rápidamente la cadena completa y dice …binance.com73184.com — el ojo se detiene en binance.com y trata los dígitos como un nodo de caché o un fragmento. Es una mejora directa respecto al binancc de la primera oleada, que al menos parecía estar mal escrito.

El payload se modificó entre una oleada y otra

Creció de 24,640 a 34,335 bytes. Los siete endpoints privados son idénticos — la misma enumeración, el mismo rescate de ahorros, la misma conversión y la misma retirada —, pero se añadieron cuatro cosas:

• El pago cambió de Bitcoin a Solana. Más rápida, más barata y más difícil de revertir.
• Límites de conversión por activo, coherentes con mantener cada conversión por debajo del umbral que pueda llamar la atención.
• Evasión de límites de velocidad. Una cadena que sobrevivió dice Retried just under limit: — están ajustando deliberadamente el comportamiento frente a los límites de la plataforma y midiéndolo.
• Portugués, añadido al chino y coreano que ya estaban presentes.

Y ahora falsifica la pantalla de aprobación

Este es el cambio en el que merece la pena detenerse. La página muestra una versión falsa de un aviso de seguridad de Binance, en cuatro idiomas:

Nuevo inicio de sesión detectado · ¿Eres tú? · Dispositivo · Ubicación · Dirección IP · [Aprobar] [Denegar] · bloqueo automático en 15s

Antes, al describir qué hace fiable una aprobación push, escribimos que el aviso debe mostrar la aplicación, la location y la dirección IP — que un aviso sin contexto es uno sobre el que no puedes decidir correctamente. Esos son precisamente los campos reproducidos aquí. El atacante tomó el diseño que hace seguro un aviso de seguridad auténtico y lo reconstruyó como decorado.

También cierra el bucle que abre el SMS. El mensaje dice si no fuiste tú, visita este enlace. El visitante llega preocupado y encuentra exactamente la pantalla que una persona preocupada espera ver: un inicio de sesión que no reconoce, los detalles expuestos y un botón marcado Denegar. Pulsar Denegar parece recuperar el control. Ambos botones pertenecen al atacante, y la cuenta atrás de quince segundos sirve para impedir que nadie piense en ello durante dieciséis.

Lo que hicimos esta vez

Todo se capturó durante la primera hora y se conservó con sumas de comprobación; ambos payloads se guardaron uno junto al otro para que la diferencia entre las oleadas pueda demostrarse en vez de recordarse. Enviamos informes a la dirección de seguridad publicada de Binance, al registrador, al proveedor de alojamiento y a dos centros de coordinación antiphishing mientras el sitio todavía respondía.

El registrador abrió un ticket. En el momento de escribir estas líneas, ninguna de las dos direcciones de destino — la de Bitcoin de la primera oleada y la de Solana de la segunda — ha recibido jamás una transacción.

La parte incómoda es que ninguno de los razonamientos de la sección anterior era incorrecto. Las pruebas de la primera oleada sí caducaron, ninguna parte reconoció lo ocurrido y la técnica sobrevivió intacta. Lo que no anticipamos fue la rapidez con la que quedaría demostrado.

Tercera oleada: dejaron de necesitar a Binance por completo

Dos días después de los primeros mensajes llegó un tercero. Mismo pretexto, conductos distintos:

Vuelve a leer ese host. No es un dominio de Binance. No hay s.binance.com, ninguna redirección a través de app.binance.com, ningún enlace profundo bnc:// ni identificador de Mini Program en parte alguna de la cadena. El operador registró su propio dominio, le dio un nombre destinado a confundirse con un servicio de enlaces cortos de Binance y sirve el payload directamente desde él.

Las mismas manos

Todo lo que identifica al operador permanece igual que en las oleadas anteriores: el mismo servidor, el mismo registrador, el mismo proveedor de DNS y la misma compilación del servidor web. Solo es nueva la ruta de entrega.

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

Menos de siete minutos desde el registro hasta obtener un certificado válido, y menos de treinta y cinco hasta que los mensajes llegaron a teléfonos reales — la misma forma que las dos oleadas anteriores, al minuto.

Por qué renunciaron a un enlace de Binance perfectamente válido

Entre la segunda y la tercera oleada cambió exactamente una cosa del lado de la plataforma: uno de los dos enlaces cortos de la segunda oleada dejó de resolver. El otro seguía funcionando, y el Mini Program que estaba detrás de ambos continuaba activo.

Es una intervención pequeña y parcial, y la respuesta consistió en construir desde cero un canal de entrega de sustitución en dos días. Merece la pena detenerse en lo que implica. El operador no trató la ruta alojada en Binance como algo desechable. La consideró lo bastante valiosa como para reconstruirla en cuanto dejó de ser fiable — una afirmación más clara sobre el valor de esa ruta que cualquier argumento que pudiéramos formular.

La parte que debería preocupar a un defensor

Obtuvimos la página de la tercera oleada del mismo modo que las demás. Lo que recibimos son 94 KB de script ofuscado — casi tres veces el tamaño del payload anterior — sin ningún formulario, elemento de entrada ni llamada de red. Dos solicitudes separadas por segundos devolvieron bytes diferentes, porque la página se genera para cada solicitud con una clave nueva.

También contiene tres comprobaciones con nombre que el ofuscador no consiguió ocultar:

isWebDriverPresent
isPhantomOverflow
isPhantomETSL

Estas detectan la automatización del navegador — exactamente las herramientas que usa un escáner de seguridad. Lo que recuperamos no es el ataque. Es una puerta que decide si eres una persona.

Podemos ser más precisos gracias a algo que el archivo no contiene. Examinados de principio a fin, esos 94 KB no contienen ninguna URL de ningún tipo — ningún http, ningún ://, ni un solo dot-com, ni siquiera el nombre del sitio que lo sirve. Tampoco hay ninguna llamada de red: ni fetch, ni XMLHttpRequest, ni WebSocket. Lo que sí hay es una rutina para escribir una cookie y una clave que se regenera para cada solicitud.

La secuencia es esta: la página mide el navegador, escribe en una cookie lo que concluyó y vuelve a cargarse. El servidor decide qué enviar a continuación. El ataque no está oculto dentro del archivo — no está en el archivo en absoluto y no puede estarlo. Quien descarga esa página y la desmonta, por mucha atención que ponga, examina a un portero en vez de la habitación.

Conviene distinguirlo de la ofuscación ordinaria. Las oleadas uno y dos entregaban todo su payload a una única consulta desde la línea de comandos: los endpoints, la dirección de pago y la lógica de conversión estaban en la respuesta para cualquiera que los pidiera. La tercera oleada no entrega nada, y ninguna paciencia con un desensamblador cambia eso, porque lo buscado nunca se envió.

Podemos explicar lo que eso significa en la práctica porque nos ocurrió. El envío de esta campaña a un servicio de análisis automatizado devolvió el resultado «ninguna amenaza encontrada» para un sitio que estaba activo y sirviendo contenido. En parte se debió a nuestro propio error, que hemos descrito más arriba. Pero una página oculta derrota a un escáner honestamente y por diseño: el escáner informa exactamente de lo que se le mostró.

Por tanto, la conclusión que debe extraerse es incómoda y merece expresarse con claridad. Un resultado limpio de un verificador automatizado no demuestra que un enlace sea seguro. Demuestra que aquello que recibió el verificador parecía seguro. Ambas frases solo son equivalentes cuando nadie intenta engañarlo.

Qué cambió y qué no

La entrega salió de la infraestructura de Binance. La marca no — el dominio existe únicamente para confundirse con el suyo, y el mensaje sigue suplantando una notificación de cuenta. El señuelo, el operador, el servidor y los tiempos son idénticos.

Y el identificador de Mini Program que transportó las oleadas uno y dos sigue activo en el momento de redactar esto. Ya ha sobrevivido a tres campañas.

Por qué no hay enlaces en este artículo

Todas las direcciones hostiles anteriores están escritas de forma desactivada y ninguna es un hipervínculo. Es deliberado. Publicar un enlace de phishing activo como ancla funcional convierte el artículo en una redirección, presta a la campaña una parte de nuestra reputación y pide a un motor de búsqueda que asocie ambas cosas. Describir un ataque no debería ampliar su alcance.

No estamos afiliados a Binance. Esto se publica porque la técnica es generalizable: un acortador oficial, un enlace profundo hacia una aplicación de confianza y un puente de webview que entrega la confianza del sitio a una URL arbitraria forman un patrón que puede hacerse aparecer en cualquier gran aplicación de consumo. Si tu producto incluye un acortador de enlaces, un esquema de URL personalizado o un navegador dentro de la aplicación que acepta un destino como parámetro, esta es la cadena que debes revisar por tu cuenta.