Tickets Kerberos - Golden Ticket

Hoy vamos a hablar sobre una de las diferentes técnicas que solemos llevar a cabo sobre pentest interno

Una vez que un atacante logra comprometer un dominio tras alcanzar privilegios altos, como por ejemplo Domain Admin o Enterprise Admin, es muy difícil para una organización recuperar el control total del bosque y considerarlo 100% limpio.

Los atacantes con este acceso pueden hacer uso de sus altos privilegios para extraer credenciales especiales del dominio y utilizarlas para ganar persistencia, pudiendo volver a obtener accesos como cualquier usuario en cualquier momento. Estas credenciales se modifican raramente o incluso no se modifican nunca, lo que otorga a los atacantes un acceso prácticamente ilimitado.

A lo largo de diferentes publicaciones, vamos a ver algunas de estas técnicas de persistencia, las cuales se basan en el uso de tickets de Kerberos.

GOLDEN TICKET

Un ataque Golden Ticket consiste en la creación de un Ticket Granting Ticket (TGT) legítimo que se hace pasar por cualquier usuario mediante el uso del hash NTLM de la cuenta KRBTGT de Active Directory. Esta técnica es particularmente poderosa, ya que permite el acceso a cualquier servicio o máquina dentro del dominio como el usuario suplantado. Es fundamental recordar que las credenciales de la cuenta KRBTGT nunca se actualizan automáticamente.

Para adquirir el hash NTLM de la cuenta KRBTGT, se pueden emplear varios métodos:

• Se puede extraer de la memoria, realizando un volcado del proceso LSASS (Local Security Authority Subsystem Service) de un Controlador de Dominio.

• También se puede extraer del archivo de servicios de directorio NT (NTDS.dit) ubicado en cualquier Controlador de Dominio.

• O bien se puede obtener tras ejecutar un ataque DCsync, que se puede realizar utilizando herramientas como Mimikatz o el script secretsdump.py de Impacket.

Es importante mencionar que, para realizar estas operaciones, normalmente se requieren privilegios de Domain Admin o un nivel similar de acceso (auth/system). Por esta razón, los Golden Tickets son utilizados para realizar movimientos laterales por el resto del dominio, así como establecer persistencia y no para la escalada de privilegios.

Al igual que en el caso de Silver Ticket, aunque el hash NTLM sirve como un método viable para este propósito, se recomienda la ejecución de este ataque utilizando las claves AES (Advanced Encryption Standard) de Kerberos por razones de seguridad operativa y ser menos detectable.

Impacto

Un Golden Ticket permite acceso ilimitado y persistente a cualquier recurso dentro del dominio hasta que la clave KRBTGT se cambie, lo cual puede ser un proceso complejo y disruptivo.

Explotación

Para este escenario, partimos de la base de un dominio comprometido, donde tenemos credenciales de Domain Admin y hemos logrado realizar la técnica de DCSync, obteniendo así las claves de Kerberos de la cuenta KRBTGT.

Creación del ticket

Para crear el Golden Ticket, podemos hacer uso de la herramienta Rubeus y ejecutar el siguiente comando:

Rubeus.exe golden /aes256: 42a38fe97bcf9c48190e5d77e48faa7d95b7fed838c8910845a86d66d78f188a /user:Eddard.stark /domain:north.sevenkingdoms.local /sid:S-1-5-21-1430251130-2586379517-4083755373 /nowrap

• Aes256: Clave aes256 de la cuenta KRBTGT extraída anteriormente

• User: Usuario a impersonalizar, en este caso un Domain Admin

• Domain: Nombre del dominio

• Sid: SID del dominio

Importar el ticket

Una vez obtenido el ticket, podemos comprobar que no tenemos acceso mediante SMB al Controlador de Dominio.

ls \\winterfell\c$

Para ganar acceso, primero importamos el ticket en nuestra sesión. Podemos hacer uso de Rubeus de nuevo para lograrlo:

Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /domain:NORTH /username:Eddard.stark /password:PassFake /ticket: doIGDDCCBgigAwI[…]tcy5sb2NhbA==

• Program: Comando a ejecutar donde se inyectará el ticket

• Domain: Nombre del dominio

• Username: Usuario del dominio

• Password: Contraseña del usuario. No es necesario conocer la contraseña real del usuario

