El robo a Binance empezó con una entrevista de trabajo: el acceso determinó el costo

En septiembre, un ingeniero de software de Binance pasó por dos entrevistas de trabajo con una empresa que no existía. La primera fue una videollamada en directo con un representante de Recursos Humanos que compartió una cuenta personal de redes sociales, con fotos y videos, para demostrar que era una persona real. La segunda tuvo lugar en una aplicación de chat, con alguien que se presentó como el director ejecutivo. Hacia el final, le pidieron al ingeniero que descargara una prueba de programación en su computadora de trabajo.

El 29 de octubre, los atacantes sacaron de las billeteras de Binance unos 6,34 mil millones de dólares, la mayor parte en aproximadamente 20 minutos. El FBI atribuyó el robo a TraderTraitor, el grupo norcoreano al que también se responsabiliza del robo de 1.500 millones de dólares a Bybit en febrero de 2025. Es el mayor robo de criptomonedas del que se tiene registro.

Binance ha asumido la responsabilidad y afirma que cubrirá las pérdidas. Al 3 de noviembre, informó que había repuesto el 98 % de los activos afectados en tokens y que se habían congelado o interceptado unos 2.850 millones de dólares.

La pregunta que vale la pena plantearse es: ¿a qué podía acceder una sola computadora portátil comprometida, y puede cada equipo comprobarlo hoy en su propio entorno?

Dos vías de acceso y una campaña que se extendió de junio a octubre

Nada en la actualización de Binance del 3 de noviembre apunta al uso de ultrafalsificaciones u otras técnicas asistidas por IA. Ambas vías de acceso pasaron por personas: un ingeniero que confió en un resultado de búsqueda y otro que confió en un reclutador.

La campaña duró al menos cinco meses. En junio, un ingeniero de DevOps del equipo de billeteras que buscaba una herramienta de programación con IA descargó un instalador manipulado de Homebrew. El equipo de seguridad de Binance detectó la anomalía, reemplazó el dispositivo y cambió las credenciales. Para entonces, los atacantes ya habían averiguado quiénes formaban parte del equipo de infraestructura de billeteras.

Tres meses después, volvieron por otra vía. El ingeniero al que contactaron en septiembre tenía un perfil en una plataforma legítima de búsqueda de empleo donde mencionaba su experiencia en Binance. La prueba de programación contenía malware que se ejecutaba durante la instalación, sustituía un componente legítimo de pyenv por uno malicioso, se conectaba a un servidor controlado por los atacantes y borraba sus rastros. Binance afirma que su protección de endpoints no lo detectó.

El 20 de octubre, los atacantes utilizaron esa computadora portátil y una herramienta interna de IA para tomar el control de las computadoras de otros dos ingenieros; una de ellas pertenecía al ingeniero de DevOps comprometido en junio. En esa computadora encontraron un token con permisos para desplegar contenedores. El 29 de octubre, iniciaron sesión en la computadora del otro ingeniero, usaron las credenciales robadas para desplegar un contenedor y ejecutaron el script que puso en marcha el robo.

Por qué siguen funcionando los engaños de los reclutadores

Los reclutadores falsos y las pruebas de programación manipuladas forman parte de un repertorio de larga data. Desde hace años, operativos norcoreanos las utilizan contra desarrolladores, sobre todo en la campaña conocida como Contagious Interview. Binance afirma que solo en 2026 detuvo 57 intentos sospechosos vinculados a Corea del Norte.

El engaño funciona porque pide a los ingenieros que hagan algo que hacen a diario. Ejecutar un repositorio desconocido es algo normal en una entrevista técnica. No hay una dirección de correo sospechosa ni un enlace sobre el que pasar el cursor; solo un empleador verosímil, una persona en una videollamada y una tarea que parece trabajo.

Además, el mensaje de un reclutador es uno de los pocos contactos no solicitados que la gente recibe con agrado. Ningún programa de concienciación puede garantizar que todos los ingenieros detecten cada intento convincente, así que los controles deben partir de la premisa de que alguno logrará pasar.

Cómo una computadora portátil llegó hasta las billeteras

Mi primera pregunta se refiere a los controles de seguridad del entorno de ese ingeniero. El uso de una computadora de trabajo para realizar una prueba de programación externa merece un examen minucioso. La preocupación mayor es cómo ese único compromiso permitió acceder a otros sistemas y, finalmente, a una infraestructura financiera sensible.

