ralfhacker/kerbeus-bofBOF pour l'abus de Kerberos (une implémentation de certaines fonctionnalités importantes de Rubeus).
Fichiers objets Beacon pour l'abus Kerberos. Il s'agit d'une implémentation de certaines fonctionnalités importantes du projet Rubeus, écrite en C. Le projet propose une intégration avec les frameworks C2 Cobalt Strike, Havoc, AdaptixC2 et Outflank C2.
L'action asktgt construit un trafic AS-REQ (demande de TGT) brut pour l'utilisateur et la clé de chiffrement spécifiés (/rc4 ou /aes256). Un indicateur /password peut également être utilisé à la place d'un hash - dans ce cas, /enctype:X utilisera RC4 par défaut. Si aucun /domain n'est spécifié, le domaine actuel de l'ordinateur est extrait, et si aucun /dc n'est spécifié, il en va de même pour le contrôleur de domaine actuel du système. Si l'authentification réussit, l'AS-REP résultant est analysé et le KRB-CRED (un fichier .kirbi, qui inclut le TGT de l'utilisateur) est sorti sous forme de blob base64. L'indicateur /ptt effectuera un "pass-the-ticket" et appliquera le justificatif Kerberos résultant à la session d'ouverture de session actuelle. Aussi, une note OPSEC : un seul TGT peut être appliqué à la fois à la session d'ouverture de session actuelle, donc le TGT précédent est effacé lorsque le nouveau ticket est appliqué en utilisant l'option /ptt.
Pour former des AS-REQ plus conformes aux demandes authentiques, l'indicateur /opsec peut être utilisé ; cela enverra d'abord un AS-REQ sans pré-authentification, si cela réussit, l'AS-REP résultant est déchiffré et le TGT est retourné, sinon un AS-REQ avec pré-authentification est ensuite envoyé.
La demande d'un TGT sans PAC peut être effectuée à l'aide du commutateur /nopac. L'indicateur /nopreauth peut être utilisé pour envoyer un AS-REQ sans pré-authentification.
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]
L'action asktgs construit/analyse un échange TGS-REQ/TGS-REP brut de demande de ticket de service en utilisant le TGT spécifié /ticket:X fourni. Cette valeur doit être un encodage base64 d'un fichier .kirbi. Si un /dc n'est pas spécifié, le contrôleur de domaine actuel de l'ordinateur est extrait et utilisé comme destination pour le trafic de la demande. L'indicateur /ptt effectuera un "pass-the-ticket" et appliquera le ticket de service résultant à la session d'ouverture de session actuelle. Un ou plusieurs SPN /service:X doivent être spécifiés, séparés par des virgules.
Les types de chiffrement pris en charge dans le TGS-REQ construit seront RC4_HMAC et AES256_CTS_HMAC_SHA1. Dans ce cas, le plus haut niveau de chiffrement mutuellement pris en charge sera utilisé par le KDC pour construire le ticket de service renvoyé. Si vous souhaitez forcer l'utilisation de clés RC4 ou AES256, utilisez /enctype:[rc4 ou aes256].
Pour former des TGS-REQ plus conformes aux demandes authentiques, l'indicateur /opsec peut être utilisé ; cela entraînera également l'envoi automatique d'un TGS-REQ supplémentaire lorsqu'un ticket de service est demandé pour un compte configuré pour la délégation non contrainte.
L'indicateur /u2u a été implémenté pour demander des tickets User-to-User. Avec l'argument /tgs:X (utilisé pour fournir le TGT du compte cible), l'argument /service:X peut être le nom d'utilisateur du compte auquel le TGT fourni est destiné (avec l'argument /tgs:X). L'argument /targetuser:X demandera un PAC de tout autre compte en insérant une section de données PA-FOR-USER avec le nom d'utilisateur de l'utilisateur cible.
L'indicateur /keyList a été implémenté pour les demandes de liste de clés Kerberos. Ces demandes doivent utiliser un TGT partiel forgé provenant d'un contrôleur de domaine en lecture seule dans le paramètre /ticket:BASE64. De plus, le champ /spn:x doit être défini sur le SPN KRBTGT dans le domaine, par ex. 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]
L'action renew construit/analyse un échange TGS-REQ/TGS-REP brut de renouvellement de TGT en utilisant le /ticket:X fourni. Cette valeur doit être un encodage base64 d'un fichier .kirbi. Si un /dc n'est pas spécifié, le contrôleur de domaine actuel de l'ordinateur est extrait et utilisé comme destination pour le trafic de renouvellement. L'indicateur /ptt effectuera un "pass-the-ticket" et appliquera le justificatif Kerberos résultant à la session d'ouverture de session actuelle.
krb_renew /ticket:BASE64 [/dc:DC] [/ptt]
Si un compte utilisateur (ou ordinateur) est configuré pour la délégation contrainte (c'est-à-dire qu'il possède une valeur SPN dans son champ msds-allowedtodelegateto), cette action peut être utilisée pour abuser de l'accès au SPN/serveur cible.
Une explication TL;DR : un compte avec délégation contrainte activée est autorisé à demander des tickets pour lui-même en tant que n'importe quel utilisateur, dans un processus appelé S4U2self. Pour qu'un compte soit autorisé à le faire, il doit avoir TrustedToAuthForDelegation activé dans sa propriété useraccountcontrol, ce que seuls les utilisateurs élevés peuvent modifier par défaut. Ce ticket possède l'indicateur FORWARDABLE par défaut. Le service peut ensuite utiliser ce ticket spécialement demandé pour demander un ticket de service vers tout nom de principal de service (SPN) spécifié dans le champ msds-allowedtodelegateto du compte. Donc, pour faire court, si vous contrôlez un compte avec TrustedToAuthForDelegation activé et une valeur dans msds-allowedtodelegateto, vous pouvez vous faire passer pour n'importe quel utilisateur du domaine auprès des SPN définis dans le champ msds-allowedtodelegateto du compte.
Le ticket S4U2self peut ensuite être utilisé comme paramètre /tgs:Y (blob base64) pour exécuter le processus S4U2proxy. Une valeur valide msds-allowedtodelegateto pour le compte doit être fournie (/service:X).
Le paramètre /altservice nous permet de substituer n'importe quel nom de service que nous souhaitons dans le fichier KRB-CRED résultant. Un ou plusieurs noms de service alternatifs peuvent être fournis, séparés par des virgules (/altservice:cifs,HOST,...).
Pour former les TGS-REQ plus conformes aux demandes authentiques, l'indicateur /opsec peut être utilisé.
Il est possible, dans certaines circonstances, d'utiliser un ticket S4U2Self pour usurper l'identité d'utilisateurs protégés afin d'élever les privilèges sur le système demandeur, comme discuté ici. À cette fin, l'indicateur /self et l'argument /altservice:X peuvent être utilisés pour générer un ticket de service utilisable.