¿En que consiste un Golden Ticket attack?

Un ataque de Golden Ticket es cuando un adversario puede comprometer una Cuenta de Servicio de Distribución de Claves de Active Directory (KRBTGT) y usarla para crear un Ticket Granting Ticket (TGT) de Kerberos. Si lo hace, les permitirá acceder a cualquier recurso en un dominio de Active Directory sin hacer sonar ninguna alarma, por lo que se conoce como un «Ticket Dorado».
Al igual que con cualquier ataque de Kerberoasting, el atacante primero debe obtener acceso a una cuenta de usuario legítima con privilegios elevados, que tiene acceso a un controlador de dominio (DC). Para hacer esto, el atacante generalmente intentará infectar la computadora de un usuario privilegiado con malware para extraer credenciales, a menudo a través de phishing o explotando alguna otra vulnerabilidad.
Luego, deberán iniciar sesión en el controlador de dominio y usar una aplicación de piratería como Mimikatz para volcar el hash de la contraseña de la cuenta KRBTGT. Luego pueden cargar el token Kerberos en cualquier sesión, lo que les dará acceso a cualquier recurso en la red.

¿Cómo prevenir los ataques de Golden Ticket?

Dado que los Golden Ticket Attacks solo son posibles si el atacante puede obtener acceso a una cuenta de usuario con privilegios elevados, la línea de defensa inicial obvia es asegurarse de que puedas protegerte de los ataques de phishing y otros métodos de infiltración.
Un buen punto de partida sería asegurarte de que todos los miembros del personal estén lo suficientemente capacitados para identificar correos electrónicos sospechosos. Deberán verificar la dirección del remitente, verificar el dominio de los enlaces incrustados antes de hacer clic en ellos, y nunca deben entregar sus credenciales a nadie.
Como siempre, los usuarios deben recibir los privilegios mínimos que necesitan para llevar a cabo adecuadamente su función, y las cuentas de administrador solo deben usarse cuando realizan tareas administrativas.
Como se mencionó, Golden Ticket Attacks confía en Mimikatz para volcar el hash de la contraseña de la cuenta KRBTGT. En resumen, deberás asegurarte de que todos los sistemas operativos se mantengan actualizados y debes deshabilitar el almacenamiento de contraseñas de texto sin formato en Active Directory.
En lugar de depender de que los usuarios entreguen sus credenciales, es posible que el atacante intente abrirse camino mediante la fuerza bruta al intentar repetidamente diferentes contraseñas en una cuenta de usuario privilegiado. Aquí, deberás utilizar una solución de auditoría en tiempo real que sea capaz de responder automáticamente a eventos que coincidan con una condición de umbral predefinida.
Por ejemplo, si se ha detectado un número X de intentos fallidos de inicio de sesión en Y segundos, se puede ejecutar un script personalizado para detener el ataque potencial en seco. Esto puede incluir deshabilitar una cuenta de usuario, detener un proceso específico, cambiar la configuración del firewall o apagar el servidor afectado.
Es una buena idea cambiar la contraseña del usuario de KRBTGT con regularidad. Sin embargo, dado que el Centro de distribución de claves (KDC) utiliza tanto la contraseña actual como la anterior del usuario de KRBTGT para validar los tickets de Kerberos, la contraseña debe cambiarse dos veces, aproximadamente entre 12 y 24 horas para evitar posibles interrupciones del servicio.
Otras señales a las que puedes prestar atención que podrían indicar que un atacante ha obtenido un Billete Dorado incluyen: nombres de usuario que no existen, discrepancias de nombre de usuario y RID, membresías de grupo modificadas, tipos de cifrado más débiles de lo normal y duraciones de tickets que exceden el máximo de dominio.
La mayoría de las amenazas a los datos confidenciales comienzan con Active Directory. El uso de una solución de seguridad y auditoría de Active Directory como puede ayudarte a obtener la visibilidad que necesitas para detectar y responder a estas amenazas antes de que se intensifiquen.

