Servidor expuesto de de delincuente revela puertas traseras en miles de sitios de WordPress

Un grupo de ciberdelincuentes dejó uno de sus servidores completamente expuesto en Internet durante tres semanas, revelando así el funcionamiento interno de la operación: las herramientas de hacking, los registros de actividad y listas de objetivos con más de 1,4 millones de sitios web. Un servidor WP-SHELLSTORM abierto expuso herramientas, registros y listas de objetivos que nombran 1,4 millones de sitios, y los investigadores validaron 25.195 vulneraciones.

Si bien se logró acceder a muchos menos sitios, los archivos expuestos mostraron a los investigadores cómo se lleva a cabo una operación de hackeo masivo desde dentro.

La operación, ahora conocida como WP-SHELLSTORM, es lo que SOCRadar denomina una red de acceso a webshells: un grupo que accede a sitios web a gran escala, instala una puerta trasera oculta (una "webshell") en cada uno y empaqueta ese acceso para su reventa.

La mayor actividad se centró en sitios de WordPress con plugins desactualizados. Si utilizas WordPress o Joomla, las dos vulnerabilidades más importantes se encontraban en el plugin de caché Breeze y en el editor JCE de Joomla; consulta la lista de verificación a continuación si este es tu caso.

Un servidor olvidado

Dos equipos analizaron la misma carpeta expuesta. El equipo de inteligencia de amenazas de SOCRadar lo detectó el 11 de junio de 2026 en un servidor alquilado en EE.UU. (137.175.93[.]126) sin contraseña. En su interior se encontraron aproximadamente 800 MB distribuidos en 434 archivos: webshells, scripts de explotación, resultados de escaneos, el historial de comandos del operador y la configuración de comando y control.

Ctrl-Alt-Intel también había analizado el mismo directorio, tras encontrarlo en la plataforma de directorios abiertos Hunt.io, y publicó el 22 de junio, semanas antes del informe de SOCRadar del 9 de julio. La vulnerabilidad se debió a un simple descuido: el operador inició un servidor web Python para transferir archivos y lo dejó funcionando durante 22 días.

El equipo aprovechó vulnerabilidades conocidas públicamente en plugins web, la mayoría en WordPress, y creó escáneres automatizados para lanzar esos exploits contra enormes listas de objetivos obtenidas de FOFA, un motor de búsqueda chino para sistemas conectados a Internet, similar a Shodan.

Cuando un sitio web ejecutaba una versión vulnerable, el exploit podía instalar un webshell: un pequeño script que permite al atacante ejecutar comandos en el servidor desde cualquier lugar, leer archivos, robar contraseñas y acceder a niveles más profundos de la red.

El conjunto de herramientas cubría 27 vulnerabilidades conocidas, aunque unas pocas fueron las que generaron la mayor parte del trabajo. La más importante fue una vulnerabilidad en el plugin de caché Breeze (CVE-2026-3844), que el equipo lanzó contra más de 45.000 objetivos y, según sus propios cálculos, creó puertas traseras en más de 17.000 de ellos.

Las cifras, en términos sencillos

La cifra principal requiere una aclaración. El recuento de 1,4 millones se refiere a la cantidad de dominios incluidos en las listas de objetivos, no a la cantidad de sitios comprometidos, y dichas listas abarcaban WordPress, Joomla y otras plataformas. El archivo más grande contenía una lista de 587.034 objetivos de Joomla.

La cantidad real de sitios comprometidos fue mucho menor, y los dos equipos de investigación la calcularon de forma diferente: el recuento deduplicado de Ctrl-Alt-Intel encontró 25.195 sitios con evidencia de compromiso confirmada o validada, mientras que SOCRadar, contabilizando los webshells activos, estimó la cifra real en más de 5.700.

Un fallo muestra claramente esta discrepancia: un exploit de Joomla se lanzó contra más de 560.000 objetivos, pero solo afectó a 77 de ellos.

Estar en la lista de escaneo de alguien no es lo mismo que haber sido hackeado. Tenga esto en cuenta siempre que un informe comience con una cifra alarmante de objetivos.

Las herramientas y una campaña anterior

La puerta trasera principal, un archivo llamado down.php, estaba altamente ofuscada, con cuatro capas de profundidad, y parece una variante de una webshell china de código abierto llamado BestShell. Una vez en ejecución, podía gestionar archivos, ejecutar comandos, abrir shells inversas, escanear la red y comprobar qué software de seguridad utilizaba el host.

Para su propio acceso remoto, el grupo utilizó un dropper SNOWLIGHT para instalar VShell, una puerta trasera sigilosa que disfraza su nombre de proceso como [kworker/0:2] para mimetizarse con los hilos del kernel en una lista de procesos.

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

El servidor también contenía rastros de un ataque anterior, muy diferente. SOCRadar descubrió que, antes del sonado ataque a WordPress, el mismo grupo llevó a cabo una campaña más discreta a principios de mayo de 2026 contra sistemas Java corporativos. Extrajeron 613 archivos de configuración de 11 sistemas de nueve empresas de los sectores de tecnología financiera, comercio electrónico, logística, videojuegos y electrónica.

El botín incluía claves de acceso a la nube para AWS, Alibaba Cloud, Oracle, Tencent y DigitalOcean, contraseñas de bases de datos y claves privadas RSA de Alipay. Se aprovecharon de una vulnerabilidad antigua y conocida en Nacos, un servidor de configuración (CVE-2021-29441), que permite a un atacante eludir el inicio de sesión falsificando una sola cabecera web.

SOCRadar interpreta la secuencia temporal como una secuencia: primero, obtener credenciales corporativas de alto valor; luego, semanas después, centrarse en el ataque de puertas traseras de mayor volumen; una ronda de financiación antes de la expansión.

Técnicas de trabajo deficientes

Ambos equipos evalúan con un grado de confianza medio-alto que el operador es chino o habla chino. Señalan el dominio del chino simplificado en todo el código y el historial de comandos, la dependencia de FOFA (que, según los investigadores, requiere un número de teléfono chino para registrarse) y las herramientas Godzilla y VShell, preferidas en foros de habla china.

SOCRadar va un paso más allá, interpretando que el grupo actuaba por motivos económicos en lugar de estar dirigido por el Estado. Los nombres en los archivos (tance, chen-kk, chenyk) se consideran pistas, no pruebas concluyentes. Un cabo suelto destaca: una única dirección IP en Taiwán realizó más de 42.000 solicitudes para descargar las herramientas del propio grupo. Podría tratarse de un segundo operador, un cliente u otro investigador. Los registros no permiten esclarecerlo.

Para un grupo que utilizaba un conjunto de herramientas realmente capaz, la negligencia del grupo fue notable. Dejó el servidor abierto, un archivo de configuración de FOFA que esta organización puede rastrear a través de su canal de investigación, y un historial de comandos sin editar que lo revelaba todo. Cuando finalmente se percató de su detección, entre el 2 y el 4 de julio, eliminó varias líneas de registro. Tres semanas demasiado tarde.

Este error es recurrente. En marzo de 2026, la misma organización de investigación descubrió al grupo ruso Fancy Bear (APT28) de la misma manera: un directorio abierto que había olvidado expuso las herramientas de phishing y los registros del grupo, en una campaña que Hunt.io denominó Operación Roundish.

¿Qué hacer?

Si utiliza alguno de los programas afectados, revíselo hoy mismo. No se trata de vulnerabilidades desconocidas: dos de ellas están siendo explotadas activamente en otros lugares.

Wordfence registró decenas de miles de ataques bloqueados contra la vulnerabilidad de Everest Forms Pro (CVE-2026-3300) esta primavera, y el fallo JCE de Joomla (CVE-2026-48907) es una vulnerabilidad de máxima gravedad que CISA ha añadido a su lista de Vulnerabilidades Explotadas Conocidas.

Lo que hace que WP-SHELLSTORM merezca atención no es su sofisticación, sino su aparente normalidad. Exploits públicos, escaneo automatizado y una lista de objetivos de un millón de líneas fueron suficientes para comprometer sitios web a gran escala, sin necesidad de vulnerabilidades de día cero. Los detalles son públicos únicamente porque el grupo olvidó apagar su propio servidor.

Fuente: THN

Seguir leyendo...

Explotan activamente una vulnerabilidad crítica de Oracle E-Business Suite

Actores maliciosos están explotando activamente la vulnerabilidad CVE-2026-46817, una vulnerabilidad crítica de acceso remoto sin autenticación en Oracle E-Business Suite (EBS). Se detectó actividad de ataque en tiempo real en infraestructura honeypot durante el fin de semana del 27 y 28 de junio de 2026.

CVE-2026-46817 es una vulnerabilidad de gravedad crítica que reside en el producto Oracle Payments dentro de Oracle E-Business Suite, específicamente en el componente de transmisión de archivos. La vulnerabilidad tiene una puntuación base CVSS de 9.8 y permite que un atacante no autenticado con acceso a la red a través de HTTP comprometa completamente Oracle Payments, lo que conlleva el control total de la confidencialidad, la integridad y la disponibilidad.

Esta vulnerabilidad de seguridad se descubrió en el componente de transmisión de archivos del producto Oracle Payments de EBS y permite que agentes maliciosos no autenticados con acceso a la red HTTP se apoderen de sistemas vulnerables mediante ataques de baja complejidad.

Las versiones afectadas abarcan desde Oracle E-Business Suite 12.2.3 hasta 12.2.15. El vector CVSS refleja la baja complejidad del ataque y la ausencia de requisitos de autenticación, lo que facilita su explotación a gran escala.

Aunque no existe código de prueba de concepto (PoC) público, esta es la primera explotación real conocida de esta vulnerabilidad, lo que indica que el atacante podría estar utilizando capacidades de explotación desarrolladas de forma privada.

