Del ‘Pass-The-Cookie’ al ‘Pass-The-VPN’: tácticas y técnicas modernas para la evasión de defensas

Independientemente de la técnica utilizada, todas parten de una situación asumida anterior. Un equipo de un empleado ha sido comprometido con un implante malicioso que permite al Red Team tomar el control del equipo. Este ordenador infectado utiliza una conexión VPN para acceder a los recursos corporativos de la empresa y, por ejemplo, poder teletrabajar.

2. Objetivo del atacante

El objetivo del equipo atacante es poder obtener esa conexión VPN, para poder realizar la conexión desde un equipo suyo (no corporativo) y así poder acceder de manera directa a la red interna. Esto presenta numerosas ventajas:

• Persistencia: al contar con una conexión VPN, el equipo atacante podrá conectarse independientemente de que el usuario cambie su contraseña o se pierda el implante por una detección o un crash en el proceso.
• Independencia de que el usuario tenga el ordenador encendido: la conexión directa permite al atacante conectarse a cualquier hora y desde cualquier lugar, no es necesario que el usuario tenga el equipo encendido para poder pivotar a través de él.
• Evasión del EDR en el endpoint: aunque es cierto que las conexiones VPN y el tráfico de red genera también telemetría, esta es mucho menor que la telemetría generada en el endpoint. Las posibilidades de detección se reducen de manera drástica cuando se compara una conexión VPN con un implante en un equipo con EDR.

Cabe destacar también que en ninguna de las técnicas mencionadas a continuación son necesarios permisos administrativos en el equipo.

Pass-The-Certificate

Un certificado digital es un fichero utilizado para identificar a una persona, organización o dispositivo de manera segura a través de algoritmos criptográficos. Los certificados digitales son emitidos por una autoridad de certificación (CA), que valida la identidad de la persona o entidad antes de emitir el certificado. Esta CA puede ser externa a la organización y reconocida como válida tanto por la organización actual como por todas las demás organizaciones o interna que permite validar datos únicamente dentro de la organización.

Los certificados digitales constan de dos partes fundamentales:

• Clave pública: permite validar que la información proviene de un usuario, dispositivo u organización. Como su propio nombre indica, es pública y conocida por todos.
• Clave privada: debe mantenerse en secreto y puede ser utilizada para firmar documentos o validarte en un determinado sistema remoto.

3. Resultados de las pruebas de Red Team

Durante los ejercicios de Red Team realizados, se identificaron bastantes empresas que utilizan una combinación de usuario y contraseña + certificado digital para acceder a la VPN corporativa. Es por ello, que la posible extracción de un certificado digital almacenado en el equipo comprometido permite a un atacante reutilizarlo para conseguir una conexión desde su propio equipo de operador.

La obtención del usuario y contraseña de la víctima queda fuera del alcance de este análisis, pero existen numerosas maneras de poder obtenerlo: phishing, credenciales almacenadas en el equipo, etc.

En los sistemas Windows existen dos almacenes de certificados diferentes en función de su uso y necesidad. Por un lado, los certificados del usuario actual, accesibles en su visualización y uso para un usuario sin privilegios.

Y los certificados del equipo, cuyo uso solo está permitido para un usuario con privilegios administrativos. Los usuarios sin privilegios pueden consultar qué certificados tienen instalados en este almacén, pero no podrán utilizarlos.

Los certificados digitales pueden tener numerosos usos: firmar código fuente, validar procedencia de emails, etc. Para este caso concreto interesan aquellos certificados cuyo propósito sea Autenticación del Cliente que, como su propio nombre indica, permiten autenticar a un usuario en un determinado sistema. Además, vamos a poner el foco en aquellos certificados que además de estar almacenados cuentan con una clave privada, ya que ésta es la que permitirá una autenticación posterior.

Al importar un nuevo certificado en el equipo, Windows ofrece la opción de marcar el certificado como exportable por si queremos exportar la clave privada en algún momento.

Esta opción no se considera segura y, a lo largo de nuestros ejercicios de Red Team no hemos visto que esté habilitada en ninguna organización. Cuando un certificado se marca como exportable, es posible hacer click derecho sobre él y exportar la clave privada del mismo. En caso de que no sea exportable, no será posible.

La famosa herramienta Mimikatz, permite exportar certificados sin necesidad de utilizar la interfaz gráfica a través del comando «crypto:: certificates /export». Sin embargo, como se puede ver en la imagen, solo es capaz de exportar la clave privada de aquel certificado marcado como exportable.

Sin embargo, podemos utilizar la función “crypto::capi” para parchear la memoria de la función de exportación de la Crypto API de Windows, permitiendo exportar certificados marcados como “no exportables”. Este parcheo modifica el código interno de las funciones de Windows para hacerle pensar que sí que puede exportar el certificado. Todo esto se puede realizar con un usuario sin privilegios en el equipo.

