Revisado por Iván Quintas, Editor de IA News
¿Te manda un repo un reclutador? Compruébalo antes de ejecutarlo
Cómo revisar el repo de una entrevista antes de ejecutarlo. Probamos los consejos de un tuit: ignore-scripts, git hooks, VS Code y qué falla en cada uno.

“Antes de hacer npm install de un repo que te mandó un ‘reclutador’, revísalo”, escribía Jesús Morán en X. El consejo llega en buen momento: Binance contó a principios de noviembre que una prueba técnica de una entrevista falsa fue parte del camino hacia un robo de unos 6.340 millones de dólares.
Hemos contrastado la lista con la documentación y probado sus puntos técnicos. La base es buena, pero hay un consejo que puede fallarte, otro que necesita matiz y un vector que falta.
Contra qué te estás protegiendo
Unit 42, de Palo Alto Networks, bautizó esta campaña como Contagious Interview. MITRE la registra como grupo G1052. El método: un falso entrevistador te hace instalar un paquete. BeaverTail, JavaScript muy ofuscado, roba datos de wallets y tarjetas guardados en el navegador y descarga InvisibleFerret, una puerta trasera en Python con control remoto, keylogger y robo de credenciales.
Un aviso sobre el contexto. Binance no ha dicho que su caso usara BeaverTail ni npm: lo que describe es una prueba que alteraba pyenv durante la instalación. El engaño es el mismo, pero no hay que dar por hecha la misma familia de malware.
Lo que hemos probado
Usamos npm 12.2.1 y Git 2.43 con scripts inofensivos que solo creaban un archivo testigo.
| Prueba | Resultado |
|---|---|
ignore-scripts=true en tu usuario y ignore-scripts=false en el .npmrc del repo | Se ejecuta el postinstall |
Lo mismo, instalando con npm install --ignore-scripts | Bloqueado |
ignore-scripts=true y npm run dev | Se ejecuta dev, no su predev |
npm install en npm 12 con una dependencia con postinstall sin aprobar | Bloqueado, con aviso |
npm install en npm 12 con postinstall en el propio proyecto | Se ejecuta |
git clone de un repo con hooks y core.hooksPath | No se copian, no se ejecutan |
Copia del proyecto con su .git y git checkout | Se ejecuta el hook |
Copia con core.fsmonitor apuntando a un script y git status | Se ejecuta el script |
La revisión, paso a paso
1. No lo abras aún en tu editor
Empieza en una terminal, y mejor dentro de la máquina desechable del paso 7. Si llegó en un zip con carpeta .git, no lances comandos de Git dentro. Mira el contenido sin ejecutarlo:
cat .git/config
ls -la .git/hooks
Aquí el tuit se queda corto y a la vez exagera. Dice que un hooksPath hacia una carpeta del repo “corre solo con hacer checkout”. Es cierto si recibes el .git de otra persona, pero no pasa con un git clone normal. Y hay un riesgo que no menciona: core.fsmonitor, que en nuestra prueba ejecutó un script con un simple git status. Lo más sencillo es borrar ese .git que te han pasado.
2. Lee los archivos que ejecutan cosas solos
Empieza por package.json. Busca preinstall, install, postinstall y prepare, y desconfía de cualquier curl, comando largo o node sobre un archivo raro. Mira también dev, start y test, porque son los que te van a pedir que lances.
Después, lo que el tuit no cubre: .vscode/tasks.json.
cat package.json
ls -la .vscode 2>/dev/null
grep -rn "folderOpen" .vscode 2>/dev/null
GitLab y CSO Online describen esta variante. El repo incluye una tarea con "runOn": "folderOpen", y en cuanto concedes confianza a la carpeta se descarga la siguiente fase. No hace falta ningún npm install.
3. Cuando abras el editor, no le des tu confianza
VS Code abre las carpetas desconocidas en modo restringido, que limita tareas, terminal, depuración, extensiones y agentes de IA. Para leer código no necesitas más: responde que no confías en los autores. La presión de la entrevista juega a favor del atacante, como señala GitLab.
4. Busca código ofuscado
El comando del tuit solo mira .js y .ts. Lo ampliamos a otros formatos habituales y dejamos fuera node_modules:
grep -rnIE "eval\(|child_process|exec\(|atob\(|base64|https?://" \
--include=*.js --include=*.cjs --include=*.mjs --include=*.ts --include=*.json \
--exclude-dir=node_modules .
Y añadimos una búsqueda de líneas larguísimas, otra de las señales que menciona:
find . -type f \( -name '*.js' -o -name '*.cjs' -o -name '*.mjs' -o -name '*.ts' \) \
-not -path './node_modules/*' \
-exec awk 'length > 1000 {print FILENAME ": línea " FNR " (" length " caracteres)"}' {} +
Saldrán falsos positivos, sobre todo con las URL y los archivos minificados. Y el resultado contrario tampoco demuestra nada: no encontrar nada no significa que el repo esté limpio.
5. Revisa las dependencias
El tuit acierta. Mira los paquetes con nombres casi iguales a otros conocidos, los que apuntan a una URL de Git o un tarball y las versiones raras. Comprueba en npm su edad, sus descargas y su repositorio. Unit 42 también vio BeaverTail inyectado en proyectos legítimos, así que un nombre conocido o un repo que parece real no bastan.
6. Instala sin scripts, siempre con el flag
npm install --ignore-scripts
Pon también ignore-scripts=true en tu ~/.npmrc, no en el proyecto. Sirve de red, pero no te fíes solo de ella: como muestra la tabla, el .npmrc del repo puede anularla, y el flag no.
Ten en cuenta dos límites que la documentación de npm deja claros. npm run y npm test ejecutan igualmente el script que les pides. Y la política allowScripts de npm 12 se define en el propio proyecto, así que en un repo hostil tampoco la tomes por buena sin leerla.
7. Ejecútalo en un entorno desechable
Este es el paso que de verdad importa, y el tuit lo pone como “lo más importante” con razón. Todos los anteriores pueden fallar. Este reduce el daño cuando fallan.
Lo mejor es una máquina virtual sin tus cuentas. Un contenedor es una opción más ligera, aunque comparte el núcleo con tu sistema y protege menos:
# Instalar: necesita red, sin scripts
docker run --rm -v "$PWD":/app -w /app node:24-slim npm install --ignore-scripts
# Ejecutar: sin red
docker run --rm --network none -v "$PWD":/app -w /app node:24-slim npm run dev
Monta solo la carpeta del proyecto. Nada de ~/.ssh, ~/.aws, wallets, ni el socket de Docker, porque quien tiene el socket controla tu máquina. Si te piden tus claves reales para “probar la integración”, ya tienes tu respuesta.
Si ya lo has ejecutado
- Desconecta el equipo de la red y, si es de empresa, avisa a seguridad antes de tocar nada más.
- Cambia las credenciales desde otro dispositivo limpio: contraseñas guardadas en el navegador, tokens de GitHub y npm, claves SSH y de la nube.
- Cierra las sesiones abiertas. InvisibleFerret roba datos del navegador, así que cambiar la contraseña no siempre basta.
- Mueve tus fondos a una wallet nueva, generada en un dispositivo limpio. Si la semilla pudo quedar expuesta, la antigua ya no es segura.
- Reinstala el sistema. Borrar la carpeta del proyecto no elimina una puerta trasera.
La regla del tuit sigue siendo la correcta: un repo de una entrevista es código no confiable. Ninguna empresa seria te penalizará por ejecutarlo en una máquina aislada.
¿Te ha servido? Márcanos como fuente preferida en Google y verás antes nuestros artículos en Noticias destacadas, AI Overviews y AI Mode.
📎 Fuente original: Unit 42 ↗