• Ticket: El ticket creado anteriormente

Una vez importado el ticket, podemos acceder al DC.

ls \\winterfell\c$

Os dejamos ciertos aspectos a tener en cuenta cuando pensamos en la posibilidad de un Golden Ticket.

Credenciales Necesarias

Característica	Golden Ticket
Objetivo	Acceso a todo el dominio
Credenciales Necesarias	Administrador de dominio o KRBTGT
Impacto	Acceso ilimitado en el dominio
Complejidad del ataque	Alta
Contramedidas Clave	Protección de KRBTGT, monitoreo exhaustivo

Y hasta aquí de tickets y no precisamente de feria, nos vemos en la próxima entrega.

Álvaro Temes, Analista de ciberseguridad en Zerolynx.

Mantén tu Directorio Activo de Azure Protegido

Siempre que hablamos de ciberseguridad pensamos en los servidores que tenemos alojados en nuestra empresa y nos preocupamos sobre su exposición al exterior y el impacto que podría tener el compromiso de cualquier recurso de nuestra red. Sin embargo, son ya muchas las empresas que utilizan servicios en la nube o sistemas híbridos para desplegar su infraestructura.

Hoy venimos a hablar de Azure, y cuales son algunos de los puntos de entrada que explotan algunos atacantes para comprometer una organización y también daremos algunas recomendaciones básicas de seguridad.

Vectores de Entrada hacia Azure AD

Aplicaciones Vulnerables + Managed Identities: 

En muchas ocasiones se utiliza Azure para exponer aplicaciones antiguas y añadirles una capa de seguridad, sin embargo, una aplicación con vulnerabilidades no deja de tenerlas por el mero hecho de subirla a la nube. En este caso, cuando se despliega una aplicación en Azure, se le asocia una Managed Identity, es decir, una cuenta de Azure que será utilizada por la aplicación y a la que se le asignarán permisos necesarios para acceder a diferentes recursos como bases de datos o Key Vaults dentro de la organización.

En el caso de que un atacante logre explotar una vulnerabilidad de tipo RCE o SSRF en la aplicación, podría ser capaz de obtener el Access token de la Managed Identity, pudiendo así llegar a impersonar a esta cuenta y utilizarla para acceder a la organización y a sus recursos, siendo además que este tipo de cuentas al no estar pensadas para ser utilizadas por una persona, no cuentan con MFA.

Para intentar reducir las posibilidades de que este vector de entrada sea utilizado, se recomienda lo siguiente:

• Analizar y mitigar vulnerabilidades en las aplicaciones expuestas.

• Limitar al máximo los permisos de las Managed Identities.

• Monitorizar las acciones de las Managed Identities para detectar cualquier acción que difiera de su uso esperado.

Azure Blobs Expuestos: 

Los blobs de Azure son un servicio de almacenamiento de objetos para la plataforma Azure. Es común que los usuarios no restrinjan correctamente los permisos de los blobs que crean, de manera que estos pueden llegar a ser enumerados mediante herramientas como MicroBurst. Por otro lado, también es posible compartir el acceso a estos blobs mediante enlaces. Cuando se comparten recursos con enlaces puede realizarse mediante Share Keys o Shared Access Signature, siendo que ambas opciones pueden permitir que la duración del enlace sea muy elevada o que incluso no caduque nunca, dando así acceso a cualquier atacante que consiga el enlace generado.

A continuación, se exponen algunas recomendaciones para proteger los blobs de la organización:

• Concienciar a los empleados para que no almacenen información sensible en estos recursos y que administren correctamente los permisos.

• Revisar con frecuencia los blobs públicos para asegurarse que ninguno esté público.

• Limitar tiempo de duración de enlaces a blobs.

Ausencia de MFA + Leaks: 

Cuando hablamos de directorio activo on-premise, suele haber una capa de seguridad antes de poder acceder a la organización ya sea acceso físico a la red o mediante VPN. Es por ello por lo que, aunque se produzcan leaks de credenciales, los atacantes deben de conseguir también acceso a la organización. Sin embargo, los servicios de Azure están expuestos en internet, por lo que si un atacante logra comprometer una cuenta de Active Directory, podría ser capaz de acceder al dominio de Azure y enumerarlo por completo pese a no tener acceso a la red interna.

Para reducir las posibilidades de ser atacados mediante este vector se recomienda:

