Lanzamiento de kekeo 2.2.0 20200718: una pequeña caja de herramientas para jugar con Microsoft Kerberos

kekeo

Kekeo es una pequeña caja de herramientas que he comenzado a manipular Microsoft Kerberos en C (y por diversión)

Registro de cambios 2.2.0 20200718

• [nuevo] servidor básico :: http para obtener el ticket Kerberos de las delegaciones

• [mejora] tgt :: ahora admite certificados de autenticación con claves privadas CNG

kekeo incluye

1. Kirbikator  es una pequeña herramienta para convertir tickets Kerberos de diferentes formatos a otro.
   Se puede usar para inyectarlos en Windows LSA sin  mimikatz. Se usa principalmente para convertir  Golden Tickets u otros boletos Kerberos de Windows, en un formato nativo en Linux.Uso kirbikator {formato} ticket1 ticket2 ... Donde {format}  es el formato de destino, este debe ser uno de:
   • ccache: caché de credenciales MIT: un  ticket por archivo
   • ccaches - MIT Credential Cache - todos los tickets en un archivo único
   • kirbi - RFC KRB-CRED (# 22) - un  ticket por archivo
   • kirbis - RFC KRB-CRED (# 22) - todos los  tickets en un archivo único
   • lsa - API de Microsoft LSA - Pase el ticket para todos los tickets

   ticket1 ticket2 ...  puede estar en MIT Credential Cache o en formato RFC KRB-CRED (# 22)

   Observaciones

   • ccache & ccaches están diseñados para MIT Kerberos o Heimdal Kerberos (Linux, Unix, Mac o Windows con una pila Kerberos particular)
   • Kirbi está diseñado para usarse con mimikatz (Windows NT6 o> versión)
   • Kirbis no se puede usar como lo es con mimikatz, pero es útil para almacenar múltiples tickets
   • lsa solo está disponible con Windows NT6 o> versión
2. MS14-068 es una vulnerabilidad de Windows en el servicio del Centro de distribución de claves (KDC). Permite que un usuario autenticado inserte un PAC arbitrario (una estructura que representa todos los derechos del usuario) en su ticket Kerberos (el TGT).
   

   https://technet.microsoft.com/library/security/ms14-068.aspx

   En los dominios de Windows, permite la escalada de privilegios (generalmente de usuario estándar a administrador de dominio / empresa)

   Técnico

   La vulnerabilidad se encuentra en el Centro de distribución de claves (KDC - kdcsvc.dll) de los controladores de dominio. Un usuario puede obtener tickets presentando un Kerberos TGT con un PAC alterado.
   Normalmente, el servicio KDC detecta una alteración de PAC verificando su firma (cada KDC conoce la clave simétrica secreta para verificarla)

   La vulnerabilidad: el servicio KDC permite el uso de algoritmos sin claves (como MD4, MD5, SHA1 o CRC32). Significa que cualquier usuario puede falsificar un PAC sin conocer ninguna clave secreta y solicitar al KDC que lo incluya en un ticket.

   Flujo de trabajo

   1. (AS-REQ) El usuario se autentica en un KDC y solicita un TGT sin un PAC.
   2. (PAC TIME) El usuario crea un PAC con datos arbitrarios y lo sella con un algoritmo sin claves (aquí, MD5).
   3. (TGS-REQ) Desde su TGT, un usuario le pide a un TGS el servicio krbtgt (tipo TGT) con su PAC falso incluido.
   4. (TGS-REQ) Desde su TGS, un usuario le pide a otro TGS el servicio krbtgt (similar a TGT):  si es vulnerable, KDC realmente firmará PAC falso aquí.
   5. (KRB-CRED) Desde el TGS final, el boleto se convierte como estructura KRB-CRED (para guardar en disco o inyectar en LSA)

   El paso 4. parece ser opcional, pero es necesario usar un TGT con un PAC bien firmado con un controlador de dominio no vulnerable (equilibrio de carga).

   Argumentos

   Estándar

   • / domain: el nombre de dominio completo del destino (por ejemplo, lab.local)
   • / user: el nombre de usuario que desea usar como usuario autenticado (cualquier cuenta que tenga permiso para iniciar sesión está bien, por ejemplo: utilisateur)

   Entonces puedes elegir entre:

   • / contraseña: la contraseña de la cuenta del usuario
   • / clave: la clave derivada de la cuenta del usuario, puede ser RC4_HMAC_NT (NTLM), AES128_CTS_HMAC_SHA1_96 o AES256_CTS_HMAC_SHA1_96

   De manera predeterminada, / clave y / contraseña se utilizarán con el algoritmo RC4_HMAC_NT, pero puede especificar / aes128 (AES128_CTS_HMAC_SHA1_96) o / aes256 (AES256_CTS_HMAC_SHA1_96)

   El uso final es entre:

   • / ticket - opcional - nombre de archivo utilizado para escribir un ticket (s) en el disco - el valor predeterminado es: tgt.kirbi
   • / ptt - opcional - Pase el boleto: no se escribirá ningún boleto, el primer boleto válido se inyecta en LSA (se necesita NT6)

   Recuperado automáticamente

   Si no se proporciona, RPC / CLDAP puede recuperar estos argumentos de forma remota, en este caso: / contraseña es obligatoria y / clave no está permitida.

   • / sid - opcional  - el SID del  dominio (por ejemplo: S-1-5-21-1644491937-412668190-839522115 )
   • / rid - opcional  - la ID relativa del  usuario (ej: 1105)
   • / kdc - opcional - el DC que desea usar para todas las consultas (ej .:  dc.lab.local ), si no se proporciona, el programa seleccionará una automáticamente, luego:
     • probar  todos los  KDC en el dominio
     • al guardar el ticket en el archivo: guarde cada ticket exitoso en archivos separados, nombrados como % dcshortname%.% filename% .kirbi
     • Cuando pase el boleto : inyecte el primer boleto exitoso en LSA y luego rompa el ciclo
     • imprima un pequeño informe al final con el número de servidores vulnerables frente al total.

   Afinación

   • / groups - opcional - identificación de familiares de grupos a los que pertenecerá el usuario (primero es el grupo primario, separador de coma) - el valor predeterminado es: 513,512,520,518,519 para los grupos de administradores conocidos.
   • / sids - opcional  - SID externo (externo al dominio) para agregar.
     • un SID interesante es S-1-5-21-root forest-519 (Administradores de empresa)
3. PKINIT Mustiness  es lo opuesto a  PKINIT Freshness  ( https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-freshness ). Abusa de la forma en que Kerberos autentica a los usuarios con tarjeta inteligente / token, al generar  AS-REQdesafíos para usos futuros ... sin necesidad de acceso al secreto de usuario en este futuro para descifrar  AS-REP .TécnicoAutenticación de contraseña / clave (la clásica)
   1. El cliente obtiene su clave simétrica (derivada de su contraseña o no), generalmente, RC4 / AES128 / AES256, puede ser DES u otro
   2. El cliente crea una marca de tiempo en PA-ENC-TS-ENC
   3. El cliente cifra la   estructura PA-ENC-TS-ENC en un  PA_ENC_TIMESTAMP , con su clave simétrica
   4. El cliente envía un  AS-REQ  con este  PA-DATA  (contiene el  PA_ENC_TIMESTAMP ) al  AS , como prueba del conocimiento de su secreto.
   5. El AS (KDC en un controlador de dominio en un mundo de Windows) conoce la clave simétrica del usuario y puede descifrar la marca de tiempo
   6. El AS encripta una parte secreta del   ticket TGT (EncKDCRepPart) con la clave simétrica del cliente
   7. El cliente obtiene la clave de sesión de TGT descifrando la parte secreta de la  TGT clave simétrica
   8. El cliente usa el ticket TGT.

   Aquí, el cliente necesita usar su clave simétrica secreta dos veces: 3. y 7.

Descargar

Fuente:  https://github.com/gentilkiwi/

Siguenos en

https://twitter.com/HackingTeam1

Telegram

@hackingteamelrinconoscuro

Youtube

https://www.youtube.com/channel/UC7NpQbpv7BzwZwb9tpVURiA