Impacket : comprendre les outils, auditer Active Directory et détecter les usages à risque

1. Qu’est-ce qu’Impacket ?

Impacket, maintenu par Fortra, est un ensemble de classes Python permettant de manipuler des protocoles réseau. Le projet fournit aussi des programmes d’exemple utilisables en ligne de commande. Parler « d’Impacket » peut donc désigner la bibliothèque intégrée à un logiciel ou l’un de ces programmes. Cette distinction compte lorsqu’un rapport ou une alerte mentionne son nom.

Dans un environnement Windows, SMB sert notamment au partage de fichiers, RPC aux appels de fonctions distantes et Kerberos à l’authentification par tickets. LDAP permet d’interroger un annuaire. Impacket expose plusieurs de ces mécanismes et facilite leur étude. Il ne rend pas automatiquement un compte administrateur : les droits, les politiques et les conditions réseau restent déterminants.

Pour un décideur, l’intérêt est concret : vérifier qu’un compte utilisateur ne peut pas devenir un moyen d’administration transversal. Pour un technicien, c’est un moyen de distinguer un problème de protocole, une permission trop large et une erreur de configuration. Sa présence dans un environnement d’audit peut être légitime ; une exécution inattendue sur un poste métier mérite une investigation.

2. Les protocoles et les identités, expliqués simplement

Authentifier une personne et l’autoriser à agir sont deux décisions différentes. Un mot de passe correct peut ouvrir une session sans permettre de lire un partage particulier. Inversement, une permission mal attribuée peut rendre accessible un fichier sensible sans aucune vulnérabilité logicielle.

Un ticket Kerberos est une preuve d’authentification pour un usage déterminé. Un hash n’est pas un mot de passe lisible, mais certaines empreintes d’authentification peuvent devenir des secrets réutilisables. Évitez donc de les traiter comme de simples chaînes anonymisées dans les rapports ou les tickets de support.

3. Une architecture de laboratoire reproductible

Préparez un contrôleur de domaine de test, un serveur membre avec un partage contenant uniquement des fichiers factices et un poste d’audit. Un compte ordinaire peut lire un seul dossier. Un second compte est volontairement exclu de ce dossier. Cette différence fournit un résultat attendu mesurable : le premier accès doit réussir, le second être refusé.

Documentez les noms des machines, les résolutions DNS, les versions des systèmes, les droits et les règles réseau. Des instantanés facilitent la remise en état du laboratoire, mais leur restauration doit respecter les contraintes propres à l’annuaire. Utilisez les procédures de sauvegarde et restauration adaptées à votre hyperviseur et à vos contrôleurs de domaine.

La matrice d’autorisation d’un audit doit préciser les comptes, les hôtes, les plages horaires et les actions. La lecture d’un annuaire n’autorise pas implicitement l’extraction de secrets ou l’exécution distante. Fixez aussi les critères d’arrêt : instabilité d’un service, verrouillage d’un compte ou sortie du périmètre convenu.

4. Installer proprement et identifier ce qui est exécuté

Partez du dépôt officiel ou d’un paquet fourni par une distribution de confiance. Évitez les archives republiées sans provenance. Un environnement Python isolé réduit les conflits de dépendances ; un conteneur ne dispense pas de limiter ses accès réseau et ses volumes. Consignez une version publiée ou un commit précis, puis conservez le fichier des dépendances de cet environnement.

Sur une distribution qui fournit les lanceurs préfixés impacket-, les commandes suivantes servent à vérifier l’installation et l’aide. Le nom des exécutables varie selon le mode d’installation : les exemples du dépôt peuvent conserver le suffixe .py. Utilisez l’aide du programme réellement installé.

python -m pip show impacket
impacket-smbclient -h
impacket-rpcdump -h

La première commande décrit le paquet du Python sélectionné. Si elle ne trouve rien alors qu’un lanceur fonctionne, vérifiez son interpréteur : il peut provenir d’un autre environnement. Ne corrigez pas ce décalage en installant successivement plusieurs copies à l’aveugle.

Conservez la version avant le test, les options retenues et les éventuelles adaptations. Une capture d’écran indiquant seulement « succès » n’est pas une preuve reproductible. Une mise à jour entre deux mesures peut aussi changer le comportement observé ; elle doit figurer dans le compte rendu.