Detectar y mitigar el kerberoasting

Por varias razones, incluida la falta de higiene adecuada de contraseñas y condiciones de dominio descuidadas similares, Kerberoasting sigue siendo increíblemente factible en todo el mundo empresarial, lo que puede dejar a muchos propietarios de sistemas y profesionales de la seguridad boquiabiertos sobre por qué ocurrió el ataque.
Sin embargo, en defensa de todos, el ataque sigue siendo tan difícil de detectar y mitigar como siempre; después de todo, Kerberoasting, como técnica general, estaba profundamente arraigado en el tejido de Kerberos antes de cualquier intento de Microsoft de aceptar cualquiera de sus fallas criptográficas preexistentes. Pero, mientras tanto, sin duda podemos centrar nuestros esfuerzos en algunas, si no en todas, las siguientes recomendaciones:

• La etapa de fuerza bruta , o de descifrado de contraseñas, del ataque puede verse seriamente atenuada al hacer cumplir requisitos sólidos de complejidad de contraseñas en las cuentas de servicio en todo el dominio. Esto incluye el uso de la longitud de contraseña recomendada de 25 caracteres o más, o el uso de cuentas de servicio administradas introducidas por Microsoft en 2012 en un esfuerzo por ayudar con la administración y rotación automática de contraseñas.
• Los atacantes a menudo son quirúrgicos sobre qué sistemas eligen atacar. Ten en cuenta las pertenencias a grupos de tus cuentas de servicio y audita con frecuencia las asignaciones de SPN vinculadas a cuentas de usuarios con altos privilegios. Por ejemplo, ninguna cuenta de miembro de grupos como los administradores de dominio debería tener nunca SPN asignados. Esto limitará el alcance de los sistemas que pueden verse comprometidos aún más en caso de que un atacante se apodere de cuentas con menos privilegios.
• Utiliza Kerberos FAST (Túnel seguro de autenticación flexible), si es posible, para proteger los datos previamente autenticados protegiendo los intercambios del servicio de autenticación (AS) con el KDC a través de un túnel seguro. En caso de que FAST se vuelva difícil de implementar, la delegación restringida basada en recursos se puede utilizar como una forma más segura de delegación para restringir los servicios a los que un servidor determinado puede actuar en nombre de un usuario.
• Aprovecha las políticas de grupo para eliminar el uso de protocolos inseguros como RC4: la prueba de fuego por la cual Kerberoasting se convierte en un vector de ataque decisivo. El uso de conjuntos de cifrado de claves simétricas más fuertes como AES-256 para proteger los TGT contribuirá en gran medida a proteger tu entorno, pero no desactives RC4 en todos los ámbitos hasta que comprendas todas las posibles repercusiones.
• Por último, retira los sistemas heredados (Windows Server 2003 y anteriores) utilizando formas más antiguas de cifrado Kerberos tan pronto como puedas.
• Cuando se trata de oportunidades de detección, ten cuidado con los grandes volúmenes de solicitudes de tickets TGS que se generan en un corto período de tiempo; aunque las transacciones TGS muy frecuentes no son raras, Kerberoasting tiende a lanzar una red amplia que no se oculta tan fácilmente.

La actividad de TGS de base también puede ayudar con los esfuerzos de detección. A tal efecto, examina cuidadosamente los registros de Windows, especialmente si la auditoría de operaciones de tickets de servicio de Kerberos está habilitada, lo que puede conducir a detecciones en torno al uso de RC4 en entornos donde solo se permite AES.
Como siempre, la literatura de detección abunda en materiales complementarios; Sé proactivo en tu enfoque para proteger tu entorno Kerberos y asegúrate de confiar en la comunidad cibernética si necesitas comprensión y apoyo adicionales.

¿Desea conocer una solución avanzada de protección de directorio activo?