Una falla crítica en Rails podría permitir que atacantes no autenticados lean archivos del servidor mediante la carga de imágenes

Ruby on Rails ha publicado correcciones para una vulnerabilidad crítica de Active Storage que podría permitir a atacantes no autenticados leer archivos arbitrarios de servidores de aplicaciones mediante cargas de imágenes manipuladas.

Seguimiento como CVE-2026-66066 (Puntuación CVSS: 9,5), la falla puede exponer el entorno del proceso Rails y secretos como secret_key_basela clave maestra de Rails, las contraseñas de la base de datos, las credenciales de almacenamiento en la nube y los tokens API. Esos secretos pueden permitir la ejecución remota de código (RCE) o el movimiento lateral hacia sistemas conectados.

Las aplicaciones afectadas utilizan libvips para el procesamiento de imágenes de Active Storage y aceptan cargas de imágenes de usuarios que no son de confianza. Rails selecciona Vips en load_defaults 7.0y los valores predeterminados posteriores lo conservan.

Ethiack y GMO Flatt Security enumeran los rangos afectados como Rails 7.0.0 a 7.2.3.1, Rails 8.0.0 a 8.0.5 y Rails 8.1.0 a 8.1.3. Las versiones Rails 6.0.0 a 6.1.7.10 se ven afectadas solo cuando Active Storage está configurado para usar Vips, que no era el procesador predeterminado en Rails 6.

El aviso oficial enumera una gama de paquetes más amplia: activestorage < 7.2.3.2. Ambos equipos de investigación ubican la ruta práctica de ataque Vips en Rails 6.0 y posteriores. Las aplicaciones que utilizan MiniMagick no quedan expuestas a través de esta ruta de ataque específica. Rails 7.0 y 7.1 están al final de su vida útil y no tienen versiones fijas, por lo que las aplicaciones en esas ramas deben actualizarse a Rails 7.2.3.2 o posterior.

Ciberseguridad

Los operadores deben actualizar a Rails 7.2.3.2, 8.0.5.1 u 8.1.3.1 y rotar todos los secretos legibles mediante el proceso de solicitud. Las instalaciones parcheadas requieren libvips 8.13 o posterior y, cuando está instalado ruby-vips, ruby-vips 2.2.1 o posterior.

Ninguno de los equipos de investigación había publicado una prueba de concepto (PoC) a las 17:30 UTC del 29 de julio de 2026. Las búsquedas de términos exactos realizadas por The Hacker News no encontraron ningún repositorio de exploits en los resultados indexados de GitHub, GitLab, Exploit-DB o Packet Storm al mismo tiempo. Rails advirtió que la aplicación del parche no invalida las credenciales que ya hayan sido robadas.

La falla se encuentra en el límite de confianza entre Active Storage y libvips. El Aviso de seguridad de rieles dice que libvips admite cargadores, protectores y otras operaciones, algunas respaldadas por bibliotecas de terceros y marcadas como «no fuzzed» o «no confiables» porque no son seguras para entradas hostiles. Active Storage no los bloqueó, lo que permitió que una carga manipulada invocara uno y revelara archivos legibles por el trabajador de Rails.

Una aplicación vulnerable no necesita exponer una operación de cambio de tamaño o miniatura dedicada. «Generar variantes no es un requisito separado», dijo Rails. El parche público También muestra que tanto el analizador Vips como el transformador pasaron archivos adjuntos no confiables a las operaciones inseguras.

Una solicitud exitosa le da al atacante una primitiva de lectura de archivos arbitraria. La ejecución del código o el movimiento lateral dependería de lo que extraiga el atacante y de lo que esas credenciales puedan alcanzar. Rails les dice a los operadores que giren secret_key_basela clave maestra y las credenciales descifradas, las credenciales de la base de datos, las claves del servicio Active Storage y los tokens de terceros.

El parche llama Vips.block_untrusted(true) cuando se inicia el almacenamiento activo. Las aplicaciones que no pueden actualizar Rails inmediatamente pueden establecer VIPS_BLOCK_UNTRUSTED cuando ejecute libvips 8.13 o posterior, o llame Vips.block_untrusted(true) con ruby-vips 2.2.1 o posterior. Rails dice que las versiones anteriores de libvips no pueden bloquear estas operaciones, por lo que las aplicaciones deben actualizar libvips o eliminarlo de la aplicación.

Ciberseguridad

Rails dio crédito a André Baptista, Bruno Mendes y Rafael Castilho de ethiaky RyotaK de Seguridad plana de OGMcon informar el problema de forma independiente. Los investigadores no han revelado el formato malicioso, la construcción de lectura de archivos ni la cadena RCE. Rails dijo que se publicarán más detalles técnicos a más tardar el 28 de agosto de 2026.

Hacker News se ha puesto en contacto con el equipo de seguridad de Rails sobre la explotación y las versiones afectadas, y con Ethiack sobre la cadena de ataque.

Ni Rails ni los investigadores informaron sobre explotación salvaje en el momento de la publicación. Una revisión realizada por The Hacker News a las 17:30 UTC del 29 de julio encontró que CVE-2026-66066 no figuraba en la versión 2026.07.27 de CISA Catálogo de vulnerabilidades explotadas conocidas.

No se dispone de un recuento fiable de aplicaciones vulnerables ni de víctimas nombradas. La puntuación de 9,5 describe la gravedad según CVSS, no cuántas implementaciones están expuestas: una implementación vulnerable también debe usar Vips, aceptar cargas de imágenes que no sean de confianza e incluir una operación explotable en su compilación libvips.

Los piratas informáticos aprovechan la falla del molino de viento para leer archivos de servidor arbitrarios sin autenticación – CYBERDEFENSA.MX

Una falla de seguridad de alta gravedad que afecta la plataforma de desarrollo de código abierto Molino ha sido objeto de explotación activa en la naturaleza, según VulnCheck.

La vulnerabilidad en cuestión es CVE-2026-29059 (Puntuación CVSS: 7,5), un caso de recorrido de ruta no autenticado que afecta el punto final «get_log_file» de Windmill («/api/w/{workspace}/jobs_u/get_log_file/{filename}»).

«El parámetro de nombre de archivo está concatenado en una ruta de archivo sin desinfección, lo que permite a un atacante leer archivos arbitrarios en el servidor usando secuencias ../», según un aviso. publicado por Windmill en marzo de 2026.

«El principal valor sensible expuesto por esta vulnerabilidad es la variable de entorno SUPERADMIN_SECRET, legible a través de /proc/1/environ. Cuando se establece, este secreto se puede utilizar como token de portador para autenticarse como superadministrador y ejecutar código arbitrario a través de la API de vista previa del trabajo».

Sin embargo, vale la pena señalar que SUPERADMIN_SECRET no está configurado de forma predeterminada y, para instancias independientes de Windmill sin SUPERADMIN_SECRET configurado, el impacto de la vulnerabilidad se limita a la lectura de archivos arbitrarios. Desde entonces, el problema se solucionó en Windmill 1.603.3, lanzado en enero de 2026, agregando comprobaciones de desinfección al parámetro de nombre de archivo para evitar el cruce de directorios.

Según VulnCheck, a cuyo investigador de seguridad Valentin Lobstein se le atribuye haber descubierto y reportado la falla, los esfuerzos de explotación se han dirigido contra el punto final «get_log_file» de Windmill para extraer información confidencial del archivo «/etc/passwd».

«Hemos observado exploits dirigidos tanto a los puntos finales directos de Windmill como a la ruta del proxy Nextcloud», Caitlin Condon, vicepresidenta de investigación de seguridad de VulnCheck, dicho en una publicación en LinkedIn.

La empresa de ciberseguridad dijo que identificó alrededor de 170 sistemas vulnerables expuestos en 24 países.

