Binance y Redbanc: la oferta de trabajo que abre la puerta

Un mensaje de un reclutador. Una oferta buena, de esas que cuesta dejar pasar. Una entrevista que parece normal y, casi al final, una prueba técnica: “descarga este proyecto y cuéntanos cómo te va”.

Así empezaron, con ocho años de diferencia, la intrusión a la red de cajeros de Chile y el mayor robo de criptomonedas registrado. Cambiaron las herramientas. La técnica, no.

Qué pasó en Binance

El 29 de octubre de 2026, desde las 20:05 UTC, comenzaron a salir fondos de las billeteras calientes de Binance, la mayor casa de intercambio de criptomonedas del mundo. En su comunicado oficial del 3 de noviembre, Binance habla de unos US$6.340 millones en activos afectados.

Lo más útil del comunicado es que cuenta cómo se llegó hasta ahí. Binance descarta que haya sido “una brecha aislada o un simple phishing” y describe una campaña en etapas:

1. Junio: una herramienta manipulada. Un ingeniero del equipo de billeteras buscó en internet una herramienta de programación con inteligencia artificial e instaló un Homebrew (un instalador de programas) adulterado. Seguridad detectó la anomalía, cambió el computador y rotó las credenciales. Pero el atacante ya sabía quién trabajaba en la infraestructura de billeteras.
2. Septiembre: la entrevista falsa. Otro ingeniero fue contactado por un supuesto director de proyecto a través de una plataforma de empleo legítima. Tuvo una entrevista en video con una falsa persona de recursos humanos y una segunda con alguien que se presentó como gerente general de una empresa ficticia. Al final le pidieron descargar un “ejercicio” en su equipo de trabajo. Era un repositorio malicioso que reemplazó un componente de pyenv y abrió comunicación con un servidor del atacante. Según Binance, las herramientas de protección del equipo no lo detectaron en ese momento.
3. 20 de octubre: se amplía el acceso. Con ese computador y una herramienta interna de IA, el atacante tomó control de otros dos ingenieros. En uno encontró un token que permitía desplegar contenedores.
4. 29 de octubre: el robo. Entre las 17:15 y las 19:56 UTC, el atacante usó esas credenciales para desplegar un contenedor y ejecutar un script. Con él accedió al servicio interno de firma de billeteras e inició transacciones fuera del proceso normal de retiros.

Binance atribuye la responsabilidad a Corea del Norte, citando la información más reciente del FBI. Dice además que en 2026 detectó y frenó otros 57 casos vinculados a ese país. TRM Labs, Chainalysis y Elliptic apuntan al grupo TraderTraitor.

Por qué fue tan difícil frenarlo

Hubo un detalle técnico que explica por qué el daño siguió creciendo. En Ethereum, el atacante usó una función llamada EIP-7702 para dejar autorizaciones registradas en la cadena, que funcionaban por separado de la infraestructura de retiros de Binance. Por eso, suspender los retiros no las apagó. Y como la billetera usaba computación multipartita (MPC), no existía una clave única para revocarlas de inmediato: el equipo tuvo que diseñar un procedimiento especial. La delegación se borró el 30 de octubre a las 00:10 UTC.

Cómo terminó, por ahora

• Unos US$2.850 millones quedaron congelados o interceptados, en coordinación con emisores de stablecoins, autoridades y firmas de inteligencia blockchain. Es una cifra sujeta a conciliación.
• Binance asegura que los usuarios no pagan la pérdida y que al 31 de octubre había repuesto el 98% de los activos afectados.
• La investigación sigue abierta, parte de los detalles técnicos se mantendrá en reserva y los hallazgos serán revisados por terceros.

La herramienta de IA: lo que se sabe y lo que no

Es el detalle más moderno del caso y también el más escueto. Binance dice que el 20 de octubre el atacante usó el computador comprometido del ingeniero B “y una herramienta interna de IA” para tomar control de otros dos ingenieros. No nombra la herramienta, no explica para qué servía ni cómo se abusó de ella. Lo único que sí informa es que la reconstruyó junto con sus controles de acceso, lo que confirma que formó parte de la ruta.

Los analistas llenan el vacío con hipótesis, y conviene separarlas del comunicado:

• Vectra plantea que nadie explotó una falla de la herramienta: el atacante ya actuaba con la sesión del ingeniero B y la herramienta hizo lo que estaba diseñada para hacer, conectar personas entre equipos.
• StepSecurity subraya que el informe no habla de un zero-day, de prompt injection ni de una falla de MCP como causa.
• CSO Online sospecha que la herramienta tenía privilegios demasiado amplios o controles de acceso débiles, y pregunta por qué el token de despliegue era de larga duración y si el despliegue exigía alguna aprobación.

Ninguna de estas lecturas es un hecho confirmado. Lo que sí podemos sacar de ahí es una regla: una herramienta interna de IA es una identidad con privilegios, no una utilidad. Si actúa con la sesión de quien la usa, un equipo comprometido le entrega al atacante todo lo que esa herramienta alcanza. Cada servicio debe autorizar por sí mismo, y cada acción debería quedar registrada con quién la inició, hacia dónde fue y qué hizo.