El tráfico de ataque capturado en los honeypots de Defused reveló solicitudes POST dirigidas a /OA_HTML/ibytransmit, el punto final de transmisión de archivos de Oracle iPayment.

La IP del atacante, 45.84.137[.]125, operando a través de AS136787 PacketHub S.A. (Francia), se dirigió al puerto 443 y envió una carga útil XML DeliveryRequest manipulada.

La carga útil contenía un esquema de transmisión CODEX_PULL, con el parámetro FULL_FILE_PATH configurado en /etc/passwd, un indicador clásico de una cadena de explotación de lectura de archivos locales/recorrido de rutas diseñada para extraer archivos confidenciales del sistema.

Según Shadowserver, el 28 de junio se registraron un total de 456 ataques en todas las regiones monitorizadas, con Norteamérica (193) y Asia (181) concentrando la mayor parte del tráfico. Europa registró 53 ataques, Sudamérica 18, África 9 y Oceanía 2.

Oracle abordó la vulnerabilidad CVE-2026-46817 en su Actualización Crítica de Parches de Seguridad (CSPU), publicada el 28 de mayo de 2026. Esta actualización corrigió 35 vulnerabilidades CVE distintas en diversas familias de productos de Oracle, 11 de las cuales se clasificaron como críticas.

Oracle recomendó encarecidamente a todos sus clientes que aplicaran los parches inmediatamente después de su publicación. Posteriormente, el 16 de junio de 2026, se publicó una CSPU complementaria que reforzó la postura de Oracle respecto a las vulnerabilidades.

Las organizaciones que utilizan Oracle E-Business Suite deben actuar de inmediato:

• Aplicar sin demora el parche CSPU de mayo de 2026 para las versiones 12.2.3 a 12.2.15 de EBS.
• Bloquee o restrinja el acceso público a internet a las interfaces de Oracle EBS, en particular a la ruta /OA_HTML/.
• Auditar los registros del servidor web en busca de solicitudes POST a /OA_HTML/ibytransmit con cargas útiles XML inusuales.
• Investigar la IP del atacante (45.84.137[.]125) y la cadena User-Agent (ibytransmit-lab-poc/1.0) en los registros del firewall y del proxy.
• Realizar una evaluación de la vulnerabilidad si la aplicación del parche se retrasó más allá del 28 de mayo de 2026.

Dada la ausencia de código PoC público y la aparición confirmada de herramientas de explotación privadas, las implementaciones de Oracle EBS sin parchear siguen expuestas a un grave riesgo de sufrir una vulneración total del sistema.

Fuente: CyberSecurityNews

Seguir leyendo...

Vulnerabilidades explotadas: ya no puedes salir de esto con parches

Durante treinta años, la gestión de vulnerabilidades se ha basado en lo que ahora parece un lujo imposible: un margen de meses entre el momento en que se encontró una vulnerabilidad y el momento en que alguien pudo descubrir cómo convertirla en un arma. Clasificar por gravedad, programar la solución, validar y seguir adelante.

Ese generoso amortiguador es lo que hizo que todo el sistema funcionara.

La IA ha eliminado el arrastre manual que hacía que la creación y utilización de "armas" fuera lenta. Leer el aviso, encontrar el camino, dar forma a la cadena, probar qué funciona: nada de eso puede darse el lujo de moverse a la velocidad humana. Hoy en día, los plazos desde la divulgación hasta la explotación son de horas, no de meses.

El Zero Day Clock, que rastrea esto en tiempo real, actualmente tiene un promedio de alrededor de 8 horas para 2026, frente a aproximadamente 53 días hace apenas dos años. La cifra cambia a medida que llegan nuevos datos, pero en este punto se sitúa firmemente por debajo de las 24 horas.

No puedes salir de esto con parches

El reflejo suele ser simplemente parchear más rápido. Pero la remediación no es simplemente un interruptor que se activa. Los parches esperan una serie de contingencias: pruebas de regresión, ventanas de cambio y compromisos de tiempo de actividad. Y hoy, lamentablemente, todos los números que importan van en la dirección equivocada.

El Informe de investigaciones de vulneración de datos de 2026 de Verizon, elaborado en más de 13.000 organizaciones, encontró que:

• El tiempo medio de reparación de vulnerabilidades conocidas y explotadas es ahora de 43 días, frente a los 32 del año pasado.
• La proporción de organizaciones que los parchean completamente se redujo del 38% al 26%.
• Incluso los que tienen mejor desempeño cierran sólo entre el 30 y el 40% de estas vulnerabilidades en la primera semana, una tasa que apenas ha variado en años.

Cuando la infracción se desarrolla en horas y la reparación en semanas, la infracción se produce en el medio. Y la pista cada vez es más larga.

El volumen lo garantiza: 48.185 CVE en 2025, menos del 0,6% jamás parcheados. "Parchear para salir" ha dejado de ser una matemática viable.

Mythos es el umbral en el que los modelos de IA fueron capaces de encontrar y convertir en armas vulnerabilidades por sí solos, y no es teórico: el modelo de clase Mythos de Anthropic encontró una falla que había estado oculta en OpenBSD, ampliamente considerado como uno de los sistemas operativos más seguros del mundo, durante 27 años.

La línea de base para 2025 se ha convertido en el piso, no en el techo.

La pregunta ya no es "¿qué es vulnerable?" porque en una lista donde todo tiene una puntuación de 9 o 10, esto efectivamente no prioriza nada. La verdadera pregunta es: "¿Qué es realmente explotable contra nosotros en este momento, con los controles que ya estamos aplicando?". Encontrar la exposición nunca fue la parte difícil. Demostrar la decisión correcta (parchear, mitigar, monitorear o aceptar) es la brecha crítica.

Las herramientas de pentesting automatizados toman la prueba de penetración manual que solía realizarse una vez por trimestre y la ejecutan continuamente, a escala, activando cadenas de exploits reales contra activos reales. Donde se puede ejecutar eso, es la prueba más fuerte que existe: ves cómo el exploit tiene éxito. Pero, aunque automatizar el lanzamiento te hace más rápido; no cambia lo que puede alcanzar la explotación.

La explotación en vivo solo funciona cuando es seguro activar un exploit y cuando existe un exploit funcional. Eso deja tres espacios en la herramienta pentest que se pueden cerrar, y apilarlos juntos tampoco ayuda. ¿Por qué?

• Sin exploit, nada que ejecutar. Una gran parte de los CVE divulgados nunca obtienen un exploit público o seguro. Sin nada que iniciar, la ejecución no puede indicarle si son explotables en su entorno.
• Activos que no puedes arriesgar. Los sistemas críticos para el negocio, regulados y aislados son exactamente aquellos contra los que no se puede detonar un exploit de forma segura y, por lo general, son los que más importan.
• La ventana del primer día. Armar un nuevo exploit y conectarlo a sus herramientas lleva tiempo. Los atacantes ya se están moviendo mientras tu lanzamiento todavía está en el banco.

En una empresa típica, la porción que puede explotar de forma segura en vivo suele ser sólo del 10 al 15% de su imagen de exposición total. Para el 85% o 90% restante, la ejecución no tiene respuesta que dar.

Probar en tierra un cohete que no se puede lanzar

La forma más segura de demostrar que un cohete volará es lanzarlo. Pero ningún programa espacial demuestra que su flota sea así.

Algunos existen sólo como un diseño en papel, otros cuentan con tripulación y son demasiado valiosos para arriesgarlos, y otros todavía están en la línea de ensamblaje. Así que los ingenieros los prueban en tierra: el motor empuja en una posición estática, prueba el sistema de combustible bajo presión total y el escudo térmico contra su carga térmica máxima. Si algún componente requerido falla, el cohete no puede volar y ellos lo saben sin abandonar la plataforma.

Ésa es la misma brecha de tres partes que enfrentan los equipos de seguridad.

• El CVE sin exploits es el cohete que sólo existe en el papel.
• El activo prohibido es el cohete tripulado que no arriesgarás.
• El CVE del primer día es el fuselaje parcialmente construido mientras se agota la ventana de lanzamiento.
• El lanzamiento es la prueba a la que llegas cuando puedes; la prueba sobre el terreno es la prueba en la que confías cuando no puedes.

Romper la cadena, rompe el exploit

Un exploit no es mágico. Es una cadena de técnicas específicas, los TTP que un atacante tiene que ejecutar en secuencia: obtener ejecución, eludir una protección, escalar privilegios, deshacerse de credenciales, avanzar hacia el objetivo.

Cada enlace depende de las condiciones de su entorno, y cada uno puede probarse por sí solo con los controles implementados reales, de la misma manera que un ingeniero prueba un motor en un soporte estático sin tener que arrancar todo el vehículo.

Esa es la validación de la cadena TTP. Usted asigna un CVE a la cadena de técnicas que requiere su explotación y luego valida cada técnica con sus controles existentes. Si su entorno rompe algún vínculo requerido, el exploit no podrá tener éxito allí y usted lo sabrá sin tener que activar un exploit activo. Si todos los vínculos se mantuvieran, la exposición sería genuinamente explotable, con evidencia.

Cuatro cosas distintas que veredicto de una etiqueta CVSS o EPSS estática:

• Valida por inferencia, no por detonación. Por lo tanto, funciona donde la explotación en vivo sería insegura o imposible.
• Es consciente del control. El veredicto refleja su EDR, GPO, protección LSASS, lista de permitidos y firewall reales, no solo un número en una hoja de datos.
• Pesa la accesibilidad. Las exposiciones contenidas no se contabilizan en exceso.
• Envía pruebas. La cadena, los controles probados y el resultado: una pista de auditoría que llega hasta la junta directiva.

Cómo se ve en un CVE real