La divulgación se produce cuando la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) agregado cuatro fallas de seguridad en sus vulnerabilidades explotadas conocidas (KEV), incluidos dos errores de WordPress rastreados como wp2shell (CVE-2026-60137 y CVE-2026-63030), junto con un desbordamiento del búfer basado en pila en DD-WRT (CVE-2021-27137) y un problema de ejecución remota de código no autenticado en Langflow (CVE-2026-0770).

«wp2shell es uno de los eventos de seguridad de WordPress Core más importantes de los últimos años», Wordfence dicho. «La combinación de accesibilidad no autenticada, ningún requisito de complemento o tema, una gran superficie de ataque global, un camino hacia el acceso de administrador y la ejecución de código, así como la disponibilidad pública de exploits de prueba de concepto hacen que esta cadena de vulnerabilidad sea inusualmente grave».

Los datos de ataque capturados por la empresa de seguridad de WordPress muestran que los actores de amenazas están emitiendo solicitudes para explotar el problema de confusión de ruta de solicitud por lotes de la API REST y una inyección SQL no autenticada para lograr la ejecución del código.

En cuanto a CVE-2026-0770, Ryan Dewhurst de KEVIntel dijo a The Hacker News que detectó por primera vez intentos de explotación dirigidos a la falla contra sus sensores el 27 de junio de 2026, registrando 137 intentos de explotación de 46 direcciones IP únicas de atacantes asociadas con 17 países.

No menos de 75 intentos, que representan más de la mitad de la actividad, se originaron desde 20 direcciones IP de atacantes durante los últimos siete días. Las cargas útiles observadas incluyen comprobaciones de ejecución de comandos base, intentos de extraer el contenido de «/etc/passwd» o acceder a las credenciales de AWS, recopilación de variables de entorno, descargas de malware mediante wget o curl y ejecución de scripts de shell para instalar cargas útiles de segunda etapa.

«La actividad no se limita a comprobaciones de vulnerabilidad», dijo Dewhurst. «Si bien gran parte involucraba comandos como id, whoami y lectura /etc/passwd, también observamos cargas útiles que intentaban descargar malware y obtener variables de entorno, credenciales de AWS y metadatos de contenedores».

Se recomienda a las agencias del Poder Ejecutivo Civil Federal (FCEB) que remedien las fallas identificadas antes del 24 de julio de 2026.

Un servidor expuesto revela un kit de herramientas de phishing asistido por IA detrás de la campaña de malware WebDAV – CYBERDEFENSA.MX

Un operador de malware dejó su servidor de entrega completamente abierto y Rapid7 eliminó todo el conjunto de herramientas: 1.048 archivos que abarcaban plantillas de señuelo, pruebas de suplantación de nombres de archivos, experimentos de ejecución, cuentagotas, notas de creación y dos cadenas de campaña. Uno ya estaba activo contra usuarios de Windows en México, entregando un robo de información a través de un sitio de búsqueda de identificación gubernamental falso a través de WebDAV.

Lo que lo hace más que un volcado de carga útil: captó la operación a mitad de construcción. Las notas de prueba, los experimentos fallidos, la documentación y los registros de entrega en vivo se encontraban en un solo lugar, el tipo de ruta de desarrollo completa que los defensores rara vez ven.

rápido7 lee los artefactos, hasta una ruta codificada que apunta a una herramienta de codificación de IA de código abierto, como un operador que utiliza IA generativa para producir, probar y documentar la entrega de phishing a gran velocidad.

El conjunto de pruebas más desarrollado centrado en CVE-2025-33053 (CVSS 8.8, ahora en Catálogo KEV de CISA), el secuestro del directorio de trabajo de WebDAV Punto de control documentado el año pasado en su informe Stealth Falcon.

El operador parecía estar reproduciéndolo. La técnica abusa de un .url acceso directo para iniciar un binario legítimo de Windows firmado mientras apunta su directorio de trabajo a un recurso compartido WebDAV controlado por un atacante. En el ataque original, se lanzó el atajo. iediagcmd.exeuna herramienta de diagnóstico de Internet Explorer que inicia ayudas como route.exe por nombre de archivo simple; Con el directorio de trabajo apuntando al recurso compartido remoto, Windows carga el archivo del atacante. route.exe desde WebDAV en lugar del real en System32.

El propio README del operador afirma que esto se ejecuta sin advertencias de SmartScreen o Mark-of-the-Web, «SIN advertencias de seguridad. ¡Cero alertas!» Microsoft corrigió la falla en junio de 2025.

Ciberseguridad

Las notas reflejan el informe de Check Point lo suficientemente fiel como para que un archivo README recuperado conserve el texto exacto. summerartcamp[.]net@ssl@443\DavWWWRoot\OSYxaOjr ruta de ejemplo del informe original. Luego el operador amplió la prueba.

Un «kit de prueba completo» amplió la técnica única a 59 .url archivos dirigidos a otros binarios firmados: herramientas .NET como InstallUtil y RegAsmentradas LOLBAS, incluso candidatos para omitir UAC, cada uno con una teoría escrita de por qué el secuestro debería funcionar y un orden de prueba escalonado.

Las notas los tratan como candidatos para investigar uno por uno, no secuestros confirmados, y el operador creó el conjunto por una razón concreta: el truco original falla en Windows 11 24H2, donde Internet Explorer, etc. iediagcmd.exese ha ido. El directorio también contenía conjuntos de pruebas más pequeños para otras dos fallas en el manejo de archivos, la omisión de MSHTML CVE-2026-21513 y la fuga de NTLM CVE-2025-24054pero el secuestro de WebDAV fue el evento principal.

La información está en el papeleo. Rapid7 dice que los archivos README, las guías de generación de señuelos, los resúmenes de pruebas estilo matriz y un _MAPPING.csv vincular cada archivo de prueba a su binario de destino lleva el formato de plantilla, la verbosidad y la estructura con muchos emojis que asocia con la salida de LLM.

Lee el JavaScript cargado de emojis del sitio de phishing de la misma manera. Los comentarios rusos y los nombres de carpetas, uno llamado testik (un diminutivo de «prueba»), coloque al operador en un contexto de habla rusa pero no lo identifique. Rapid7 atribuye la operación a un flujo de trabajo asistido por LLM, probablemente creado con la ayuda de codificadorque representa «CodeRRR».

The Hacker News confirmó que el repositorio es público a partir del 20 de julio de 2026: un agente de codificación de IA de código abierto y de uso general inspirado en Claude Code, GitHub Copilot CLI y Cursor, no herramientas específicas del atacante. El resumen de Rapid7 es contundente: «el atacante utilizó LLM para operar más como un equipo de productos de software moderno».

El operador incluso dejó el panel de entrega, una herramienta de administración llamada Simba Service, ubicada en el mismo servidor con su puerto predeterminado y sus credenciales sin cambios.

Una campaña activa dirigida a usuarios mexicanos

La alerta MDR se remonta a gobf[.]mxun typosquat de la búsqueda de identificación nacional CURP del gobierno, que ofrecía a las víctimas una página falsa de recuperación de registros cuyo botón de descarga disparaba un search-ms: consulta. Eso abrió el recurso compartido WebDAV del operador mientras una búsqueda del Explorador de Windows se filtraba a .scr archivos.

El señuelo más entregado parecía un informe CURP en PDF pero era un .scr ejecutable, su nombre de archivo se invirtió con una anulación de derecha a izquierda para leerlo como PDF. Era un instalador de Inno Setup que descomprimió un cargador y ejecutó un ladrón de información .NET completamente en la memoria, integrado en un proceso Qihoo 360 firmado.

Ciberseguridad

El ladrón se apoderó de billeteras de criptomonedas, credenciales del navegador, cookies de sesión y sesiones de Telegram. Un segundo directorio de campaña, DlrtyGamestomó una ruta diferente, descargando una DLL troyanizada a través de un binario firmado de Ubisoft para colocar un .NET RAT modular.