Basado en la idea y el código anterior de mimikatz, el equipo de Red Team de KPMG en España ha desarrollado un nuevo BOF (Beacon Object File) para utilizar a través de su implante y volcar los certificados exportables y no exportables almacenados en el equipo.

Una vez el atacante cuenta con los certificados digitales en su poder, puede importarlos en el almacén de certificados de su equipo de operador y, junto con el usuario y la contraseña, ganar acceso a la VPN corporativa.

Mitigación Pass-The-Certificate

Existen diversas alternativas de bastionado que se pueden realizar para mitigar la técnica de Pass-The-Certificate:

• No permitir conexiones simultáneas: si no se permiten conexiones simultáneas a la VPN, el atacante solo podrá conectarse fuera de la jornada laboral, lo que facilitaría las detecciones a nivel de red. Además, también es posible crear reglas de detección en el caso de conexiones simultáneas donde se detecte que el usuario ha sido comprometido.
• Certificado == Credenciales: la comprobación de las credenciales (usuario y contraseña) y el certificado digital deben ir de la mano. Hemos observado casos donde primero se realiza una comprobación del certificado digital y luego de las credenciales, lo que permite a un atacante utilizar un certificado y otras credenciales que no pertenecen al mismo usuario.

• Autenticación MFA: si se utilizan sistemas MFA basados en un dispositivo móvil el atacante no podrá conectarse únicamente con el certificado digital.
• Acceso condicional (Entra ID): es posible establecer políticas de acceso condicional que bloqueen la conexión a la VPN del atacante. Por ejemplo, es posible exigir que la conexión VPN se realice desde un sistema corporativo que el atacante no tendrá.
• Certificados protegidos: en los equipos que dispongan de un módulo TPM es posible utilizarlo para proteger la clave privada del certificado digital habilitando la siguiente opción:

Aunque existen técnicas de extracción de certificados digitales protegidos por el TPM, son necesarios privilegios administrativos para lograrlo, quedando fuera del alcance de este artículo.

Pass-The-Cookie (EntraID)

Tras haber abusado de la técnica de pass-the-certificate durante meses en los diferentes ejercicios, los clientes empezaron a establecer diferentes medidas de mitigación (como las comentadas anteriormente) que evitaban que el equipo de Red Team pudiese conectarse a la VPN. Por ello, el equipo de I+D comenzó una nueva línea de investigación que intentaría secuestrar la sesión una vez iniciada y validada.

Así, en una de las empresas donde se estaba realizando uno de estos ejercicios de simulación avanzada de ataques, utilizaba un sistema de login basado en EntraID. Tras autenticarse con usuario y contraseña + notificación push en el teléfono móvil, el sistema solicita si queremos mantener la sesión iniciada. Aquí, por un tema de usabilidad, los usuarios clickan Sí para que la VPN no les solicite las credenciales cada vez que inician sesión.

Tras este paso, el equipo encargado de la investigación pensó que era una funcionalidad interesante para investigar ya que mantenía una sesión “persistente” en el equipo sin necesidad de volver a introducir credenciales. Para proceder a la investigación se preparó un laboratorio que permitía capturar todas las peticiones HTTP que estaban siendo enviadas desde el cliente VPN al servidor.

Se trataba de un flujo SAML normal donde se verificaba la autenticidad del cliente a través del entorno de EntraID. Sin embargo, la propia documentación de Microsoft especifica que existen cookies persistentes para facilitar el inicio de sesión único. En concreto mencionan a la cookie ESTSAUTHPERSISTENT.

¿Será posible encontrar dónde se encuentra almacenada esta cookie y reutilizarla para validar el flujo de SSO? Tras realizar un volcado de memoria del cliente de VPN, encontramos que la cookie ESTSAUTHPERSISTENT se encuentra en memoria en texto claro.

Por ello, el equipo de Red Team desarrolló un nuevo Beacon Object File (BOF) que realiza la búsqueda del string ESTSAUTHPERSISTENT= dentro del proceso de VPN de la víctima y lo muestra por pantalla.

Cabe destacar que el valor de esta cookie también se encuentra en disco, ya que la VPN reconecta de igual manera tras reiniciar el equipo. El equipo de Red Team, tras entender el proceso de almacenamiento y descifrado de la cookie decidió optar por la solución de la extracción desde memoria. Se propone al lector como ejercicio la búsqueda y descifrado de esta cookie desde disco.

Con esto en poder del atacante, es posible iniciar una nueva conexión VPN e interceptar el tráfico SAML y modificar las cookies de la petición para añadirle el valor de ESTSAUTHPERSISTENT=

Consiguiendo de esta manera la conexión a la VPN desde un equipo del atacante.