• Investigar de manera continua información expuesta de la organización con el fin de detectar credenciales comprometidas para poder cambiarlas.

• Establecer MFA obligatorio para todas las cuentas.

• Implementar controles en el Conditional Access Policy para restringir el acceso al dominio de Azure solo desde ubicaciones permitidas.

Phishing: 

Los ataques de phishing son una táctica común utilizada por los atacantes para engañar a los usuarios y obtener sus credenciales. Además, se pueden utilizar técnicas como Ilicit Consent Grant Attack, para que en lugar de obtener las credenciales de la víctima, el atacante intente obtener un Access Token del usuario, el cual podría ser utilizado para acceder a recursos del dominio. Los ataques de phishing que utilizan este tipo de técnicas son extremadamente peligrosos, puesto que se utilizan sistemas legítimos de Microsoft para que la víctima delegue sus permisos sobre una aplicación controlada por el atacante y así obtener el Access Token anteriormente mencionado.

Para reducir el impacto se recomienda:

• Concienciar a los empleados ante estas y otras técnicas de phishing para que aprendan a reconocerlas y a evitarlas.

• Limitar lo máximo posible los permisos de los usuarios en el dominio de Azure.

Persistencia mediante invitación de usuarios:

Cuando un atacante consigue acceso a un activo, siempre intenta conseguir persistencia en el objetivo, de esta manera podrá continuar enumerando tras el compromiso inicial. Existen diversas técnicas para establecer persistencia, pero la más sencilla es utilizar la función de invitar usuarios de Azure, ya que por defecto una cuenta de Azure puede invitar usuarios externos. Estos usuarios no tendrán permisos elevados, pero podrían enumerar información del dominio.

Como mitigación se recomienda deshabilitar esta función para que los usuarios no puedan dar acceso de invitado al tenant.

¡Hasta la próxima linces, nos vemos en la nube!

Ignacio Sánchez, Analista de Ciberseguridad en Zerolynx. 

Moniker Link (CVE-2024-21413)

El 13 de febrero de 2024, Microsoft notificó sobre una vulnerabilidad en su aplicación Outlook. A esta vulnerabilidad se la identifico con el CVE-2024-21413, cuya criticidad se catalogó con un 9.8 (crítica). Las versiones afectadas son:

Edición	Versión
Microsoft Office LTSC 2021	Afectado desde la versión 19.0.0
Microsoft 365 Apps for Enterprise	Afectado desde la versión 16.0.1
Microsoft Office 2019	Afectado desde la versión 16.0.1

Esta vulnerabilidad es posible evitando la opción vista protegida (Protected View) de Outlook, una característica que nos limita el acceso de lectura, evitando así que se ejecuten scripts maliciosos como macros en el sistema.

La vulnerabilidad evita los mecanismos de seguridad de Outlook usando un tipo específico de hyperlink llamado Moniker Link, lo que da el nombre a la vulnerabilidad. El atacante puede explotar esta vulnerabilidad enviando un email que contenga el Moniker Link a una víctima. Cuando la víctima hace click en el enlace, envía las credenciales NetNTLMv2 al atacante.  

Dentro de un entorno controlado fue posible replicar la vulnerabilidad paso a paso. El primer paso para comprender la vulnerabilidad es saber que mediante el uso del Moniker Link: file:// en Outlook se puede hacer que la víctima intente acceder a un archivo en una red compartida. Para ello se usa el protocolo SMB el cual necesita las credenciales del usuario, por lo que la Protected View de Outlook bloquea el link. Sin embargo, mediante el uso de carácter “!” se puede evitar esta medida de seguridad de Outlook. El código resultante para poder explotar la vulnerabilidad sería:

Una vez comprendido esto, lo siguiente a realizar es levantar un SMB listener en la máquina del atacante.

