27 may 2024

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ísticaGolden Ticket
ObjetivoAcceso a todo el dominio
Credenciales NecesariasAdministrador de dominio o KRBTGT
ImpactoAcceso ilimitado en el dominio
Complejidad del ataqueAlta
Contramedidas ClaveProtecció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.

20 may 2024

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.