Cada paso posterior a la infección inicial se basó en la confianza que ya existía dentro de Binance. Una herramienta interna de IA aceptó instrucciones de una computadora comprometida y las hizo llegar a los dispositivos de otros empleados. Un token de despliegue estaba en la computadora portátil de un ingeniero. Un despliegue de contenedor realizado con credenciales válidas movió miles de millones. Nada de esto requirió otro engaño.

Las herramientas internas de IA merecen especial atención. A menudo tienen permisos amplios en repositorios, endpoints y servicios, por lo que quien controla una computadora capaz de darles instrucciones hereda su alcance.

Cómo proteger a los desarrolladores sin frenar la ingeniería

Los desarrolladores necesitan descargar paquetes, ejecutar código desconocido y probar software. Bloquear sus computadoras portátiles como si fueran estaciones de trabajo del área financiera frenaría la ingeniería y empujaría a los ingenieros a buscar soluciones alternativas. Es razonable establecer una política que prohíba realizar actividades de búsqueda de empleo en dispositivos corporativos, pero nadie cumple una política en todo momento. El objetivo práctico es limitar lo que puede hacer a continuación una computadora de desarrollador comprometida.

Un puñado de controles marca la mayor diferencia. El código no confiable debe ejecutarse en máquinas virtuales desechables sin acceso a las credenciales corporativas. Siempre que sea posible, las credenciales de despliegue deben tener una vigencia breve, un alcance limitado y emitirse a flujos de trabajo de despliegue controlados. Las claves de firma de billeteras o sus fragmentos deben protegerse por separado de las estaciones de trabajo de los desarrolladores, y las políticas de firma deben limitar qué transacciones y autorizaciones pueden aprobarse. Las acciones que afecten a sistemas de billeteras, pagos o producción deben requerir la aprobación de una segunda persona desde otro dispositivo. Las herramientas internas de IA deben ejecutarse con los permisos mínimos y registrar sus acciones.

La detección también debe funcionar cuando las credenciales son legítimas. La supervisión del comportamiento que alerta sobre un despliegue desde una máquina inesperada o a una hora inusual da al equipo la oportunidad de intervenir aunque todas las credenciales parezcan correctas. Binance afirma que ha ampliado este tipo de detección desde el incidente.

Dónde encaja la inteligencia sobre amenazas

La alerta se hizo pública seis semanas antes del robo. El aviso conjunto sobre Contagious Interview describía a operadores que se hacían pasar por reclutadores de empresas de IA, criptomonedas y NFT para atacar a profesionales de TI y robar criptomonedas. El caso de Binance siguió el mismo modus operandi.

La inteligencia sobre amenazas cumple una función concreta en campañas como esta. Los actores pueden cambiar, pero sus tácticas son conocidas. Los equipos que les siguen la pista pueden bloquear la infraestructura conocida y advertir a los ingenieros sobre los pretextos que se están utilizando en ese momento.

La inteligencia también permite saber quién necesita protección adicional. Cuando un incidente revela quién tiene acceso a información sensible, como ocurrió con la brecha de Binance en junio, esas personas deben considerarse objetivos probables durante meses, y sus dispositivos y los intentos de contacto que reciben deben vigilarse más de cerca.

Qué significa esto más allá del sector cripto

Las plataformas de intercambio de criptomonedas son un objetivo evidente porque los fondos robados se transfieren rápidamente y son difíciles de recuperar. Este patrón se da allí donde una estación de trabajo de un desarrollador está a pocos pasos de sistemas críticos, ya sea en la infraestructura de pagos de un banco o en los procesos de compilación y lanzamiento de un proveedor de software. Los pretextos de reclutamiento llegan a los ingenieros de todos esos sectores.

Para los responsables de seguridad que esta semana estén revisando sus propios entornos, hay dos comprobaciones que son prioritarias. Primero, hay que determinar a qué podría acceder hoy un único portátil de desarrollador comprometido, incluidos los tokens almacenados, las claves SSH, las credenciales de la nube y las herramientas internas de IA. Segundo, hay que confirmar que los despliegues en producción y las transacciones de alto valor requieren una aprobación independiente que una sola identidad comprometida no pueda otorgar.

Binance reconstruyó los sistemas afectados e incorporó revisores independientes, pero tomó esas decisiones después de sufrir las pérdidas. Las organizaciones que realicen ahora el mismo ejercicio podrán tomar esas decisiones según su propio calendario.