Durante aproximadamente 5,5 días (del 20 al 26 de junio de 2026 UTC), el panel de entrega registró 77.098 solicitudes de 3.892 IP únicas en 101 países; México por sí solo genera el 82,5 % del tráfico y el 96,9 % de la actividad de lanzamiento. Un solo señuelo CURP representó 2.384 de los 2.441 eventos de lanzamiento, alrededor del 97,7%.

Esa cifra mide el alcance de entrega, no las infecciones: Rapid7 cuenta un «evento de lanzamiento» cuando el panel ve una solicitud de cliente o abre un ejecutable del recurso compartido, no una ejecución confirmada en un punto final, y el tráfico de EE. UU. y Alemania parecía más un escaneo que víctimas. La actividad también se concentró en el horario laboral mexicano, consistente con usuarios reales en lugar de escáneres automatizados.

Para los defensores, el parche de junio de 2025 cerró el original iediagcmd.exe ruta, pero el kit de 59 archivos muestra al operador buscando otros binarios firmados que se comportan de la misma manera. Rapid7 ha publicado indicadores para ambas campañas, incluidas direcciones C2 y hashes de archivos, en su GitHub; bloquearlos primero.

Para conocer lo que los IOC pasan por alto, observe el comportamiento que detectó la alerta por primera vez: el servicio WebClient iniciando y davclnt.dll llegar a un host remoto, un binario firmado que genera un hijo cuya ruta de imagen se encuentra en un recurso compartido WebDAV o UNC, y nombres de archivos que usan RTLO (U+202E), extensiones dobles o relleno antes .exe o .scr.

Hacker News se comunicó con Rapid7 para obtener aclaraciones sobre la identificación de la carga útil final y el estado actual de la infraestructura expuesta, y actualizará esta historia con cualquier respuesta.

La ráfaga de entrega duró poco y se enfrió después del 24 de junio. Lo que perdura es el método: un operador conectó herramientas de codificación de IA, nunca construidas para el trabajo, en una tubería repetible para producir y probar la entrega de phishing, lista para apuntar al siguiente objetivo.

La falla de OpenSSL HollowByte podría congelar la memoria del servidor con solicitudes TLS de 11 bytes – CYBERDEFENSA.MX

Once bytes harán que un servidor OpenSSL sin parches reserve hasta 131 KB de memoria para un mensaje que nunca llega. En los sistemas glibc que Okta probó, esa memoria desaparece hasta que se reinicia el proceso.

OpenSSL envió el byte hueco Se solucionó en junio sin CVE, sin avisos y sin entrada de registro de cambios que lo apunte. El equipo rojo de Okta, que informó del error de denegación de servicio y le puso nombre, publicó los detalles el jueves.

Las versiones fijas son OpenSSL. 4.0.1, 3.6.3, 3.5.7, 3.4.6 y 3.0.21todos con fecha del 9 de junio. Todas las versiones de esas ramas anteriores a las fijas lo tienen. Nada en una canalización de parches normal le indicará dónde están: no hay ningún identificador que pueda coincidir con un escáner ni ningún aviso que leer.

El defecto es que OpenSSL tomó la palabra del atacante. Cada mensaje de protocolo de enlace TLS lleva un encabezado de 4 bytes, tres de los cuales declaran la longitud del cuerpo. Las versiones anteriores aumentaron el búfer de recepción al tamaño declarado en el momento en que llegó el encabezado, antes de que apareciera un solo byte del cuerpo y antes de que se ejecutaran las comprobaciones del protocolo de enlace.

Para un ClientHello entrante, el límite máximo es de 131 KB. Luego el hilo trabajador se bloquea, esperando un cuerpo que nunca llega. Sin autenticación, sin sesión, sin intercambio de claves.

El recuerdo no vuelve

Por sí solo, eso es un ataque de agotamiento de la conexión, y esos son tan antiguos como Slowloris. Lo que hace que HollowByte se mantenga es simplista. Cuando el atacante interrumpe la conexión, OpenSSL libera el búfer, pero glibc retiene fragmentos pequeños y medianos para reutilizarlos en lugar de devolverlos al kernel.

El ataque varía el tamaño reclamado en cada conexión y, en las pruebas de Okta, eso fue suficiente para evitar que el asignador reutilizara lo que liberó. El montón se fragmenta, el tamaño del conjunto residente aumenta y permanece así mucho tiempo después de que el atacante se ha ido.

Ciberseguridad

En las pruebas NGINX de Okta, un servidor de 1 GB fue eliminado por OOM con 547 MB ​​de memoria congelada en fragmentos. En un servidor de 16 GB, HollowByte bloqueó el 25% de la memoria del sistema sin siquiera cruzar el límite de conexión, razón por la cual el Equipo Rojo dice «Las defensas estándar que limitan la conexión no lo detendrán».

Esas cifras son propiedad de Okta y no publicó ningún código de explotación junto con ellas. The Hacker News no encontró ningún repositorio público de prueba de concepto en GitHub hasta el 18 de julio.

OpenSSL decidió que esto no era una vulnerabilidad

El solicitud de extracción de Matt Caswell, quien escribió el parche, lo dice claramente: el equipo de seguridad optó por «manejar esto como una única solución de ‘error o endurecimiento’». El propio OpenSSL política de seguridad define cuatro niveles de gravedad, desde Crítico hasta Bajo, y «error o endurecimiento» no se encuentra entre ellos.

Incluso un problema bajo obtiene un CVE, una nota de registro de cambios y una entrada en la página de vulnerabilidades. HollowByte no tiene ninguno de los tres. The Hacker News no encontró ninguna mención de la solución en el notas de lanzamiento o en las 23 entradas de OpenSSL 4.0.1 registro de cambios.

OpenSSL no ha dicho por qué. Este es su caso: 131 KB por conexión es pequeño, cada servidor TLS asigna memoria por conexión y una asignación limitada no es una vulnerabilidad. La respuesta de Okta es que el recuerdo nunca vuelve.

Hacker News ha preguntado a OpenSSL por qué HollowByte se clasificó por debajo de Low y si la solución alcanzó las ramas de soporte extendido 1.1.1 y 1.0.2. También preguntó a Okta si la fragmentación sobrevive a asignadores distintos de glibc. Esta historia se actualizará con cualquier respuesta.

La línea del proyecto es más fina de lo que parece. En enero, OpenSSL asignó CVE-2025-66199calificado como Bajo, debido a un error de compresión de certificados TLS 1.3 en el que una longitud proporcionada por un par hizo crecer un búfer de montón antes de la validación, con un valor de alrededor de 22 MiB por conexión.

Ese necesitaba cuatro cosas para alinearse: compresión de certificados compilada, un algoritmo de compresión disponible, la extensión negociada y, en los servidores, certificados de cliente solicitados. HollowByte no necesita ninguno de ellos.

El mismo lanzamiento del 9 de junio asignado CVE-2026-34183clasificado como moderado, a crecimiento de memoria ilimitado en el controlador QUIC PATH_CHALLENGE. Ambos son DoS por agotamiento de la memoria. Ambos obtuvieron números.

Ciberseguridad

El lanzamiento también cerró 18 CVE, incluido un uso después de la liberación de alta gravedad en PKCS7_verify(), por lo que cualquiera que ejecute una de esas compilaciones ascendentes tiene la solución sin que se lo digan.

Río abajo es peor. sombrero rojo incumplimiento documentado es realizar una copia de seguridad en lugar de mover la versión, por lo que un paquete parcheado aún informa la versión a partir de la cual se creó. Lo que normalmente resuelve esto es el aviso y el feed OVAL, ambos codificados con nombres CVE. No hay ningún CVE aquí para ingresar.

Eso deja el registro de cambios del paquete o el mantenedor: pregunte si cambiaron la base en la versión del 9 de junio o si tomaron el parche, que es una solicitud de extracción. 30792 para maestro y 4.0, 30793 para 3.6, 3.5 y 3.4, y 30794 para 3.0.

Si crea OpenSSL usted mismo, actualice a la versión indicada y reinicie lo que cargó la versión anterior.

