ToolShell: la historia de cinco vulnerabilidades en Microsoft SharePoint

El 19 y 20 de julio de 2025, varias empresas de seguridad y los CERT de algunos países publicaron alertas sobre la explotación activa de servidores SharePoint que habían sido instalados en las empresas de los clientes. Según los informes, los ataques observados no requerían autenticación, permitían a los atacantes obtener control total sobre los servidores infectados y se realizaban utilizando una cadena de exploits de dos vulnerabilidades: CVE-2025-49704 y CVE-2025-49706, conocidas bajo el nombre de “ToolShell”. Además, en las mismas fechas, Microsoft lanzó parches de seguridad fuera de banda para las vulnerabilidades CVE-2025-53770 y CVE-2025-53771, destinados a abordar los problemas de seguridad que las correcciones ya emitidas por CVE-2025-49704 y CVE-2025-49706 habían pasado por alto. El lanzamiento de las nuevas actualizaciones, las “correctas”, causó confusión sobre exactamente qué vulnerabilidades estaban explotando los atacantes y si estaban utilizando exploits de día cero.

Los productos de Kaspersky detectaron y bloquearon de forma proactiva la actividad maliciosa vinculada a estos ataques, lo que nos permitió recopilar estadísticas sobre el marco temporal y la propagación de esta campaña. Nuestras estadísticas muestran que la explotación generalizada comenzó el 18 de julio de 2025 y los atacantes apuntaron a servidores en varios países del mundo, incluyendo Egipto, Jordania, Rusia, Vietnam y Zambia. Entidades de múltiples sectores se vieron afectadas: gobierno, finanzas, manufactura, silvicultura y agricultura.

Mientras analizábamos todos los elementos relacionados con estos ataques, que fueron detectados por nuestros productos, y gracias a información pública proporcionada por investigadores externos, encontramos una captura de una solicitud POST que, según se afirmaba, contenía la carga maliciosa utilizada en estos ataques. Después de realizar nuestro propio análisis, pudimos confirmar que esta captura contenía la carga maliciosa detectada por nuestras tecnologías, y que enviar esta única solicitud a una instalación de SharePoint afectada era suficiente para que allí se ejecutara la carga maliciosa.

Nuestro análisis del exploit mostró que dependía mucho de vulnerabilidades que ya se habían corregido bajo CVE-2025-49704 y CVE-2025-49706 pero, al cambiar solo un byte en la solicitud, se podían eludir esas correcciones.

En esta publicación, proporcionamos información detallada sobre CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771 y una vulnerabilidad relacionada. Dado que el exploit ya está publicado en línea, es muy fácil de usar y representa un riesgo notable, aconsejamos a todas las organizaciones instalar las actualizaciones lo más pronto posible.

El exploit

Nuestra investigación comenzó con el análisis de la captura de una solicitud POST asociada con esta ola de ataques contra servidores SharePoint.

Fragmento de la solicitud POST del exploit

Podemos ver que esta solicitud POST está dirigida al endpoint “/_layouts/15/ToolPane.aspx” e incorpora dos parámetros: “MSOtlPn_Uri” y “MSOtlPn_DWP”. Al observar el código de ToolPane.aspx, se nota que el archivo en sí no contiene mucha funcionalidad y la mayor parte de su código se encuentra en la clase ToolPane del espacio de nombres Microsoft.SharePoint.WebPartPages en Microsoft.SharePoint.dll. Al analizar esta clase, descubrimos el código que maneja los dos parámetros presentes en el exploit. Sin embargo, en condiciones normales, no se puede acceder a este endpoint sin primero eludir la autenticación en el servidor de SharePoint atacado. Aquí es donde entra en juego la primera vulnerabilidad de spoofing de Microsoft SharePoint Server CVE-2025-49706.

CVE-2025-49706

