Cómo una prueba de código falsa drenó 11,8 millones de dólares de una empresa de criptomonedas

Recibí un mensaje en Signal el mes pasado de un desarrollador que casi cae en una trampa similar. El reclutador tenía un perfil pulido, un historial de recomendaciones de nombres reconocibles en el espacio Web3 y una descripción de puesto que ofrecía un aumento salarial del 40%. El desarrollador solo se retiró porque la "evaluación de código" requería que descargara un entorno personalizado en lugar de usar un IDE estándar basado en el navegador. Esa intuición salvó a su empresa. Otros no tuvieron tanta suerte. La Fuerza de Policía de Singapur y la Agencia de Seguridad Cibernética de Singapur detallaron recientemente una brecha en la que el deseo de un solo empleado por una mejor trayectoria profesional resultó en una pérdida de 11,8 millones de dólares estadounidenses.

Este incidente es un ejemplo de libro de texto sobre cómo los actores de amenazas modernos evaden defensas sofisticadas al dirigirse al elemento humano en el borde de la red. Los atacantes no buscaron un "zero-day" en un firewall o una falla en un protocolo criptográfico. Buscaron a una persona que estuviera dispuesta a demostrar su valía técnica en un dispositivo emitido por la empresa. Para cuando el centro de operaciones de seguridad notó la actividad inusual, los atacantes ya se habían movido desde una bandeja de entrada de LinkedIn hasta el corazón de la infraestructura financiera de la empresa.

El gancho psicológico de un trabajo de ensueño

La ingeniería social tiene éxito porque explota la ambición profesional. La campaña comenzó en LinkedIn, donde un estafador que se hacía pasar por reclutador de una firma de criptomonedas se acercó a la víctima. Esta fase consistió en generar confianza y legitimidad. El atacante trasladó la conversación al correo electrónico, utilizando un dominio suplantado que reflejaba la dirección de una empresa real. Para un empleado que revisa rápidamente su bandeja de entrada, una diferencia de una sola letra en un nombre de dominio es casi invisible.

El proceso de entrevista consolidó aún más el engaño. La víctima asistió a varias rondas en Google Meet. La persona al otro lado mantuvo su cámara apagada, citando problemas técnicos o de privacidad, una táctica común utilizada para ocultar la identidad de los actores de amenazas que operan desde jurisdicciones como Corea del Norte. Esta etapa es el caballo de Troya digital. El objetivo es hacer que la víctima sienta que está en una evaluación profesional de alto nivel, lo que baja su guardia cuando llega la "evaluación técnica".

Cuando la evaluación de código se convierte en un arma

In la etapa final del proceso de contratación, la víctima recibió un enlace a un sitio web suplantado. Se le indicó que completara una tarea de programación en su computadora portátil emitida por la empresa. Esta solicitud es estándar en la industria del software, lo que la convierte en un mecanismo de entrega ideal para cargas útiles maliciosas. Mientras la víctima ejecutaba el código proporcionado o instalaba el entorno de software sugerido, el malware se ejecutaba en segundo plano.

Este malware específico fue diseñado para recolectar tokens de sesión. Desde una perspectiva de riesgo, este es un escenario de pesadilla para cualquier departamento de TI. Los tokens de sesión son el equivalente digital a que el portero de un club VIP reconozca tu rostro después de que ya hayas mostrado tu identificación. Debido a que el token demuestra que el usuario ya se ha autenticado, el atacante no necesita saber la contraseña ni tener acceso al dispositivo físico de MFA de la víctima. Simplemente inyectan el token robado en su propio navegador y heredan la sesión activa de la víctima.

Envenenando el flujo de despliegue de software

Una vez que los atacantes obtuvieron el token de sesión, accedieron a la cuenta de Bitbucket de la víctima. Bitbucket es la materia oscura de un entorno de desarrollo; a menudo es invisible para el personal general, pero contiene la lógica central del negocio de la empresa. Acceder a un repositorio es una falla sistémica porque permite a los atacantes ver cómo la empresa construye y despliega software.

Detrás de escena, los intrusos modificaron las instrucciones automatizadas de despliegue de software. Al cambiar el código en el repositorio o los scripts que indican a los servidores cómo ejecutar ese código, los atacantes ganaron un punto de apoyo en la infraestructura interna. Este movimiento lateral les permitió saltar de una sola computadora portátil comprometida a los servidores de producción que manejan dinero real. En caso de una brecha como esta, el modelo de confianza de todo el ciclo de vida de desarrollo se rompe. Los atacantes ya no eran solo invitados en una computadora portátil; eran, efectivamente, administradores del código de la empresa.

Evadiendo la última línea de defensa financiera