La solución cubre solo TLS. Caswell escribió en la solicitud de extracción que DTLS se quedó solo porque hacerlo correctamente habría sido mucho más invasivo y que el proyecto decidió no molestarse con eso por ahora. The Hacker News comparó la fuente de OpenSSL en las etiquetas 3.6.2 y 3.6.3 y encontró que el archivo de protocolo de enlace DTLS tenía bytes idénticos en toda la solución. En 4.0.1, la versión más reciente, esa ruta todavía dimensiona su búfer a partir de la longitud que declara el par.

OpenSSL no ha clasificado esa ruta ni se ha comprometido a solucionarla. Las notas de la versión, el registro de cambios y la página de vulnerabilidades no dicen nada al respecto. La solicitud de extracción sí lo hace.

Un servidor mal configurado revela tres operaciones de phishing de Evilginx dirigidas a Microsoft 365 – CYBERDEFENSA.MX

Un atacante que ejecutaba una operación de phishing en vivo de Microsoft 365 dejó un servidor web Python escuchando en un puerto público con la lista de directorios activada. El comando que lo hizo: python3 -m http.server 8080todavía estaba sentado en el legible .bash_history.

A partir de ese lapsus, la empresa de seguridad francesa lexfo levantó todo el conjunto de herramientas del operador y lo pasó a dos operadores de phishing más, tres campañas en total. Cada uno ejecutó una bifurcación personalizada del proxy Evilginx de código abierto, clonado del GitHub público.

El más grande de los tres había estado funcionando durante más de un año, y sus víctimas en su mayoría eran buzones corporativos.

Los tres superaron MFA de dos maneras mecánicamente diferentes: una mediante proxy del inicio de sesión en vivo y otra abusando de un flujo de inicio de sesión legítimo de Microsoft. Los dos necesitan defensas diferentes, que es la parte que más importa si ejecuta Microsoft 365.

La lista de directorios en un servidor de ataque en funcionamiento está cerca de ser una confesión completa. La lista exponía configuraciones de phishing, registros de recolección de credenciales, instaladores de RMM, listas combinadas, archivos de respaldo y los propios archivos de sesión de Telegram del operador.

Detrás de él se ejecutaba un proxy de adversario en el medio Evilginx y una consola remota SimpleHelp en el mismo host, en 185.163.204[.]7 en Budapest, catalogado a finales de abril de 2026 durante un escaneo de rutina en Internet.

El historial de bash y una serie de repositorios públicos apuntaban directamente al operador: un actor egipcio al que la empresa sigue como codificadoactivo en foros de piratería y VoIP desde 2018, ahora ejecuta una plataforma Microsoft 365 AiTM en picis[.]net y monetizar el acceso a través de un correo masivo que escribió llamado Blaster MaDoO.

Su campaña se puso en marcha el 20 de abril y continuó funcionando hasta el día en que se encontró el directorio, el 30 de abril, con nuevos subdominios y un certificado comodín renovado semanas después. Su propio robot registró capturas en dos cuentas corporativas de M365, una francesa y otra norteamericana.

Las capturas repetidas de las mismas cuentas de diferentes IP son consistentes, dice la firma, y ​​el operador actualiza los tokens robados a medida que caducan.

De dónde vinieron los kits

codemado no construyó el marco que ejecuta. Lo clonó y su historial de bash lo muestra comparando kits uno al lado del otro. El servidor contenía cuatro variantes de Evilginx extraídas de otros dos desarrolladores de GitHub, y ambos resultaron ser operadores activos por derecho propio.

La primera, reina rojaproviene de un operador nigeriano que el informe llama mail-argenta y muestra cuánto pulido se incorpora a un marco público. Su tenedor cambia el nombre del crossorigin y integrity Atributos HTML para anular las comprobaciones de integridad de los subrecursos y agrega un motor de reescritura de URL para http_proxy.go para esquivar la detección basada en rutas. Completa previamente la dirección de correo electrónico de la víctima para reducir el abandono.

También establece un TTL de un año, 31.536.000 segundos, en las cookies de sesión de Microsoft capturadas. El informe dice que un inicio de sesión interceptado puede durar más que un restablecimiento de contraseña y, sin una política de acceso condicional compatible con CAE, permanecer utilizable durante meses.

Un precompilado evilginx2.exe está comprometido con el repositorio, por lo que un comprador nunca tiene que construir nada. Una cookie M365 capturada que se encontraba en el repositorio tenía una fecha de vencimiento del 30 de junio de 2027.

correo-argenta Fue atrapado como lo hacen sus propias víctimas. La empresa encontró su correo electrónico y una contraseña en registros de robo de información, el tipo de datos de credenciales recopilados que sus paneles de phishing producen. Esa contraseña filtrada coincidía con la codificada como contraseña de MySQL en su panel Kraken y reutilizada en sus cuentas.

el tranquilo

El tercer tenedor, reina negraregistró muchas más capturas que los otros dos y nunca toca una contraseña. Su autor, a quien los investigadores no pudieron identificar más allá del identificador. sarola01lo creó en torno al flujo de código de dispositivo OAuth de Microsoft, una ruta de inicio de sesión legítima destinada a dispositivos con entrada restringida.

El ataque genera un código de dispositivo real, lo envuelve en una página señuelo con el tema del Autenticador y le dice al objetivo que lo ingrese en la página genuina. microsoft.com/devicelogin. La víctima inicia sesión en una página real de Microsoft y borra MFA por sí misma. El backend de saroula01 sondea el punto final del token y toma el token en el momento en que lo hace.

Llamar a esto «bypass de MFA» no comprende cómo funciona: no se omite nada. La página de señuelo tiene el tema de Authenticator y fue creada por el atacante, pero el código del dispositivo y la página de Microsoft donde termina la víctima son genuinos, por lo que el mensaje de MFA que la víctima satisface es real.

Una clave de acceso o FIDO2 tampoco ayuda, porque la víctima la borra en la infraestructura genuina de Microsoft mientras autoriza la sesión del atacante; el enlace de origen que detiene a Evilginx pasa limpiamente cuando el origen realmente es Microsoft.

microsoft documentó la técnica en febrero de 2025.en una campaña que evaluó con confianza media como alineada con Rusia. Desde entonces, se ha extendido mucho más allá del uso respaldado por el estado y ha llegado a campañas que afectan a cientos de organizaciones de Microsoft 365.

La versión de saroula01 funcionó silenciosamente durante más de un año. La empresa contó 218 cuentas capturadas distintas en los registros del bot de Telegram de la campaña en una docena de países entre junio de 2025 y julio de 2026, alrededor del 94 por ciento de ellas buzones de correo corporativos. Esas son capturas registradas, no objetivos de escaneo.

Un archivo de token enviado brevemente al repositorio y luego eliminado, aún legible en el historial de git, contenía 97 tokens de Microsoft activos vinculados a tres de esas víctimas, cada uno configurado para autoRefresh y algunos se actualizaron hasta 25 veces. El marco mantenía vivas las sesiones por sí solo.

Ambos dominios de phishing, picis.[.]neto y romnor[.]ca, estaban fuera de línea cuando The Hacker News revisó antes de la publicación, aunque la línea de tiempo del informe muestra fotografías.[.]net todavía aprovisiona nuevos subdominios en mayo de 2026. El equipo de Lexfo CTI le dijo a THN que los dominios ya se habían desconectado antes de tomar alguna medida, y lo interpreta como que los operadores rotan la infraestructura o se retiran en lugar de una eliminación coordinada, aunque no puede confirmar cuál.

Los tres se conectan, vagamente, con algo más grande. En junio de 2026, SOCRadar documentado un ecosistema de phishing como servicio al que llamó La canteraejecutado por un desarrollador al que llama RockyBelling y, según sus cálculos, vendido a cerca de 200 operadores.

