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.
krb_s4u /ticket:BASE64 /service:SPN {/impersonateuser:USER | /tgs:BASE64} [/domain:DOMAIN] [/dc:DC] [/altservice:SERVICE] [/ptt] [/nopac] [/opsec] [/self]
krb_cross_s4u /ticket:BASE64 /service:SPN /targetdomain:DOMAIN /targetdc:DC {/impersonateuser:USER | /tgs:BASE64} [/domain:DOMAIN] [/dc:DC] [/altservice:SERVICE] [/nopac] [/self]
La acción ptt enviará un /ticket:X (TGT o ticket de servicio) para la sesión de inicio de sesión actual a través de la API LsaCallAuthenticationPackage() con un mensaje KERB_SUBMIT_TKT_REQUEST, o (si está elevado) a la sesión de inicio de sesión especificada por /luid:ea4... Al igual que otros parámetros /ticket:X, el valor puede ser una codificación base64 de un archivo .kirbi.
krb_ptt /ticket:BASE64 [/luid:LOGONID]
La acción purge eliminará todos los tickets Kerberos de la sesión de inicio de sesión actual, o (si está elevado) de la sesión de inicio de sesión especificada por /luid:0xA...
krb_purge [/luid:LOGONID]
La acción describe toma un valor /ticket:X (TGT o ticket de servicio), lo analiza y describe los valores del ticket. Al igual que otros parámetros /ticket:X, el valor puede ser una codificación base64 de un archivo .kirbi.
krb_describe /ticket:BASE64
klist mostrará información detallada sobre la sesión de inicio de sesión y los tickets Kerberos del usuario actual, si no está elevado. Si se ejecuta desde un contexto elevado (SYSTEM), se muestra información sobre todas las sesiones de inicio de sesión y los tickets Kerberos asociados. La información de inicio de sesión y tickets se puede mostrar para un LogonID específico con /luid:3ea.. (si está elevado).
krb_klist [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
La acción dump extraerá los TGT y tickets de servicio actuales si está en un contexto elevado (SYSTEM). Si no está elevado, se extraen los tickets de servicio del usuario actual.
krb_dump [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
La acción triage generará una tabla de los tickets Kerberos del usuario actual, si no está elevado. Si se ejecuta desde un contexto elevado (SYSTEM), se muestra una tabla que describe todos los tickets Kerberos en el sistema.
krb_triage [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
Para klist, triage y dump, los tickets se pueden filtrar por /luid, /service y /client.
Se necesita contexto SYSTEM.
tgtdeleg abusa de la API GSS-API de Kerberos para obtener un TGT utilizable para el usuario actual sin necesidad de elevación en el host. Se utiliza AcquireCredentialsHandle() para obtener un identificador de las credenciales de seguridad Kerberos del usuario actual, y InitializeSecurityContext() con la bandera ISC_REQ_DELEGATE y un SPN objetivo de CIFS/DC.domain.com para preparar un contexto delegado falso para enviar al DC. Esto resulta en un AP-REQ en la salida de GSS-API que contiene un KRB_CRED en el checksum del autenticador. La clave de sesión del ticket de servicio se extrae de la caché Kerberos local y se usa para descifrar el KRB_CRED en el autenticador, resultando en un TGT .kirbi utilizable.
Si falla la extracción automática de objetivo/dominio, se puede especificar un SPN conocido de un servicio configurado con delegación sin restricciones con /target:SPN.
krb_tgtdeleg [/target:SPN]
kerberoasting se utiliza para solicitar el ticket de servicio apropiado. El argumento /ticket:X especifica el ticket TGT del usuario del dominio. El argumento /spn:X especifica el SPN objetivo. Los argumentos /domain y /dc son opcionales y recuperan los valores predeterminados del sistema como las otras acciones.
El argumento /nopreauth:USER intentará enviar un AS-REQ con el servicio pasado a /spn:Y para solicitar tickets de servicio.
krb_kerberoasting /spn:SPN [/nopreauth:USER] [/dc:DC] [/domain:DOMAIN]
krb_kerberoasting /spn:SPN /ticket:BASE64 [/dc:DC]
Si un usuario del dominio no tiene la preautenticación Kerberos habilitada, se puede solicitar con éxito un AS-REP para el usuario, y un componente de la estructura puede ser descifrado sin conexión al estilo kerberoasting. El argumento /user:X especifica el usuario objetivo. Los argumentos /domain y /dc son opcionales, obteniendo los valores predeterminados del sistema como otras acciones.
krb_asreproasting /user:USER [/dc:DC] [/domain:DOMAIN]
La acción hash tomará un /password:X y opcionalmente /user:USER y/o /domain:DOMAIN. Generará la representación rc4_hmac (NTLM) de la contraseña. Si se especifican el usuario y el dominio, se generan las formas hash aes128_cts_hmac_sha1 y aes256_cts_hmac_sha1. Los nombres de usuario y dominio se utilizan como sales para las implementaciones AES.
krb_hash /password:PASSWORD [/user:USER] [/domain:DOMAIN]
La acción changepw tomará el blob .kirbi TGT de un usuario y ejecutará un cambio de contraseña MS kpasswd con el valor /new:PASSWORD especificado. 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 restablecimiento de contraseña.
Los argumentos /targetuser y /targetdomain se pueden usar para cambiar la contraseña de otros usuarios, siempre que el usuario cuyo TGT se usa tenga suficientes privilegios.
Tenga en cuenta que se puede usar tanto un TGT de usuario como un ticket de servicio para kadmin/changepw para cambiar la contraseña
krb_changepw /ticket:BASE64 /new:PASSWORD [/dc:DC] [/targetuser:USER] [/targetdomain:DOMAIN]
asktgt /cert:...describe