TrapDoor: la campaña que convierte tu entorno de desarrollo en una puerta trasera para robar credenciales

Un nuevo operativo coordinado que los investigadores han bautizado como TrapDoor ha explotado los tres grandes repositorios de paquetes —npm, PyPI y Crates.io— para distribuir malware cuyo objetivo principal es robar credenciales y secretos de desarrolladores. Según los análisis, la campaña abarca más de 34 paquetes maliciosos en más de 384 versiones, con la primera actividad registrada el 22 de mayo de 2026 a las 20:20 UTC; las publicaciones se realizaron en oleadas desde un conjunto de cuentas que actuaron en rápida sucesión. Los atacantes han orientado específicamente a comunidades relacionadas con criptografía, DeFi, Solana y herramientas de IA, aprovechando que los desarrolladores de esos ecosistemas incorporan dependencias aparentemente inocuas en sus entornos de desarrollo y despliegue.

La técnica de entrega muestra una adaptación multipropósito a cada ecosistema: en npm se usaron ganchos postinstall y cargas remotas de JavaScript que se ejecutan al importar un paquete; en Rust se abusó de scripts de construcción (build.rs) para ejecutar código durante la compilación; y en Python las cargas se diseñaron para auto-ejecutarse en el momento del import. En una parte del ataque, los paquetes descargan JavaScript desde un dominio controlado por el atacante y lo ejecutan con node -e, permitiendo que el actor cambie comportamiento sin publicar nuevas versiones en los repositorios.

El malware implementado no se limita a robar contraseñas locales: escanea por claves SSH, wallets de criptomoneda, variables de entorno, datos de navegador y archivos de configuración, valida credenciales contra APIs de AWS y GitHub y trata de establecer persistencia mediante cron, systemd, hooks de Git y otros mecanismos. En Rust, se informó de exfiltración cifrada hacia Gists de GitHub tras encriptar artefactos con un XOR hardcodeado. Además, la campaña incluye una táctica llamativa: archivos como .cursorrules y CLAUDE.md con instrucciones ocultas que intentan inducir a asistentes de IA a ejecutar “escaneos” que revelen secretos; los atacantes también estuvieron creando pull requests en proyectos populares de IA para propagar esas instrucciones y ver si los flujos normales de contribución provocan que herramientas automáticas procesen código o instrucciones peligrosas.

Estas variantes muestran que los atacantes combinan la clásica suplantación por nombre de paquete con vectores modernos dirigidos al flujo de trabajo del desarrollador. Las consecuencias potenciales son graves: desde el robo directo de fondos en wallets y la toma de control parcial de infraestructuras cloud hasta la escalada lateral dentro de entornos corporativos mediante claves y tokens válidos. Además, el uso de cargas externas y la capacidad de modificar comportamiento sin publicar nuevas versiones incrementan la ventana de explotación y complican las mitigaciones basadas únicamente en auditorías de paquetes publicadas.

Frente a este tipo de campañas, hay medidas prácticas y urgentes que todo equipo y desarrollador debe considerar. En primer lugar, tratar las máquinas de desarrollo como activos críticos: utilizar entornos efímeros o contenedores aislados para pruebas de dependencias, restringir el acceso a credenciales locales y segmentar la red para minimizar egress no autorizado. En instalaciones automatizadas de paquetes en CI/CD, desactivar la ejecución de scripts de paquete cuando sea posible (por ejemplo, evitando lifecycle scripts en npm) y emplear instalaciones reproducibles y bloqueadas mediante lockfiles verificables. Auditar de forma explícita los scripts de build en proyectos Rust (build.rs) y el código de importación en paquetes Python antes de confiar en ellos en entornos sensibles.

Las plataformas y equipos de seguridad deben instrumentar detección y respuesta: monitorizar creación de unidades systemd, cambios en cron y hooks de Git, escanear endpoints con herramientas EDR, revisar logs de autenticación para intentos de validación de tokens (AWS, GitHub) y buscar exfiltraciones inusuales hacia Gists u otros servicios públicos. Si se sospecha compromiso, la respuesta inmediata debe incluir la revocación y rotación de claves y tokens potencialmente expuestos, análisis forense de estaciones de trabajo afectadas y reconstrucción desde imágenes limpias. Implementar control de privilegios mínimos para tokens y claves, y auditar las políticas de IAM en la nube reducirá el impacto si unas credenciales son comprometidas.

En el plano preventivo es esencial integrar análisis de la cadena de suministro en el ciclo de vida del software: generar y verificar SBOMs, usar herramientas de Software Composition Analysis (SCA) que alerten sobre paquetes nuevos o con nombres sospechosos, establecer listas blancas de paquetes aprobados en entornos críticos y emplear escaneo automático de repositorios para detectar secretos accidentalmente comprometidos. También es importante educar a los desarrolladores sobre riesgos como la ejecución de código remoto mediante node -e o scripts de instalación, y sobre el peligro de aceptar o ejecutar recomendaciones de asistentes de IA sin revisión humana, dado el uso emergente de la ingeniería de prompt maligno en este ataque. Para orientaciones prácticas sobre seguridad de la cadena de suministro y mejores prácticas en plataformas de desarrollo puede consultarse la documentación y guías de la industria, por ejemplo en la página de GitHub sobre seguridad de la cadena de suministro https://docs.github.com/en/code-security/supply-chain-security y la explicación de scripts de ciclo de vida en npm https://docs.npmjs.com/cli/v9/using-npm/scripts, así como los recursos de agencias de seguridad para fortalecer la resiliencia del software supply chain https://www.cisa.gov/supply-chain.

Para los encargados de los repositorios, este episodio vuelve a subrayar la necesidad de mejorar los controles de publicación, detección de cuentas fraudulentas y análisis de comportamientos posteriores a la publicación. Los responsables de proyectos open source deben revisar contribuciones que introduzcan archivos atípicos o instrucciones dirigidas a asistentes automáticos y tratar los cambios en permisos y scripts de construcción con especial cautela. Finalmente, los desarrolladores y equipos de seguridad no deben confundir campañas con nombres similares: TrapDoor en este caso no guarda relación con otra operación homónima que distribuyó apps fraudulentas en tiendas móviles la semana anterior, lo que muestra cómo distintos actores y campañas pueden solaparse en nombre pero diferir en objetivos y técnicas.

En resumen, TrapDoor es un recordatorio de que la superficie de ataque se ha desplazado hacia el entorno del desarrollador y la cadena de herramientas. La defensa exige una combinación de controles técnicos, prácticas operativas y conciencia humana: auditar dependencias y scripts, limitar privilegios, aislar entornos de desarrollo y revisar cualquier código sugerido por asistentes automáticos antes de ejecutarlo en máquinas con acceso a secretos.