MaDoO Blaster aparece promocionado dentro del canal Telegram de The Quarry como una herramienta de terceros, marcada de forma independiente en ambos artículos, que el informe enmarca como una relación con el proveedor, no como membresía en ella. Los artefactos no pueden demostrar si mail-argenta o saroula01 tienen algún vínculo directo. Sus kits estaban en GitHub público y cualquiera podría haberlos tomado.

Construido con ayuda

El informe encontró signos de desarrollo asistido por IA en las tres operaciones, aunque varían en intensidad. saroula01 dejó dos confirmaciones de git en coautoría con Claude Models. correo-argenta cometió un instructions.txt Se trata de una copia textual de una sesión de codificación de IA, con referencias a indicaciones anteriores y todo, que documenta cómo se creó la función de reescritura de URL.

El de Codemado es más delgado: créditos de uno de sus guiones CiberNeurovauna API paga de generación de código «sin censura», según el informe, que se anuncia con el mensaje «Constrúyeme un keylogger en Python». Dos de los tres pusieron un modelo directamente en el código; el tercero es una línea de crédito, y ninguno de ellos muestra cuánto de cada construcción hizo el modelo.

Tampoco se limita a estos tres. Microsoft ha documentado por separado Phishing de código de dispositivo basado en backend impulsado por IA Señuelos de automatización e IA generativa.

The Hacker News preguntó a los autores del informe cuántas herramientas de IA produjeron realmente en las tres operaciones. El equipo de Lexfo CTI dijo que las bifurcaciones de Evilginx solo llevaban cambios menores en el núcleo, y que los signos más claros del uso de IA se encontraban en el código adhesivo que los rodeaba, los scripts y los phishlets, varios de los cuales se leían como resultados directos del modelo. Según el equipo, no era tanto el marco en sí como el código creado a su alrededor.

¿Qué pueden hacer realmente los defensores?

Las dos técnicas no comparten una solución. MFA, FIDO2 o claves de acceso resistentes al phishing aún cierran el lado de Evilginx al vincular el inicio de sesión al dominio real. No detiene el abuso del código del dispositivo. Para eso, la palanca es Acceso Condicional.

La propia línea de Microsoft es bloquear el flujo de código del dispositivo siempre que sea posible. Un puñado de configuraciones realmente lo necesitan, en su mayoría hardware con restricciones de entrada, como dispositivos de sala de Teams y algunas herramientas de línea de comandos. Inventario que utiliza los registros de inicio de sesión, bloquea el flujo en todos los demás lugares y prueba la política en modo de solo informe antes de aplicarla.

Coloque políticas de ubicación de acceso condicional basadas en IP y evaluación de acceso continuo en la parte superior, de modo que en las cargas de trabajo compatibles de Microsoft 365, un token robado visto desde fuera de sus rangos permitidos se reevalúe en lugar de agotar su vida útil.

Para la detección, el informe marca las concesiones de tokens de actualización del ID de cliente de Microsoft Office. d3590ed6-52b3-4102-aeff-aad2292ab01c en los registros de inicio de sesión de Entra como dignos de atención, donde ese cliente de escritorio no está en uso normal; cotejarlos con direcciones IP de origen desconocidas.

La misma guía de Microsoft señala un problema: una sesión que comenzó con el flujo de código del dispositivo permanece etiquetada en actualizaciones posteriores incluso cuando el evento actual ya no lo muestra, así que busque en los registros Original transfer method campo, no solo el protocolo de autenticación en vivo.

En los endpoints, busque las herramientas RMM que estos operadores utilizan para lograr persistencia; El kit de Codemado llega a XEOX, así que comience con el agente en C:\Program Files (x86)\XEOX\xeox-agent_x64.exe y tareas programadas coincidentes *XEOX*Agent*Watchdog*. Los dominios y las IP están en el informe, pero esa infraestructura rota, así que trátelo como una contención, no como una solución.

Hacker News también preguntó a Microsoft sobre el abuso del flujo de código de su dispositivo y no había recibido respuesta al momento de la publicación. Esta historia se actualizará con cualquier respuesta.

Nada de esto requirió mucho: tres operadores, ninguno de los cuales construyó los marcos que ejecutaban, pusieron en marcha campañas de trabajo en repositorios públicos, kits que se venden por unos pocos cientos de dólares y un modelo que ayudaba con las piezas personalizadas.

El informe dice que la barrera para una campaña funcional ha caído a casi cero, y el equipo de Lexfo CTI espera que este tipo de ataque se vuelva significativamente más común en los próximos meses.

Un ecosistema barato ahora ofrece dos formas de evitar la MFA, y esa es la parte que dura más que cualquier campaña aquí: una tienda endurecida contra el phishing de proxy inverso todavía está abierta al abuso de códigos de dispositivos. Bloquear esa segunda ruta es una política de acceso condicional, no se agrega ninguna clave de acceso y existe solo una vez que alguien la escribe.

El servidor de hackers expuesto revela la puerta trasera WP-SHELLSTORM en miles de sitios de WordPress – CYBERDEFENSA.MX

Un equipo de cibercrimen dejó uno de sus propios servidores abierto en Internet durante tres semanas y expuso el funcionamiento interno de la operación: las herramientas de piratería, los registros de actividad y las listas de objetivos que nombran a más de 1,4 millones de sitios web.

En realidad, muchos menos fueron pirateados, pero los archivos expuestos mostraron a los investigadores cómo una operación de piratería masiva de sitios se ejecuta desde adentro.

La operación, ahora rastreada como WP-SHELLSTORMes lo que SOCRadar llama intermediación de acceso a webshell: un equipo que irrumpe en sitios a escala, coloca una puerta trasera oculta (un «webshell») en cada uno y empaqueta ese acceso para su reventa.

La actividad más fuerte afectó a los sitios de WordPress que ejecutan complementos desactualizados. Si ejecuta WordPress o Joomla, los dos defectos que más importaban estaban en el complemento de almacenamiento en caché Breeze y en el editor JCE de Joomla; salte a la lista de verificación a continuación si ese es usted.

Un servidor olvidado

Dos equipos excavaron en la misma carpeta expuesta. El equipo de inteligencia de amenazas de SOCRadar lo detectó el 11 de junio de 2026 en un servidor alquilado con sede en EE. UU. en 137.175.93.[.]126 sin contraseña alguna. En su interior había aproximadamente 800 MB en 434 archivos: webshells, scripts de explotación, resultados de escaneo, historial de comandos escritos por el operador y configuraciones de comando y control.

Ctrl-Alt-Intel También había analizado el mismo directorio, lo encontró en la plataforma de directorio abierto de Hunt.io y lo publicó el 22 de junio, semanas antes del artículo de SOCRadar del 9 de julio. La exposición se redujo a un desliz básico: el operador inició un simple servidor web Python para mover archivos y lo dejó funcionando durante 22 días.

Ciberseguridad

El equipo tomó errores conocidos públicamente en complementos de sitios web, la mayoría de ellos en WordPress, y construyó escáneres automáticos para disparar esos exploits a listas de objetivos masivas extraídas de FOFA, un motor de búsqueda chino para sistemas conectados a Internet, similar a Shodan.

Cuando un sitio ejecutaba una versión vulnerable, el exploit podía cargar un webshell: un pequeño script que permite al atacante ejecutar comandos en el servidor desde cualquier lugar, leer archivos, robar contraseñas y profundizar en la red.

El conjunto de herramientas cubría 27 fallas conocidas, aunque unos pocos hicieron la mayor parte del trabajo. El mayor productor fue un error en el complemento de almacenamiento en caché Breeze (CVE-2026-3844), que el equipo disparó contra más de 45.000 objetivos y, según sus propios cálculos, cerró por puerta trasera a más de 17.000 de ellos.

Esto tiene un inconveniente: solo funciona cuando está activada una configuración no predeterminada de «Hospedar archivos localmente – Gravatars», por lo que la mayoría de las instalaciones de Breeze nunca estuvieron expuestas.

Los números, en términos sencillos