Esta vulnerabilidad está presente en el método PostAuthenticateRequestHandler, en Microsoft.SharePoint.dll. SharePoint requiere que los Servicios de Información de Internet (IIS) estén configurados en modo integrado. En este modo, las etapas de autenticación de IIS y ASP.NET están unificadas. En consecuencia, el resultado de la autenticación de IIS no se conoce hasta la etapa PostAuthenticateRequest, una vez que se han terminado de usar tanto los métodos de autenticación de ASP.NET como los de IIS. Por lo tanto, el método PostAuthenticateRequestHandler utiliza una serie de indicadores para rastrear posibles infracciones de autenticación. Un error lógico en este método permite eludir la autenticación si el encabezado “Referrer” de la solicitud HTTP es igual a “/_layouts/SignOut.aspx”, “/_layouts/14/SignOut.aspx” o “/_layouts/15/SignOut.aspx” utilizando una comparación que no distingue entre mayúsculas y minúsculas.

Código vulnerable en el método PostAuthenticateRequestHandler (Microsoft.SharePoint.dll versión 16.0.10417.20018)

El código que se muestra en la imagen de arriba maneja la solicitud de cierre de sesión y activa cuando la página de cierre de sesión se especifica como el Referrer. Cuando flag6 está establecido en falso y flag7 en verdadero, se omiten ambas ramas condicionales que podrían generar una excepción de “Acceso no autorizado”.

Controles de acceso no autorizado que el exploit logra evadir

El 8 de julio, Microsoft publicó una actualización que corrige esta vulnerabilidad. Para ello, la actualización introduce una verificación adicional que comprueba el uso de la ruta “ToolPane.aspx” cuando en el encabezado “Referrer” está presente la página de cierre de sesión.

Corrección de CVE-2025-49706 (Microsoft.SharePoint.dll versión 16.0.10417.20027)

La verificación añadida utiliza una comparación que no distingue entre mayúsculas y minúsculas para verificar si la ruta solicitada termina en “ToolPane.aspx”. ¿Es posible eludir esta verificación, digamos, utilizando otro endpoint? Nuestras pruebas han demostrado que es fácil eludirla.

CVE-2025-53771

Pudimos eludir con éxito el parche para la vulnerabilidad CVE-2025-49706 al agregar solo un byte a la solicitud POST del exploit. Todo lo que se requería para eludir este parche era agregar una “/” (barra) al final de la ruta “ToolPane.aspx” solicitada.

Forma de eludir la corrección de CVE-2025-49706

El 20 de julio de 2025, Microsoft lanzó la actualización CVE-2025-53771 ,que solucionó esta vulnerabilidad. Con esta solución, en lugar de comprobar “ToolPane.aspx”, se verifica si la ruta solicitada está incluida en la lista de rutas autorizadas para utilizarse con la página de cierre de sesión indicada como referrer.

Corrección de CVE-2025-53771 (Microsoft.SharePoint.dll versión 16.0.10417.20037)

Esta lista de rutas permitidas (allowlist) incluye: “/_layouts/15/SignOut.aspx”, “/_layouts/15/1033/initstrings.js”, “/_layouts/15/init.js”, “/_layouts/15/theming.js”, “/ScriptResource.axd”, “/_layouts/15/blank.js”, “/ScriptResource.axd”, “/WebResource.axd”, “/_layouts/15/1033/styles/corev15.css”, “/_layouts/15/1033/styles/error.css”, “/_layouts/15/images/favicon.ico”, “/_layouts/15/1033/strings.js”, “/_layouts/15/core.js”, y puede contener rutas adicionales añadidas por el administrador.

Durante las pruebas para eludir el parche de la CVE-2025-49706 con las actualizaciones del 8 de julio instaladas en nuestro entorno de depuración, obtuvimos un resultado inesperado. No solo logramos eludir la corrección que nos interesaba, sino también ejecutar la cadena completa de exploits. Pero, ¡un momento! ¿Acaso no habían utilizado los atacantes una vulnerabilidad adicional de ejecución remota de código en Microsoft SharePoint CVE-2025-49704, que se suponía iba a ser corregida en la misma actualización? Para entender por qué en nuestro caso toda la cadena del exploits logró sus objetivos malintencionados, echemos un vistazo a la vulnerabilidad CVE-2025-49704 y cómo se la solucionó.