Aunado a esto, creamos un archivo, donde vamos a introducir el código del exploit, el cual se puede encontrar fácilmente en github (https://github.com/CMNatic/CVE-2024-21413).

Modificaciones por realizar:

• Modificar el Moniker link en la línea 12 para reflejar la IP de la máquina del atacante

• Cambiar el MAILSERVER de la línea 31 por la IP de la máquina

Una vez se han realizado todos los cambios, se guarda el script y se ejecuta. Cuando el usuario inconsciente hace clic en el hipervínculo, intenta conectarse a un recurso compartido de red inexistente. Como tal, podemos capturar el hash NetNTLMv2 debido que al hacer click se intenta una conexión.

Con esto ya se habría completado la explotación de la vulnerabilidad de Moniker Link exitosamente. 

Para evitar este tipo de ataques, se recomienda:

• No hacer click en emails cuyo origen no conocemos

• Previsualizar los emails antes de hacer click en enlaces sospechosos

¡Y hasta aquí el post por hoy, gracias por el tiempo y hasta la próxima!

Jorge Ezequiel de Francisco, Analista de Ciberseguridad en Zerolynx.

CVE-2023-32784 - KeePass

En el post de hoy venimos a hablar sobre KeePass, un conocido gestor de contraseñas. KeePass Password Safe es un gestor de contraseñas gratuito y de código abierto que sirve para administrar tus contraseñas de manera segura, permitiendo así tener una contraseña para cada servicio sin morir en el intento. El funcionamiento de KeePass se basa en tener una contraseña maestra, la cual debe ser muy robusta y será necesario recordarla, de manera que esta clave nos dará acceso a nuestra base de datos de contraseñas, teniendo en cuenta que podremos generarlas de manera aleatoria y no tendremos necesidad de recordarlas.

Pese a que siempre recomendamos el uso de esta herramienta u otras similares para proteger nuestras contraseñas, a mediados de 2023 surgió la vulnerabilidad CVE-2023-32784, la cual podría causar el compromiso de la contraseña maestra si se cumplen las siguientes condiciones:

• El atacante accede a un equipo con un proceso de KeePass ejecutándose (no es necesario que la sesión de KeePass esté desbloqueada).

• El usuario víctima ha introducido la contraseña maestra manualmente (no copiando y pegando).

Esta vulnerabilidad se debe al uso del cuadro de texto “SecureTextBoxEx” durante el acceso con la contraseña maestra, ya que esta funcionalidad también sirve para recuperar contenido de contraseñas en otras secciones de KeePass.

Para demostrar el funcionamiento de esta vulnerabilidad, se verificarán dos exploits públicos, los cuales permiten el descifrado de la contraseña maestra a excepción del primer carácter. El hecho de que el primer carácter no se almacene, se debe a cómo funciona a nivel de .net la funcionalidad de “SecureTextBoxEx”, ya que enmascara el carácter anterior y muestra el actual, por ejemplo, para la palabra password:

-a, --s, ---s, ----w, -----o, ------r, -------d.

Para este ejercicio, lo primero que haremos será crear una base de datos de pruebas, y le asignaremos la contraseña: sup3r$3cr3tP4ssw0rd!

Tras tener creada nuestra nueva base de datos y haber bloqueado la sesión para “protegerla” es necesario realizar un volcado de la memoria del proceso de KeePass. Es posible realizar volcados de memoria mediante diferentes técnicas, pero para esta prueba de concepto, es suficiente con poder utilizar el administrador de tareas sin ningún tipo de privilegio administrativo.

Una vez que tenemos el volcado de memoria del proceso de KeePass, procederemos a hacer uso de los siguientes exploits:

• https://github.com/vdohney/keepass-password-dumper

• https://github.com/z-jxy/keepass_dump

Como podemos apreciar, ambos exploits nos permiten descifrar la contraseña maestra sin ningún tipo de dificultad, siendo que solo será necesario adivinar el primer carácter de la contraseña.

Esto no significa para nada que debamos desconfiar de los gestores de contraseñas, simplemente como cualquier otra aplicación, son susceptibles de contener vulnerabilidades, por lo que es necesario mantenerlos siempre actualizados para contar con los últimos parches de seguridad. A continuación, ofrecemos una serie de recomendaciones a seguir en caso de haber podido ser afectado por esta vulnerabilidad:

• Actualizar a KeePass 2.54 o superior.

• Cambiar tu contraseña maestra de KeePass por si esta se hubiese visto comprometida.

• Eliminar ficheros que puedan contener contraseñas de KeePass en memoria como los crash dumps (usualmente ubicados en C:\Windows\memory.dmp para windows), el archivo de hibernación (hiberfil.sys) y el archivo de paginación/intercambio (pagefile.sys).

Ignacio Sánchez, Analista de Ciberseguridad en Zerolynx.