La cifra principal necesita una advertencia. El recuento de 1,4 millones es cuántos dominios estaban en las listas de destino, no cuántos fueron divididos, y esas listas abarcaban WordPress, Joomla y otras plataformas. El archivo más grande era una lista de 587.034 destinos Joomla.

El número realmente comprometido fue mucho menor, y los dos equipos de investigación lo midieron de manera diferente: el recuento deduplicado de Ctrl-Alt-Intel encontró 25,195 sitios con evidencia de compromiso confirmada o validada, mientras que SOCRadar, contando webshells activos, colocó la cifra en vivo en más de 5,700.

Un error muestra claramente la brecha: un error de Joomla se disparó contra más de 560.000 objetivos, pero aterrizó sólo en 77 de ellos.

Estar en la lista de escaneo de alguien no es lo mismo que ser pirateado. Tenga esto en cuenta siempre que un informe comience con un número objetivo aterrador.

Las herramientas y una campaña anterior.

La puerta trasera principal, un archivo llamado down.php, estaba muy ofuscado, tenía cuatro capas de profundidad y parece derivar de un webshell chino de código abierto llamado BestShell. Una vez en ejecución, podía administrar archivos, ejecutar comandos, abrir shells inversos, escanear la red y verificar qué software de seguridad estaba ejecutando el host.

Para su propio acceso remoto, el equipo utilizó un cuentagotas SNOWLIGHT para instalar VShell, una puerta trasera sigilosa que disfraza el nombre de su proceso como [kworker/0:2] para mezclarse con los subprocesos del núcleo en una lista de procesos.

Esas dos herramientas tienen una historia: en abril de 2025, Sysdig vinculó esta cadena SNOWLIGHT a VShell con el presunto grupo estatal chino UNC5174, actividad cubierta por THN en ese momento. Sin embargo, el propio VShell es una herramienta común en los círculos criminales de habla china, por lo que su presencia por sí sola no apunta a un actor estatal.

El servidor también contenía rastros de un trabajo anterior muy diferente. SOCRadar descubrió que antes de la ruidosa ola de WordPress, el mismo equipo llevó a cabo una campaña más silenciosa a principios de mayo de 2026 contra los sistemas Java corporativos. Obtuvo 613 archivos de configuración de 11 sistemas en nueve empresas de tecnología financiera, comercio electrónico, logística, juegos y electrónica.

El botín incluyó claves de inicio de sesión en la nube para AWS, Alibaba Cloud, Oracle, Tencent y DigitalOcean, contraseñas de bases de datos y claves privadas Alipay RSA. Se apoyaba en un error antiguo y conocido en Nacos, un servidor de configuración (CVE-2021-29441), que permite a un atacante omitir el inicio de sesión falsificando un único encabezado web.

SOCRadar interpreta el momento como una secuencia: primero obtener credenciales corporativas de alto valor, luego, semanas después, pasar al trabajo de puerta trasera de mayor volumen, una ronda de financiación antes de ampliar la escala.

Comercio descuidado

Ambos equipos evalúan con confianza media a alta que el operador es chino o habla chino. Señalan el chino simplificado fluido a lo largo del código y el historial de comandos, la dependencia de FOFA (que, según los investigadores, necesita un número de teléfono chino para registrarse) y las herramientas Godzilla y VShell preferidas en los foros de habla china.

SOCRadar va un paso más allá y considera que la tripulación está motivada financieramente y no dirigida por el estado. Los nombres que aparecen en los archivos (tance, chen-kk, chenyk) se tratan como pistas sueltas, no como pruebas. Destaca un cabo suelto: una única dirección IP en Taiwán realizó más de 42.000 solicitudes descargando las propias herramientas del equipo. Podría ser un segundo operador, un cliente u otro investigador. Los troncos no pueden resolverlo.

Para ser un grupo que maneja una cadena de herramientas genuinamente capaz, el equipo fue descuidado. Dejó el servidor abierto, dejó un archivo de configuración de FOFA que FOFA puede rastrear a través de su canal de aplicación de la ley y dejó un historial de comandos sin editar que expuso todo. Cuando finalmente se dio cuenta de que había sido detectado, en algún momento entre el 2 y el 4 de julio, eliminó un lote de líneas de registro. Tres semanas demasiado tarde.

Ciberseguridad

El error es familiar. En marzo de 2026, el mismo taller de investigación detectó al Fancy Bear ruso (APT28) de la misma manera: un directorio abierto olvidado difundió las herramientas y registros de phishing del grupo, en una campaña llamada Hunt.io. Operación redondeada.

Que hacer ahora

Si ejecuta alguno de los programas específicos, compruébelo hoy. Estos no son errores desconocidos: dos de ellos están siendo explotados activamente en otros lugares.

Wordfence rastreó decenas de miles de ataques bloqueados contra la falla de Everest Forms Pro (CVE-2026-3300) esta primavera, y el error Joomla JCE (CVE-2026-48907) es una falla de máxima gravedad que CISA ha agregado a su lista de vulnerabilidades explotadas conocidas.

  • WordPress y Joomla, primero: parchear Breeze (CVE-2026-3844, corregido en 2.4.5) si la configuración no predeterminada «Hospedar archivos localmente – Gravatars» está activada; produjo la mayor cantidad de puertas traseras aquí. Trate la falla JCE de Joomla (CVE-2026-48907, corregida en 2.9.99.5) como urgente también, ya que es de máxima gravedad y está en la lista de explotaciones activas de CISA, a pesar de que apenas apareció en esta campaña.
  • WordPress y Joomla, consulte también: Complementos ThemeREX (CVE-2026-1969), Lista de archivos simple (CVE-2020-36847), CSS JS PHP personalizado (CVE-2026-6433), BerqWP (CVE-2025-7443), cargas de Ninja Forms (CVE-2026-0740), WavePlayer (CVE-2025-12057), WPBookit (CVE-2025-7852) y Administrador de archivos WP (CVE-2020-25213). Ambos informes enumeran la Lista de archivos simple bajo CVE-2025-34085, un duplicado ahora rechazado; la identificación válida es CVE-2020-36847.
  • Nacos: actualice a 2.2.1 o posterior y active la autenticación (nacos.core.auth.enabled=true). Si su instancia alguna vez estuvo expuesta, rote todas las credenciales que se encuentran en ella, no solo las obvias.
  • Bota de trabajo y primavera XXL: cierre los puntos finales de ejecutor no autenticados y deshabilite /actuator/heapdump en producción.
  • Busque las puertas traseras: busque los patrones de nombres de archivos webshell del equipo, como .bd.php, .wp-log.php y .brq-*.php. Luego verifique cualquier proceso llamado [kworker/X:Y]. Un hilo del kernel real no ejecuta ningún programa propio, por lo que su /proc//exe no apunta a nada. Tampoco tiene línea de comando ni sockets de red. A [kworker] eso demuestra que cualquiera de estos es un impostor. Bloquear la infraestructura conocida: 137.175.93[.]126, 43.108.17[.]80, y el dominio xs.xxooonline[.]UE[.]cc.

Lo que hace que WP-SHELLSTORM merezca atención no es lo avanzado que es, sino lo ordinario que es. Los exploits públicos, el escaneo automatizado y una lista de objetivos de un millón de líneas fueron suficientes para comprometer sitios a escala, sin necesidad de un día cero. Los detalles son públicos sólo porque el equipo olvidó cerrar su propio servidor.

The Hacker News se comunicó con SOCRadar para obtener más detalles sobre sus hallazgos y actualizará esta historia con cualquier respuesta.

Una falla sin parche en el servidor de repositorio de Argo CD podría permitir a los atacantes apoderarse de los clústeres de Kubernetes

CD Argouna herramienta ampliamente utilizada para implementar software en Kubernetes, tiene una falla sin parchear en su componente de servidor de repositorio que permite que un atacante no autenticado ejecute código, siempre que pueda alcanzar el puerto de red interno del componente.