Tomemos como ejemplo CVE-2025-29824, un uso después de la liberación de CLFS de Windows que escala a SYSTEM (visto en estado salvaje en la actividad Storm-2460 o RansomEXX).

En lugar de activar un exploit, lo descompones en la cadena que un atacante debe ejecutar y prueba cada paso con tu pila:

• Ejecución de certutil y MSBuild – T1105 / T1127
• Bypass KASLR / SysInfo – T1082
• Explotación CLFS UAF → ejecución del kernel – T1068
• modificación de token e inyección de dllhost – T1134 / T1055
• Volcado de LSASS a través de dllhost enmascarado – T1003

Cada técnica se prueba con respecto a la política de EDR, GPO/refuerzo, protección LSASS, lista de aplicaciones permitidas y NGFW.

Si su lista de permitidos detiene el ejecutivo de MSBuild, o su protección LSASS bloquea el volcado de credenciales, la cadena se rompe, el CVE no es explotable en ese activo y puede mostrar exactamente por qué. No se necesita un exploit certificado y funciona en la caja aislada a la que nunca apuntarías un exploit en vivo. Y al hacerlo, ha pasado de una nueva identificación CVE a una decisión defendible en horas, el día de la divulgación, en lugar de semanas después.

Pruébelo en todas partes, no sólo donde pueda lanzarlo

El lanzamiento y la prueba en tierra no son rivales, son simbióticos. Los programas más potentes ejecutan ambos y siguen probando a medida que el entorno avanza a través del tiempo y las configuraciones.

Se pueden ejecutar cadenas de exploits en vivo donde el disparo es seguro, encadenamiento TTP para los activos fuera de los límites y CVE del primer día que un lanzamiento no puede alcanzar, y validación de control continuo para que la "aceptación" del último trimestre se vuelva a probar, no se asuma.

Esto da una respuesta a la única pregunta que importa: "¿Qué es realmente explotable aquí y ahora?"

Fuente: BC

Seguir leyendo...

(Otra) vulnerabilidad permite eludir BitLocker de Windows (Zero-Day)

El investigador de seguridad Chaotic Eclipse (también conocido como Nightmare-Eclipse y MSNightmare) ha publicado una nueva vulnerabilidad para eludir BitLocker de Windows, denominada GreatXML, un día después de haber publicado un exploit para Microsoft Defender.

"Fue un descubrimiento accidental; me llevó cuatro horas encontrarlo", declaró el investigador en una publicación. "Si alguna vez intentaste usar el análisis sin conexión de Windows Defender, eres automáticamente vulnerable a un exploit de BitLocker. No estoy seguro de si aún se puede activar el fallo sin usar la función de análisis sin conexión, porque sin duda es posible".

El exploit funciona de la siguiente manera:

• Copie un archivo XML ("unattend.xml") y una carpeta de recuperación que contenga otro archivo XML ("Recovery/WindowsRE/ReAgent.xml") a la raíz de la partición de recuperación.
• Reinicie en el Entorno de Recuperación de Windows (WinRE) manteniendo presionada la tecla Mayús mientras hace clic en Reiniciar en el menú de inicio de Windows.

Si se siguen todos los pasos correctamente, se generará una shell con acceso ilimitado al volumen de BitLocker.

"Si nunca se inició el análisis sin conexión de Defender, deberá iniciar sesión e iniciarlo manualmente o encontrar una manera de arrancar en WinRE en estado de análisis sin conexión (creo que debería ser posible hacerlo sin iniciar sesión) y seguir los pasos anteriores", señaló Chaotic Eclipse.

El lanzamiento de GreatXML se produce poco después de RoguePlanet, una vulnerabilidad de día cero en Microsoft Defender que facilita la escalada de privilegios local (LPE) a SYSTEM, otorgando al atacante la capacidad de ejecutar código arbitrario o realizar acciones no autorizadas.

GreatXML es también el segundo exploit para eludir BitLocker publicado por Chaotic Eclipse después de YellowKey (también conocido como CVE-2026-45585), cuyos parches fueron publicados por Microsoft esta semana como parte de las actualizaciones de Patch Tuesday.

Fuente: THN

Seguir leyendo...

BlueHammer: Zero Day y exploit que usa Windows Defender para hackear Windows (sin parche)

BlueHammer es un Zero-Day sin parche (CVE-2026-33825 ya parcheado el 14 de abril por Microsoft ) que permite a un usuario local con bajos privilegios escalar a NT AUTHORITY\SYSTEM en menos de un minuto, sin exploits del kernel ni corrupción de memoria. El investigador Will Dormann lo confirmó como operativamente relevante. El código de explotación es público y no ha sido parcheado.

Windows Defender, el antivirus integrado que se ejecuta en todas las máquinas con Windows, tiene un exploit de Zero-Day con el código fuente completo en GitHub. Sin parche, sin CVE, y se confirmó que funciona en Windows 10 y 11 completamente actualizado. Un investigador, que dice que Microsoft incumplió su palabra, simplemente está entregando un escalamiento de privilegios que lleva cualquier cuenta con pocos privilegios directamente a NT AUTHORITY\SYSTEM. En Windows Server el resultado es diferente pero sigue siendo grave: un usuario estándar termina con acceso de administrador elevado.

Historia de BlueHammer

El 2 de abril, el investigador publicó la divulgación pública en un blog personal, y el 3 de abril, el código fuente completo del exploit se publicó en GitHub. Ambos publicados bajo el alias Chaotic Eclipse, también conocido como Nightmare Eclipse, con un mensaje al Centro de Respuesta de Seguridad de Microsoft que se reduce a: "Les dije que esto sucedería".

Antes de entrar en el aspecto técnico, hay una historia de fondo que vale la pena conocer. A finales de marzo, el mismo investigador abrió un blog con una sola publicación en la que explicaba que no quería volver nunca más a la investigación pública. Alguien había llegado a un acuerdo con ellos y luego lo había roto, sabiendo exactamente cuáles serían las consecuencias. La publicación dice que dejó al investigador sin hogar y sin nada. No es alguien molesto por un proceso de revisión lento. Es alguien que no tiene nada que perder.

El exploit

Pasemos ahora al exploit en sí, porque realmente vale la pena entenderlo.

BlueHammer no es un error tradicional y no necesita código shell, corrupción de memoria ni un exploit del kernel para funcionar. Lo que hace es encadenar cinco componentes de Windows completamente legítimos en una secuencia que produce algo que sus diseñadores nunca pretendieron. Esos cinco componentes son: Windows Defender, Volume Shadow Copy Service, la API de archivos en la nube, los bloqueos oportunistas y la interfaz RPC interna de Defender.

Una limitación práctica que vale la pena conocer: el exploit necesita una actualización pendiente de la firma de Defender para estar disponible en el momento del ataque. Sin uno en la cola, la cadena no se activa. Eso lo hace menos confiable que un "exploit de botón", pero no hace que sea seguro ignorarlo.

Así es como funciona la cadena de ataque. Cuando Defender ejecuta una actualización de la definición de antivirus, parte de ese proceso implica la creación de una instantánea de volumen temporal, que es el mismo mecanismo de instantánea que utiliza Windows para realizar copias de seguridad y restaurar. Esa instantánea contiene archivos que normalmente están completamente bloqueados durante el funcionamiento normal, incluida la base de datos SAM, que almacena los hash de contraseña para cada cuenta local en la máquina.

BlueHammer se registra como proveedor de sincronización de Cloud Files, el mismo tipo de cosas que usan OneDrive o Dropbox para sincronizar archivos. Cuando Defender toca un archivo específico dentro de esa carpeta, el exploit recibe una devolución de llamada e inmediatamente coloca un bloqueo oportunista en ese archivo. El defensor se detiene, bloqueado, esperando una respuesta que nunca llega. La instantánea que acaba de crear todavía está montada. La ventana está abierta.

Con Defender congelado, el exploit lee las secciones de registro SAM, SYSTEM y SECURITY directamente desde la instantánea. Descifra los hashes de contraseña NTLM almacenados utilizando la clave de arranque extraída de la sección SYSTEM, cambia la contraseña de una cuenta de administrador local, inicia sesión con esa cuenta, copia el token de seguridad del administrador, lo envía al nivel SYSTEM, crea un servicio temporal de Windows y genera un símbolo del sistema que se ejecuta como NT AUTHORITY\SYSTEM. Luego, para cubrir sus huellas, devuelve el hash de la contraseña original. La contraseña de la cuenta local parece completamente sin cambios. Ningún accidente, ninguna alerta, nada.

Toda la cadena se ejecuta en menos de un minuto desde una sesión de usuario normal. Toda la cadena usa VSS, Cloud Files API y oplocks: herramientas legítimas de Windows, lo que dificulta enormemente la detección por firmas estáticas.

El nombre del proveedor de Cloud Files codificado en el código fuente del exploit es IHATEMICROSOFT. La contraseña de administrador utilizada durante el escalamiento está codificada como $PWNed666!!!WDFAIL. Estos no son errores dejados por accidente. Son mensajes, escritos directamente en el código, y solo hay un lector previsto.

Will Dormann, analista principal de vulnerabilidades de Tharros, probó el exploit y confirmó que funciona lo suficientemente bien como para ser una amenaza real.

Microsoft ha estado recortando costos. Los analistas experimentados que sabían cómo analizar un exploit complejo y comprenderlo realmente han sido reemplazados por personal que sigue rígidas listas de verificación de procesos. Uno de esos requisitos de la lista de verificación es una demostración en video del exploit. Los investigadores que se niegan a grabar un vídeo cierran sus informes.

Mitigaciones

Hasta que Microsoft emita un parche oficial o un aviso de mitigación, los equipos de seguridad deben tomar las siguientes medidas preventivas:

