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.
Pour forger un renvoi S4U2Self, seule la clé de confiance est requise. En utilisant l'argument /targetdomain:X avec l'indicateur /self et sans l'argument /targetdc, le ticket fourni avec /ticket:X sera traité comme un renvoi S4U2Self et seul le ticket de service S4U2Self final sera demandé. L'argument /altservice:X peut également être utilisé pour réécrire le sname dans le ticket résultant.
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]
L'action ptt soumet un /ticket:X (TGT ou ticket de service) pour la session d'ouverture de session actuelle via l'API LsaCallAuthenticationPackage() avec un message KERB_SUBMIT_TKT_REQUEST, ou (si élevé) vers la session d'ouverture de session spécifiée par /luid:ea4... Comme pour les autres paramètres /ticket:X, la valeur peut être un encodage base64 d'un fichier .kirbi.
krb_ptt /ticket:BASE64 [/luid:LOGONID]
L'action purge purge tous les tickets Kerberos de la session d'ouverture de session actuelle, ou (si élevé) vers la session d'ouverture de session spécifiée par /luid:0xA...
krb_purge [/luid:LOGONID]
L'action describe prend une valeur /ticket:X (TGT ou ticket de service), l'analyse et décrit les valeurs du ticket. Comme pour les autres paramètres /ticket:X, la valeur peut être un encodage base64 d'un fichier .kirbi.
krb_describe /ticket:BASE64
klist liste les informations détaillées sur la session d'ouverture de session de l'utilisateur actuel et les tickets Kerberos, si non élevé. Si exécuté dans un contexte élevé (SYSTEM), les informations sur toutes les sessions d'ouverture de session et les tickets Kerberos associés sont affichées. Les informations de session et de ticket peuvent être affichées pour un LogonID spécifique avec /luid:3ea.. (si élevé).
krb_klist [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
L'action dump extrait les TGT et tickets de service actuels si dans un contexte élevé (SYSTEM). Si non élevé, les tickets de service pour l'utilisateur actuel sont extraits.
krb_dump [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
L'action triage affiche un tableau des tickets Kerberos de l'utilisateur actuel, si non élevé. Si exécuté dans un contexte élevé (SYSTEM), un tableau décrivant tous les tickets Kerberos sur le système est affiché.
krb_triage [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
Pour klist, triage et dump, les tickets peuvent être filtrés par /luid, /service et /client.
Contexte SYSTEM requis.
tgtdeleg abuse de l'API GSS-API Kerberos pour récupérer un TGT utilisable pour l'utilisateur actuel sans nécessiter d'élévation sur l'hôte. AcquireCredentialsHandle() est utilisé pour obtenir un handle vers les justificatifs de sécurité Kerberos de l'utilisateur actuel, et InitializeSecurityContext() avec l'indicateur ISC_REQ_DELEGATE et un SPN cible de CIFS/DC.domaine.com pour préparer un contexte de délégation factice à envoyer au DC. Cela produit un AP-REQ dans la sortie GSS-API qui contient un KRB_CRED dans la somme de contrôle de l'authentifiant. La clé de session du ticket de service est extraite du cache Kerberos local et est utilisée pour déchiffrer le KRB_CRED dans l'authentifiant, résultant en un TGT .kirbi utilisable.
Si l'extraction automatique de la cible/du domaine échoue, un SPN connu d'un service configuré avec une délégation non contrainte peut être spécifié avec /target:SPN.
krb_tgtdeleg [/target:SPN]
kerberoasting est utilisé pour demander le ticket de service approprié. L'argument /ticket:X spécifie le ticket TGT de l'utilisateur du domaine. L'argument /spn:X spécifie le SPN cible. Les arguments /domain et /dc sont facultatifs et récupèrent les valeurs par défaut du système comme les autres actions.
L'argument /nopreauth:USER tentera d'envoyer un AS-REQ avec le service passé à /spn:Y pour demander des tickets de service.
krb_kerberoasting /spn:SPN [/nopreauth:USER] [/dc:DC] [/domain:DOMAIN]
krb_kerberoasting /spn:SPN /ticket:BASE64 [/dc:DC]
Si un utilisateur du domaine n'a pas la pré-authentification Kerberos activée, un AS-REP peut être demandé avec succès pour l'utilisateur, et un composant de la structure peut être cracké hors ligne à la manière du kerberoasting. L'argument /user:X spécifie l'utilisateur cible. Les arguments /domain et /dc sont facultatifs, en tirant les valeurs par défaut du système comme les autres actions.
krb_asreproasting /user:USER [/dc:DC] [/domain:DOMAIN]
L'action hash prend un /password:X et optionnellement /user:USER et/ou /domain:DOMAIN. Elle génère la représentation rc4_hmac (NTLM) du mot de passe. Si les noms d'utilisateur et de domaine sont spécifiés, les formes de hash aes128_cts_hmac_sha1 et aes256_cts_hmac_sha1 sont générées. Les noms d'utilisateur et de domaine sont utilisés comme sels pour les implémentations AES.
krb_hash /password:PASSWORD [/user:USER] [/domain:DOMAIN]
L'action changepw prend un blob .kirbi de TGT d'utilisateur et exécute un changement de mot de passe MS kpasswd avec la valeur /new:PASSWORD spécifiée. 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 réinitialisation de mot de passe.
Les arguments /targetuser et /targetdomain peuvent être utilisés pour changer le mot de passe d'autres utilisateurs, à condition que l'utilisateur dont le TGT est utilisé dispose de privilèges suffisants.
Notez qu'un TGT d'utilisateur ou un ticket de service pour kadmin/changepw peut être utilisé pour changer le mot de passe
krb_changepw /ticket:BASE64 /new:PASSWORD [/dc:DC] [/targetuser:USER] [/targetdomain:DOMAIN]
asktgt /cert:...describe