Cómo un desarrollador frontend junior puede buscar rastros de compromiso en el repositorio local y la configuración de paquetes inmediatamente después de un ataque
No hay tiempo para pasarse la noche buscando en Google tras enterarse de noticias sobre un incidente de seguridad. En mayo de 2026, se distribuyó una extensión maliciosa de Visual Studio Code que comprometió las máquinas de los desarrolladores y filtró unos 3800 repositorios de código fuente de la empresa. En esta situación, borrar código a lo ciego o formatear la laptop destruirá las pruebas forenses y hará imposible encontrar la causa. Vamos a revisar directamente los registros de ejecución del gestor de paquetes, las marcas de tiempo de las CLI globales y los permisos de los procesos activos para comprobar si fuimos vulnerados.
Autodiagnóstico de si tu entorno de desarrollo local fue comprometido en 10 minutos
Los gestores de paquetes dejan registros de transacciones en el directorio de caché del sistema durante el proceso de instalación. npm arroja registros de depuración en la carpeta _logs dentro de la ruta npm config get cache, y pnpm almacena los artefactos en pnpm store path. Dado que los paquetes maliciosos extraen variables de entorno o credenciales mediante scripts que se ejecutan en el momento de la instalación, debes revisar primero el historial de ejecución del ciclo de vida.
El siguiente comando busca registros de los últimos 14 días para detectar la adición no autorizada de paquetes o la ejecución de scripts externos. Abre la terminal y ejecuta los comandos tal cual se muestran a continuación.
`bash
NPM_CACHE_DIR=$(npm config get cache)
find $NPM_CACHE_DIR/_logs/ -type f -mtime -14 -exec grep -Hn "lifecycle" {} +
`
Revisa en la pantalla de resultados si se ejecutaron ganchos preinstall o postinstall que no hayas autorizado. Terminarás en tres minutos. Si no hay registros de comunicación con URLs externas extrañas, puedes respirar tranquilo respecto al miedo de contaminación directa a nivel de paquete.
Los atacantes incrustan binarios maliciosos en herramientas CLI globales o en la caché de npx para persistir dentro de la laptop. Obtén la lista de paquetes instalados globalmente y compara la fecha de creación y modificación de los archivos en la carpeta de binarios con los registros del sistema para verificar su integridad.
`bash
npm list -g --depth=0 --json
ls -lact $(npm config get prefix)/bin/
`
Si el momento de la modificación coincide con una franja horaria anómala, extrae los valores hash con el siguiente comando para contrastarlos.
`bash
shasum -a 256 $(npm config get prefix)/bin/
`
Los scripts de instalación de paquetes se ejecutan con los mismos permisos que la cuenta del desarrollador. Debes detener los procesos demonio que corren en segundo plano.
`bash
ps aux | grep -E "node|npm|pnpm|bun" | grep -v grep
lsof -i -P -n | grep -E "node|npm|pnpm"
`
Si un proceso sospechoso se está comunicando con un servidor C2 externo, detenlo y mátalo de inmediato.
`bash
kill -9 [PID]
npm config set ignore-scripts true
`
Inspección de archivos de configuración de paquetes y contaminación de direcciones de registro
Un patrón frecuente en los ataques a la cadena de suministro consiste en alterar los archivos de configuración para interceptar el registro. Los atacantes incrustan direcciones de servidores espejo maliciosos en el archivo .npmrc del proyecto o en la configuración global. Dado que cambian la ruta de descarga de URL dentro del archivo de bloqueo (lockfile) para forzar la descarga de un tarball malicioso durante la instalación real, debes revisar a fondo todos los valores de configuración.
El procedimiento para verificar si hay anulaciones no autorizadas incrustadas en la configuración local y global es el siguiente. Primero, obtén la lista de enlaces de configuración.
`bash
npm config list
pnpm config list
`
A continuación, verifica que el ámbito del registro privado de la empresa esté configurado correctamente.
`bash
npm config get @company:registry
`
Busca también directamente si hay direcciones de espejos externos codificadas de forma rígida en los archivos de configuración del directorio principal del usuario y de la raíz del proyecto.
`bash
grep -Rn "registry" ~/.npmrc ./.npmrc
`
Al seguir estos tres pasos, podrás determinar en cinco minutos si se registró una dirección de espejo extraña.
Dado que los archivos package-lock.json y pnpm-lock.yaml registran las URLs de origen de descarga de dependencias, debes analizar si están contaminados utilizando expresiones regulares.
`bash
grep -E '"resolved": "https?://' package-lock.json | grep -vE 'registry.npmjs.org|registry.corp.example'
`
Si usas pnpm, introduce el siguiente comando.
`bash
grep -E 'resolution: {tarball:' pnpm-lock.yaml | grep -vE 'registry.npmjs.org|registry.corp.example'
`
Si encuentras un archivo de bloqueo contaminado, debes borrarlo por completo y generarlo nuevamente.
`bash
rm -rf node_modules package-lock.json pnpm-lock.yaml
npm cache clean --force
pnpm store prune
npm config set registry https://registry.npmjs.org/
npm ci --ignore-scripts
`
Si ignoras la ejecución de los scripts de ciclo de vida y reconstruyes el árbol de dependencias en un estado inmutable, podrás asegurar un entorno en estado puro.
Reducción de privilegios de claves SSH y tokens de API
En entornos Linux y Mac, los binarios maliciosos saquean el almacenamiento de contraseñas del navegador y recogen todas las claves de API de IA, claves de acceso de AWS y claves SSH integradas en las variables de entorno. Debes comprobar ahora mismo si tus credenciales han sido expuestas en el entorno de la terminal.
`bash
ls -la ~/.ssh/
env | grep -E 'TOKEN|KEY|SECRET|AUTH|AWS|GITHUB|OPENAI|ANTHROPIC'
grep -E '(ghp_[A-Za-z0-9]{36}|AKIA[0-9A-Z]{16}|bearer)' ~/.zsh_history ~/.bash_history
`
Si aparece alguna clave expuesta en texto plano, revócala inmediatamente sin titubear. Comprueba también el ámbito del token con el que iniciaste sesión en la CLI de GitHub.
`bash
gh auth status
`
Elimina de inmediato los tokens Classic que otorguen acceso a todos los repositorios. Al volver a crear un PAT (Personal Access Token), especifica únicamente repositorios concretos y limita los permisos de lectura al rango más estrecho posible.
Para aislar el host local y los procesos de desarrollo, debes utilizar la estructura de DevContainer. Crea el archivo .devcontainer/devcontainer.json en la raíz del proyecto y configura la imagen de la siguiente manera.
`json
{
"image": "mcr.microsoft.com/devcontainers/javascript-node:22",
"postCreateCommand": "npm ci --ignore-scripts"
}
`
Al iniciar el contenedor de esta forma, la instalación de paquetes y la compilación se ejecutan en un estado completamente aislado de las credenciales del sistema de la laptop principal, lo que bloquea de raíz cualquier vía de filtración de los activos de la empresa.