ralfhacker/kerbeus-bofBOF para abuso de Kerberos (una implementación de algunas características importantes de Rubeus).
Archivos de Objeto Beacon para abuso de Kerberos. Esta es una implementación de algunas características importantes del proyecto Rubeus, escrita en C. El proyecto incluye integración con los frameworks C2 Cobalt Strike, Havoc, AdaptixC2 y Outflank C2.
La acción asktgt construirá tráfico AS-REQ (solicitud de TGT) sin procesar para el usuario y clave de cifrado especificados (/rc4 o /aes256). También se puede usar una bandera /password en lugar de un hash; en ese caso /enctype:X usará RC4 por defecto. Si no se especifica /domain, se extrae el dominio actual del equipo, y si no se especifica /dc, se hace lo mismo con el controlador de dominio actual del sistema. Si la autenticación es exitosa, el AS-REP resultante se analiza y el KRB-CRED (un .kirbi, que incluye el TGT del usuario) se genera como un blob base64. La bandera /ptt "pasará el ticket" y aplicará la credencial Kerberos resultante a la sesión de inicio de sesión actual. Además, otra nota de opsec: solo se puede aplicar un TGT a la vez a la sesión de inicio de sesión actual, por lo que el TGT anterior se borra cuando se aplica el nuevo ticket usando la opción /ptt.
Para formar AS-REQ más acordes con las solicitudes genuinas, se puede usar la bandera /opsec. Esto enviará primero un AS-REQ sin preautenticación; si tiene éxito, se descifra el AS-REP resultante y se devuelve el TGT; de lo contrario, se envía un AS-REQ con preautenticación.
Solicitar un TGT sin PAC se puede hacer usando el interruptor /nopac. La bandera /nopreauth se puede usar para enviar un AS-REQ sin preautenticación.
krb_asktgt /user:USER /password:PASSWORD [/domain:DOMAIN] [/dc:DC] [/enctype:{rc4|aes256}] [/ptt] [/nopac] [/opsec]
krb_asktgt /user:USER /aes256:HASH [/domain:DOMAIN] [/dc:DC] [/ptt] [/nopac] [/opsec]
krb_asktgt /user:USER /rc4:HASH [/domain:DOMAIN] [/dc:DC] [/ptt] [/nopac]
krb_asktgt /user:USER /nopreauth [/domain:DOMAIN] [/dc:DC] [/ptt]
La acción asktgs construirá/analizará una solicitud de ticket de servicio TGS-REQ/TGS-REP sin procesar usando el TGT especificado /ticket:X. Este valor debe ser una codificación base64 de un archivo .kirbi. Si no se especifica un /dc, se extrae el controlador de dominio actual del equipo y se utiliza como destino para el tráfico de solicitud. La bandera /ptt "pasará el ticket" y aplicará el ticket de servicio resultante a la sesión de inicio de sesión actual. Se debe especificar uno o más /service:X SPN, separados por comas.
Los tipos de cifrado admitidos en el TGS-REQ construido son RC4_HMAC y AES256_CTS_HMAC_SHA1. En este caso, el KDC usará el cifrado mutuo más alto compatible para construir el ticket de servicio devuelto. Si desea forzar claves RC4 o AES256, use /enctype:[rc4 or aes256].
Para formar TGS-REQ más acordes con las solicitudes genuinas, se puede usar la bandera /opsec. Esto también provocará que se envíe automáticamente un TGS-REQ adicional cuando se solicite un ticket de servicio para una cuenta configurada para delegación sin restricciones.
La bandera /u2u se implementó para solicitar tickets Usuario-a-Usuario. Junto con el argumento /tgs:X (utilizado para proporcionar el TGT de la cuenta objetivo), el argumento /service:X puede ser el nombre de usuario de la cuenta para la que se proporciona el TGT (con el argumento /tgs:X). El argumento /targetuser:X solicitará un PAC de cualquier otra cuenta insertando una sección de datos PA-FOR-USER con el nombre de usuario del usuario objetivo.
La bandera /keyList se implementó para Solicitudes de Lista de Claves de Kerberos. Estas solicitudes deben utilizar un TGT parcial falsificado de un controlador de dominio de solo lectura en el parámetro /ticket:BASE64. Además, el campo /spn:x debe establecerse en el SPN de KRBTGT dentro del dominio, p. ej., KRBTBT/domain.local.
krb_asktgs /ticket:BASE64 /service:SPN1,SPN2,... [/domain:DOMAIN] [/dc:DC] [/tgs:BASE64] [/targetdomain:DOMAIN] [/targetuser:USER] [/enctype:{rc4|aes256}] [/ptt] [/keylist] [/u2u] [/opsec]
La acción renew construirá/analizará un intercambio de renovación de TGT TGS-REQ/TGS-REP sin procesar usando el /ticket:X proporcionado. Este valor debe ser una codificación base64 de un archivo .kirbi. Si no se especifica un /dc, se extrae el controlador de dominio actual del equipo y se utiliza como destino para el tráfico de renovación. La bandera /ptt "pasará el ticket" y aplicará la credencial Kerberos resultante a la sesión de inicio de sesión actual.
krb_renew /ticket:BASE64 [/dc:DC] [/ptt]
Si una cuenta de usuario (o equipo) está configurada para delegación restringida (es decir, tiene un valor SPN en su campo msds-allowedtodelegateto), esta acción se puede usar para abusar del acceso al SPN/servidor objetivo.
Una explicación TL;DR es que una cuenta con delegación restringida habilitada puede solicitar tickets para sí misma como cualquier usuario, en un proceso conocido como S4U2self. Para que una cuenta pueda hacer esto, debe tener TrustedToAuthForDelegation habilitado en su propiedad useraccountcontrol, algo que solo los usuarios elevados pueden modificar por defecto. Este ticket tiene la bandera FORWARDABLE establecida por defecto. El servicio puede entonces usar este ticket solicitado especialmente para solicitar un ticket de servicio a cualquier nombre principal de servicio (SPN) especificado en el campo msds-allowedtodelegateto de la cuenta. En resumen, si tiene control de una cuenta con TrustedToAuthForDelegation establecido y un valor en msds-allowedtodelegateto, puede hacerse pasar por cualquier usuario del dominio para los SPN establecidos en el campo msds-allowedtodelegateto de la cuenta.
El ticket S4U2self se puede usar luego como parámetro /tgs:Y (blob base64) para ejecutar el proceso S4U2proxy. Se debe proporcionar un valor válido de msds-allowedtodelegateto para la cuenta (/service:X).
El parámetro /altservice nos permite sustituir cualquier nombre de servicio que queramos en el archivo KRB-CRED resultante. Se pueden proporcionar uno o más nombres de servicio alternativos, separados por comas (/altservice:cifs,HOST,...).
Para formar TGS-REQ más acordes con las solicitudes genuinas, se puede usar la bandera /opsec.
Es posible, en ciertas circunstancias, usar un ticket S4U2Self para suplantar usuarios protegidos con el fin de escalar privilegios en el sistema solicitante, como se discute aquí. Con este propósito, se pueden usar la bandera /self y el argumento /altservice:X para generar un ticket de servicio utilizable.
Para falsificar una referencia S4U2Self, solo se requiere la clave de confianza. Usando el argumento /targetdomain:X con la bandera /self y sin el argumento /targetdc, tratará el ticket proporcionado con /ticket:X como una referencia S4U2Self y solo solicitará el ticket de servicio S4U2Self final. El /altservice:X también se puede usar para reescribir el sname en el ticket resultante.