sinácticoque encontró el error, dice que puede conducir a una toma de control total del clúster. No hay solución ni CVE. La empresa dice que informó la falla a los encargados de mantenimiento de Argo CD en enero de 2025; Aproximadamente dieciocho meses después, sigue sin parchear, por lo que publicó los detalles para advertir a los usuarios.

El error se encuentra en el servidor de repositorio, el componente de CD de Argo que lee los repositorios de Git y crea manifiestos de Kubernetes, los archivos que definen lo que implementa el clúster.

Su servicio gRPC interno no tiene autenticación; cualquiera que pueda acceder a él puede enviar una solicitud diseñada para ejecutar un comando. Synacktiv demostró el ataque contra Argo CD v2.13.3 y no informa ninguna versión parcheada; no publicó una lista completa de las versiones afectadas.

La técnica abusa personalizaruna herramienta estándar que ejecuta Argo CD para convertir archivos del repositorio en manifiestos. Kustomize tiene una opción –helm-command que apunta al binario de helm al que debe llamar.

Ciberseguridad

Synacktiv descubrió que una solicitud no autenticada al servicio GenerateManifest del servidor de repositorio puede establecer esa opción en un script, extraído de un repositorio Git controlado por un atacante. Cuando se ejecuta kustomize, ejecuta el script en lugar de helm.

Pero «interno» no significa aislado por defecto. CD Argo envía políticas de red de Kubernetes que separan el servidor de repositorio de todo excepto de sus propios componentes.

Synacktiv encontró el gráfico Helm, una forma común de instalar Argo CD, deja esas políticas desactivadas de forma predeterminadacon networkPolicy.create establecido en false. En esa configuración, un atacante que comprometa un solo pod en el clúster puede llegar al servidor de repositorio y desencadenar el error.

Ejecutar código en el servidor de repositorio no es el final. Synacktiv usó ese acceso para leer la contraseña de Redis del clúster desde una variable de entorno, conectarse al caché de Redis de Argo CD y envenenar los datos de implementación almacenados. En la siguiente sincronización automática, Argo CD implementó una carga de trabajo proporcionada por el atacante.

Ese paso revive CVE-2024-31989Cycode encontró una falla en 2024 donde Redis de Argo CD no tenía contraseña, lo que permitió que cualquier pod en el clúster envenenara el caché de implementación. Argo CD solucionó el problema agregando una contraseña de Redis, pero el caché en sí aún no está firmado, por lo que robar la contraseña vuelve a abrir el mismo ataque.

que hacer

No existe una versión parcheada, por lo que la defensa es el aislamiento de la red. Active las políticas de red de Kubernetes para que solo los componentes propios de Argo CD puedan llegar al servidor de repositorio y a los puertos de Redis. Argo CD proporciona los archivos de políticas; Los usuarios de Helm tienen que habilitarlos porque el gráfico los deja fuera.

Comprueba qué está activo con: kubectl obtiene la política de red -A. Una instalación saludable muestra una política de red por componente, incluido el servidor de repositorio y Redis. Si faltan esas políticas, se puede acceder al servidor de repositorio y a los puertos de Redis desde el resto del clúster.

Ciberseguridad

Synacktiv creó una herramienta, argo-cdown, que automatiza el ataque completo. Está reteniendo la herramienta por ahora para darles tiempo a los defensores para bloquear sus políticas de red, y dice que la publicará en GitHub más adelante para que los administradores puedan probar sus propias implementaciones.

Esta no es la primera vez que Argo CD expone sus propios componentes internos. En septiembre de 2025, parchó CVE-2025-55190donde un token API con solo acceso de lectura básico podría recuperar las credenciales del repositorio Git de un proyecto, una falla que The Hacker News señaló en ese momento.

En mayo de 2026, otro error, CVE-2026-42880permitió a los usuarios de solo lectura leer secretos de Kubernetes en texto sin formato. Es difícil pasar por alto el patrón: Argo CD concentra el acceso al clúster y los secretos del repositorio, y sus superficies internas siguen entregándolos, a una solicitud no autenticada en un error y a un token de privilegios bajos en el siguiente.

Hasta que se envíe un parche, tratar la red del clúster como hostil es la única defensa real.

Microsoft parchea el defecto CVE-2026-45659 de SharePoint RCE en todas las versiones del servidor – CYBERDEFENSA.MX

Microsoft ha implementado actualizaciones para corregir una vulnerabilidad de ejecución remota de código que afecta a SharePoint y que podría ser explotada por delincuentes en ataques sin que sea necesario cumplir ninguna condición especializada.

La vulnerabilidad, rastreada como CVE-2026-45659tiene una puntuación CVSS de 8,8. Se le ha asignado una gravedad importante.

«La deserialización de datos que no son de confianza en Microsoft Office SharePoint permite a un atacante autorizado ejecutar código a través de una red», dijo Microsoft en un aviso publicado la semana pasada.

Microsoft señaló que la vulnerabilidad podría ser activada por cualquier atacante autenticado y que no requiere administrador ni otros privilegios elevados.

«En un ataque basado en red, un atacante autenticado, que tiene un mínimo de permisos de miembro del sitio (PR:L), podría ejecutar código de forma remota en SharePoint Server», añadió el fabricante de Windows.

Ciberseguridad

Microsoft le dio crédito a un investigador llamado MEOW por descubrir e informar la falla. Se han publicado actualizaciones para las siguientes versiones:

El mes pasado, Microsoft publicó correcciones para una vulnerabilidad de suplantación de identidad que afectaba a Microsoft SharePoint Server (CVE-2026-32201, puntuación CVSS: 6,5) y que, según dijo, había sido explotada en estado salvaje.

Aunque el gigante tecnológico señala que es menos probable que CVE-2026-45659 sea explotado, es esencial que los usuarios apliquen las correcciones necesarias para una protección óptima, particularmente si se considera el hecho de que los atacantes han utilizado repetidamente varias fallas en la plataforma colaborativa a lo largo de los años.

actualice su servidor inmediatamente – CYBERDEFENSA.MX

cPanel tiene liberado actualizaciones de seguridad para abordar un problema de seguridad que afecta varias rutas de autenticación que podrían permitir a un atacante obtener acceso al software del panel de control.

El problema afecta a todas las versiones actualmente compatibles, según una alerta publicada por cPanel el martes. El problema se ha solucionado en las siguientes versiones:

  • 11.110.0.97
  • 11.118.0.63
  • 11.126.0.54
  • 11.132.0.29
  • 11.136.0.5
  • 11.134.0.20
Ciberseguridad

«Si su servidor no ejecuta una versión compatible de cPanel que sea elegible para esta actualización, se recomienda encarecidamente que trabaje para actualizar su servidor lo antes posible, ya que también puede verse afectado», señaló cPanel.

Si bien cPanel no compartió ningún detalle sobre la vulnerabilidad, la empresa de alojamiento web y registro de dominio Namecheap revelado que «se relaciona con un exploit de autenticación de inicio de sesión que podría permitir el acceso no autorizado al panel de control».

Como medida de precaución, la compañía ha aplicado una regla de firewall para bloquear el acceso a los puertos TCP 2083 y 2087, una medida que, según dijo, restringirá temporalmente el acceso de los clientes a sus interfaces cPanel y WHM hasta que se aplique un parche completo.

«Nuestro equipo está monitoreando activamente la situación y aplicará el parche oficial en todos los servidores compatibles tan pronto como esté disponible», señaló Namecheap. «El acceso a sus paneles de control se restaurará inmediatamente una vez que el parche se haya implementado con éxito».

A partir del 29 de abril de 2026 a las 02:42 am UTC, la solución se aplicó al revendedor, a los servidores de Stellar Business y al resto, según el equipo de soporte de Namecheap.

El servidor SystemBC C2 revela más de 1570 víctimas en la operación The Gentlemen Ransomware – CYBERDEFENSA.MX