• Monitorear herramientas de detección y respuesta en endpoints (EDR) en busca de actividad inusual de escalada de privilegios.
• Restringir los permisos de usuarios locales al mínimo necesario para las operaciones.
• Aplicar un registro mejorado en sistemas Windows para detectar procesos anómalos a nivel de SYSTEM.
• Monitorear la enumeración de VSS proveniente de procesos de usuario regulares. Las llamadas a NtQueryDirectoryObject dirigidas a objetos HarddiskVolumeShadowCopy desde cualquier cosa fuera de la copia de seguridad o las herramientas del sistema son una señal de alerta que casi no tiene una explicación inocente.
• Esté atento al registro raíz de sincronización de Cloud Files mediante procesos desconocidos. Vale la pena comprobar de inmediato que se llama a CfRegisterSyncRoot desde cualquier otro dispositivo que no sea OneDrive, Dropbox o Box. Esa llamada es exactamente cómo BlueHammer prepara su trampa.
• Alerta sobre procesos con pocos privilegios que crean servicios de Windows o obtienen tokens a nivel de SYSTEM. BlueHammer usa CreateService para registrar brevemente un servicio malicioso durante el escalamiento, y eso aparece en la telemetría de EDR.
• Estar atento a los cambios rápidos de contraseña consecutivos en las cuentas de administrador local. BlueHammer restablece la contraseña, la usa y luego la restablece. Los ID de eventos de seguridad 4723 y 4724 que se activan dos veces en rápida sucesión en la misma cuenta no tienen una explicación normal.
• Mantener estrictos los permisos. BlueHammer necesita una sesión local para ejecutarse, por lo que cada permiso que un usuario estándar en realidad no necesita es una superficie de ataque que se puede eliminar.
• Estar atentos a una actualización de seguridad de Microsoft o un aviso que aborde la vulnerabilidad BlueHammer.

Microsoft aún no ha emitido una declaración pública ni asignado un CVE para esta vulnerabilidad en el momento de la publicación. Hasta ahora solo ha actualizado la firma de Defender como Exploit:Win32/DfndrPEBluHmr.BB, capaz de detectar el binario original del PoC. Sin embargo, esta protección se puede eludir fácilmente simplemente recompilando el código fuente. Investigadores de Cyderes y el reconocido experto Will Dormann ya han corregido la PoC (video) para lograr una explotación más confiable.

Fuente: HackingPassion

Seguir leyendo...

Aumentan los ataques "zero-day": Microsoft fue el proveedor más afectado en 2025, seguido de Google y Apple

Un nuevo informe de ciberseguridad revela que los ataques que explotan vulnerabilidades "zero-day" aumentaron durante 2025, con un total de 90 vulnerabilidades explotadas activamente, según un análisis del equipo GoogleThreat Intelligence Group.

Esta cifra representa un incremento aproximado del 15% respecto a 2024, cuando se registraron 78 casos, aunque sigue por debajo del récord de 100 observado en 2023.

Microsoft fue el proveedor más atacado

El informe señala que Microsoft fue la empresa más afectada por exploits zero-day, con 25 vulnerabilidades explotadas en sus productos durante 2025.

Le siguieron otras grandes empresas tecnológicas:

• Google – 11 vulnerabilidades explotadas
• Apple – 8 vulnerabilidades
• Cisco – 4 vulnerabilidades
• Fortinet – 4 vulnerabilidades
• Ivanti – 3 vulnerabilidades
• VMware – 3 vulnerabilidades

Estas fallas incluyeron distintos tipos de problemas técnicos como ejecución remota de código (RCE), escalada de privilegios, inyecciones y errores de corrupción de memoria.

¿Qué es una vulnerabilidad "zero-day"?

Una vulnerabilidad zero-day es un fallo de seguridad en software que aún no ha sido descubierto o corregido por el fabricante.

Si un atacante descubre y explota esa vulnerabilidad antes de que exista un parche, se produce un ataque zero-day. Estos ataques son especialmente peligrosos porque no existe protección disponible en el momento de la explotación.

Los sistemas operativos fueron el objetivo principal

El informe indica que los sistemas operativos fueron uno de los principales objetivos de los atacantes. De los 90 casos detectados en 2025:

• 24 ataques zero-day afectaron a sistemas operativos de escritorio
• 15 ataques afectaron a plataformas móviles

Los investigadores explican que los sistemas operativos son objetivos atractivos porque permiten a los atacantes obtener control completo del dispositivo comprometido.

Disminuyen los ataques contra navegadores

En contraste, los ataques zero-day dirigidos a navegadores web disminuyeron respecto a años anteriores.

Durante 2025 se registraron solo ocho vulnerabilidades zero-day explotadas en navegadores, lo que sugiere que las mejoras de seguridad en estos productos podrían estar dificultando su explotación.

Sin embargo, los analistas advierten que otra posible explicación es que los atacantes estén ocultando mejor sus actividades o desplazando sus objetivos hacia otros componentes del ecosistema tecnológico.

Crece la amenaza de los ataques avanzados

El informe concluye que el aumento de exploits zero-day demuestra que las amenazas cibernéticas siguen evolucionando rápidamente.

Los investigadores advierten que tanto grupos criminales como actores patrocinados por estados continúan utilizando estas vulnerabilidades para infiltrarse en redes corporativas, robar datos y comprometer sistemas críticos. Por ello, recomiendan a las organizaciones aplicar parches rápidamente, reforzar la seguridad del software y adoptar prácticas de desarrollo "secure-by-design" para reducir el riesgo de explotación.

Fuente: The 420

Seguir leyendo...

Atacantes explotan Kubernetes y Cloud SQL en un sofisticado robo de criptomonedas

Un ciberataque atribuido a un presunto grupo de amenazas vinculado a Corea del Norte revela cómo los atacantes pueden pasar del dispositivo personal de un desarrollador a la infraestructura cloud de una empresa, explotando flujos de trabajo DevOps para robar millones en criptomonedas.

Un ataque que comenzó en un dispositivo personal

La intrusión comenzó cuando un desarrollador fue engañado mediante ingeniería social para descargar un archivo comprimido que supuestamente formaba parte de un proyecto open-source. El archivo se abrió primero en el dispositivo personal del desarrollador y posteriormente se transfirió al equipo corporativo mediante AirDrop.

Al interactuar con el archivo dentro de un entorno de desarrollo asistido por inteligencia artificial, se ejecutó código Python malicioso que instaló un binario disfrazado como la herramienta de línea de comandos de Kubernetes. Este programa actuó como backdoor, conectándose a un dominio controlado por los atacantes y otorgándoles acceso remoto al sistema.

Movimiento desde el equipo comprometido hacia la nube

Una vez dentro de la red corporativa, los atacantes utilizaron credenciales disponibles y sesiones autenticadas para explorar el entorno de Google Cloud de la organización. Durante la fase de reconocimiento localizaron un bastion host, que normalmente se utiliza para gestionar el acceso a sistemas protegidos.

Los atacantes modificaron la política de autenticación multifactor (MFA) del bastion host para obtener acceso y continuar explorando el entorno cloud, incluyendo los pods de Kubernetes desplegados en la infraestructura.

Explotación de workflows DevOps y Kubernetes

Tras obtener acceso más profundo, el grupo manipuló la infraestructura DevOps. Modificaron configuraciones de despliegue en Kubernetes para ejecutar automáticamente un comando bash cada vez que se creaba un nuevo pod, lo que descargaba malware adicional y garantizaba persistencia.

También alteraron recursos vinculados al sistema CI/CD, introduciendo comandos que mostraban en los logs tokens de cuentas de servicio. Con esos tokens pudieron acceder a una cuenta con privilegios elevados, escalar privilegios y moverse lateralmente por la infraestructura.

En una fase posterior, utilizaron credenciales robadas para acceder a un pod de infraestructura en modo privilegiado, escapar del contenedor e instalar otro backdoor que les permitió mantener acceso persistente al entorno.

Manipulación de bases de datos y robo de criptomonedas

El objetivo final del ataque fueron los sistemas que gestionaban datos de clientes y activos financieros. Los atacantes obtuvieron credenciales de base de datos que estaban almacenadas de forma insegura en variables de entorno dentro de un pod de Kubernetes.

Con esas credenciales accedieron a la base de datos de producción mediante Cloud SQL Auth Proxy y ejecutaron comandos SQL para modificar configuraciones de cuentas de usuario, incluidos reseteos de contraseñas y cambios en los valores de MFA.

Con el control de varias cuentas de alto valor, los atacantes consiguieron retirar criptomonedas por valor de varios millones de dólares.

Una cadena de ataque compleja

Investigadores de Google Cloud atribuyen la operación con confianza moderada al grupo norcoreano UNC4899, también conocido como Jade Sleet, PUKCHONG, Slow Pisces o TraderTraitor.

El incidente demuestra una cadena de ataque compleja que combina ingeniería social, abuso de herramientas cloud legítimas y manipulación de infraestructuras DevOps. Este tipo de operaciones, descritas como "living-off-the-cloud", utiliza funciones legítimas de la plataforma para persistir en el entorno y evadir detección.

Para reducir riesgos similares, los expertos recomiendan validación estricta de identidades, MFA resistente al phishing, monitorización de actividad en contenedores y una gestión más segura de credenciales en entornos cloud.

Fuente: The420

Seguir leyendo...

Zero-Day de Qualcomm explotado en ataques dirigidos contra Android

 La actividad de explotación contra CVE-2026-21385, un fallo de corrupción de memoria de alta gravedad, podría estar vinculada a spyware comercial o grupos de amenazas estatales.

