hkenzokimura/cve-2025-47981
# Script de evaluación de PowerShell que comprueba sistemas Windows para CVE-2025-47981 (desbordamiento de montón SPNEGO NEGOEX) verificando la versión del kernel, la clave de registro PKU2U y los puertos SPNEGO expuestos. Proporciona pasos de remediación y orientación de detección.
Tipo: Evaluación de Vulnerabilidad — Detección / Verificación de Cumplimiento CVE: CVE-2025-47981 CVSS: 9.8 Crítico (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) CWE: CWE-122 — Desbordamiento de Búfer Basado en Heap Alias: "SPNEGO Nightmare" / "RCE Wormable de Autenticación de Windows" Parche: KB5062560 | Patch Tuesday de Julio 2025
Script PowerShell de evaluación que verifica si un sistema Windows es vulnerable al CVE-2025-47981 — desbordamiento de búfer basado en heap en el mecanismo SPNEGO Extended Negotiation (NEGOEX) que permite RCE sin autenticación. No ejecuta exploits — solo evalúa exposición y estado del parche.
Desarrollado por: HKK$ cat ./vulnerability_summary.txtCVE-2025-47981 es un desbordamiento de búfer basado en heap en el protocolo NEGOEX — la capa de extensión interna del mecanismo de autenticación SPNEGO de Windows. La vulnerabilidad permite que atacantes no autenticados ejecuten código remoto arbitrario, obteniendo potencialmente control total del sistema.
Analistas ya han descrito el CVE como teniendo "las características desafortunadas de convertirse en un problema significativo", con potencial wormable — capaz de propagarse automáticamente entre sistemas vulnerables sin interacción del usuario.
La vulnerabilidad afecta a Windows 10 (versión 1607 en adelante) y a todos los Windows Server desde 2008 R2 hasta Server 2025, incluyendo variantes Server Core — más de 33 configuraciones distintas de Windows y Server confirmadas como vulnerables en arquitecturas x64, x86 y ARM64.
$ cat ./technical_background.txtSPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) es la capa de handshake de autenticación que Windows usa antes de cada sesión autenticada. Las aplicaciones frecuentemente necesitan autenticación sin fijar un protocolo — Windows puede usar Kerberos en un entorno, NTLM en otro, o un mecanismo de autenticación extendido en un modelo de confianza diferente. SPNEGO es el mecanismo de negociación que decide qué protocolo de autenticación usar.
Cliente Servidor
│ │
│──── SPNEGO Negotiation ────────►│
│ MechTypeList: │
│ [Kerberos, NTLM, NEGOEX] │
│ │
│◄─── Selected Mechanism ─────────│
│ │
│──── Auth Exchange ─────────────►│ ← overflow aquí en NEGOEX
NEGOEX es el mecanismo de extensión dentro de SPNEGO — permite que autenticaciones PKU2U (peer-to-peer) y otros mecanismos personalizados sean negociados. La vulnerabilidad está en la función ntoskrnl!SpnegoHandleExtended, que procesa estructuras SPNEGO_TOKEN de tamaño excesivo enviadas en múltiples fragmentos, causando desbordamiento en el heap del kernel.
El riesgo es elevado en sistemas donde la Group Policy "Network security: Allow PKU2U authentication requests to this computer to use online identities" está habilitada. Esta configuración, habilitada por defecto en muchos despliegues de Windows, amplifica la superficie de ataque de NEGOEX al permitir autenticación peer-to-peer que activa la ruta de código vulnerable de NEGOEX en endpoints que de otra forma no la expondrían.
$ cat ./architecture.txt┌─────────────────────────────────────────────────────────────────────────┐
│ CVE-2025-47981 ASSESSMENT SCRIPT — FLOW │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ CHECK 1: Windows Version │ │
│ │ Get-CimInstance Win32_OperatingSystem → .Version │ │
│ │ Contexto: identifica el build exacto para correlación con patch│ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ CHECK 2: ntoskrnl.exe Version │ │
│ │ Get-Item C:\Windows\System32\ntoskrnl.exe │ │
│ │ Compare: installed < 10.0.14393.8246 → VULNERABLE │ │
│ │ Compare: installed ≥ 10.0.14393.8246 → KB5062560 aplicado │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ CHECK 3: PKU2U Registry Key │ │
│ │ HKLM:\SYSTEM\...\Lsa\pku2u\AllowOnlineID │ │
│ │ 1 → PKU2U habilitado → superficie de ataque ampliada │ │
│ │ 0 → PKU2U deshabilitado → vector PKU2U mitigado │ │
│ │ No existe → configuración predeterminada (evaluar vía GPO) │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ CHECK 4: Puertos SPNEGO Expuestos │ │
│ │ Get-NetTCPConnection → 135, 445, 5985, 3389, 80, 443, 25 │ │
│ │ Cada puerto abierto = un vector de entrega del exploit │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │ │
│ Format-Table -AutoSize │
│ (salida legible para informe de pentest) │
└─────────────────────────────────────────────────────────────────────────┘
$ cat ./design_decisions.mdntoskrnl.exe$kernelPath = [System.IO.Path]::Combine($env:SystemRoot, "System32\ntoskrnl.exe")
$requiredVersion = "10.0.14393.8246"
$installedVersion = (Get-Item $kernelPath).VersionInfo.FileVersion
if ([version]$installedVersion -lt [version]$requiredVersion) {
"Vulnerable - Parche ausente ($missingKB)"
}
¿Por qué ntoskrnl.exe y no Get-HotFix?
Get-HotFix lista KBs instalados, pero tiene limitaciones conocidas:
DISM o Windows Update en modo silenciosoVerificar la versión de ntoskrnl.exe directamente es más confiable — el archivo solo recibe la versión parcheada cuando el KB ha sido efectivamente aplicado y el sistema reiniciado. Un sistema con KB pendiente de reinicio aún tendrá la versión antigua del kernel en memoria.
[version] cast: PowerShell compara strings lexicográficamente por defecto — "10.0.14393.8246" -lt "10.0.14393.800" sería $false (incorrecto). El cast a [version] garantiza comparación numérica correcta por octeto.
[System.IO.Path]::Combine($env:SystemRoot, ...): usa SystemRoot en lugar de C:\Windows hardcodeado — portable para sistemas con Windows instalado en unidades diferentes.
10.0.14393.824610.0.14393.xxxx → Windows 10 version 1607 / Windows Server 2016
│
└─ 8246 = build con KB5062560 aplicado
¿Por qué este build específico?