miércoles, 4 de noviembre de 2026 · Madrid
Guías· 05 de noviembre de 2026 · 6 min de lectura

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.

Caja de cartón abierta dentro de una urna de cristal sobre una mesa de acero, con hilos violetas luminosos que suben y chocan contra el vidrio, junto a una lupa y un flexo

“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.

PruebaResultado
ignore-scripts=true en tu usuario y ignore-scripts=false en el .npmrc del repoSe ejecuta el postinstall
Lo mismo, instalando con npm install --ignore-scriptsBloqueado
ignore-scripts=true y npm run devSe ejecuta dev, no su predev
npm install en npm 12 con una dependencia con postinstall sin aprobarBloqueado, con aviso
npm install en npm 12 con postinstall en el propio proyectoSe ejecuta
git clone de un repo con hooks y core.hooksPathNo se copian, no se ejecutan
Copia del proyecto con su .git y git checkoutSe ejecuta el hook
Copia con core.fsmonitor apuntando a un script y git statusSe 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

  1. Desconecta el equipo de la red y, si es de empresa, avisa a seguridad antes de tocar nada más.
  2. Cambia las credenciales desde otro dispositivo limpio: contraseñas guardadas en el navegador, tokens de GitHub y npm, claves SSH y de la nube.
  3. Cierra las sesiones abiertas. InvisibleFerret roba datos del navegador, así que cambiar la contraseña no siempre basta.
  4. Mueve tus fondos a una wallet nueva, generada en un dispositivo limpio. Si la semilla pudo quedar expuesta, la antigua ya no es segura.
  5. 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.

#seguridad#npm#malware#Contagious Interview#BeaverTail#VS Code#Git

📎 Fuente original: Unit 42 ↗

Noticias relacionadas

Preguntas frecuentes

¿Basta con usar npm install --ignore-scripts?
No. Evita los scripts de instalación, pero el código malicioso puede estar en la propia aplicación y ejecutarse al lanzar npm run dev o npm test. Es una capa útil, no una garantía.
¿Dónde pongo ignore-scripts=true?
En tu ~/.npmrc, y aun así pasa el flag al instalar. En nuestra prueba con npm 12.2.1, un .npmrc dentro del repo con ignore-scripts=false anuló la opción del usuario. El flag --ignore-scripts sí se impuso.
¿Un git clone puede ejecutar hooks del repo?
Un clone normal no copia los hooks ni core.hooksPath. El riesgo aparece si te pasan el proyecto con su carpeta .git, por ejemplo en un zip, o si un script del repo cambia tu configuración después.
¿npm 12 ya me protege?
En parte. En nuestra prueba, npm 12.2.1 bloqueó por defecto el postinstall de una dependencia no aprobada, pero sí ejecutó el del propio proyecto, que es justo el que controla quien te envía el repo.
¿Abrir el proyecto en VS Code es seguro?
Abrirlo en modo restringido limita la ejecución automática. El riesgo llega al pulsar que confías en los autores: un tasks.json con runOn folderOpen puede ejecutar comandos sin más avisos.
¿Qué hago si ya lo he ejecutado?
Desconecta el equipo, avisa a seguridad si es de empresa y cambia desde otro dispositivo limpio contraseñas, tokens, claves SSH y sesiones. Mueve los fondos de wallets que hubiera en esa máquina a una wallet nueva.

De la misma familia · ForjaCMS

¿Y si tu próximo cliente no necesitara WordPress?

Dale un panel para gestionar su contenido y quédate tú con una web Astro rápida, segura y fácil de mantener.

Descubre ForjaCMS