Magic Quadrant™ para la gestión de acceso privilegiado 2025: Netwrix reconocida por cuarto año consecutivo. Descarga el informe.

Plataforma
Centro de recursosBlog
Compromiso total del dominio con un ataque de Golden Ticket

Compromiso total del dominio con un ataque de Golden Ticket

Aug 31, 2022

Esta serie de blog post series cubre técnicas que los atacantes pueden usar para encontrar y comprometer cuentas de servicio de Active Directory. Primero, detallamos cómo pueden descubrir cuentas de servicio con LDAP reconnaissance; luego revelamos cómo pueden extraer contraseñas de cuentas con Kerberoasting; y luego explicamos cómo elevar los derechos de una cuenta utilizando Silver Tickets para habilitar acceso y actividades adicionales.

En esta publicación final, exploramos la cuenta de servicio más poderosa en cualquier entorno de Active Directory: la cuenta KRBTGT, que se utiliza para emitir los tickets de Kerberos necesarios para acceder a los sistemas de TI y datos. Al obtener el hash de la contraseña de esta cuenta desde el Key Distribution Center (KDC), un atacante puede comprometer todas las cuentas en Active Directory, otorgándoles acceso ilimitado y prácticamente indetectable a cualquier sistema conectado a la red de AD.

¿Qué es la cuenta KRBTGT en AD?

Image

Los controladores de dominio de Active Directory son responsables de manejar las solicitudes de tickets de Kerberos, que se utilizan para autenticar a los usuarios y otorgarles acceso a computadoras y aplicaciones. La contraseña de la cuenta KRBTGT se utiliza para cifrar y descifrar los tickets de Kerberos. Esta contraseña rara vez cambia y el nombre de la cuenta es el mismo en cada dominio, por lo que es un objetivo común para los atacantes.

Creando Golden Tickets

Usando Mimikatz, es posible aprovechar la contraseña de la cuenta KRBTGT para crear Tickets de Concesión de Tickets (TGTs) de Kerberos falsificados que pueden ser utilizados para solicitar tickets de Servidor de Concesión de Tickets (TGS) para cualquier servicio en cualquier computadora del dominio.

Para crear Golden Tickets, un adversario necesita la siguiente información:

  • Hash de la contraseña de la cuenta KRBTGT
  • El nombre y SID del dominio al que pertenece la cuenta KRBTGT

Veamos cómo recopilar esta información y crear Golden Tickets para Kerberos, paso a paso.

Paso 1. Obtenga el hash de la contraseña KRBTGT y el nombre de dominio y SID.

Obtener el hash de la contraseña KRBTGT es la parte más difícil del ataque porque requiere obtener acceso privilegiado a un controlador de dominio. Una vez que un adversario puede iniciar sesión de manera interactiva o remota en un DC, pueden usar Mimikatz para extraer la información requerida utilizando los siguientes comandos:

      privilege::debug
lsadump::lsa /inject /name:krbtgt
      

Esto mostrará el hash de la contraseña, así como el nombre de dominio y el SID:

Image

Paso 2. Crear Golden Tickets.

Ahora el hacker puede crear Golden Tickets a voluntad. Los parámetros útiles de Mimikatz para crear Golden Tickets incluyen:

  • Usuario— El nombre de la cuenta de usuario para la cual se creará el ticket. Tenga en cuenta que puede ser un nombre de cuenta válido, pero no es necesario que lo sea.
  • ID— El RID de la cuenta que el atacante pretenderá ser. Podría ser una ID de cuenta real, como la ID de administrador predeterminada de 500, o una ID falsa.
  • Grupos— Una lista de grupos a los que pertenecerá la cuenta en el ticket. Domain Admins se incluye por defecto, por lo que el ticket se creará con privilegios máximos.
  • SIDs— Esto insertará un SID en el atributo SIDHistory de la cuenta en el ticket. Esto es útil para autenticar a través de dominios.

El siguiente ejemplo crea un ticket para un usuario falso pero proporciona la ID del administrador predeterminado. Veremos en un momento cómo estos valores entran en juego cuando se utiliza este ticket. El /ptt (Pass the Ticket) inyecta el Golden Ticket que se está creando en la sesión actual.

Image

Paso 3. Pase el ticket.

Ahora es el momento de usar el Golden Ticket que se cargó en la sesión actual. Vamos a lanzar un símbolo del sistema bajo el contexto de ese ticket utilizando el comando misc::cmd .

Image

Puede ver en el símbolo del sistema que el atacante opera como un usuario de dominio regular sin membresía en ningún grupo del dominio, lo que significa que no debería tener derechos sobre ningún otro ordenador del dominio.

Image

Sin embargo, debido a que el ticket de Kerberos está en memoria, es posible conectarse a un controlador de dominio y obtener acceso a todos los archivos almacenados allí.

Image

Usando PSExec, el atacante puede abrir una sesión en el controlador de dominio objetivo; de acuerdo con esa sesión, ahora están registrados como Administrador.

Image

El sistema cree que el atacante es el Administrador debido al RID de 500 que utilizaron para generar el Golden Ticket. Los registros de eventos en el controlador de dominio también muestran que el sistema cree que el atacante es el Administrador, pero las credenciales son las que se falsificaron durante el ataque del Golden Ticket. Esto puede ser particularmente útil para atacantes que buscan evadir la detección o crear registros de seguridad engañosos.

Protección contra ataques de Golden Ticket

Los ataques con Golden Ticket de Active Directory son muy difíciles de detectar porque los Golden Tickets parecen TGTs perfectamente válidos. Sin embargo, en la mayoría de los casos, se crean con una vida útil de 10 años o más, lo que supera con creces los valores predeterminados en Active Directory para la duración del ticket. Aunque las marcas de tiempo de TGT no se registran en los registros de autenticación de Kerberos, las soluciones de seguridad de Active Directory adecuadas son capaces de monitorearlos. Si observa que los Golden Tickets se están utilizando dentro de su organización, debe restablecer la cuenta KRBTGT dos veces; hacerlo puede tener consecuencias de gran alcance, así que proceda con precaución.

La protección más importante contra los Golden Tickets es restringir los derechos de inicio de sesión en los controladores de dominio. Debe haber el mínimo absoluto de Administradores de Dominio, así como miembros de otros grupos que proporcionan derechos de inicio de sesión en los DC, como Operadores de Impresión y Servidores. Además, se debe utilizar un protocolo de inicio de sesión por niveles para evitar que los Administradores de Dominio inicien sesión en servidores y estaciones de trabajo donde se pueden volcar sus hashes de contraseña de la memoria y usarse para acceder a un DC para extraer el hash de la cuenta KRBTGT.

Compartir en

Aprende más

Acerca del autor

Un hombre con una chaqueta azul y camisa a cuadros sonre para la cmara

Jeff Warren

Director de Producto

Jeff Warren supervisa el portafolio de productos de Netwrix, aportando más de una década de experiencia en gestión y desarrollo de productos enfocados en la seguridad. Antes de unirse a Netwrix, Jeff lideró la organización de productos en Stealthbits Technologies, donde utilizó su experiencia como ingeniero de software para desarrollar soluciones de seguridad innovadoras y escalables para empresas. Con un enfoque práctico y un talento para resolver desafíos de seguridad complejos, Jeff se centra en construir soluciones prácticas que funcionen. Tiene un BS en Sistemas de Información de la Universidad de Delaware.