CVE-2025-49704

CVE-2025-49704 describe una vulnerabilidad relacionada con la deserialización de datos no confiables causada por una validación incorrecta del contenido XML. Al observar la solicitud POST de explotación, podemos ver que contiene dos parámetros codificados en la URL: “MSOtlPn_Uri” y “MSOtlPn_DWP”. Podemos ver cómo se manejan examinando el código del método GetPartPreviewAndPropertiesFromMarkup en Microsoft.SharePoint.dll. Un análisis rápido revela que “MSOtlPn_Uri” es una URL de página que podría apuntar a cualquier archivo en la carpeta CONTROLTEMPLATES y el parámetro “MSOtlPn_DWP” contiene algo conocido como WebPart markup. Este marcado contiene directivas especiales que se pueden usar para ejecutar controles seguros en un servidor y tiene un formato muy similar al XML.

WebPart markup utilizado por los atacantes

Aunque el “XML” incluido en el parámetro “MSOtlPn_DWP” no contiene en sí mismo una vulnerabilidad, permite a los atacantes instanciar el control ExcelDataSet de Microsoft.PerformancePoint.Scorecards.Client.dll con la propiedad CompressedDataTable configurada con una carga maliciosa, y activar su procesamiento utilizando el getter de la propiedad DataTable.

Código del método que maneja los contenidos de la propiedad CompressedDataTable de ExcelDataSet en el getter de la propiedad DataTable

Al observar el código del getter de la propiedad DataTable de ExcelDataSet en Microsoft.PerformancePoint.Scorecards.Client.dll, encontramos el método GetObjectFromCompressedBase64String, responsable de deserializar el contenido de la propiedad CompressedDataTable. El dato proporcionado como cadena Base64 se decodifica, descomprime y se pasa al método BinarySerialization.Deserialize de Microsoft.SharePoint.dll.

Conjunto de datos con el contenido XML explotando CVE-2025-49704 (deserializado)

Los atacantes utilizan este método para proporcionar un DataSet malicioso cuyo contenido deserializado se muestra en la imagen de arriba. Contiene un XML con un elemento de tipo peligroso "System.Collections.Generic.List`1[[System.Data.Services.Internal.ExpandedWrapper`2[...], System.Data.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]", lo que permite a los atacantes ejecutar métodos arbitrarios con la ayuda de la conocida técnica ExpandedWrapper, dirigida a la explotación de la deserialización insegura de XML en aplicaciones basadas en el marco .NET. De hecho, esto no debería ser posible, ya que BinarySerialization.Deserialize en Microsoft.SharePoint.dll utiliza un XmlValidator especial diseñado para proteger contra esta técnica al verificar los tipos de todos los elementos presentes en el XML proporcionado y asegurarse de que estén en la lista de tipos permitidos. Sin embargo, el exploit elude esta verificación al colocar el objeto ExpandedWrapper en la lista.

Ahora, para averiguar por qué el exploit funcionó en nuestro entorno de depuración de SharePoint con las actualizaciones del 8 de julio de 2025 instaladas, veamos cómo se trató de resolver esta vulnerabilidad. En este parche, Microsoft no solucionó la vulnerabilidad, sino que solo la mitigó al agregar la nueva clase AddExcelDataSetToSafeControls al espacio de nombres Microsoft.SharePoint.Upgrade. Esta clase contiene un nuevo código que modifica el archivo web.config y marca el control Microsoft.PerformancePoint.Scorecards.ExcelDataSet como no seguro. Debido a que SharePoint no ejecuta este código por sí mismo después de instalar actualizaciones, la única manera de lograr el efecto de seguridad era ejecutar una actualización manual de la configuración utilizando la herramienta Asistente de Configuración de Productos de SharePoint. Cabe destacar que la guía de seguridad para la CVE-2025-49704 no menciona la necesidad de este paso, lo que implica que al menos algunos administradores de SharePoint podrían haberlo omitido. Y quienes instalaron esta actualización pero no hicieron una actualización manual de la configuración seguían siendo vulnerables.