Un nuevo error de Qualcomm ha sido explotado en ataques limitados y dirigidos contra dispositivos Android vulnerables. Google publicó su boletín de seguridad mensual de Android el 2 de marzo con, como es habitual, una serie de vulnerabilidades que afectan a los dispositivos del ecosistema. Entre los más de 100 CVE listados, destacan dos en particular.

Uno es el CVE-2026-21385, una vulnerabilidad de alta gravedad en el kernel de gráficos de Qualcomm que afecta a una amplia gama de chipsets. Aunque hay pocos detalles disponibles, se trata de un problema de desbordamiento de enteros (integer overflow) que requiere acceso local para ser explotado. En su propio boletín, Qualcomm lo describe como "corrupción de memoria al utilizar alineaciones para la asignación de memoria". El fallo, que recibió una puntuación CVSS de 7.8, fue añadido este lunes al catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de la CISA.

¿Posible ataque de spyware?

La razón por la que el CVE-2026-21385 destaca es que Google afirmó en el boletín de Android: "Existen indicios de que el CVE-2026-21385 puede estar bajo una explotación limitada y dirigida". No está claro qué significa exactamente "explotación limitada y dirigida".

Sin embargo, Adam Boynton, gerente senior de estrategia de seguridad en Jamf, señala que, aunque se debe ser cuidadoso con las especulaciones, este "es el lenguaje específico que Google utiliza cuando la actividad es demasiado estrecha para ser una infraestructura criminal, pero demasiado deliberada para ser oportunista". Es decir, posiblemente un actor estatal o un proveedor de vigilancia comercial.

"El CVE-2024-43047 —otro zero-day de Qualcomm— utilizó el mismo lenguaje cuando fue revelado, y más tarde fue vinculado a herramientas de spyware comercial a través del Laboratorio de Seguridad de Amnistía Internacional", dice Boynton. "Eso no es una confirmación de que ocurra lo mismo aquí, pero el perfil es consistente. No sabemos quién está detrás de esto, pero la forma en que Google y Qualcomm lo describen dice algo sobre lo que creen que están viendo".

La otra vulnerabilidad notable de este mes es el CVE-2026-0047, un fallo crítico de escalada de privilegios local en el componente System de Android "que podría permitir la ejecución remota de código sin necesidad de privilegios de ejecución adicionales", según el boletín. Tampoco se requiere interacción del usuario. El fallo se debe a una falta de verificación de permisos en dumpBitmapsProto de ActivityManagerService.java.

"La evaluación de gravedad se basa en el efecto que tendría la explotación de la vulnerabilidad en un dispositivo afectado, asumiendo que las mitigaciones de la plataforma y del servicio están desactivadas para fines de desarrollo o si se eluden con éxito", advirtió Google.

Boynton afirma que el hecho de que un atacante ya necesite estar en el dispositivo para utilizarlo ofrece una barrera significativa, razón por la cual probablemente aún no ha sido explotado de forma masiva. Se utilizaría como parte de un ataque en cadena en lugar de uno independiente.

"Alguien obtiene acceso inicial a través de un enlace de phishing, una aplicación maliciosa o un RCE como el CVE-2026-0006, y luego utiliza la escalada para profundizar y persistir. La pregunta no es realmente si será explotado, sino si será visible cuando ocurra. Estas técnicas encadenadas son más difíciles de atribuir y a menudo solo salen a la luz en análisis forenses tras el incidente, mucho después de que el daño ya esté hecho".

La complejidad de parchear fallos en Android

Los parches para el CVE-2026-21385 ya están disponibles, y Qualcomm afirma que se están compartiendo con los fabricantes de equipos originales (OEM) pertinentes, a quienes "se les ha notificado y recomendado encarecidamente que desplieguen dichos parches en los dispositivos comercializados lo antes posible". Los parches para el CVE-2026-0047 también están disponibles a través del Android Open Source Project (AOSP).

Un problema a considerar es que los fallos de Android, especialmente los de Qualcomm, dependen de los OEM a nivel de usuario final. Como señala Boynton, esto significa que los consumidores dependen de que los fabricantes (que no son necesariamente Google o Qualcomm) reparen un dispositivo afectado con un parche, incluso si este fue lanzado en el momento de la divulgación. Ese retraso es crítico cuando las vulnerabilidades se explotan más rápido que nunca.

Como resultado, Qualcomm instó en su boletín a los clientes a "ponerse en contacto con el fabricante del dispositivo para obtener información sobre el estado de los parches de los dispositivos comercializados".

Fuente: DarkReading

Seguir leyendo...

Actores de amenazas utilizan la lógica de redirección de OAuth para distribuir malware

Investigadores de Microsoft han revelado una campaña de phishing activa que está abusando del mecanismo de redirección de autenticación OAuth. El objetivo es evadir las defensas convencionales del correo electrónico y del navegador.

Los atacantes se dirigen a organizaciones gubernamentales y del sector público, redirigiendo a usuarios desprevenidos desde páginas de inicio de sesión legítimas hacia su propia infraestructura para distribuir malware o capturar credenciales de acceso.

El ataque desde la perspectiva de la víctima

El mecanismo de redirección de autenticación OAuth es una función de inicio de sesión confiable utilizada por Microsoft, Google y otros proveedores. Permite a los usuarios iniciar sesión a través de un proveedor de identidad central y luego ser redirigidos automáticamente de vuelta a una aplicación aprobada.

Sin embargo, en esta campaña, los atacantes manipularon ese flujo de redirección para que las víctimas fueran enviadas desde una página de autenticación legítima hacia sitios maliciosos que alojan kits de phishing o malware.

El ataque comienza con un correo electrónico de apariencia legítima que contiene un enlace que parece apuntar a una página de inicio de sesión auténtica de Microsoft o Google, o bien un archivo PDF adjunto que incluye dicho enlace.

Tras hacer clic, la víctima aterriza brevemente en una página de inicio de sesión de OAuth genuina alojada en un dominio confiable. La URL parece auténtica y el diseño de la página coincide con lo que el usuario ve a diario. No obstante, en cuestión de instantes, el navegador redirige de nuevo al usuario a un sitio controlado por el atacante.

Dependiendo de la variante de la campaña, la víctima puede ver una página de inicio de sesión falsa pero convincente, diseñada para capturar credenciales o tokens de sesión, o una página que descarga automáticamente un archivo ZIP o un archivo de acceso directo (.lnk) disfrazado como el documento, grabación o informe prometido.

Abuso de OAuth

En esta campaña, los atacantes explotan debilidades en la lógica de redirección de OAuth mediante la creación de solicitudes de autorización con parámetros deliberadamente inválidos (por ejemplo, un scope imposible o una solicitud de "autenticación silenciosa" que no puede completarse con éxito).

Cuando el proveedor de identidad (por ejemplo, Microsoft Entra ID) intenta procesar dicha solicitud, se activa una redirección estándar de manejo de errores hacia una URI de redirección "registrada" que los atacantes controlan.

"Por diseño, los flujos de OAuth pueden redirigir a los usuarios tras ciertas condiciones de error. Los atacantes explotan este comportamiento para sondear silenciosamente los puntos de enlace (endpoints) de autorización e inferir la presencia de sesiones activas o la aplicación de medidas de autenticación", explicaron los investigadores. "Aunque todavía se requiere la interacción del usuario para hacer clic en el enlace, la ruta de redirección aprovecha los dominios de confianza del proveedor de identidad para hacer avanzar el ataque".

Los atacantes persisten a pesar del cierre de aplicaciones

El abuso de una redirección de autenticación confiable hace que el ataque se camufle con la actividad empresarial legítima, reduciendo la probabilidad de que la víctima se dé cuenta de que ha ocurrido algo malicioso.

Además, los cebos de correo electrónico utilizados por los atacantes no son inusuales: invitaciones para ver un documento, una grabación de una reunión de Teams, una invitación para ver un informe de empleados, una solicitud de validación de contraseña de Microsoft 365, una solicitud de firma electrónica o una invitación de calendario. Según Microsoft, también se han utilizado temas relacionados con la seguridad social, finanzas y política.

Los investigadores no precisaron qué tan extendidas están estas campañas, pero confirmaron que, a pesar de que Microsoft Entra ha desactivado las aplicaciones OAuth observadas, creadas y utilizadas por los atacantes, "la actividad de OAuth relacionada persiste y requiere una monitorización continua".

"Para reducir el riesgo, las organizaciones deben gestionar estrechamente las aplicaciones OAuth limitando el consentimiento del usuario, revisando regularmente los permisos de las aplicaciones y eliminando aquellas que no se utilicen o tengan privilegios excesivos. Combinadas con la protección de identidad, las políticas de Acceso Condicional y la detección multidominio en el correo electrónico, la identidad y los endpoints, estas medidas ayudan a evitar que los flujos de autenticación confiables sean mal utilizados para el phishing o la distribución de malware", concluyeron los investigadores de Microsoft.

Fuente: HelpNetSecurity

Seguir leyendo...

Parches de emergencia de Windows Server corrigen un error de WSUS con un exploit PoC

Microsoft ha lanzado actualizaciones de seguridad fuera de banda (OOB) para corregir una vulnerabilidad crítica del Servicio de Actualización de Windows Server (WSUS) con un código de explotación de prueba de concepto disponible públicamente.

WSUS es un producto de Microsoft que permite a los administradores de TI gestionar y distribuir actualizaciones de Windows a los equipos de su red.

Identificada como CVE-2025-59287 y corregida durante el martes de parches de este mes, esta falla de seguridad de ejecución remota de código (RCE) afecta únicamente a servidores Windows con el Rol de Servidor WSUS habilitado, una función que no está habilitada por defecto.

La vulnerabilidad puede explotarse remotamente en ataques de baja complejidad que no requieren la interacción del usuario, lo que permite a los atacantes sin privilegios atacar sistemas vulnerables y ejecutar código malicioso con privilegios de SYSTEM. Esto la hace potencialmente susceptible de propagación entre servidores WSUS.

