En 2014, el investigador Tim Medin, un instructor senior de SANS y desarrollador de contenido, tomó por sorpresa al entorno Infosec cuando reveló Kerberoast.
Esta implementación múltiple o proceso de hash de credenciales de fuerza bruta dentro del ecosistema de Windows Active Directory pronto se convertiría en el vector de ataque de facto contra el protocolo Kerberos, aprovechando ciertos mecanismos de autenticación y encriptación explotables de la popular tecnología nacida del MIT mientras involucraba al gigante de Redmond en una cascada de amenazas existenciales en los años venideros.
Debido a esto, se necesitaría el esfuerzo de toda la comunidad de ciberseguridad para luego llegar a un arreglo adecuado de oportunidades de detección y mitigación.
A pesar de lo generalizado que era, Kerberoast en realidad encarnaba solo un puñado de principios operativos que permitían a los usuarios de dominio sin privilegios tener en sus manos las llamadas cuentas de servicio, una propuesta atractiva que generalmente obtenía un resultado favorable en el caso de las cuentas de servicio. No hace falta decir que el formalismo conocido como Kerberoasting se acusó rápidamente de ser un accesorio para un número creciente de escenarios posteriores a la explotación que plagaron a las empresas modernas de todo el mundo.
En esta publicación de blog, exploraremos el asunto Kerberoasting a la luz de sus características más destacadas; sumergirse rápidamente en algunos de sus toques más creativos y periodizar ideas importantes en lo que respecta a la escalada de privilegios y los aspectos de movimiento lateral de la cadena de muerte cibernética, así como a su contribución a la lista cada vez mayor de amenazas de red.
Comenzaremos nuestro viaje revisando Kerberos, examinando sus trampas y entrando en detalles sobre por qué el antiguo aparato criptográfico expuso vulnerabilidades críticas que llevaron a la extracción de datos tan sensibles con tan poco esfuerzo relativo.
Vamos a empezar.
Indice
Revisión de Kerberos
Los sistemas de computación distribuida a finales de los 80 presentaban desafíos únicos en el contexto de autenticación en el que se requería que una entidad de punto final demostrara su confiabilidad a otra, preferiblemente mediante un inicio de sesión único que pudiera aprovechar una infraestructura de administración centralizada de acuerdo con la tecnología.
En este contexto, Kerberos emergió rápidamente como un protocolo de árbitro entre el cliente y el servidor que aprovechó los tickets criptográficos como el mecanismo de intercambio de autenticación aceptado entre hosts confiables para lograr un acceso controlado a los servicios y aplicaciones.
A lo largo de los años, Kerberos abarcó cinco modelos o versiones diferentes que abarcaban varios subprotocolos agrupados en tres componentes diferentes:
- Un tercero de confianza, también llamado centro de distribución de claves o KDC, con una base de datos de principales (cuentas de usuario y de servicio) y sus correspondientes cuentas compartidas secretas para realizar la autenticación.
- Un cliente, o usuario privilegiado, que negocia la autenticación dentro de un ámbito específico mediante la emisión de una solicitud al servicio de otorgamiento de tickets (TGS) para un ticket especial (TGT o ticket de otorgamiento de tickets) que se utiliza para derivar las credenciales necesarias para obtener acceso a un recurso específico.
- Servicio, o servidor de aplicaciones, que aloja datos o el recurso en cuestión que está solicitando el cliente.
Kerberos se destacó en escenarios entre dominios donde los límites organizacionales requerían autenticación en diferentes segmentos de red. Organizadas de manera jerárquica, estas capacidades entre dominios son la principal fuerza impulsora detrás de Active Directory de Microsoft y la forma en que esta implementación propietaria de Kerberos versión 5 establece el control y la autenticación del usuario.
Esto representó una gran mejora con respecto a los enfoques anteriores basados en NTLM, incluida la adopción de primitivas criptográficas simétricas y «salting» en lugar del hash de contraseñas, o las opciones de funciones de delegación y autenticación mutua antes mencionadas que requieren las aplicaciones de varios niveles. Kerberos también se clasifica como un estándar abierto.
Antes de continuar, resumamos todos los acrónimos pertinentes y terminología similar introducidos hasta ahora, con un puñado de otros adicionales que se discutirán más adelante:
A pesar de sus características sólidas, Kerberos tiene algunas debilidades importantes; dos, para ser precisos:
- Permite la suplantación de identidad del usuario a través del almacenamiento de claves de sesión no seguro.
- Permite a los atacantes obtener fuerza bruta (el «asado» en Kerberoast) Tickets de Kerberos asociados con un cifrado débil vinculado a una higiene deficiente de la contraseña.
Otras fallas menores incluyen preguntas que giran en torno al almacenamiento en caché de claves (y un problema de almacenamiento general), así como ciertas operaciones con límite de tiempo propensas a fallar debido a compensaciones de tiempo entre clientes y servidores.
¿Qué son los ataques de Kerberoasting?
Pero, ¿qué son exactamente los ataques Kerberoasting? Kerberoasting pertenece a la fase posterior a la explotación, o posterior al compromiso, de un ataque que se centra en obtener un mayor acceso a objetivos adicionales mediante la escalada de privilegios y técnicas de movimiento lateral similares.
En un nivel alto, Kerberoasting permite a los atacantes, haciéndose pasar por usuarios de dominio sin privilegios con atributos SPN preestablecidos, solicitar tickets TGS relacionados con el servicio de la memoria en un intento de descifrar los hashes NTLM asociados de las contraseñas de texto sin formato vinculadas a esa cuenta de servicio en particular.
Hay algunos puntos clave para resaltar con respecto a la definición anterior:
- Como se explicó, el ataque no requiere privilegios especiales o derechos administrativos para el dominio; cualquier máquina unida a un dominio lo hará con el propósito de extraer los volcados de credenciales de la cuenta de servicio, sin ninguna interacción con los controladores de dominio o los servicios de directorio.
- El aspecto de la suplantación proviene de una capacidad de delegación ilimitada por parte de ciertas cuentas de computadora para aprovechar otras cuentas para acceder a los recursos en nombre de esos usuarios. Esto frustra el propósito de los límites de confianza al permitir que los servicios fuera de alcance lleguen a través de dominios. Desde entonces, Microsoft ha implementado protecciones adicionales, pero las implementaciones más antiguas aún pueden estar en riesgo.
- La naturaleza del ataque para descifrar contraseñas fuera de línea es una propuesta atractiva, especialmente cuando aún no se ha determinado el alcance de las defensas activas involucradas o cuando se requiere el sigilo y las acciones encubiertas son imprescindibles.
Kerberoasting simplifica enormemente el trabajo pesado frecuente que tiene lugar después de que se ha logrado un punto de apoyo. Esto se reduce a que los malhechores pueden realizar una hazaña notable de hackear el ingenio con relativa facilidad.
Por lo tanto, es un error común ignorar los vectores de ataque anticuados, como Kerberoasting, con la mentalidad de que las deficiencias en el diseño y la implementación del protocolo se pueden superar mediante detecciones adecuadas. Por el contrario, Kerberoasting sigue siendo tan relevante como lo era cuando apareció por primera vez; de hecho, está lejos de estar separado de sus días de gloria, un testimonio de su sutil sofisticación y validez.
¿Cómo funcionan?
En el corazón de Kerberoasting se encuentra el soporte heredado de Microsoft para una forma de cifrado Kerberos que admite RC4, un cifrado de flujo que se debilita constantemente y es altamente sensible a los sesgos estadísticos que reduce significativamente la fuerza del algoritmo hash de contraseñas utilizado para proteger a los principales en el ecosistema de Active Directory.
Las mejores prácticas criptográficas que sugieren el uso de una «sal» como entrada adicional a la función hash también están ausentes de ciertas funciones de cifrado RC4. Esto permite a los atacantes construir tablas de arco iris más pequeñas que disminuyen los esfuerzos computacionales necesarios para abrir RC4.
¿Cómo se aplica todo esto a Kerberoasting? Bueno, en lo que respecta a la intención, comprometer el dominio de Active Directory comienza cuando el atacante escanea el entorno en busca de cuentas de dominio cuyos valores de SPN indiquen cualquier asociación relacionada con el servicio.
Con esta información en la mano, el siguiente paso es solicitar tickets de servicio TGS para cualquier SPN de alto privilegio utilizando su TGT de prueba de identidad mientras se enfoca en SPN específicamente vinculados a cuentas de usuario de dominio y no basados en host.
Extracción de contraseñas de cuentas de servicio
Las cuentas de servicio son cuentas no humanas que se utilizan para ejecutar servicios o aplicaciones. Las cuentas de servicio a menudo tienen privilegios elevados, sus contraseñas rara vez se cambian y los equipos de seguridad rara vez las supervisan. Esto permite a los piratas informáticos aprovechar una cuenta de servicio comprometida durante un período de tiempo prolongado, lo que los convierte en un objetivo atractivo.
Cada instancia de servicio tiene un identificador único llamado Nombre principal del servicio (SPN), que también incluye información sobre para qué se usa la cuenta y su ubicación. Cualquier usuario autenticado puede iniciar sesión en un dominio de Active Directory y enviar una solicitud de un ticket de servicio de concesión de tickets (TGS) para cualquier cuenta de servicio especificando su valor de SPN.
Luego, pueden extraer el hash de la contraseña de la cuenta de servicio e intentar un ataque de fuerza bruta para obtener la contraseña de texto sin formato, con poco riesgo de ser detectados o bloqueados de su cuenta.
Cómo prevenir la extracción de cuentas de servicio
En primer lugar, necesitas saber exactamente qué cuentas de servicio tienes. Deberás crear un inventario de estas cuentas e incluir información sobre por qué existen las cuentas, quién tiene acceso a ellas y a qué servicios y aplicaciones pueden acceder.
También debes incluir documentación sobre cuándo deben revisarse, desactivarse o eliminarse. Deberás asegurarte de que a las cuentas de servicio se les otorguen los privilegios mínimos que necesitan para desempeñar su función. Como siempre, deberás asegurarte de que se cambien las contraseñas predeterminadas de la cuenta de servicio.
Como se mencionó anteriormente, una de las principales razones por las que las cuentas de servicio son un objetivo atractivo para los piratas informáticos es porque sus contraseñas tienden a no cambiar. Por ello, debes utilizar una solución de administración de contraseñas automatizada para asegurarte de que las contraseñas se roten periódicamente.
Para minimizar el daño que podría causar una cuenta de servicio comprometida, debes asegurarte de que se utilicen cuentas separadas para diferentes servicios y usuarios. Asimismo, debes evitar utilizar la misma contraseña para varias cuentas de servicio. Cuando ya no se necesita una cuenta de servicio, debe darse de baja lo antes posible.
Para ayudar con esto, hay herramientas disponibles que pueden detectar y administrar automáticamente las cuentas de servicio inactivas.
Por último, asegúrate de supervisar las cuentas de servicio en busca de actividad sospechosa mediante el uso de una sofisticada solución de auditoría en tiempo real que utiliza el aprendizaje automático para detectar y responder a actividades anómalas.
Ataques de Billetes Dorados
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 Lepide Data Security Platform 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.
Conclusión
La narrativa en torno a Kerberoasting es bastante simple: una técnica de piratería que ha resistido la prueba del tiempo por su capacidad para pasar casi desapercibida, aprovechando un enfoque distorsionado en los mecanismos destinados a proteger los mismos datos que Kerberoasting busca obtener de forma encubierta.
Kerberoasting se puede llevar a cabo a través de cualquier número de herramientas y aplicaciones nativas de SO tan comunes como PowerShell, por lo que registrar y monitorizar el uso de estos recursos es imprescindible para que cualquier empresa de ciberdefensa comience a tener una oportunidad en su contra.
En general, si hay algo que Kerberoasting nos enseña, es que lograr la seguridad adecuada es cualquier cosa menos trivial, ya que la autenticación eficaz en los servicios de directorio modernos de hoy en día implica admitir una población compartida de usuarios y servicios dispares, y a menudo muy complejos, a través de múltiples fronteras.
Finalmente, observa más de cerca tus datos de referencia y ajusta tu arsenal de prevención siguiendo cualquiera de las recomendaciones anteriores. Debes saber qué buscar en las herramientas y capacitar a tus socorristas para que lo hagan también mediante el uso de ejercicios del equipo rojo destinados a fortalecer tu postura de seguridad. Será tiempo y esfuerzo bien gastados y las recompensas serán abundantes.