Se ha observado que los actores de amenazas asociados con la operación The Gentlemen ransomware-as-a-service (RaaS) intentan implementar un conocido malware proxy llamado SystemBC.

De acuerdo a nueva investigación Publicado por Check Point, el servidor de comando y control (C2 o C&C) vinculado a SystemBC ha llevado al descubrimiento de una botnet con más de 1.570 víctimas.

«SystemBC establece túneles de red SOCKS5 dentro del entorno de la víctima y se conecta a su servidor C&C utilizando un protocolo cifrado RC4 personalizado», dijo Check Point. También puede descargar y ejecutar malware adicional, con cargas útiles escritas en el disco o inyectadas directamente en la memoria.

Desde su aparición en julio de 2025, The Gentlemen se ha establecido rápidamente como uno de los grupos de ransomware más prolíficos, cobrándose más de 320 víctimas en su sitio de filtración de datos. Operando bajo un modelo clásico de doble extorsión, el grupo es tan versátil como sofisticado, exhibiendo capacidades para apuntar a sistemas Windows, Linux, NAS y BSD con un casillero basado en Go, además de emplear conductores legítimos y herramientas maliciosas personalizadas para subvertir las defensas.

No está claro exactamente cómo los actores de amenazas obtienen acceso inicial, aunque la evidencia sugiere que se está abusando de los servicios de Internet o de las credenciales comprometidas para establecer un punto de apoyo inicial, seguido de la participación en el descubrimiento, el movimiento lateral, la puesta en escena de la carga útil (es decir, Cobalt Strike, SystemBC y el cifrador), la evasión de defensa y la implementación de ransomware. Un aspecto notable de los ataques es el abuso de los objetos de política de grupo (GPO) para facilitar el compromiso de todo el dominio.

«Al adaptar sus tácticas contra proveedores de seguridad específicos, The Gentlemen ha demostrado una gran conciencia de los entornos de sus objetivos y una voluntad de participar en un reconocimiento profundo y modificación de herramientas durante el curso de su operación», dijo el proveedor de seguridad Trend Micro. anotado en un análisis del oficio del grupo en septiembre de 2025.

Los últimos hallazgos de Check Point muestran que un afiliado de The Gentlemen RaaS implementó SystemBC en un host comprometido, con el servidor C2 vinculado al malware proxy que se apoderó de cientos de víctimas en todo el mundo, incluidos EE. UU., Reino Unido, Alemania, Australia y Rumania.

Ciberseguridad

Si bien SystemBC se ha utilizado en operaciones de ransomware desde 2020, la naturaleza exacta de la conexión entre el malware y el esquema de delito electrónico de The Gentlemen aún no está clara, por ejemplo, si es parte del manual de ataque o si es algo implementado por un afiliado específico para la exfiltración de datos y el acceso remoto.

«Durante el movimiento lateral, el ransomware intenta cegar a Windows Defender en cada host remoto accesible al impulsar un script de PowerShell que deshabilita el monitoreo en tiempo real, agrega amplias exclusiones para la unidad, el recurso compartido de preparación y su propio proceso, apaga el firewall, vuelve a habilitar SMB1 y afloja los controles de acceso anónimo de LSA, todo antes de implementar y ejecutar el binario del ransomware en ese host», dijo Check Point.

La variante ESXi incorpora menos funcionalidades que la variante de Windows, pero está equipada para apagar máquinas virtuales para mejorar la efectividad del ataque, agrega persistencia a través de crontab e inhibe la recuperación antes de que se implemente el binario del ransomware.

«La mayoría de los grupos de ransomware hacen ruido cuando se inician y luego desaparecen. Los Gentlemen son diferentes», dijo Eli Smadja, gerente de grupo de Check Point Research, en un comunicado compartido con The Hacker News.

«Han solucionado el problema de reclutamiento de afiliados al ofrecer un mejor trato que cualquier otra persona en el ecosistema criminal. Cuando ingresamos a uno de los servidores de su operador, encontramos más de 1,570 redes corporativas comprometidas que ni siquiera habían aparecido en las noticias todavía. La escala real de esta operación es significativamente mayor de lo que se conoce públicamente, y sigue creciendo».

Los hallazgos se producen cuando Rapid7 destacó el funcionamiento interno de otra familia de ransomware relativamente nueva llamada Kyber que surgió en septiembre de 2025, dirigido a infraestructuras Windows y VMware ESXi utilizando cifradores desarrollados en Rust y C++, respectivamente.

«La variante ESXi está diseñada específicamente para entornos VMware, con capacidades de cifrado de almacenes de datos, terminación opcional de máquinas virtuales y alteración de interfaces de gestión», dijo la empresa de ciberseguridad. dicho. «La variante de Windows, escrita en Rust, incluye una característica ‘experimental’ que él mismo describe para apuntar a Hyper-V».

«Kyber ransomware no es una obra maestra de código complejo, pero es muy eficaz a la hora de causar destrucción. Refleja un cambio hacia la especialización sobre la sofisticación».

Según los datos compilados por ZeroFox, en el primer trimestre de 2026 se observaron al menos 2.059 incidentes distintos de ransomware y extorsión digital (I+DE), y en marzo se registraron no menos de 747 incidentes. Los grupos más activos durante el período fueron Qilin (338), Akira (197), The Gentlemen (192), INC Ransom y Cl0p.

«En particular, las víctimas con sede en América del Norte representaron aproximadamente el 20 por ciento de los ataques de The Gentlemen en el tercer trimestre de 2025, el 2% en el cuarto trimestre de 2025 y el 13% en el primer trimestre de 2026», ZeroFox. dicho. «Esto va en gran medida en contra de las tendencias típicas de ataques regionales por parte de otros colectivos de I+D, de los cuales al menos el 50 por ciento son víctimas de América del Norte».

La velocidad cambiante de los ataques de ransomware

La empresa de ciberseguridad Halcyon, en su Informe de evolución del ransomware 2025reveló que la amenaza continúa madurando hasta convertirse en algo más disciplinado y una empresa criminal impulsada por los negocios, incluso cuando los ataques de ransomware dirigidos a la industria automotriz más del doble en 2025representando el 44% de todos los incidentes cibernéticos en todo el sector.

Ciberseguridad

Otras tendencias importantes incluyen intentos de perjudicar las herramientas de seguridad de detección y respuesta de endpoints (EDR), el uso de la técnica de ataque Bring Your Own Vulnerable Driver (BYOVD) para escalar privilegios y deshabilitar soluciones de seguridad, desdibujar las campañas de ransomware criminales y de los estados nacionales, y aumentar los ataques a organizaciones pequeñas y medianas y a entornos de tecnología operativa (OT).

«El ransomware continuó creciendo como un ecosistema industrializado duradero construido sobre la especialización, la infraestructura compartida y la rápida regeneración en lugar de una sola marca», dijo. «La presión de las fuerzas del orden y las incautaciones de infraestructura interrumpieron operaciones importantes, generando fragmentación, cambios de marca e intensificación de la competencia en un panorama más fluido».

Las operaciones de ransomware son cada vez más rápidas y los tiempos de permanencia se reducen de días a horas. Se ha descubierto que alrededor del 69% de los intentos de ataque observados se realizaron deliberadamente durante las noches y los fines de semana para superar la respuesta de los defensores.

Por ejemplo, los ataques que involucran el ransomware Akira han demostrado una rapidez inusual, escalando rápidamente desde el punto de apoyo inicial hasta el cifrado completo en una hora en algunos casos sin detección, lo que destaca un motor de ataque bien engrasado diseñado para maximizar el impacto.

«La combinación de Akira de capacidades de compromiso rápido, ritmo operativo disciplinado e inversión en infraestructura de descifrado confiable lo distingue de muchos operadores de ransomware», dijo Halcyon. «Los defensores deberían tratar a Akira no como una amenaza oportunista, sino como un adversario capaz y persistente que explotará cada debilidad disponible para alcanzar su objetivo».