Qué pasó en Redbanc en 2018

La historia es pública. A fines de diciembre de 2018, un profesional informático de Redbanc, la red de cajeros automáticos de Chile, respondió a un aviso de trabajo en LinkedIn. La entrevista fue por Skype, en español. En medio de la conversación le pidieron descargar y ejecutar un “formulario de postulación”: un archivo llamado ApplicationPDF.exe.

Era malware. Flashpoint lo identificó como PowerRatankba, una herramienta vista antes en campañas atribuidas al grupo norcoreano Lazarus. La atribución nunca fue confirmada oficialmente y se basa en esa reutilización de herramientas.

Redbanc informó que el programa se instaló sin activar el antivirus, pero que su sistema de monitoreo detectó comportamiento anormal, que la amenaza se mitigó y que no hubo impacto en sus operaciones. El caso se conoció en enero de 2019.

El patrón se repite

No estamos hablando de un ataque sofisticado a un firewall. Estamos hablando de una persona con acceso valioso a quien le interesa su carrera. El atacante no necesita romper nada si logra que el empleado ejecute el programa por él.

¿Por qué sigue funcionando?

Porque ataca donde no mira nadie:

• Nadie tiene una política para las ofertas de trabajo. Es un tema personal que termina en el equipo de la empresa.
• Una prueba técnica pide ejecutar código ajeno. Para un desarrollador es normal. Ahí está la trampa.
• El antivirus no es una garantía. Ni en 2018 ni en 2026 saltó a tiempo.
• El atacante elige a quién. En Binance sabía qué ingenieros trabajaban en billeteras desde junio. Y el ingeniero contactado en septiembre tenía un perfil público que mencionaba su trabajo en Binance.

¿Qué hacer desde el lado defensivo?

Ninguna de estas medidas exige comprar herramientas nuevas. Exigen decidirlas y repetirlas:

1. Ningún archivo ni prueba técnica de un reclutador se ejecuta en un equipo de la empresa. Si alguien quiere hacerla, que sea en una máquina virtual aislada o en un equipo personal sin accesos.
2. Instala herramientas desde su sitio oficial, no desde un buscador. El primer eslabón de Binance fue un instalador adulterado que apareció en una búsqueda.
3. Si contienes un incidente, asume que el atacante ya sabe quién eres. Binance cambió el equipo y rotó credenciales en junio, y aun así los colegas del ingeniero siguieron siendo blanco. Después de un incidente menor, vigila de cerca a las personas expuestas.
4. No dejes tokens de despliegue en los computadores, y trata tus herramientas internas de IA como cuentas con privilegios. Credenciales de vida corta, atadas al dispositivo, para que un token robado no baste para desplegar contenedores. A la herramienta, los mismos permisos mínimos que a cualquier cuenta de servicio y un registro de lo que hace.
5. Que nadie mueva dinero solo. Transferencias, retiros y cambios de cuentas con una segunda verificación por otro canal, y límites por operación. Es lo que, en este caso, el atacante esquivó usando el servicio de firma.
6. Quita el acceso humano directo a producción y limita los permisos de las cuentas de servicio, como explicamos en minimizar privilegios.
7. Ensaya cómo revocar. Apagar un servicio no apaga lo que ya quedó autorizado. Define con anticipación cómo cortar accesos y permisos, incluso los que no dependen de tu infraestructura.
8. Mira el comportamiento, no solo las firmas. En Chile fue el monitoreo de conducta anormal lo que dio la alerta. En Binance, una alerta interna por transferencias de gran volumen. Mientras más corto el tiempo que un intruso pasa adentro, menor el daño.
9. Capacita a las personas. Una oferta de trabajo falsa se reconoce si alguien te enseñó a mirarla. Es el hábito de capacitar periódicamente.
10. Ten un plan de respuesta ensayado. Binance logró congelar o interceptar cerca de la mitad de lo robado porque coordinó con emisores, autoridades y firmas de inteligencia blockchain. Define quién decide, a quién avisas y cómo cortas accesos antes de necesitarlo.

Si quieres revisar cómo está tu organización, nuestro equipo de Blue Team y respuesta a incidentes puede ayudarte, y FreeScan te da una primera foto de tu postura web sin costo ni compromiso.

Material informativo. Fuentes: comunicado oficial de Binance “29 October 2026 Binance Security Incident: Initial Findings and Response Update” (3 de noviembre de 2026), complementado con TRM Labs, Chainalysis, Elliptic, Security Alliance (SEAL), StepSecurity, Vectra y CSO Online para el caso de 2026, y con Flashpoint y los reportes públicos de 2019 para el caso de Redbanc. Las cifras corresponden al 10 de noviembre de 2026. La investigación de Binance sigue abierta y los datos pueden cambiar. La atribución del caso de 2018 se basa en análisis técnico de terceros y no fue confirmada oficialmente.