- Siete paquetes npm enmascarados con Adspect utilizaron filtrado de tráfico, CAPTCHAs falsos y trucos antiinvestigación; uno actuó como señuelo.
- Una campaña de spam a gran escala denominada “IndonesianFoods” aprovechó scripts inactivos, nombres con patrones y encadenamiento de dependencias para inundar el registro.
- El alcance se amplió de decenas de miles a más de 150,000 paquetes; Amazon Inspector y OpenSSF coordinaron las identificaciones MAL y las eliminaciones.
- Las medidas de mitigación incluyen auditorías de dependencias, derechos de publicación restringidos, SCA para archivos inactivos, limitación de velocidad, SBOM y una verificación de cuentas más estricta.
Como el centro más activo del ecosistema JavaScript, el registro npm está lidiando con dos amenazas muy diferentes a la vez.Un pequeño conjunto de paquetes que redirigen silenciosamente a los usuarios mediante enmascaramiento, y una extensa campaña que publica masivamente contenido basura para obtener recompensas en criptomonedas. Ambos problemas, aunque distintos, revelan lagunas conocidas en defensas de la cadena de suministro.
Investigadores de varios equipos informan que Los atacantes combinaron el enmascaramiento del tráfico, la automatización y la distribución de código abierto. El objetivo es desviar a las víctimas a destinos poco fiables o saturar el sistema con paquetes de bajo valor a una escala sin precedentes. Estos casos ponen de manifiesto cómo los incentivos y las herramientas pueden utilizarse en contra de la comunidad cuando las medidas de seguridad no se adaptan a la creatividad de los atacantes.
Las redirecciones basadas en el enmascaramiento convierten los paquetes npm en puertas de acceso al tráfico.
Los investigadores identificaron siete paquetes npm vinculados a un único actor que usar el servicio Adspect para separar a los usuarios reales de los investigadores y ocultar la carga útil realLos paquetes, atribuidos a una cuenta ahora eliminada llamada “dino_reborn”, aparecieron entre septiembre y noviembre de 2025 con recuentos de descargas de apenas unos cientos.
Seis de los paquetes contenían un componente de aproximadamente 39 kB que Deja huellas digitales del entorno, bloquea las herramientas para desarrolladores en el navegador. (para dificultar el análisis), y se ejecuta inmediatamente mediante el patrón IIFE de JavaScript una vez importado. Un séptimo paquete, «signals-embed», destacó por entregar una página blanca inofensiva como señuelo más que un comportamiento abiertamente malicioso.
Cuando se cargan los sitios implantados, el tráfico se envía a través de un punto final proxy en asociación-googlexyz/adspect-proxyphpEsto ayuda a determinar si el visitante parece una víctima o un investigador. Si se le identifica como víctima, el usuario ve un CAPTCHA falso que, en última instancia, Redirige a páginas con temática criptográfica que suplantan servicios. (p. ej., StandX). Si se identifica como un posible analista, la página muestra una vista señuelo sencilla e incluso incluye texto genérico relacionado con una empresa ficticia llamada Offlido.
Adspect se promociona como una Servicio de ocultación en la nube para bloquear tráfico no deseado como bots o rastreadores antivirus., ofreciendo planes escalonados y prometiendo un “enmascaramiento a prueba de balas”. Viendo este estilo de filtrado propio de la tecnología publicitaria integrado en los paquetes npm sigue siendo inusual, y los investigadores lo señalan eficazmente integra la lógica de control de tráfico en la distribución de código abierto. Así, el código decide en tiempo real quién recibe una carga útil real.
Dado que la lógica se ejecuta tan pronto como se carga el recurso, No se necesita interacción del usuario para activar el comportamientoEse flujo de ejecución inmediata —y los bloqueos a nivel de navegador en las herramientas para desarrolladores— complican el análisis y ayudan a mantener el esquema fuera de la vista para una inspección superficial.
Una extensa operación de spam de npm impulsada por recompensas de tokens.
En otro orden de cosas, los equipos de seguridad descubrieron un amplio conjunto de paquetes npm spam Publicado en tandas durante aproximadamente dos añosInicialmente, parecían inofensivas, pero estaban diseñadas para ser replicadas y obtener beneficios económicos. Conocidas colectivamente como “IndonesianFoods”, estas iniciativas utilizaron un sistema de nombres coherente que combinaba Nombres indonesios aleatorios con términos de comida y varios sufijos para generar miles de paquetes con nombres plausibles.
En apariencia, muchas participaciones parecían legítimas; algunas incluso se enviaron por correo. Plantillas funcionales de Next.jsPero enterrados en su interior había archivos sin usar como auto.js or publishScript.js que, cuando se ejecuta manualmente, Produjo nuevos paquetes a gran velocidad.Se crearon versiones modificadas y se eliminaron las medidas de privacidad. Esta automatización de fácil implementación —en lugar de un comportamiento verdaderamente autónomo similar al de un gusano— fue lo que impulsó su rápido crecimiento.
La red de spam a menudo hacía referencia a entre ocho y diez dependencias falsas adicionales. magnificando el impacto a través de cadenas de dependenciaInstala uno, y npm podría instalar silenciosamente docenas más, aumentando el desorden en el registro sin causar ningún daño inmediato y obvio a las máquinas de los desarrolladores.
La monetización parece estar ligada a la Las recompensas de código abierto del protocolo TEASe incluyen varios paquetes. té.yaml señalando cuentas y direcciones de billeteras específicas, lo que sugiere un esfuerzo por inflar las puntuaciones de impacto y extraer pagos de tokensEn algunos casos, la documentación incluso mencionaba estas ganancias, reforzando la idea de un plan coordinado y orientado a las ganancias, en lugar de una experimentación aleatoria.
Diferentes grupos de investigación midieron la ola en diversas etapas: los resultados variaron desde aproximadamente 43,000 cargas de spam al inicio de la campaña a más de 100,000 más tarde, con El inspector de Amazon informó finalmente de más de 150,000 paquetes. en múltiples cuentas para mediados de noviembre de 2025. El crecimiento expuesto límites de tasa de registro, comprobaciones de metadatos y detección de patrones como áreas que necesitan atención.
Por qué los escáneres no lo detectaron y qué cambió
Una de las razones clave por las que la campaña duró tanto es que La mayoría de las herramientas automatizadas buscan malware de tiempo de instalación—por ejemplo, sospechoso postinstalación ganchos o actividad del sistema de archivos. En este caso, la carga útil estaba inactiva y sin referencias, por lo que las heurísticas comunes la etiquetaron como inofensiva. Sin activadores activos, los escáneres frecuentemente Trató los archivos adicionales como desorden inofensivo..
Otro factor fue la escala y la frecuencia de las publicaciones: Los scripts podrían enviar paquetes nuevos cada pocos segundos., generando un volumen abrumador sin activar las firmas clásicas de malware. Los informes señalan que varios sistemas de datos de seguridad se vieron inundados de avisos, incluyendo picos masivos en alertas vinculadas a OSV.
A finales de octubre de 2025, Amazon Inspector implementó una nueva regla de detección. combinado con patrones impulsados por IA para detectar rasgos reveladores como la presencia de tea.yaml, código clonado o mínimo, nombres predecibles, huellas digitales de generación automatizada y cadenas de dependencias circulares. Tras confirmar los patrones a principios de noviembre, el equipo coordinó con el Fundación de Seguridad de Código Abierto (OpenSSF) para asignar rápidamente los MAL-IDs; el tiempo de respuesta promedio fue de unos 30 minutos.
Un matiz importante: algunos comentarios iniciales calificaron la campaña de «gusano». Actualizaciones posteriores aclararon que La lógica de replicación no se autopropaga.Debe ejecutarse. Esa corrección es importante, pero el resultado…Inundación rápida e industrializada de paquetes—la infraestructura del registro y la confianza siguen estando bajo presión.
Medidas prácticas para reducir la exposición
Las organizaciones deberían abordar la reducción del riesgo de npm como un proceso continuo y por capasSe combinan prácticas proactivas de gestión de dependencias con controles basados en políticas y registros. Las siguientes medidas reflejan las recomendaciones de investigadores y gestores de ecosistemas.
- Verificar las dependencias comparándolas con listas de editores conocidos por ser problemáticos y Eliminar paquetes sospechosos o de baja calidad.
- Restringir la publicación de npm Permisos para CI/CD y mantenedores verificados; evitar la ejecución accidental de scripts de replicación.
- Adoptar un análisis de composición de software (SCA) capaz de marcar archivos inactivos, nombres con patrones o redes de dependencias circulares.
- Introducir limitación de la velocidad y monitoreo del comportamiento Para envíos de gran volumen, considere el uso de CAPTCHA y una verificación de cuenta más estricta.
- Refuerza tu oleoducto con SBOM, fijación de versiones y CI/CD aislado., además de rigurosos controles de firmas y procedencia.
En conjunto, estas medidas Reducir el ruido en el registro y facilitar la detección de comportamientos maliciosos o manipuladoresTambién reducen el radio de explosión si un paquete defectuoso se cuela en el gráfico.
En ambos incidentes, el hilo conductor es simple: Los atacantes se guían por incentivos y puntos ciegos.Ya sea por la lógica de ocultamiento que separa a los analistas de las víctimas o por la obtención automatizada de tokens que eclipsa el trabajo legítimo, la respuesta radica en una mayor visibilidad, una colaboración más rápida y políticas que dificulten y encarezcan el abuso a gran escala.
