Una oferta de trabajo por LinkedIn prometía teletrabajo y revisar un proyecto de videojuegos descentralizado; en realidad era una trampa diseñada por el grupo Lazarus que escondía tres mecanismos de infección dentro de un repositorio. El objetivo final era claro: robar monederos de criptomonedas y credenciales. De acuerdo con el análisis de DLTCode y AllSecure, el ataque aprovechó funciones legítimas de desarrollo para ejecutarse sin que la víctima notara nada.
¿Qué pasó exactamente?
Vemos un ataque que combina ingeniería social con abusos técnicos muy concretos. Los atacantes contactaron por LinkedIn, agendaron una videollamada (algunos procesos pedían 45 minutos de entrevista) y solicitaron que el candidato descargara un repositorio para «revisar el código». Al abrir la carpeta en Visual Studio Code se dispararon tres mecanismos: tareas automáticas de VS Code que ejecutan comandos en segundo plano; scripts de instalación npm que exfiltran credenciales durante el proceso de instalación; y un tercer componente redundante que asegura la persistencia. DLTCode reportó que la operación llevaba activa desde septiembre de 2025 y controlaba 11 servidores de comando y control, según su investigación. Además, el FBI atribuye al grupo Lazarus un botín en criptomonedas estimado en USD 1.500 millones, lo que da una idea del alcance económico de estas campañas.
¿Cómo te puede afectar si sos desarrollador o freelancer?
Lo que convirtió esto en una trampa eficaz fue que pide exactamente lo que un desarrollador hace a diario: abrir proyectos y ejecutar dependencias. Si sos ingeniero o freelancero, abrí los ojos ante tres señales: 1) te contactan por LinkedIn para un proyecto «extraordinario» y te piden ejecutar código en la primera llamada; 2) hay insistencia en que arranques el repo en local; 3) las instrucciones parecen generadas por IA o contienen inconsistencias. En dos casos documentados por DLTCode y AllSecure, el mismo modus operandi se repitió en países distintos. Papathanasiou, CEO de AllSecure, empezó a grabar la videollamada y luego analizó el repositorio desde un entorno aislado; Claudio Chifa, de DLTCode, también investigó el código antes de ejecutarlo. Ninguna empresa legítima debería pedir que ejecutes código de origen desconocido en la primera interacción.
Qué hacer hoy: checklist práctico y rápido
Vemos que las medidas simples y verificables son las más útiles. Primero, desactivar la ejecución automática de tareas en Visual Studio Code y revisar el archivo .vscode/tasks.json antes de abrir cualquier proyecto. Segundo, inspeccionar package.json y scripts de instalación — si hay un postinstall sospechoso no instales dependencias en tu máquina principal. Tercero, abrir el proyecto en un entorno aislado: una máquina virtual, un contenedor Docker o un sandbox que no tenga credenciales ni claves montadas. Cuarto, si ya abriste algo y sospechás, rotá claves AWS/Stripe/SSH y cambiá contraseñas almacenadas; usá un gestor de contraseñas para verificar accesos. Quinto, reportá el incidente: en España podés comunicarte con INCIBE y el Grupo de Delitos Telemáticos de la Guardia Civil, según lo recomendado por los especialistas.
Si llegaste hasta acá, ya tenés lo más difícil hecho: identificar el patrón social y técnico. Si esto te parece demasiado técnico, la alternativa honesta es pedir pruebas de identidad de la empresa y revisar el repositorio en CodeSandbox o en un VM antes de aceptar cualquier prueba técnica. La tecnología tiene que salvar tiempo, no consumirlo: estas precauciones toman minutos y pueden ahorrar pérdidas irreparables.
Perspectiva y cierre
Vemos que los grupos estatales como Lazarus no escatiman en complejidad ni en inversión. La combinación de deepfakes en videollamadas y cadenas de ejecución automáticas convierte ofertas legítimas en vectores de compromiso. Desde el punto de vista práctico, la mejor defensa es la sospecha razonable: no ejecutar nada sin auditarlo y preferir entornos aislados. También es útil exigir procesos de selección que no pidan poner en riesgo tu máquina personal en el primer contacto. Mantener las buenas prácticas de seguridad —deshabilitar automatismos, revisar scripts y rotar claves cuando algo no cuadra— es la forma más directa de reducir la ventana de ataque.