Los servidores Windows que no tienen habilitado el rol de servidor WSUS no son vulnerables a esta vulnerabilidad. Si el rol de servidor WSUS está habilitado, el servidor se volverá vulnerable si no se instala la corrección antes de habilitarlo, explicó Microsoft.

Un atacante remoto no autenticado podría enviar un evento manipulado que active la deserialización de objetos no seguros en un mecanismo de serialización heredado, lo que resultaría en la ejecución remota de código.

Un exploit de prueba de concepto CVE-2025-59287 ya está disponible en línea, lo que hace aún más crucial la aplicación inmediata de parches a los servidores vulnerables.

Microsoft también compartió soluciones alternativas para los administradores que no puedan instalar estos parches de emergencia de inmediato, como deshabilitar el rol de servidor de WSUS para eliminar el vector de ataque o bloquear todo el tráfico entrante a los puertos 8530 y 8531 del firewall del host para que WSUS deje de funcionar. Sin embargo, es importante tener en cuenta que los endpoints de Windows dejarán de recibir actualizaciones del servidor local después de deshabilitar WSUS o bloquear el tráfico.

"Esta es una actualización acumulativa, por lo que no es necesario aplicar ninguna actualización anterior antes de instalar esta, ya que reemplaza todas las actualizaciones anteriores para las versiones afectadas", añadió Microsoft. "Si aún no ha instalado la actualización de seguridad de Windows de octubre de 2025, le recomendamos que aplique esta actualización OOB. Después de instalar la actualización, deberá reiniciar el sistema".

En un documento de soporte independiente, Microsoft afirmó que WSUS ya no mostrará detalles de errores de sincronización después de instalar estas o posteriores actualizaciones porque esta funcionalidad se eliminó temporalmente para abordar la vulnerabilidad RCE CVE-2025-59287.

La empresa holandesa de ciberseguridad Eye Security detectó intentos de explotación basados en la PoC y que involucran una carga útil .NET codificada en Base64 diseñada para evadir el registro mediante la ejecución de comandos a través de un encabezado de solicitud personalizado llamado 'aaaa'.

Fuente: BC

Seguir leyendo...

Vulnerabilidad de SMB en Windows explotada activamente (CVE-2025-33073 con PoC)

La Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) emitió una alerta urgente el 20 de octubre de 2025, destacando una vulnerabilidad grave CVE-2025-33073 en el cliente SMB de Windows de Microsoft.

Conocida como una falla de control de acceso indebido, esta vulnerabilidad, rastreada bajo la CVE, cuyos detalles aún no se han especificado por completo, representa un riesgo significativo de escalamiento de privilegios para atacantes de todo el mundo.

Aunque Microsoft se refiere a CVE-2025-33073 como una elevación de privilegios, en realidad se trata de una ejecución remota autenticada de un comando como SYSTEM en cualquier equipo que no implemente la firma SMB.

La vulnerabilidad explota el protocolo SMB, un componente fundamental del intercambio de archivos y las comunicaciones de red de Windows. Según el catálogo KEV de la CISA, los actores maliciosos pueden crear un script que engaña al equipo de la víctima para que inicie una conexión SMB con el sistema del atacante.

La vulnerabilidad ya tiene varias PoC disponible (y un lab) y se está utilizando activamente.

Esta autenticación forzada otorga acceso no autorizado, lo que potencialmente permite el control total sobre el dispositivo comprometido. Vinculada a CWE-284 (Control de Acceso Inadecuado), esta falla pone de relieve las antiguas preocupaciones sobre los mecanismos de autenticación de SMB, que han sido un objetivo predilecto de los ciberdelincuentes desde el brote de WannaCry en 2017.

Vulnerabilidad de SMB en Windows explotada activamente

Los atacantes aprovechan esta vulnerabilidad mediante ingeniería social o descargas no autorizadas, donde los usuarios ejecutan accidentalmente la carga maliciosa. Una vez activada, el cliente SMB se autentica en el servidor del atacante, evadiendo las medidas de seguridad habituales y permitiendo el movimiento lateral dentro de las redes. La empresa Synacktiv ha realizado un detalle técnico sobre la explotación de la vulnerabilidad.

Si bien CISA señala que se desconoce si esta falla específica impulsa campañas de ransomware, la técnica refleja las tácticas utilizadas por grupos como LockBit y Conti, que explotaban rutinariamente los protocolos de Windows para el acceso inicial.

La alerta llega en un momento de tensión para los administradores de TI, tras una oleada de exploits relacionados con SMB en 2025, incluyendo aquellos dirigidos a entornos de Azure sin parches.

Los expertos advierten que los sistemas sin medidas de mitigación podrían sufrir exfiltración de datos o la implementación de malware, especialmente en sectores como el financiero y el sanitario.

Mitigaciones

CISA insta a actuar de inmediato: aplicar los parches más recientes de Microsoft, tal como se describe en sus avisos de seguridad, o seguir la Directiva Operacional Vinculante (BOD) 22-01 para servicios en la nube.

Si las mitigaciones no son viables, se debe suspender el uso de los productos afectados. Herramientas como Windows Defender y la detección de endpoints de terceros pueden ayudar a monitorizar las anomalías del tráfico de las PYMES.

Deshabilitar las funciones innecesarias de SMBv1 y aplicar el acceso con privilegios mínimos siguen siendo las mejores prácticas.

Por último, se debe destacar que CVE-2025-33073 es un buen ejemplo de por qué habilitar mitigaciones de defensa en profundidad, como la firma SMB, puede resultar extremadamente eficiente, incluso contra ataques de día cero.

Fuente: CyberSecurityNews

Seguir leyendo...

Oracle corrige vulnerabilidad Zero-Day de EBS explotada en ataques de robo de datos

Oracle advierte sobre una vulnerabilidad Zero-Day crítica en E-Business Suite (CVSS 9,8), identificada como CVE-2025-61882, que permite a los atacantes ejecutar código remoto sin autenticación. Esta falla se explota activamente en ataques de robo de datos Clop.

La falla se encuentra en el producto Oracle Concurrent Processing de Oracle E-Business Suite (componente: BI Publisher Integration) y se da debido a su falta de autenticación y facilidad de explotación.

"Esta vulnerabilidad se puede explotar de forma remota sin autenticación; es decir, puede explotarse a través de una red sin necesidad de nombre de usuario ni contraseña. Si se explota con éxito, puede provocar la ejecución remota de código", explica la empresa.

Oracle ha confirmado que la vulnerabilidad afecta a Oracle E-Business Suite, versiones 12.2.3-12.2.14, y ha publicado una actualización de emergencia para solucionar el fallo. La compañía señala que los clientes deben instalar primero la actualización de parches críticos de octubre de 2023 antes de poder instalar las nuevas actualizaciones de seguridad.

Dado que existe un exploit PoC público y que el fallo se está explotando activamente, es crucial que los administradores de Oracle instalen la actualización de seguridad lo antes posible.

Vulnerabilidad explotada en ataques de robo de datos Clop

Si bien Oracle no ha declarado explícitamente que se trata de una vulnerabilidad de día cero, sí compartió indicadores de compromiso que corresponden a un exploit de Oracle EBS compartido recientemente por actores de amenazas en Telegram.

Charles Carmakal, director de tecnología de Mandiant - Google Cloud, también confirmó que esta fue la falla explotada por el grupo de ransomware Clop en los ataques de robo de datos ocurridos en agosto de 2025. "Clop explotó múltiples vulnerabilidades en Oracle EBS, lo que les permitió robar grandes cantidades de datos de varias víctimas en agosto de 2025", declaró Carmakal a BleepingComputer. "Se explotaron múltiples vulnerabilidades, incluyendo vulnerabilidades corregidas en la actualización de Oracle de julio de 2025, así como una corregida este fin de semana (CVE-2025-61882)", continuó Carmakal.

CVE-2025-61882 es una vulnerabilidad crítica que permite la ejecución remota de código no autenticado.

La noticia de la última campaña de extorsión de Clop se conoció por primera vez la semana pasada, cuando Mandiant y Google Threat Intelligence Group (GTIG) informaron que estaban rastreando una nueva campaña en la que varias empresas recibieron correos electrónicos que afirmaban ser de los actores de la amenaza.

Estos correos electrónicos afirmaban que Clop había robado datos de los sistemas Oracle E-Business Suite de la empresa y exigía un rescate para no filtrarlos. "Recientemente hemos vulnerado su aplicación Oracle E-Business Suite y copiado numerosos documentos. Todos los archivos privados y demás información se encuentran ahora en nuestros sistemas".

La banda de extorsión Clop tiene un largo historial de explotación de vulnerabilidades de día cero en ataques masivos de robo de datos. Sin embargo, Oracle vinculó inicialmente la campaña de extorsión de Clop con vulnerabilidades parcheadas en julio de 2025, en lugar de con el nuevo día cero que ahora sabemos que se utilizó en los ataques.

Oracle ha compartido indicadores de compromiso para la explotación de día cero, que incluyen dos direcciones IP detectadas explotando servidores, un comando para abrir un shell remoto y el archivo del exploit y los archivos asociados.

Exploit filtrado por cazadores de Lapsus$ de Scattered

Si bien Clop está detrás de los ataques de robo de datos y la explotación del día cero de Oracle, la noticia del día cero provino inicialmente de otro grupo de actores de amenazas que últimamente han generado titulares con sus ataques generalizados de robo de datos a clientes de Salesforce.

El viernes, estos actores, autodenominados "Scattered Lapsus$ Hunters", afirmando estar compuestos por actores de amenazas de Scattered Spider, Lapsus$ y ShinyHunters, filtraron dos archivos en Telegram que, según afirman, estaban relacionados con los ataques de Clop.