La parte más dañina de la intrusión ocurrió cuando los atacantes llegaron a los sistemas utilizados para procesar transferencias de criptomonedas. La mayoría de las firmas utilizan límites de transacciones y verificaciones de aprobación de varias personas como contramedida contra el fraude interno o fallas de un solo punto. Sin embargo, los atacantes utilizaron las credenciales que recolectaron durante su movimiento por la red para modificar estos controles.

Al reescribir las reglas que regían cuánto dinero podía salir de la empresa y quién debía aprobarlo, los atacantes despejaron el camino para transferencias masivas. Las transacciones resultantes totalizaron 11,8 millones de dólares estadounidenses. Esto resalta una paradoja arquitectónica: incluso si el perímetro de su red es resistente, su lógica interna sigue siendo vulnerable si un atacante puede suplantar a un usuario de altos privilegios a nivel de raíz. Los atacantes no rompieron el cifrado de la cadena de bloques; rompieron el proceso humano que gestionaba las llaves.

La sombra de la actividad patrocinada por el estado

Aunque las autoridades de Singapur no atribuyeron oficialmente este ataque específico a un grupo concreto, las tácticas son notablemente similares a las campañas dirigidas por actores de amenazas de Corea del Norte. Grupos como UNC4899, también conocidos como TraderTraitor, se han centrado intensamente en empresas de criptomonedas y blockchain desde al menos 2020. Son conocidos por acercarse a desarrolladores a través de LinkedIn y Telegram y persuadirlos para que ejecuten contenedores Docker maliciosos o instalen "complementos de la comunidad" para aplicaciones como Obsidian.

En incidentes anteriores, estos grupos han utilizado identidades generadas por IA para suplantar contactos de confianza. Estas campañas sitúan los entornos de desarrollo como el punto de compromiso, buscando tokens de GitHub, llaves SSH y credenciales de la nube. Hablando proactivamente, estos no son actos aleatorios de cibercrimen, sino operaciones dirigidas diseñadas para financiar intereses nacionales. La precisión requerida para modificar los flujos de despliegue y evadir los controles de transacciones sugiere una profunda familiaridad con los flujos de trabajo internos de las firmas de criptomonedas.

Reforzando el firewall humano y técnico

Para evitar que se repita este desastre de 11,8 millones de dólares, las empresas deben ir más allá de la capacitación básica en concienciación sobre seguridad. Confiar en que un empleado detecte un dominio suplantado es una estrategia reactiva que eventualmente fallará. Un enfoque más granular implica asegurar la infraestructura de modo que un solo dispositivo comprometido no pueda derribar a toda la firma.

Primero, las empresas deben imponer la autenticación multifactor basada en hardware, como las llaves de seguridad FIDO2. Los tokens de sesión robados son mucho más difíciles de usar cuando el sistema requiere un toque físico en un dispositivo dedicado para acciones sensibles como acceder a repositorios de código. Segundo, el acceso a Bitbucket y otras herramientas de misión crítica debe gestionarse a través del aprovisionamiento Just-in-Time (JIT). Ningún desarrollador debería tener acceso permanente y constante a los flujos de despliegue de producción.

Finalmente, cualquier evaluación técnica relacionada con el trabajo debe realizarse en un entorno de "sandbox" que esté completamente aislado de la red corporativa. Si un reclutador le pide a un candidato que ejecute código en una computadora portátil de la empresa, eso debería activar una alerta inmediata en el centro de operaciones de seguridad. Evaluar la superficie de ataque significa reconocer que la computadora portátil de un desarrollador es a menudo el objetivo más valioso del edificio.

Conclusiones prácticas para equipos técnicos

1. Utilice hardware dedicado y no corporativo para todas las tareas relacionadas con la contratación, incluidas las pruebas de código y las entrevistas.
2. Implemente políticas estrictas de complementos a nivel de aplicación para herramientas de productividad para evitar la ejecución de código no autorizado.
3. Audite sus registros de acceso de Bitbucket y GitHub en busca de signos de secuestro de sesión, como inicios de sesión desde direcciones IP inesperadas utilizando tokens válidos.
4. Revoque las sesiones activas de inmediato si un empleado informa un comportamiento sospechoso durante una interacción externa.
5. Fortalezca los controles de transacciones internas requiriendo aprobaciones desde dispositivos que estén físicamente separados de la red de desarrollo.

Fuentes: Fuerza de Policía de Singapur (SPF), Agencia de Seguridad Cibernética de Singapur (CSA), Google Cloud Mandiant (Informe UNC4899), Marco MITRE ATT&CK.

Descargo de responsabilidad: Este artículo es solo para fines informativos y educativos y no reemplaza una auditoría de ciberseguridad profesional o un servicio de respuesta a incidentes.