CVE-2025-53770

El 20 de julio de 2025, Microsoft lanzó una actualización con una solución eficaz para la vulnerabilidad CVE-2025-49704. Este parche introduce un XmlValidator actualizado que ahora sí valida correctamente los tipos de elementos en XML, lo que previene la explotación de esta vulnerabilidad sin requerir una actualización de configuración y, más importante aún, abordando la causa raíz y previniendo la explotación de la misma vulnerabilidad a través de controles distintos a Microsoft.PerformancePoint.Scorecards.ExcelDataSet.

Código del nuevo verificador de tipo en el XmlValidator actualizado

CVE-2020-1147

Los lectores familiarizados con exploits anteriores de SharePoint notarán que la vulnerabilidad CVE-2025-49704/CVE-2025-53770 y el exploit empleado por los atacantes son muy similares a la antigua vulnerabilidad de ejecución remota de código en .NET Framework, SharePoint Server y Visual Studio (CVE-2020-1147). Es más, si comparamos el exploit para CVE-2020-1147 y un exploit para CVE-2025-49704/CVE-2025-53770, podemos ver que son casi idénticos. La única diferencia es que en el exploit para CVE-2025-49704/CVE-2025-53770, el objeto ExpandedWrapper peligroso está presente en la lista. Esto convierte a CVE-2025-53770 en una solución actualizada para CVE-2020-1147.

Conjunto de datos con contenido XML explotando CVE-2020-1147

Conclusiones

A pesar de que los parches para las vulnerabilidades de ToolShell ya están disponibles para su implementación, creemos que esta cadena de exploits seguirá siendo utilizada por los atacantes durante mucho tiempo. Hemos observado la misma situación con otras vulnerabilidades destacadas, como ProxyLogon, PrintNightmare o EternalBlue. Aunque se las conoce desde hace años, muchos actores de amenazas continúan aprovechándolas en sus ataques para comprometer sistemas sin parches. Predecimos que las vulnerabilidades de ToolShell tendrán un destino similar, ya que pueden ser explotadas casi sin esfuerzo y permiten tomar el control total sobre el servidor vulnerable.

Para estar mejor protegidos contra amenazas como ToolShell, nosotros como comunidad deberíamos ser conscientes de las lecciones que nos dejan eventos anteriores en la industria relacionados con vulnerabilidades críticas. Hoy en día, el factor más importante para enfrentar estas vulnerabilidades es aplicar los parches de seguridad con rapidez. Los exploits públicos de vulnerabilidades peligrosas surgen casi de inmediato tras su anuncio, así que instalar los parches rápidamente es esencial: retrasarse unas horas puede ser crítico.

Asimismo, es importante proteger las redes empresariales contra los exploits de día cero, que pueden ser aprovechados cuando no hay un parche público disponible para las vulnerabilidades. En este sentido, es fundamental dotar a los equipos de soluciones de ciberseguridad fiables que hayan demostrado su eficacia frente a ataques ToolShell incluso antes de que fueran hechos públicos.

Kaspersky Next, con su componente Detección de comportamiento, ofrece una protección proactiva contra la explotación de estas vulnerabilidades. Además, es capaz de detectar la explotación y la actividad maliciosa que genera.

Los productos de Kaspersky detectan los exploits y el malware utilizado en estos ataques con los siguientes veredictos:

• UDS:DangerousObject.Multi.Generic
• PDM:Exploit.Win32.Generic
• PDM:Trojan.Win32.Generic
• HEUR:Trojan.MSIL.Agent.gen
• ASP.Agent.*
• PowerShell.Agent.*