Un archivo llamado "GIFT_FROM_CL0P.7z" contiene código fuente de Oracle que, según los nombres de archivo, parece estar relacionado con "support.oracle.com".

Sin embargo, los actores de amenazas también publicaron un archivo comprimido "ORACLE_EBS_NDAY_EXPLOIT_POC_SCATTERED_LAPSUS_RETARD_CL0P_HUNTERS.zip", cuyo nombre insinuaron que era el exploit de Oracle E-Business utilizado por Clop.

BleepingComputer ha confirmado que se trata del mismo archivo que figura en los indicadores de vulnerabilidad de Oracle.

Este archivo contiene un archivo de instrucciones readme.md y dos scripts de Python llamados exp.py y server.py. Estos scripts de Python se utilizan para explotar una instancia vulnerable de Oracle E-Business Suite y ejecutar un comando arbitrario o abrir una shell inversa a los servidores del actor de amenazas. Como los IOC compartidos por Oracle incluyen el nombre del archivo del exploit compartido por Scattered Lapsus$ Hunters, se confirma que este es el exploit utilizado por el grupo de ransomware Clop.

Sin embargo, esto plantea interrogantes sobre cómo los actores de la amenaza Scattered Lapsus$ Hunters accedieron al exploit y si colaboran de alguna manera con Clop.

Fuente: BC

Seguir leyendo...

Explotan activamente la herramienta WerFaultSecure.exe en Windows 11 24H2

Los actores de amenazas están aprovechando la utilidad de informe de errores de Windows, WerFaultSecure.exe, para extraer la región de memoria del Servicio LSASS.EXE y recopilar las credenciales almacenadas en caché de sistemas Windows 11 24H2 con todas las actualizaciones.

Tras obtener acceso inicial a un host, los atacantes suelen intentar volcar la memoria de LSASS para escalar privilegios y moverse lateralmente por la red. Las versiones modernas de Windows restringen severamente el acceso directo a la memoria de LSASS mediante la implementación de Protected Process Light (PPL), que requiere privilegios de kernel o un proceso PPL del mismo nivel para la interacción.

Los investigadores de Zero Salarium han demostrado cómo eludir estas defensas ejecutando un binario vulnerable de WerFaultSecure.exe compilado para Windows 8.1 en Windows 11, obteniendo así un volcado de memoria sin cifrar de LSASS. WER ya habia sido utilizado por Zero Salarium para "congelar" la ejecución del EDR de Microsoft.

Aprovechamiento del privilegio PPL de WerFaultSecure.exe

WerFaultSecure.exe forma parte del marco de Informe de Errores de Windows (WER) y normalmente se ejecuta con la etiqueta PPL más alta, WinTCB, para recopilar volcados de memoria de los procesos protegidos. Su estado protegido le permite acceder a la memoria LSASS bajo la apariencia de un controlador de fallos.

En Windows 8.1, existía una falla que permitía que WerFaultSecure.exe escribiera volcados de memoria sin aplicar sus rutinas de cifrado integradas, lo que resultaba en archivos de volcado sin cifrar en el disco.

Al copiar el archivo vulnerable WerFaultSecure.exe desde Windows 8.1 a un equipo con Windows 11 24H2 e iniciarlo con elevación PPL, los atacantes pueden engañar a la herramienta para que capture la memoria LSASS y escriba un volcado de memoria sin procesar.

Zero Salarium informa que la secuencia de explotación implica ejecutar WerFaultSecure.exe con parámetros no documentados descubiertos mediante ingeniería inversa: /h para invocar el modo de bloqueo oculto seguro, /pid [pid] para dirigirse al proceso LSASS, /tid [tid] para especificar su hilo principal y /file [handle] para designar un identificador de salida sin cifrar.

El atacante utiliza un cargador personalizado llamado WSASS para generar WerFaultSecure.exe mediante la API CreateProcessAsPPL, heredando los identificadores del volcado de memoria y los objetos de evento.

El cargador se llama "WSASS" y puede descargarlo en el siguiente enlace: https://github.com/TwoSevenOneT/WSASS

WSASS espera a que se complete el volcado y luego reemplaza los primeros cuatro bytes del archivo generado (del encabezado mágico PNG) con la firma MDMP (0x4D,0x44,0x4D,0x50) para que se haga pasar por un dispositivo de imagen benigno y evada los controles antivirus.

Finalmente, el cargador reanuda cualquier subproceso suspendido en LSASS otorgando permisos mínimos PROCESS_SUSPEND_RESUME para restaurar la estabilidad del sistema.

Una vez que el atacante restaura el encabezado MDMP, el minivolcado resultante puede cargarse en herramientas estándar, como pypykatz o Mimikatz, para extraer hashes NTLM y credenciales de texto plano, lo que facilita un mayor movimiento lateral.

Esta técnica subraya la importancia de supervisar los binarios de WerFaultSecure.exe fuera del directorio System32 y validar las invocaciones de procesos protegidos por PPL para detectar comportamientos anómalos de forma temprana.

Este exploit demuestra cómo se puede aprovechar la retrocompatibilidad de Windows contra las defensas modernas, lo que resalta la necesidad de que los defensores supervisen tanto la ubicación de los archivos como los contextos de invocación de las herramientas de informe de errores.

Fuente: CyberSecurityNews

Seguir leyendo...

PoC para explotar una (nueva) vulnerabilidad en FortiWeb (CVE-2025-52970)

Un investigador de seguridad ha publicado una prueba de concepto parcial para explotar una vulnerabilidad en el firewall de aplicaciones web FortiWeb que permite a un atacante remoto eludir la autenticación.

El investigador de seguridad Aviv Y denominó la vulnerabilidad FortMajeure y la describe como un "fallo silencioso inesperado". Técnicamente, se trata de una lectura fuera de los límites en el análisis de cookies de FortiWeb que permite a un atacante establecer el parámetro "Era" con un valor inesperado. Esto hace que el servidor utilice una clave secreta de ceros para el cifrado de sesión y la firma HMAC, lo que facilita la creación de cookies de autenticación falsificadas.

La falla se reportó responsablemente a Fortinet y ahora se conoce como CVE-2025-52970. Fortinet publicó una corrección el 12 de agosto.

La explotación elude completamente la autenticación, lo que permite al atacante suplantar la identidad de cualquier usuario activo, incluido un administrador.

Para explotar CVE-2025-52970 con éxito, el usuario objetivo debe tener una sesión activa durante el ataque y el atacante debe forzar un pequeño campo numérico en la cookie. El requisito de la fuerza bruta proviene de un campo en la cookie firmada que se valida mediante la función refresh_total_logins() (en libncfg.so).

Este campo es un número desconocido que el atacante debe adivinar, pero el investigador observa que el rango no suele ser superior a 30, lo que lo convierte en un espacio de búsqueda pequeño de aproximadamente 30 solicitudes.

Dado que el exploit utiliza la clave de ceros (debido al error de "Era"), cada intento se puede probar instantáneamente comprobando si se acepta la cookie falsificada.

El problema afecta a FortiWeb 7.0 a 7.6 y se solucionó en las siguientes versiones:

• FortiWeb 7.6.4+
• FortiWeb 7.4.8+
• FortiWeb 7.2.11+
• FortiWeb 7.0.11+

Fortinet afirma en el boletín que las versiones de FortiWeb 8.0 no se ven afectadas por este problema, por lo que no es necesario tomar ninguna medida.

La puntuación de severidad de 7.7 en el CVSS de Fortinet puede ser engañosa, ya que se deriva de la "alta complejidad del ataque" debido al requisito de fuerza bruta. Sin embargo, en la práctica, la parte de fuerza bruta es simple y rápida de ejecutar.

El investigador compartió el resultado de una prueba de concepto (PoC) que muestra la suplantación de administrador en un endpoint REST. Sin embargo, ocultó el exploit completo, que también cubre la conexión a la CLI de FortiWeb a través de /ws/cli/open.

Sin embargo, Aviv Y prometió publicar los detalles completos del exploit más adelante, ya que el aviso del proveedor se publicó recientemente. El investigador tomó esta decisión para que los administradores de sistemas tuvieran más tiempo para aplicar la solución.

Los detalles publicados demuestran la raíz del problema, pero no son suficientes ni siquiera para que atacantes expertos infieran el resto y desarrollen una cadena de vulnerabilidades completa, según declaró el investigador. Explicó que los atacantes tendrían que aplicar ingeniería inversa al formato de los campos de la sesión, lo cual resulta poco práctico dado que Fortinet tiene sus propias estructuras de datos.

A pesar de ello, se deben tomar medidas inmediatas para mitigar el problema, ya que los atacantes siguen de cerca estos anuncios y se preparan para actuar cuando se publiquen las PoC completas.

El boletín de seguridad no incluye soluciones alternativas ni consejos de mitigación, por lo que actualizar a una versión segura es la única medida eficaz recomendada.

Fuente: BC

Seguir leyendo...

Explotación masiva de Zero-Day Microsoft SharePoint Server (on-premise) - Actualizado

Una vulnerabilidad crítica de seguridad en Microsoft SharePoint Server (on-premise) se ha convertido en un arma como parte de una campaña de explotación activa a gran escala. CISA ya se ha hecho eco de la noticia y la explotación.

La falla Zero-Day, identificada como CVE-2025-53770 (CVSS: 9,8), se ha descrito como una variante de CVE-2025-49706 (CVSS: 6,3), un error de suplantación de identidad en Microsoft SharePoint Server que se abordó en las actualizaciones de julio de 2025.

