
Explotación y mitigación simuladas de CVE-2025-54918 (fallo de NTLM de Windows). Incluye scripts de detección, parcheo con Ansible y fortalecimiento de CI/CD. Demuestra la escalada de privilegios desde acceso de bajo nivel hasta SYSTEM en entornos de nube híbrida.
Explotación simulada y mitigación de CVE-2025-54918 (fallo NTLM de Windows). Incluye scripts de detección, parcheo con Ansible y endurecimiento de CI/CD. Demuestra la escalada de privilegios desde acceso de bajo nivel hasta SYSTEM en entornos híbridos en la nube.
Por Mark Mallia
En los entornos híbridos en la nube actuales, la línea entre la interacción del usuario y el compromiso del sistema es más delgada que nunca. Este artículo explora una cadena de ataque del mundo real que comienza con un fallo gráfico aparentemente inofensivo, CVE-2025-55226, una condición de carrera en el kernel de gráficos de Windows, y escala hasta el control total a nivel de SYSTEM mediante CVE-2025-54918, una omisión crítica de autenticación NTLM.
En conjunto, estas vulnerabilidades demuestran cómo los atacantes pueden pivotar desde la ejecución remota de código hasta la escalada de privilegios en solo unos pocos pasos. Pero lo más importante es que muestran cómo un ingeniero DevOps sénior puede detectar, mitigar y monitorear tales amenazas mediante automatización, integración con CI/CD e infraestructura como código.
Publicado: 16 de septiembre de 2025 (Patch Tuesday)
El último aviso de seguridad de Microsoft identifica un fallo grave en win32k.sys, el kernel de gráficos principal utilizado tanto por las ediciones de escritorio como de servidor de Windows. La debilidad es una condición de carrera que permite a un atacante desencadenar una Ejecución Remota de Código (RCE) en cualquier sistema donde se esté ejecutando el controlador vulnerable. Debido a que el controlador se encuentra en el corazón de GDI (Graphics Device Interface), puede ser abusado para ejecutar código arbitrario en modo kernel, un nivel de privilegio que puede comprometer toda la máquina.
Por qué esto importa:
- Ataca un subsistema central que impulsa cada interfaz gráfica de usuario, desde computadoras de oficina comunes hasta servidores de alto rendimiento.
- Un parche lanzado el martes proporciona una solución inmediata, pero solo si los administradores saben cómo descubrir, implementar y monitorearlo a tiempo.
El siguiente fragmento extrae la versión actual de win32k.sys del registro, la compara con la versión parcheada y registra las discrepancias en un archivo CSV que puede importarse en Excel o Tableau.
# DetectWin32k.ps1 – check for vulnerable win32k.sys
$target = 'Microsoft-Windows-GraphicsKernel'
$patchVersion = '6.0.22.7' # Expected patched version
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Services\$target"
$currentVer = Get-ItemProperty $regPath | Select-Object -ExpandProperty ImagePath
$kernelFile = Join-Path $env:SystemRoot \System32\win32k.sys
$fileVersion = (Get-ChildItem $kernelFile).VersionInfo.FileVersion
if ($fileVersion -ne $patchVersion) {
Write-Output "vulnerable: $currentVer (actual=$fileVersion, expected=$patchVersion)" | Out-File -Encoding ascii .\report.csv
}
Qué hace:
El siguiente archivo YAML le indica a Ansible que aplique la actualización de win32k.sys y reinicie el servicio GDI en todos los hosts objetivo.
---
- name: Deploy Windows graphics kernel patch
hosts: windows_servers
gather_facts: yes
tasks:
- name: Copy new win32k.sys
copy:
src: /tmp/patches/win32k.sys
dest: C:\Windows\System32\
mode: '0644'
force: yes
- name: Restart GDI service
win_service:
name: w32k
state: restarted
Qué hace:
windows_servers).Cree un panel simple que visualice el uso de la tabla de objetos GDI a lo largo del tiempo.
# grafana-dashboard.yml
apiVersion: 1
dashboard:
title: “GDI Usage”
panels:
- name: “Objects in use”
type: graph
targets:
- query: "SELECT timestamp, gdi_objects FROM win32k_stats WHERE $__timeFilter()"
Qué hace:
win32k_stats) y las muestra en un panel de Grafana. Puede configurar alertas cuando el uso supere un umbral: un indicador temprano de regresiones del controlador.Agregue un paso de prueba a su canalización de Jenkins o GitHub Actions que ejercite el parche fuzzeando win32k.sys con una herramienta ligera (por ejemplo, wdfuzz).
# .github/workflows/cve55226.yml
name: CVE‑2025‑55226 CI
on:
push:
branches:
- main
jobs:
test_and_deploy:
runs-on: windows-latest
steps:
- uses: actions/checkout@v3
- name: Run fuzzer
run: |
wdfuzz.exe -t win32k.sys -c config.yaml
if ($LASTEXITCODE -eq 0) { Write-Host "Fuzz passed" }
- name: Deploy patch
uses: ansible/[email protected]
with:
playbook: DetectWin32k.ps1
Qué hace:
main.Comienza con un solo fallo en el motor gráfico. Un atacante encuentra una forma de explotar una condición de carrera en el kernel de Windows como se demostró anteriormente, esquivando las defensas y ejecutando código de forma remota. Eso es CVE-2025-55226. Pero el peligro real se desarrolla cuando lo combinan con CVE-2025-54918, una debilidad en la autenticación NTLM. De repente, no solo están dentro: tienen el control.
Lo que comenzó como un error gráfico se convierte en una escalada de privilegios en toda regla, otorgándoles acceso a nivel de SYSTEM. Esta cadena de eventos no es solo teórica. Es un recordatorio de que en los entornos híbridos actuales, las vulnerabilidades rara vez existen de forma aislada.
Publicado: 9 de septiembre de 2025 (Patch Tuesday)
Puntuación CVSS v3.1: 8.8 (Alta)
Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CWE: CWE‑287 – Autenticación inadecuada
Componente afectado: NTLM de Windows (New Technology LAN Manager)
El fallo es un error de lógica en cómo NTLM valida los datos de autenticación. Un atacante que pueda alcanzar un host a través de la red, incluso con privilegios mínimos, puede engañar al sistema para que le otorgue derechos a nivel de SYSTEM. Esto significa que después de comprometer una estación de trabajo o un controlador de dominio, un adversario puede instalar aplicaciones, exfiltrar archivos confidenciales y crear nuevas cuentas de administrador, esencialmente el control total del objetivo.
La vulnerabilidad es parte de un patrón creciente en 2025: ya se han reportado otros dos errores NTLM (CVE‑2025‑53778, CVE‑2025‑21311). El parche de Microsoft para este problema corrige una rutina de comparación incorrecta que acepta indebidamente ciertos valores hash.
# Find hosts with vulnerable NTLM settings
$target = "dc01.company.local"
Invoke-Command -ComputerName $target -ScriptBlock {
Get-WmiObject -Class Win32_OperatingSystem |
Select-Object CSName, Version, BuildNumber
} | Out-File -FilePath C:\temp\nlm_detection.txt
# Check the NTLM policy value
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon" |
Select-Object "LmCompatibilityLevel"
# Export to CSV for quick review
$report = @()
foreach ($item in Get-WmiObject -Class Win32_Service | Where { $_.Name -eq "netlogon"}) {
$report += [pscustomobject]@{
Service = $item.Name
LmCompat = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon").LmCompatibilityLevel
}
}
$report | Export-Csv -Path C:\temp\nlm_report.csv -NoTypeInformation
El script extrae la compilación actual del sistema operativo, verifica que la clave Netlogon esté configurada con un valor que Microsoft recomienda (3) y escribe los resultados en un CSV fácil de consumir.
---
- name: Patch NTLM for Windows servers
hosts: windows_dc01, windows_dc02, windows_dc03
gather_facts: true
tasks:
- name: Enable Netlogon compatibility level
win_regedit:
path: HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon
key: LmCompatibilityLevel
value: 3
datatype: dword
- name: Install Microsoft patch KB5000000
win_updates:
category_name: Security
search_keyword: KB5000000
reboot_after: true
Implemente el playbook en todos los controladores de dominio. La tarea garantiza que la política esté configurada correctamente e instala la última actualización de seguridad, de modo que el mismo error de lógica ya no sea explotable.
Usando Responder e Impacket puede imitar un ataque de retransmisión NTLM del mundo real:
secretsdump.py de Impacket captura los datos de autenticación.# Start Responder on the attack box
responder -i eth0 -f
# Dump credentials from the victim
python3 impacket/secretsdump.py <victim-ip> <domain-admin-username>
# Replay hash to the target
python3 impacket/ntlmrelay.py <victim-ip> <target-ip>
Ejecute el script en un entorno controlado y valide que recibe acceso a nivel de SYSTEM.
Agregue una tarea de endurecimiento NTLM a su canalización:
- name: Validate Netlogon compatibility level
win_regedit:
path: HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon
key: LmCompatibilityLevel
value: 3
datatype: dword
state: present
# Trigger when new patches are applied
- name: Reboot if required and restart services
win_reboot:
reboot_timeout_sec: 120
La tarea se ejecuta automáticamente siempre que la canalización se active mediante una nueva compilación de parche.
Cree una alerta que se active cuando un host inicie sesión con autenticación NTLM que coincida con el patrón de hash vulnerable:
input {
beats {
type => "winlogbeat"
}
}
filter {
if [event_id] == "4624" and [logon_type] =~ /NTLM/ {
mutate {
add_field => { "[ntlm_match]" => "true" }
}
}
}
output {
elasticsearch {
hosts => ["es.company.local"]
index => "ntlm_audit"
}
}
La alerta se envía a Sentinel para su visualización, lo que permite a los reclutadores ver que la corrección se ha aplicado y se está monitoreando.
La seguridad no se trata solo de parchear vulnerabilidades; se trata de entender cómo se conectan, cómo evolucionan y cómo pueden ser armadas de maneras que no son inmediatamente obvias. Al encadenar CVE-2025-55226 y CVE-2025-54918, he mostrado cómo un solo fallo en un controlador gráfico puede abrir la puerta al compromiso total del sistema. Pero lo más importante, he demostrado cómo un ingeniero DevOps puede responder no solo con correcciones técnicas, sino con previsión, automatización y resiliencia.