846 paquetes npm maliciosos: ¿por qué la campaña Flooding Dropper es peligrosa para los equipos de scraping?

```html

El 5 de agosto de 2026, los investigadores de Sonatype registraron en npm una campaña que denominaron Flooding Dropper: 846 componentes maliciosos publicados desde decenas de cuentas desechables. Una semana después, la cuenta creció: en los datos actualizados de OpenSourceMalware, que rastrea la misma campaña bajo el nombre WEL1DROPPER, ya figuran 1033 paquetes confirmados. En su interior, hay un cargador multiplataforma que descarga la segunda etapa en Windows, macOS y Linux y elimina de la máquina del desarrollador todo lo que puede alcanzar: variables de entorno, credenciales, sesiones.

Para los equipos que dependen del scraping y la automatización, esto no es "otra noticia sobre npm". El stack de scraping es precisamente npm: Playwright, Puppeteer, Crawlee, envoltorios sobre agentes proxy, analizadores HTML, colas. Y en la misma máquina donde todo esto se instala con un solo comando, generalmente hay un .env con el nombre de usuario y la contraseña del pool de proxies, una cookie-jar de sesiones y perfiles de navegador anti-detección. Analicemos qué ocurrió exactamente y qué implica esto en la práctica.

Qué se sabe sobre la campaña

Sonatype lleva a cabo la campaña bajo el identificador sonatype-2026-005660 con una puntuación CVSS de 8.7 y una clasificación CWE-506 (código malicioso inyectado). Las características que los investigadores utilizaron para agrupar los paquetes son:

• Generación automática de nombres. Los nombres se generan mediante la interpolación de términos repetidos; en el informe se mencionan "bigops" y "bnpl", ejemplos como bigops-api y largas concatenaciones como dolyame-boxy-desktop-bnpl-card-gallery. OpenSourceMalware describe esto como "AI slop squatting" — un tipo de squatting masivo con nombres generados aleatoriamente en lugar de una imitación cuidadosa de un paquete popular.
• Versiones de un solo rango. Las versiones se agrupan alrededor de 35.x.y — números inusualmente altos para paquetes sin historial.
• Distribución entre cuentas. Cada cuenta publica un pequeño lote de paquetes, por lo que bloquear a un editor no detiene la operación.

La mecánica de ejecución se describe de diferentes maneras, y esta diferencia es importante. Sonatype indica que el código se activa "al instalar o importar" un paquete. OpenSourceMalware aclara: algunas muestras funcionan sin los clásicos hooks de ciclo de vida y requieren que el desarrollador conecte el paquete a través de require(). La conclusión práctica es una: confiar únicamente en --ignore-scripts no te salvará — si la dependencia se importa realmente en el código, la carga útil se ejecutará.

Cómo se entrega la segunda etapa

El cargador descarga el payload por HTTPS desde un host aleatorio de una lista codificada — según The Hacker News, los puntos de entrega fueron tres dominios en Cloudflare Workers. Si la descarga directa falla, se activa un canal de respaldo: la carga útil se recopila de registros DNS TXT del dominio wel1.ru con subdominios de plataforma (sdk.dl, ext.dl, pkg.dl, net.dl). Es decir, el filtro saliente por dominios HTTP se elude con solicitudes DNS normales — y en una red corporativa, estas son cortadas por muy pocos.

A continuación, en las plataformas:

• Windows: se parchean ETW y AMSI (es decir, se silencia la telemetría y la verificación antivirus de scripts), se establece mediante claves de inicio automático en el registro y tareas programadas, archivos en AppData.
• macOS: los mismos métodos de evasión, se establece mediante LaunchAgent. En la carga de macOS, los investigadores encontraron dominios de servicios financieros rusos (tcsbank.ru, cloudpayments.ru) — un signo de interés específico en las sesiones bancarias de usuarios de habla rusa.
• Linux: un binario ELF empaquetado con UPX, que despliega un agente del marco Sliver — esto ya es un canal C2 completo, no un robo único.

Además, un conjunto estándar: verificación de sandbox y depurador, detección de arquitectura, lectura de variables de entorno, procesos en segundo plano desconectados (sobreviven al cierre del terminal) y reflejo de la carga en memoria, para no dejar un archivo en el disco.

Por qué esto afecta específicamente a los equipos de scraping

El infostealer no distingue entre "importante" y "no importante" — roba todo lo que parece un secreto. Para un usuario común, esto son contraseñas del navegador y billeteras criptográficas. Para alguien que se dedica a la recolección de datos, el conjunto de trofeos es diferente y, honestamente, más sabroso:

• Variables de entorno y .env — aquí casi siempre se encuentra el host del proxy, el nombre de usuario, la contraseña y los parámetros de sesión (país, ciudad, identificador persistente). La exfiltración de variables de entorno se menciona explícitamente en el análisis de la campaña.
• Cookies y tokens de sesión. Una sesión robada es una forma de eludir MFA: la cookie en sí es una prueba de que ya se ha pasado la segunda verificación. Los registros con tokens válidos para servicios de trabajo se venden en mercados oscuros desde $5.
• Perfiles de navegadores anti-detección — una combinación de "cookie + huella + proxy", es decir, una cuenta de trabajo lista que no necesita calentarse.
• Tokens de CI/CD, npm y nube — acceso no solo a tu máquina, sino también a la pipeline, desde donde se pueden enviar tus propias compilaciones.

La magnitud del fenómeno ha dejado de ser nicho. SpyCloud en su informe de 2026 contabilizó 18.1 millones de claves API y tokens expuestos, obtenidos precisamente de registros de malware. Según Recorded Future y Flashpoint, en 2025, los infostealers infectaron 11.1 millones de máquinas y proporcionaron 3.3 mil millones de cuentas robadas. Y en el informe de Sonatype sobre el estado de la cadena de suministro de software de 2026, se mencionan más de 454,600 nuevos paquetes maliciosos en un solo año de 2025 y más de 1.233 millones bloqueados acumulativamente — un aumento del 75% año tras año. Flooding Dropper no es una anomalía, sino un episodio común del flujo.

Qué pierde el propietario de la cuenta de proxy

Quiero mencionar por separado lo que generalmente no se escribe en los análisis de seguridad, porque los autores no trabajan con proxies. Las credenciales de proxy filtradas no son "pérdida de contraseña", sino tres problemas a la vez:

1. Tráfico pagado. El tráfico residencial y móvil se cobra por gigabytes. Un scraper ajeno en tus credenciales significa que es tu cuenta, y puedes notarlo mucho después de lo que te gustaría.
2. Reputación ajena en tus IP. El atacante necesita una salida residencial "limpia" para que su actividad parezca la de un usuario doméstico normal. Tus sitios objetivo verán un comportamiento sospechoso en tu propia sesión — y recibirás bans en las cuentas que has estado calentando durante años.
3. Disputa con el proveedor. Desde la perspectiva de cualquier proveedor normal, el tráfico provenía de tu cuenta, y tendrás que explicarlo tú.

Qué hacer: mínimo práctico

1. Separar entornos. El stack de scraping se instala en un contenedor o VM separada — no en la máquina donde están las cookies personales, el correo de trabajo y los tokens de producción. Esta es la única medida que funciona incluso contra un paquete del que aún nadie sabe.
2. Eliminar credenciales de proxy del .env junto al código. Los secretos deben ir al gestor de secretos o a las variables de entorno del runner, no en un archivo en la raíz del proyecto que cualquier módulo importado puede leer.
3. Activar la autorización por IP donde sea posible. Vincular el acceso a tu servidor devalúa la pareja robada de nombre de usuario/contraseña: desde una dirección ajena simplemente no funcionará. Cómo se organiza esto y en qué escenarios es adecuado, se ha analizado en el material sobre lista blanca de IP para proxies. Las reglas generales para almacenar accesos están en la guía sobre almacenamiento seguro de credenciales de proxy.
4. Credenciales separadas para cada proyecto y límites de tráfico. Si cada script tiene su propio acceso con un límite de gigabytes, la filtración de uno no vacía todo el saldo y se localiza en minutos.
5. Monitorear el consumo. Un aumento repentino en el consumo de GB sin un aumento en las tareas — el detector de compromiso más temprano y más barato que tienes.
6. Disciplina de dependencias. npm ci según el archivo de bloqueo en lugar de un install libre, cuarentena para nuevas versiones (7–14 días), verificación de la antigüedad del paquete y el historial del editor, espejo interno con allowlist. Un paquete con versión 35.x.y, sin historial y con un nombre de palabras concatenadas — es motivo para detenerse, no para instalar.

Si sospechas que ya has sido comprometido

Las recomendaciones de Sonatype son aquí extremadamente concretas y el orden en ellas es fundamental: considerar el host completamente comprometido; buscar los mecanismos de anclaje descritos (claves de inicio automático y tareas programadas en Windows, LaunchAgent en macOS); rotar credenciales — npm, GitHub, nube, CI/CD — después de limpiar la máquina, no antes, de lo contrario, los nuevos secretos seguirán el mismo camino; verificar los archivos de bloqueo, cachés de dependencias y espejos internos en busca de copias guardadas; antes de reinstalar, comparar los nombres de los paquetes carácter por carácter.

A esta lista añade la tuya: cambiar contraseñas de accesos a proxies, revocar sesiones activas en el navegador anti-detección y verificar el historial de consumo de tráfico de las últimas dos semanas. Si el tráfico se compra por gigabytes — proxies residenciales o proxies móviles, — el informe de consumo es tu registro de acceso.

Conclusión

Flooding Dropper es interesante no por su sofisticación, sino por su economía: mil paquetes desechables, nombres generados, cuentas en lotes — es una cadena de producción diseñada para que alguien instale una dependencia sin mirar. Algunas campañas limpiarán el registro durante semanas, pero el flujo no se detendrá: las cifras de Sonatype del año pasado no dejan lugar a ilusiones.

La conclusión práctica para quienes recolectan datos es simple. La máquina del desarrollador es un punto donde convergen todos tus accesos a la vez: proxies, cuentas, sesiones, pipeline. Aísla el stack, vincula los accesos a IP, distribuye las credenciales por proyectos y observa el gráfico de consumo de tráfico. Ninguno de estos pasos requiere esperar a que se indexe la próxima campaña.