• Tipo de vulnerabilidad: Deserialización de datos no confiables.
• Impacto: Permite a un atacante no autenticado ejecutar código de forma remota a través de la red (Remote Code Execution - RCE). Esto significa que un atacante puede tomar control total del servidor SharePoint, acceder a información confidencial, modificar datos, y potencialmente moverse lateralmente por la red.
• Severidad: Tiene una puntuación CVSS de 9.8 (Crítica), lo que indica una vulnerabilidad severa y fácilmente explotable.
• Explotación en la naturaleza: Microsoft ha confirmado que ya existen exploits para esta vulnerabilidad y que está siendo explotada activamente en ataques.

"La deserialización de datos no confiables en Microsoft SharePoint Server local permite a un atacante no autorizado ejecutar código a través de una red", declaró Microsoft con respecto al nuevo Zero.Day. En una alerta independiente emitida ayer sábado, Redmond afirmó tener conocimiento de ataques activos dirigidos a clientes locales de SharePoint Server, pero enfatizó que SharePoint Online en Microsoft 365 no se ve afectado.

La divulgación se produce después de que Eye Security y Palo Alto Networks Unit 42 advirtieran sobre ataques que encadenan CVE-2025-49706 y CVE-2025-49704 (CVSS: 8,8), una falla de inyección de código en SharePoint, para facilitar la ejecución de comandos arbitrarios en instancias susceptibles. La cadena de exploits se conoce como ToolShell (by Khoa Dinh @_l0gg)

Sin embargo, dado que CVE-2025-53770 es una variante de CVE-2025-49706, se sospecha que estos ataques están relacionados.

Las dos vulnerabilidades CVE previamente parcheadas (49704/49706) se divulgaron inicialmente en Pwn2Own Berlín. Posteriormente, se descubrió que estas dos fallas podían combinarse para generar la cadena completa de ataque RCE "ToolShell". Este nombre hace referencia al abuso inicial de /ToolPane.aspx (CVE-2025-49704) de SharePoint, una página del sistema utilizada para la configuración y administración de sitios web.

Esta cadena de vulnerabilidades permite la ejecución remota de código sin autenticación mediante el envío de una solicitud POST manipulada al URI /layouts/15/ToolPane.aspx?DisplayMode=Edit, aprovechando una falla lógica en la validación del encabezado Referer. Esta omisión permite a los atacantes acceder a la funcionalidad ToolPane de SharePoint sin autenticación, lo que finalmente provoca la ejecución de código a través de componentes web cargados o en memoria.

La actividad maliciosa consiste básicamente en la entrega de cargas útiles ASPX a través de PowerShell, que luego se utilizan para robar la configuración de MachineKey del servidor SharePoint, incluyendo ValidationKey y DecryptionKey, para mantener el acceso persistente.

La empresa holandesa de ciberseguridad afirmó que estas claves son cruciales para generar cargas útiles __VIEWSTATE válidas, y que obtener acceso a ellas convierte cualquier solicitud autenticada de SharePoint en una oportunidad de ejecución remota de código.

Ahora, con la cadena ToolShell (CVE-2025-49706 + CVE-2025-49704), los atacantes parecen extraer la clave de validación (ValidationKey) directamente de la memoria o la configuración. Una vez filtrado este material criptográfico, el atacante puede crear cargas útiles __VIEWSTATE totalmente válidas y firmadas. Con ysoserial, el atacante puede generar sus propios tokens válidos de SharePoint para RCE.

"Seguimos identificando oleadas masivas de exploits", declaró Piet Kerkhofs, director de tecnología de Eye Security. "Esto tendrá un gran impacto, ya que los adversarios se mueven lateralmente utilizando esta ejecución remota de código con gran rapidez".

"Notificamos a casi 75 organizaciones que sufrieron una vulneración, tras identificar el shell web malicioso en sus servidores de SharePoint. En este grupo se encuentran grandes empresas y organismos gubernamentales de todo el mundo".

Ante la falta de una actualización oficial, Microsoft insta a los clientes a configurar la integración de la Interfaz de Análisis Antimalware (AMSI) en SharePoint e implementar Defender AV en todos los servidores de SharePoint. Cabe destacar que la integración de AMSI está habilitada de forma predeterminada en la actualización de seguridad de septiembre de 2023 para SharePoint Server 2016/2019 y en la actualización de características de la versión 23H2 para SharePoint Server Subscription Edition.

Para quienes no puedan habilitar AMSI, se recomienda desconectar SharePoint Server de Internet hasta que haya una actualización de seguridad disponible. Para mayor protección, se recomienda implementar Defender for Endpoint para detectar y bloquear la actividad posterior al exploit.

Microsoft Defender para Endpoint proporciona a los clientes alertas que pueden indicar actividad de amenazas asociada con esta amenaza. Sin embargo, estas alertas pueden activarse por actividades de amenazas no relacionadas. Los siguientes títulos de alerta en el portal del Centro de Seguridad de Microsoft Defender pueden indicar actividad de amenazas en su red:

• Posible instalación de un shell web
• Posible explotación de vulnerabilidades del servidor de SharePoint
• Comportamiento sospechoso del proceso de trabajo de IIS
• El malware "SuspSignoutReq" se bloqueó en un servidor de SharePoint
• El malware "HijackSharePointServer" se bloqueó en un servidor de SharePoint

Según ShadowServer hay aproximadamente 9.300 IP de Sharepoint expuestos y, aunque ya hay un script para buscar servidores vulnerables, Microsoft aún no ha actualizado sus avisos para CVE-2025-49706 y CVE-2025-49704 para reflejar la explotación activa.

Recomendaciones de mitigación

Además de aplicar el próximo parche oficial de Microsoft en cuanto se publique, las organizaciones deberían implementar varias mitigaciones específicas de inmediato:

• Microsoft recomienda proteger el entorno local de SharePoint Server mediante la integración de AMSI en SharePoint e implementar Defender AV en todos los servidores de SharePoint. Esto impide que atacantes no autenticados aprovechen esta vulnerabilidad.
• Restringir el acceso de red a los servidores de SharePoint mediante la aplicación de reglas de firewall estrictas y limitando la exposición únicamente a direcciones IP o conexiones VPN de confianza.
• Habilitar y aplicar una validación y monitorización de entrada estrictas en los endpoints de SharePoint para detectar intentos de deserialización anómalos.
• Utilizar firewalls de capa de aplicación o firewalls de aplicaciones web (WAF) con reglas personalizadas para bloquear cargas serializadas sospechosas.
• Realizar auditorías exhaustivas de los permisos de SharePoint y eliminar privilegios administrativos innecesarios para limitar posibles daños.
• Implementar la segmentación de red para aislar los servidores de SharePoint de la infraestructura crítica y los almacenes de datos sensibles.
• Aumentar el registro y la monitorización en tiempo real para detectar patrones de actividad inusuales que indiquen intentos de explotación. Monitorear los registros de acceso para detectar actividades sospechosas, incluyendo la creación del archivo spinstall0.aspx, que indica una explotación exitosa.
• Informar a los equipos de TI y seguridad sobre los indicadores de vulnerabilidad relacionados con los ataques de deserialización.

Estas acciones específicas, combinadas con la rápida implementación de parches, reducirán significativamente el riesgo que representa esta vulnerabilidad.

Actualización 21/07

Microsoft lanzó el domingo y también reveló detalles de otra vulnerabilidad que, según dijo, ha sido abordada con "protecciones más robustas". Microsoft ha aclarado que CVE-2025-53770 añade más protecciones para CVE-2025-49704, y no para CVE-2025-49706 como se indicó anteriormente.

También ha revelado una nueva falla CVE-2025-53771 que, según afirma, incluye más protecciones que CVE-2025-49706. Esto indica que hay dos Zero-Days, ambos son omisiones para las correcciones originales de Microsoft a principios de este mes.

Los administradores de Microsoft SharePoint deben instalar las siguientes actualizaciones de seguridad inmediatamente, según la versión:

• La actualización KB5002754 para Microsoft SharePoint Server 2019 Core y la KB5002753 para el paquete de idioma de Microsoft SharePoint Server 2019.
• La actualización KB5002760 para Microsoft SharePoint Enterprise Server 2016 y la KB5002759 para el paquete de idioma de Microsoft SharePoint Enterprise Server 2016.
• La actualización KB5002768 para Microsoft SharePoint Subscription Edition.

Después de instalar las actualizaciones, Microsoft recomienda a los administradores rotar las claves de los equipos de SharePoint siguiendo estos pasos.

Actualización 24/07

Investigadores ya han desarrollado un nuevo módulo de Metasploit dirigido a las vulnerabilidades críticas en Microsoft SharePoint Server.

CISA agregó la falla de ejecución remota de código CVE-2025-53770, parte de la misma cadena de explotación ToolShell, a su catálogo de vulnerabilidades explotadas en la naturaleza.

Actualización 27/07

A partir del 18 de julio de 2025, Microsoft ha observado que el grupo chino Storm-2603 implementa el ransomware Warlock aprovechando estas vulnerabilidades. Tras vulnerar las redes de las víctimas, los operadores de Storm-2603 utilizan la herramienta de hacking Mimikatz para extraer credenciales de texto sin formato de la memoria LSASS.

Luego, se mueven lateralmente con PsExec y el kit de herramientas Impacket, ejecutando comandos a través de WMI y modificando los Objetos de Directiva de Grupo (GPO) para distribuir el ransomware Warlock en los sistemas comprometidos.

Los investigadores de Microsoft Threat Intelligence también vincularon el martes a los grupos respaldados por el estado chino Linen Typhoon y Violet Typhoon con estos ataques, días después de que la firma de ciberseguridad holandesa Eye Security detectara por primera vez ataques Zero-Day que explotaban las vulnerabilidades CVE-2025-49706 y CVE-2025-49704.

Fuente: THN | Eye Security

Seguir leyendo...