By ethicalhacktips.com
Desde el pasado 11 de febrero, Windows Server 2025 está disponible para el público generalista en sus versiones Standard y Datacenter y viene con una serie de mejoras. Orientadas a fortalecer la seguridad en gestión de identidades y resistencia ante ataques de escalada de privilegios. En este artículo se analizan las principales características introducidas por Microsoft y se documentan pruebas reales de pentesting que hemos realizado concretamente para esta nueva versión del sistema operativo de la compañía de Redmond. ¿Más luces que sombras? Vamos a verlo.
1. Nuevas características de seguridad
Credential Guard habilitado por defecto, pero leyendo la letra pequeña.
Microsoft nos promete que Credential Guard evita ataques de robo de credenciales mediante la protección de hashes NTLM, ticket kerberos (TGT) y credenciales almacenadas en memoria de los servidores.
Credential Guard usa la seguridad basada en virtualización (VBS) para aislar los secretos de modo que solo el software del sistema con privilegios pueda acceder a ellos. El acceso no autorizado a estos secretos puede provocar ataques de robo de credenciales, como pass-the-hass t pass-the-ticket.
Cuando está habilitado, Credential Guard proporciona las siguientes ventajas:
- Seguridad de hardware: NTLM, Kerberos y Credential Manager aprovechan las características de seguridad de la plataforma, incluido el arranque seguro y la virtualización, para proteger las credenciales.
- Seguridad basada en virtualización: NTLM, credenciales derivadas de Kerberos y otros secretos se ejecutan en un entorno protegido que está aislado del sistema operativo en ejecución.
- Protección contra amenazas persistentes avanzadas: cuando las credenciales se protegen mediante VBS, se bloquean las técnicas y herramientas de ataque de robo de credenciales usadas en muchos ataques dirigidos. El malware que se ejecuta en el sistema operativo con privilegios administrativos no puede extraer secretos protegidos por VBS.
Ahora bien, no todo es tan fácil como parece y para poder activarlo hay que cumplir una serie de requisitos; en las pruebas que hemos realizado no hemos podido activarlo ni en una máquina virtual en Oracle Virtual Box ni en VMware Workstation.
Verificación con PowerShell
Para comprobar si Credential Guard está habilitado, se puede ejecutar el siguiente comando:
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuardEl valor SecurityServicesConfigured debe incluir 1 (Credential Guard) y SecurityServicesRunning también debe contener 1 si está activo.
También se puede verificar el estado del aislamiento LSA con:
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name RunAsPPLUn valor 1 indica que LSA está protegido.
Comportamiento frente a herramientas como Mimikatz
En sistemas con Credential Guard habilitado, Mimikatz no puede acceder a los secretos en memoria. Por ejemplo, al ejecutar:
mimikatz.exe "sekurlsa::logonpasswords" exitEl resultado devolverá mensajes como ERROR kuhl_m_sekurlsa_acquireLSA; Logon list, indicando que no tiene acceso al proceso LSA protegido. Esto valida que las credenciales están correctamente aisladas.
Aunque Credential Guard limita seriamente la exposición de credenciales, no protege contra ataques de phishing ni contra delegaciones inseguras de Kerberos (como Unconstrained Delegation).
SMB sobre QUIC
Se introduce soporte para SMB sobre QUIC, lo cual permite una comunicación segura y cifrada, ideal para entornos híbridos o conexiones a través de Internet, sin necesidad de usar VPNs.
2. Delegated Managed Service Accounts (dMSA)
Las nuevas cuentas dMSA permiten delegar la administración de cuentas de servicio sin necesidad de privilegios elevados en el dominio. A diferencia de las gMSA, no requieren KDS y permiten una gestión más granular y flexible, ideal para entornos de mínimo privilegio.
dMSA vs gMSA: Evolución en la gestión de cuentas de servicio
| Característica | gMSA | dMSA |
|---|---|---|
| KDS requerido | Sí. | No |
| Delegación gran. | No | Sí. |
| Soporte para múltiples hosts | Sí. | Sí. |
| Requiere admin de dominio. | Sí. | No |
| Compatibilidad | 2012+ | 2025+ |
Las dMSA están diseñadas para entornos con equipos DevOps y operaciones delegadas, facilitando la adopción de Zero Trust.
4. Pruebas de escalada de privilegios
Hemos llevado a cabo varias pruebas de pentesting para evaluar la efectividad de las nuevas protecciones de Windows Server 2025. Para dichas pruebas hemos usado una máquina virtualizada con versión Windows Server 2025 Datacenter actualizado y sin software adicional.
4.1 Herramientas “Potato”: Resultados mixtos
Probamos distintas variantes de las conocidas herramientas de escalada por abuso de servicios:
- Juicy Potato → No funcionó
- Lovely Potato → No funcionó.
- Rogue Potato → No funcionó
- PrintSpoofer → No funcionó
- PetitPotato → ✅ Éxito parcial: Se consiguió escalada a Administrador local, pero no a SYSTEM.
Estas herramientas dependen de configuraciones de privilegios y permisos específicos en servicios COM y RPC y sus respectivos CLIDs. Windows Server 2025 parece implementar controles adicionales que bloquean la suplantación de tokens SYSTEM de forma efectiva. Además, observamos cambios significativos en los objetos COM con respecto a versiones anteriores de Windows Server. Aunque con PetitPotato sí logramos explotar un servidor miembro y escalar a administrador local, no conseguimos el usuario SYSTEM.
4.2 Escalada a través de servicio FTP mal configurado
Decidimos forzar un servicio mal configurado como el servicio de DNS y realizar un ataque de tipo DNSadmin con permisos excesivos y comprobar si con un payload podíamos conseguir una escalada de privilegios. Este es un método antiguo, pero para el caso la prueba resultó exitosa.
Recomendaciones
Aplicar políticas de AppLocker o Software Restriction Policies para evitar ejecución no autorizada.
Nunca otorgar permisos de escritura a ejecutables de servicios.
Auditar periódicamente los ACLs en directorios sensibles con herramientas como icacls, AccessChk, o scripts de auditoría.
4.3 Escalada mediante vulnerabilidad en el kernel (CVE-2025-21325)
También se realizaron pruebas de escalada de privilegios explotando vulnerabilidades en el kernel de Windows Server 2025. En concreto, se intentó explotar la vulnerabilidad CVE-2025-21325, que fue publicada como una potencial ruta de escalada local mediante uso indebido de objetos compartidos entre kernel y espacio de usuario.
- Prueba: Se ejecutó un exploit en la máquina Kali Linux contra la máquina Windows Server 2025 para interactuar con objetos del kernel afectados, utilizando syscalls desde un binario compilado en C.
- Resultado: ❌ No funcional en nuestro entorno. La versión probada de Windows Server 2025 ya incorporaba mitigaciones que invalidaban la explotación directa. Aunque si conseguimos establecer una revshell, no conseguimos permisos de SYSTEM.
- Observaciones: El sistema arrojó un BSOD (BugCheck 0x139: KERNEL_SECURITY_CHECK_FAILURE) tras la ejecución del exploit.
- Entorno utilizado: Oracle VirtualBox con máquinas virtuales de Kali Linux y Windows Server 2025.
5. Conclusiones
Windows Server 2025 demuestra una mejora notable en seguridad, dificultando tácticas tradicionales de escalada de privilegios. Sin embargo, sigue siendo vulnerable ante errores de configuración básicos, como permisos incorrectos en servicios. Las nuevas capacidades como Credential Guard y dMSA muestran una clara orientación hacia entornos Zero Trust, aunque su eficacia dependerá de una correcta implementación y del cumplimiento de unos requisitos concretos.
Resumen técnico y buenas prácticas
- Credential Guard: Confirmar que esté habilitado mediante PowerShell, asegurarse de que VBS esté activo y aplicar políticas para evitar su desactivación.
- Mitigación de técnicas tipo Potato: Evaluar los servicios que permiten impersonación. Limitar permisos innecesarios y proteger procesos sensibles con PPL.
- Hardening de servicios: Verificar los permisos ACL de todos los ejecutables de servicios, especialmente aquellos que corren como SYSTEM. Utilizar herramientas como
icaclsoAccessChk. - Gestión segura con dMSA: Sustituir cuentas de servicio tradicionales por dMSA, permitiendo delegación granular sin conceder privilegios innecesarios en el dominio.
- Controles de ejecución: Aplicar políticas AppLocker o Windows Defender Application Control (WDAC) para restringir la ejecución de binarios en rutas críticas.
- Visibilidad y monitoreo: Integrar Sysmon y EDRs para registrar eventos críticos, ejecución de procesos inusuales y cambios en configuraciones de servicios.