5. Panorama des outils : comprendre leurs effets

Les sources de psexec et de wmiexec illustrent des chemins techniques différents. Une règle de détection construite uniquement sur un service créé ne couvrira pas toutes les formes d’exécution distante. De même, le nom d’un fichier ne suffit pas à attribuer une activité à un outil précis.

Ce panorama sert à choisir une question de contrôle. « Mon compte de support peut-il administrer un serveur hors de son périmètre ? » est une question utile. « Combien de programmes puis-je lancer ? » ne constitue pas un objectif d’audit. Les opérations sur les secrets ou les identités doivent répondre à une nécessité explicitement définie.

6. Premier scénario : vérifier une lecture SMB autorisée

Supposons que le serveur de laboratoire porte l’adresse 192.168.56.20, que le domaine de test soit LAB et que le compte lecteur dispose d’un accès en lecture au partage AuditLecture. Ces valeurs sont illustratives : une adresse privée peut aussi appartenir à votre réseau réel. Ne les réutilisez qu’après avoir vérifié la cible et son isolement.

impacket-smbclient LAB/lecteur@192.168.56.20

Saisissez le secret de laboratoire à l’invite, sans le placer dans la ligne de commande. Dans la console interactive, consultez d’abord l’aide, puis sélectionnez le partage connu et listez ses fichiers :

help
use AuditLecture
ls
exit

Ces commandes, décrites par le client SMB du projet, visent uniquement la consultation. Ne testez pas l’écriture pour « confirmer » une permission sans avoir prévu cette action. Même une lecture produit potentiellement des journaux et des événements côté serveur.

Résultat attendu : le dossier autorisé est lisible, aucun autre dossier de test non autorisé ne l’est. Rejouez ensuite le cas avec le compte exclu, sans multiplier les mots de passe ou les tentatives. Un refus d’accès est une preuve utile ; il n’est pas un échec de l’audit.

Corrélez l’heure, l’adresse source, le compte et la ressource avec les traces du serveur. Si aucun événement n’apparaît, contrôlez la stratégie d’audit et le transfert des journaux avant de conclure à une absence de visibilité de l’outil.

7. Kerberos, relais NTLM et mouvement latéral : ne pas tout confondre

Le mouvement latéral désigne le passage d’un système à un autre dans un environnement compromis. Il peut utiliser une permission d’administration valide, un secret réutilisé ou une faiblesse de configuration. Il ne nécessite donc pas toujours une nouvelle CVE. Impacket peut servir à vérifier certains de ces chemins dans une mission autorisée.

Le Kerberoasting concerne des tickets de service dont certaines données peuvent être soumises à une recherche hors ligne du secret associé. L’AS-REP roasting repose sur une autre condition, liée à l’absence de préauthentification Kerberos pour certains comptes. Le relais NTLM consiste à transmettre un échange d’authentification vers un autre service dans des conditions particulières. Ces techniques ont des prérequis et des protections distincts.

Pour structurer la défense, rattachez chaque hypothèse à un contrôle : robustesse et gestion des comptes de service, exigences de signature, protections de liaison et d’authentification adaptées au protocole, réduction des droits d’administration, séparation des postes privilégiés. Une mesure efficace pour SMB ne couvre pas automatiquement LDAP ou HTTP.

Le guide Kerberoasting détaille ce premier mécanisme. La série durcissement Active Directory fournit le cadre global. Avec BloodHound CE, on peut représenter les relations de privilèges ; Impacket peut ensuite contribuer à vérifier une hypothèse précise dans les limites de la mission.

8. Détecter des comportements, puis enquêter

Une stratégie SOC gagne à surveiller les opérations plutôt qu’une chaîne « impacket » dans un nom de processus. Sur le poste d’audit, on peut observer Python ou un lanceur. Sur la cible Windows, on observe surtout les mécanismes distants employés. Des outils d’administration légitimes peuvent produire des comportements proches.

Construisez une matrice indiquant, pour chaque scénario, le journal attendu, sa configuration préalable, le délai de collecte et la règle de corrélation. Examinez notamment les authentifications, les accès aux partages, la création de services ou de tâches et les processus associés aux opérations d’administration. Leur disponibilité dépend des stratégies d’audit et des capteurs déployés.

