Initializing

Volver al blog
CPPJ

28 de julio de 2026

Fortaleza: cinco clics a SYSTEM desde la pantalla de bloqueo

Gerardo Eliasib

Gerardo Eliasib

CEO of Spartan-Cybersecurity

Fortaleza: cinco clics a SYSTEM desde la pantalla de bloqueo

Tienes delante un Windows Server. Nada exótico: un servidor de aplicación con un portal de "soporte técnico interno", SMB, RDP y WinRM. El tipo de máquina que hay a cientos en cualquier empresa.

Va a caer tres veces, por tres vías que no tienen nada que ver entre sí. Y la más grave de las tres no necesita un exploit compilado, ni shellcode, ni una sola contraseña.

Se explota con el ratón. Desde la pantalla de bloqueo. Antes de que exista ningún usuario.

Esa es Fortaleza, una de las tasks de dificultad fácil del CPPJ, y la lección que esconde es incómoda: la vulnerabilidad más crítica de un servidor rara vez es la más sofisticada. Todo lo que sigue ocurre dentro de un laboratorio autorizado, sobre infraestructura que construimos para eso.

No todo Windows es un dominio

Antes de tocar nada, identifica qué tienes enfrente. Si vienes de Cetro, donde el objetivo era un Domain Controller, aquí el escaneo cuenta otra historia:

bash
nmap -Pn -n -sV -p 80,135,443,445,3389,5985 \
  --script "smb-os-discovery,smb2-security-mode,smb-vuln-ms17-010,http-title,ssl-cert,rdp-ntlm-info" \
  10.10.10.102
PORT     STATE SERVICE       VERSION
80/tcp   open  http          Microsoft IIS httpd 10.0
|_http-title: Spartan-Labs // Soporte Tecnico Interno
443/tcp  open  ssl/http      Microsoft IIS httpd 10.0
| ssl-cert: Subject: commonName=expired.local
|   Not valid before: 2026-05-06T20:58:48
|_  Not valid after:  2026-05-06T21:09:18
135/tcp  open  msrpc         Microsoft Windows RPC
445/tcp  open  microsoft-ds  Windows Server 2016 Standard 14393 microsoft-ds
3389/tcp open  ms-wbt-server Microsoft Terminal Services
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0

Un DC se delata por su constelación: DNS, Kerberos, LDAP, Global Catalog. Aquí no hay nada de eso. La firma es otra —IIS + SMB + RDP + WinRM— y describe un servidor de aplicación suelto, no la autoridad de un dominio.

Lo confirma una sola línea de netexec, que sigue siendo la herramienta más densa en información por carácter escrito:

bash
nxc smb 10.10.10.102 -u '' -p ''
SMB  10.10.10.102  445  FORTALEZA  [*] Windows Server 2016 Standard 14393 x64 \
     (name:FORTALEZA) (domain:Fortaleza) (signing:False) (SMBv1:True)

Lee ese banner despacio, porque decide tu estrategia entera:

  • `domain:Fortaleza` es igual a `name:FORTALEZA`. El "dominio" que reporta es su propio hostname. Traducción: es un workgroup, no Active Directory. Los usuarios serán locales, no de dominio, y todo lo que sepas de ataques a AD aquí no aplica.
  • `signing:False` — el firmado SMB no es obligatorio. Dato para un relay, aunque en esta máquina no lo necesitarás.
  • `SMBv1:True` — un protocolo que debió morir en 2017 sigue encendido. Es la superficie de MS17-010, y sí, la máquina es vulnerable. Pero esa puerta ya la abrimos en el post de Cetro, así que aquí solo la anotamos y seguimos.

Tres puertas, entonces. MS17-010 es la conocida. La segunda es una inyección de comandos en el portal web que lleva a SeImpersonatePrivilege — la dejamos para la segunda parte, porque merece un post entero.

Y la tercera está escondida a plena vista, en el escaneo que acabas de leer.

El certificado que nace vencido

Vuelve al 443. El certificado es autofirmado, se llama expired.local, y tiene una peculiaridad que casi nadie mira:

Not valid before: 2026-05-06T20:58:48
Not valid after:  2026-05-06T21:09:18

Once minutos de validez.

