El 29 de octubre, dos ataques contra dos plataformas muy distintas terminaron de la misma forma. En Polymarket, un script secuestrado en el sitio web vació 737 cuentas y se llevó unos 2.73 millones de dólares en aproximadamente una hora. Horas después, unos 6,360 millones de dólares salieron de las billeteras calientes de Binance a través de 10 blockchains, la mayor parte en unos 20 minutos, en lo que ya se considera el mayor robo en la historia de las criptomonedas.
Las cifras difieren en varios órdenes de magnitud, pero los dos ataques expusieron la misma debilidad. Los atacantes no crearon cuentas nuevas ni burlaron los controles de identidad: tomaron prestada la autoridad de alguien en quien el sistema ya confiaba y dejaron que el sistema hiciera el resto.
Cómo ocurrió
Binance: una oferta de trabajo falsa. Según la información publicada por Binance, un ingeniero de software recibió una propuesta en un portal de empleo e hizo varias entrevistas, incluida una con un supuesto director general. Después descargó una prueba técnica que en realidad daba a los atacantes acceso a su computadora. Desde ahí, con ayuda de una herramienta interna de IA, llegaron a otro ingeniero del área de billeteras. Ese ingeniero guardaba en su equipo una credencial para desplegar servicios en los sistemas de Binance.
Con esa credencial, el atacante envió solicitudes de retiro no autorizadas desde dentro de la propia plataforma. Las solicitudes llevaban los permisos de un servicio interno, así que para el resto de los sistemas parecían operaciones legítimas. Los hallazgos iniciales de Binance no muestran que se filtraran las claves privadas de las billeteras.
Polymarket: un script de confianza. Este caso es más pequeño y, en algunos aspectos, más revelador. Los atacantes secuestraron un script externo que la plataforma usaba para medir el rendimiento del sitio. En lugar de hacer eso, el código revisaba el navegador de cada visitante en busca de una sesión iniciada. Si la encontraba, usaba las propias funciones del sitio para vender posiciones y solicitar retiros.
Todo ocurrió en segundos. En una muestra de 30 cuentas vaciadas, Bitquery encontró que cada retiro se ejecutó entre tres y siete segundos después de aprobarse. Todos pasaron por la infraestructura de Polymarket como transacciones normales. No se tocó ningún contrato inteligente ni se robó ninguna contraseña. Que la plataforma tuviera que cerrar después todas las sesiones activas dice mucho sobre dónde estaba el verdadero acceso.
Lo que tienen en común. El sector lleva más de una década invirtiendo en proteger la puerta de entrada. El onboarding, la verificación de identidad, el filtrado de listas de sanciones y la huella digital de dispositivos han mejorado enormemente. Responden muy bien a una pregunta: si la persona que abre la sesión es quien dice ser. En Binance y Polymarket, todos los controles de identidad funcionaron, pero los atacantes no los necesitaban: actuaron desde sesiones y accesos que ya estaban verificados.
La verificación dura un instante, la confianza se mantiene
En la mayoría de los sistemas financieros, un control de identidad establece quién abrió la sesión, y muchas veces es la última vez que alguien lo comprueba. A partir de ahí, un token, una cookie o una aprobación firmada carga con toda la autoridad de la persona usuaria, y cualquier cosa que lo obtenga hereda esa autoridad por completo.
Los atacantes actuales ya hicieron las cuentas. Falsificar una identidad significa superar una verificación que se vuelve más difícil cada año. Secuestrar una sesión significa esperar a que una persona legítima haga la parte difícil y entrar detrás de ella. Un equipo comprometido, un script de navegador alterado, una extensión maliciosa o una aplicación móvil interceptada llevan al mismo premio: una sesión que, para todos los sistemas posteriores, se ve exactamente igual que la del cliente.
Por eso la cifra de Polymarket me preocupa más de lo que su tamaño sugiere. La suma es modesta, pero vaciar 737 sesiones activas en una hora, a través de un script que la propia plataforma decidió cargar, es una prueba de concepto para cualquier producto financiero con una interfaz web.
La entrevista fue el ataque
El caso de Binance lleva a la misma conclusión desde otro lado. Mis colegas han escrito sobre candidatos falsos que usan identidades sintéticas para entrar en empresas. En Binance ocurrió al revés: el atacante se hizo pasar por el empleador, y el malware llegó a través de la propia entrevista. En los dos escenarios, el atacante buscó el acceso después del control de identidad, así que el control nunca falló.
El mismo patrón aparece en préstamos con el fraude guiado. Aquí el solicitante es real, la identidad es real y los documentos son reales. Un estafador acompaña al prestatario por teléfono o por chat y le indica cada paso de la solicitud. La verificación se supera porque no hay nada que falle: la sesión es legítima y solo la intención es fraudulenta.
Los prestamistas que consiguen detectarlo lo hacen observando lo que pasa dentro de la sesión, no en la entrada. Las señales son claras: dudas en campos que un solicitante real respondería de memoria, datos pegados donde se esperaría que se escribieran y un ritmo que se parece más a un dictado que a un recuerdo.
La señal está en el comportamiento
La misma lógica se aplica a una cuenta de inversión o al servicio interno de firmas de una plataforma. Una sesión que de repente liquida todas las posiciones, aprueba un retiro segundos después de firmarlo y envía los fondos a una dirección que la cuenta nunca había usado no se comporta como la persona que inició sesión, por válido que sea su token.
El monitoreo continuo de la sesión autenticada no es una idea nueva. La mayoría de las instituciones simplemente lo tratan como un complemento del inicio de sesión y no como el control principal, y ese orden tiene que cambiar.
Empieza con una línea base. Cada cuenta y cada empleado con privilegios tienen un ritmo propio: duración de las sesiones, recorridos de navegación, importes de las transacciones y frecuencia de las aprobaciones. Los cambios en esos patrones pueden alertar de que algo va mal, muchas veces antes de que se liquide una transferencia.
Sigue con la integridad del entorno, es decir, revisar el dispositivo, el navegador y los scripts cargados durante toda la sesión, no solo al iniciarla. Un control de inicio de sesión nunca vuelve a revisar lo que contiene un script de confianza.
El último elemento es la capacidad de actuar. Una detección que genera una alerta para que un equipo la revise al día siguiente no sirve de nada contra un ataque que se completa en 20 minutos. El control tiene que poder restringir una sesión, retener una transacción o exigir una segunda firma por su cuenta, y alguien tiene que haber asumido esa decisión de antemano.
Los bancos no deberían mirar desde la barrera
El sector cripto absorbió el daño inmediato. Binance afirma haber repuesto cerca del 95 % de los activos afectados con recursos propios y fondos de seguro, y se reporta que se congelaron unos 3,000 millones de dólares. En comparación, los clientes retiraron un neto de 4,720 millones de dólares cuando se restableció el acceso. Los congelamientos recuperaron parte de la pérdida, pero llegaron cuando el dinero ya se había ido.
Los bancos y las empresas de pagos de América Latina enfrentan el mismo desafío de fondo. Pix y SPEI liquidan transferencias en segundos y de forma irreversible. Las finanzas abiertas en Brasil y México extienden la vida de los tokens y las sesiones de API. La administración remota y las sesiones de larga duración hacen lo mismo. Cada una de estas extensiones permite que alguien que nunca fue verificado actúe como alguien que sí lo fue.
El récord anterior de robo de criptomonedas, los 1,500 millones de dólares que se llevaron de Bybit en febrero de 2025, empezó con el equipo comprometido de un desarrollador en Safe, la interfaz multifirma que usaban los firmantes de Bybit. Es el mismo patrón de autoridad prestada. La pérdida de Bybit fue una advertencia para el sector, y no bastó.
Un consejo de administración debería preguntar a sus responsables de riesgo y seguridad qué se sigue vigilando, en concreto, de una persona usuaria o un empleado después de la verificación, y qué se puede detener. Si la respuesta honesta es un motor de reglas que solo se activa cuando la transferencia ya está en curso, la institución está defendiendo un perímetro que los atacantes abandonaron hace tiempo.
Artículo (contenido experto) original de Nauman Abuzar, VP de Riesgo y Cumplimiento en SEON, publicado el 6 de noviembre de 2026. Traducido y revisado por el equipo hispanohablante de SEON.