Pass-The-Cookie (GlobalProtect)

Durante la investigación realizada a través del pass-the-cookie en EntraID, el equipo investigador se dio cuenta que la VPN de GlobalProtect(PaloAlto) realizaba otro tipo de autenticación basada en sus propias cookies. 

Esto era fácilmente visualizable al comparar la primera petición de una conexión en un equipo desde 0 (tráfico SAML) con una reconexión en un equipo que ya se había conectado alguna vez a la VPN.

La propia documentación de PaloAlto especifica que existe un directorio de almacenamiento de User Authentication Cookies, que el equipo investigador comenzó a revisar.

En un primer momento, el equipo pensó que quizás las cookies se encontraban almacenadas en texto claro por lo que procedió a la apertura del archivo.

Un lector con experiencia en Windows Internals podría haber notado ya que la cabecera del fichero (01 00 00 00) suele estar relacionada con DPAPI, por lo que se ha desarrollado un nuevo Beacon Object File (BOF) que permite descifrar archivos con DPAPI en el contexto del usuario actual.

Una vez eliminada la capa de DPAPI, se procede de nuevo a la apertura del fichero y se observa que sigue existiendo algún tipo de cifrado.

Es en este momento cuando el equipo investigador decide realizar un proceso de ingeniería inversa al binario de GlobalProtect para intentar comprender cómo se realiza este descifrado.

El proceso de ingeniería inversa realizado está fuera del alcance de este artículo. En la siguiente captura pueden apreciarse algunas instrucciones relacionadas con el algoritmo AES que finalmente será el algoritmo encargado de este proceso.

Tras largas horas y jornadas de trabajo, el equipo investigador concluyó que el algoritmo estaba basado en:

• AES-256-CBC, utilizando un IV nulo (\x00) de 16 bytes
• La clave de cifrado es: 2 veces el MD5(SID + MD5(«pannetwork»))

Obtener el MD5 de la palabra “pannetwork” es trivial, necesitamos obtener el Security Identifier (SID) de la máquina víctima. Esto se puede obtener con una llamada a la WINAPI LookupAccountName en un nuevo BOF.

Ahora tenemos todos los datos para proceder al descifrado. Pongamos un ejemplo:

La representación hexadecimal del SID de la máquina es: 01040000000000051500000049FA9425FDE519AFDB2A26FA

La representación hexadecimal del MD5 de «pannetwork» es: 75b8498390bc2a659c5693e7e5c5f024

Se concatenan los dos valores y se le hace el MD5: MD5(01040000000000051500000049FA9425FDE519AFDB2A26FA75b8498390bc2a659c5693e7e5c5f024)

97c660c15132551d45c937ed5b0caf07

La clave final: 97c660c15132551d45c937ed5b0caf0797c660c15132551d45c937ed5b0caf07

Una vez descifrada la cookie la transferimos al equipo del atacante, donde debemos hacer el proceso inverso:

• Cifrar AES con el SID de la máquina del atacante (+pannetwork)
• Cifrar con DPAPI en el contexto del usuario de la VM del atacante

Además, debemos mantener el nombre PanPUAC_Hash original, ya que el hash identifica al usuario concreto que vamos a suplantar. Posteriormente el equipo de ciberseguridad también se dio cuenta de que es necesario extraer ciertas claves de registro que identifican al usuario y al entorno VPN.

Para ello utilizaremos otro BOF ejecutado en el equipo de la víctima:

Con todos los datos y valores necesarios, el equipo investigador observó como en su equipo atacante se inició una conexión a través del flujo “GlobalProtect” por lo que parecía ir todo por el buen camino. Sin embargo, uno de los datos que se enviaban en la petición HTTP era el parámetro host-id que parecía validar las cookies a un determinado equipo y no permitía la conexión.

En este escenario en concreto, era suficiente con eliminar el parámetro host-id para realizar una conexión completa.

Consiguiendo nuevamente una conexión VPN desde un equipo atacante.

Varios meses después de la investigación realizada por KPMG, el investigador de seguridad rotarydrone realizó una publicación similar https://github.com/rotarydrone/GlobalUnProtect pero con ligeras diferencias entre los archivos necesarios para poder realizar el ataque.

4. Conclusión

A lo largo de este análisis, hemos podido apreciar como la autenticación basada únicamente en certificados digitales puede no ser suficiente para garantizar la seguridad en el acceso a la red corporativa. Además, nuevas investigaciones han demostrado que incluso un doble factor externo y políticas de acceso condicional pueden ser evadidas a través del robo de las cookies de sesión.

Por todo ello es importante realizar una gestión segura de sesiones, así como un monitoreo continuo y auditorías periódicas de seguridad para validar los sistemas ante los ataques más avanzados.