Un certificado no dura once minutos por accidente. Nadie configura eso por error, y ninguna herramienta lo genera así por defecto. Es un endpoint TLS deliberadamente inválido, y en un examen de recon es la clase de anomalía que separa a quien lee el output de quien solo lo copia.

Retén el dato. Todavía no significa nada. En dos minutos va a significarlo todo.

La comodidad que corre como SYSTEM

Aquí entra la pieza que convierte ese certificado en una llave.

La máquina tiene instalado FortiClient, el cliente VPN de Fortinet, en la versión 5.0.1.194. Y FortiClient ofrece una opción —desactivada por defecto— que se llama "VPN before logon": te deja conectarte a la VPN corporativa antes de iniciar sesión en Windows, directamente desde la pantalla de login.

La idea de negocio es razonable. Un portátil que arranca fuera de la oficina necesita alcanzar el dominio para validar credenciales; sin VPN previa, no hay login. Es una función que existe para resolver un problema real.

El problema es el contexto de ejecución.

Todo lo que ocurre en la pantalla de login corre como `NT AUTHORITY\SYSTEM`. No es una elección de Fortinet: es cómo funciona Windows. Esa pantalla es la sesión de Winlogon, un momento anterior a que exista ningún usuario, así que el único contexto disponible es el de la máquina. El servicio que atiende la función lo confirma sin disimulo:

NOMBRE_SERVICIO: FA_Scheduler   (FortiClient Service Scheduler)
    NOMBRE_INICIO_SERVICIO: LocalSystem
    TIPO_INICIO           : 2   AUTO_START

Ahora junta las dos mitades. Si al intentar conectar la VPN el certificado del servidor es inválido, FortiClient hace lo educado: te muestra una advertencia de certificado y te pregunta si quieres continuar.

Ese cuadro de diálogo —y cualquier ventana que abra a partir de él— hereda el token de SYSTEM.

Eso es CVE-2017-7344. No hay corrupción de memoria, no hay criptografía rota. Hay una interfaz privilegiada que te deja llegar más lejos de lo que su autor imaginó.

Por qué esta máquina cumple los dos requisitos

La vulnerabilidad necesita dos condiciones a la vez: la opción activada y un certificado inválido. Fortaleza tiene las dos, y se comprueban leyendo el registro:

HKLM\SOFTWARE\Wow6432Node\Fortinet\FortiClient\FA_VPNSTARTER
    vpn_before_logon_enabled    REG_DWORD    0x1

HKLM\SOFTWARE\Wow6432Node\Fortinet\FortiClient\Sslvpn\Tunnels\Spartan
    Server                      REG_SZ       127.0.0.1
    promptcertificate           REG_DWORD    0x0

Ahí está el círculo cerrándose. El perfil de VPN apunta a 127.0.0.1 — o sea, al propio IIS de la máquina, en el puerto 443. Y ese IIS sirve el certificado expired.local que caducó once minutos después de nacer.

Es decir: cada vez que FortiClient intenta conectar la VPN antes del logon, siempre recibe un certificado inválido, y siempre dispara el diálogo vulnerable.

El expired.local del nmap nunca fue ruido de fondo. Era la mitad del ataque, esperando a que alguien uniera los puntos.

Falta confirmar que la opción llega de verdad a la pantalla de login, y eso también está en el registro: el credential provider de Fortinet está registrado como proveedor de credenciales del sistema.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers
    {AC7DD106-EAB6-4b41-AC4F-D52FD62A82C7}   REG_SZ   FortiCredentialProvider

Cinco clics

Con acceso a la pantalla de login —físico, o por RDP sin NLA, que el 3389 permite— la cadena completa es de interfaz. Ni una línea de código:

  1. En la pantalla de login, eliges el perfil VPN de FortiClient e intentas conectar. La contraseña da igual: nunca llegas a autenticarte.
  2. FortiClient valida el certificado de 127.0.0.1:443, lo encuentra inválido y abre la advertencia. Pulsas "Ver certificado".
  3. En la pestaña "Detalles", pulsas "Copiar en archivo...". Eso lanza el asistente de exportación, que abre un cuadro de diálogo de archivo — corriendo como SYSTEM.
  4. En ese explorador, navegas a C:\Windows\System32, escribes * en el nombre de archivo y pulsas Enter para que liste todo.
  5. Clic derecho sobre cmd.exe → "Abrir".
C:\Windows\system32> whoami
nt authority\system