Une connexion inhabituelle d’un poste utilisateur vers plusieurs serveurs devient plus intéressante lorsqu’elle est suivie d’une opération privilégiée. Mais le seuil ne suffit pas : une opération unique visant un système critique peut compter davantage que cent lectures autorisées. Le propriétaire du compte, le rôle de la machine et le changement approuvé donnent le contexte.

Lors du rejeu, séparez « événement généré », « événement collecté », « alerte déclenchée » et « alerte traitée ». Une console montrant un journal ne prouve pas que l’équipe recevrait une notification. Mesurez ces étapes et documentez les trous de visibilité sans prétendre à une détection universelle.

9. Corriger, retester et remettre le laboratoire en état

Commencez par la permission ou le flux qui rend le scénario possible. Retirez les droits inutiles, séparez les comptes d’administration des usages quotidiens et limitez les accès distants aux points d’administration prévus. Planifiez les changements de protocole avec les propriétaires des applications : désactiver un mécanisme sans inventorier ses dépendances peut interrompre un service métier.

Une correction doit réussir deux tests : empêcher l’action indue et préserver l’usage légitime. Dans notre exemple, le compte exclu reste bloqué tandis que le lecteur accède toujours à son dossier. Conservez la configuration avant modification et un moyen d’accès de secours adapté au laboratoire. Le retour arrière restaure la configuration, pas la confidentialité d’un secret déjà exposé.

À la fin, retirez les comptes et permissions temporaires, supprimez les fichiers factices et les artefacts créés, puis vérifiez les services et tâches si le périmètre incluait une exécution distante. Protégez les preuves selon une durée de conservation définie. Un rapport ne doit pas devenir une copie de l’annuaire et de ses secrets.

10. Un livrable compréhensible par les équipes et la direction

Présentez chaque constat avec cinq informations : condition de départ, opération autorisée pour le test, résultat observé, conséquence métier et correction vérifiable. Ajoutez le niveau de confiance et les limites. « Accès à un dossier de factures depuis un compte hors du service comptable » explique mieux l’enjeu que « SMB exploitable ».

Une fiche de preuve peut contenir l’heure, la source, la cible, le rôle, la version du programme, la commande expurgée, le résultat attendu et le résultat observé. Ne mélangez pas les simulations avec les constats réellement obtenus. Le destinataire doit pouvoir distinguer un risque théorique, une permission confirmée et une action effectivement réalisée.

La priorité dépend du chemin complet : exposition, privilèges obtenus, données accessibles et capacité de détection. Pour organiser les suites, utilisez le guide transformer un pentest en plan de remédiation.

11. Questions fréquentes sur Impacket

Impacket est-il un malware ?

C’est un projet logiciel utilisé notamment pour la recherche, l’administration et les audits. Il peut aussi être détourné. Le contexte, la provenance, l’identité qui l’exécute et les opérations effectuées permettent d’évaluer une situation.

Faut-il être administrateur du domaine ?

Non pour toutes les opérations. Certaines lectures nécessitent peu de droits, d’autres actions exigent des privilèges précis. Ne donnez pas des droits de domaine globaux à un compte de test pour simplifier la préparation : vous fausseriez la mesure.

Un antivirus suffit-il à empêcher son utilisation ?

Un contrôle endpoint peut contribuer à bloquer certaines exécutions. La protection doit aussi porter sur les identités, les permissions, les flux et les protocoles. Un mécanisme d’administration reste accessible à d’autres logiciels capables de le parler.

Quelle différence avec Nmap et Nikto ?

Nmap aide à caractériser l’exposition réseau ; Nikto examine certains aspects des services web. Impacket permet d’interagir avec des protocoles et mécanismes d’authentification, particulièrement utiles dans un audit Windows. Le guide Nmap et Nikto détaille cette complémentarité.

Sources et références

Documentation consultée le 24 octobre 2026. Les architectures et scénarios sont pédagogiques ; les exemples restent illustratifs et ne reproduisent pas les journaux du rejeu confirmé.

• Fortra - dépôt et documentation Impacket
• Fortra - client SMB
• Fortra - exemple psexec
• Fortra - exemple wmiexec