Ataque silencioso: paquetes NuGet maliciosos apuntan a ASP.NET para exfiltrar identidades y abrir puertas traseras

Investigadores en seguridad han desenterrado una campaña sofisticada dirigida a desarrolladores de aplicaciones ASP.NET que, lejos de buscar infecciones ruidosas en los equipos de los programadores, apunta a un objetivo más valioso y silencioso: las aplicaciones que esos desarrolladores construyen. Según el informe publicado por Socket, cuatro paquetes maliciosos publicados en NuGet entre el 12 y el 21 de agosto de 2024 actuaron en conjunto para filtrar datos de identidad de ASP.NET y para implantar puertas traseras persistentes en aplicaciones desplegadas.

Los paquetes, publicados por el perfil hamzazaheer, recibieron más de 4.500 descargas antes de que fueran retirados tras la divulgación responsable. Sus nombres —incluyendo variantes como NCryptYo, DOMOAuth2_, IRAOAuth2.0 y SimpleWriter_— esconden comportamientos muy distintos: desde un “dropper” que activa la cadena de compromiso hasta componentes que extraen las tablas de identidad, roles y permisos de ASP.NET Identity y que aceptan reglas de autorización enviadas por el atacante para otorgarse privilegios.

En esencia, la campaña utiliza un ejecutable de primer estadio incrustado en uno de los paquetes (NCryptYo) que se activa cuando la librería se carga en la aplicación. Ese módulo instala hooks en el compilador JIT de .NET para desencriptar y desplegar una carga útil secundaria: un proxy local que escucha en localhost:7152 y redirige el tráfico hacia un servidor de mando y control cuya dirección se resuelve dinámicamente en tiempo de ejecución. A través de ese túnel local, los otros paquetes comienzan a enviar información sensible de identidades y permisos al exterior; la infraestructura remota puede entonces responder con nuevas reglas de autorización que la aplicación procesa, lo que permite al atacante crear cuentas administrativas o desactivar comprobaciones de seguridad en entornos de producción.

El paquete que se presentaba como utilidad de conversión de PDF, SimpleWriter_, incorpora capacidades preocupantes de escritura incondicional en disco y ejecución oculta de procesos, permitiendo que el atacante deje ejecutables adicionales en la máquina víctima y los arranque sin ventanas visibles. El análisis de metadatos y del entorno de compilación sugiere que todos los paquetes provienen del mismo actor, dado que comparten huellas de construcción idénticas.

Es importante subrayar el vector por el que se actúa: no se busca solo comprometer la estación de trabajo del desarrollador, sino manipular la capa de autorización durante el desarrollo para controlar aplicaciones desplegadas. Cuando la aplicación con dependencias maliciosas llega a producción, el canal hacia el C2 puede permanecer activo y continuar exfiltrando datos de permisos y recibiendo reglas que concedan acceso administrativo a cualquier instancia desplegada.

Este tipo de ataque es otra variación del problema más amplio de la cadena de suministro de software: componentes de terceros que parecen inofensivos y se incorporan a proyectos terminan siendo la vía de entrada a sistemas críticos. Por comparación, Tenable reportó otro caso reciente en el ecosistema npm: un paquete llamado ambar-src que se aprovechaba del hook de instalación (preinstall) para ejecutar código malicioso en Windows, Linux y macOS y descargar cargadores que daban acceso remoto al atacante. La investigación de Tenable detalla cómo esos instaladores descargaban y ejecutaban binarios o scripts que, en distintos sistemas, desplegaban desde shellcodes en memoria hasta agentes basados en frameworks como Mythic, y exfiltraban datos a dominios en servicios en la nube para camuflar su tráfico (Tenable).

Los riesgos son claros: cuando una dependencia de terceros puede modificar la lógica de autorización o instalar procesos persistentes, la integridad de la aplicación y de sus usuarios queda comprometida. Para quienes desarrollan con ASP.NET, es crucial entender que la exfiltración en estos incidentes se centra en los objetos y estructuras que manejan la autenticación y la autorización —por ejemplo, las tablas y esquemas que maneja ASP.NET Identity— y que la presencia de código no confiable en el ciclo de construcción puede permitir al atacante cambiar esas reglas desde fuera.

Ante esta realidad, conviene reforzar prácticas de higiene en la gestión de dependencias y de la cadena de suministro. Mantener un inventario de componentes y un SBOM, validar la procedencia de paquetes y preferir artefactos firmados, auditar y escanear dependencias con herramientas especializadas, aislar los procesos de construcción y controlar el tráfico saliente desde los pipelines de CI/CD son medidas que reducen la superficie de ataque. Además, aplicar políticas de menor privilegio en entornos de desarrollo y revisión manual de cambios en librerías que interactúan con la autenticación y las reglas de acceso ayudan a detectar anomalías antes de que lleguen a producción. Para profundizar en controles y recomendaciones generales sobre seguridad en la cadena de suministro, las guías de agencias como CISA resultan útiles.

Otros recursos técnicos también son relevantes: Microsoft ofrece documentación sobre la firma de paquetes y mejores prácticas para consumir paquetes en entornos .NET (firma de paquetes en NuGet), y proyectos de código abierto y proveedores de seguridad continúan mejorando las detecciones para estos comportamientos. Además, investigaciones y herramientas que analizan hooks del JIT, proxies locales sospechosos o ejecuciones en el momento de carga son cada vez más necesarias para identificar patrones como los descritos por Socket y Tenable.

Si sospechas que has usado alguno de estos paquetes o cualquier otro que actúe de forma inesperada, considera tratar el sistema como potencialmente comprometido: elimina las dependencias, revisa logs y configuraciones de autorización, rota credenciales y secretos, y realiza un análisis forense si hay indicios de acceso no autorizado. Como recordatorio técnico y operativo, la seguridad de una aplicación no empieza ni termina en su código fuente: las librerías y el proceso por el que llegan a tu proyecto importan tanto como el código que escribes.

La comunidad y las plataformas de paquetes están atentas y responden retirando artefactos maliciosos, pero la experiencia demuestra que las descargas previas a la remoción pueden dejar instalaciones en numerosos repositorios y pipelines. Por eso es imprescindible que equipos de desarrollo, operaciones y seguridad colaboren para detectar y mitigar amenazas en la cadena de suministro antes de que lleguen a producción.