Bypass de la pantalla de bloqueo y escalada a SYSTEM en el mismo movimiento. Sin credenciales, sin exploit, sin tocar el disco.

Fortaleza en vivo: la sesión completa del CPPJ, con el recon y las tres vías de compromiso

La clase de bug, no el bug

Memorizar "FortiClient 5.0.1.194 es vulnerable" no te sirve de nada: no vas a encontrar esa versión en un cliente real. Lo que sí te va a servir es reconocer el patrón, porque el patrón está en todas partes.

Se llama, informalmente, diálogo confiable: una interfaz que corre con privilegios altos y te ofrece, en algún punto de su flujo, un selector de archivos. Y un selector de archivos de Windows no es un widget inocente — es un mini explorador con menú contextual, capaz de abrir, ejecutar y renombrar. Todo con los privilegios del proceso que lo invocó.

La cadena "advertencia → ver detalles → guardar en archivo → explorador → ejecutar" reaparece constantemente:

  • Instaladores que corren como SYSTEM y ofrecen un botón "Examinar..." para elegir la carpeta de destino.
  • Kioscos y equipos de exhibición donde el navegador está bloqueado pero un diálogo de impresión o de descarga abre el sistema de archivos.
  • Salvapantallas y utilidades de accesibilidad que arrancan antes del login.
  • Herramientas de soporte remoto que se ejecutan elevadas para "ayudar al usuario".

La pregunta que debes hacerte frente a cualquier software privilegiado es siempre la misma:

¿Desde este diálogo puedo llegar a un selector de archivos? ¿Y desde el selector, a un cmd.exe?

Clément Notin reportó CVE-2017-7344 en 2017 haciéndose exactamente esa pregunta. Afecta a FortiClient para Windows hasta 5.4.3 y 5.6.0; se corrigió en 5.4.4 y 5.6.1.

El otro lado: cerrar la pantalla de login

En Spartan-Cybersecurity pensamos como atacantes, pero un buen atacante entiende la defensa mejor que quien la implementa. Este vector se cierra en cuatro sitios distintos, y conviene cerrarlo en todos:

  • Parchea el cliente. La corrección existe desde 2017. Un inventario de software que no vigila las versiones de los clientes VPN, agentes de EDR y herramientas de soporte deja abierta justo la categoría de software que corre elevado por diseño.
  • Exige NLA en RDP. Network Level Authentication obliga a autenticarse antes de que se dibuje la pantalla de login remota. Sin NLA, cualquiera que alcance el 3389 tiene acceso a la superficie de ataque de Winlogon; con NLA, esa pantalla no existe hasta que ya demostraste quién eres. Es la mitigación de mayor impacto y la más barata.
  • No actives "VPN before logon" si no la necesitas. Y si la necesitas, el certificado del endpoint tiene que ser válido. Un certificado roto no es una molestia cosmética: aquí es literalmente el disparador del bug.
  • Trata la pantalla de bloqueo como una superficie de ataque. Todo lo que se dibuja ahí corre como SYSTEM. Cada credential provider de terceros que instalas —VPN, lector de huella, MFA, tarjeta inteligente— amplía esa superficie. Audita cuáles hay registrados y por qué.

Y en detección: un proceso hijo de winlogon.exe o de un credential provider que resulte ser cmd.exe, powershell.exe o explorer.exe es una anomalía de las que no admiten explicación benigna. Cualquier EDR puede alertar de eso; hay que decirle que lo haga.

Lo que Fortaleza te enseña

Un servidor no cae por lo sofisticado que sea el atacante. Cae por la suma de decisiones razonables tomadas por separado: activar una opción cómoda, dejar un certificado autofirmado "temporal", exponer RDP sin NLA, no actualizar un cliente VPN que "solo es el de la VPN".

Ninguna de esas decisiones es un error garrafal por sí sola. Las cuatro juntas entregan SYSTEM con cinco clics.

Esa es la mentalidad que entrenamos: no la de quien memoriza exploits, sino la de quien mira un output de nmap, ve un certificado que dura once minutos, y se pregunta por qué.

En la segunda parte le entramos al camino que no toca la interfaz: una inyección de comandos en el portal web, un privilegio de token llamado SeImpersonatePrivilege, y la familia de exploits que convierte cualquier RCE en IIS en SYSTEM casi por defecto.