Impacket : la boîte à outils Python qui parle directement aux protocoles Windows

Présentation et principe de fonctionnement

Impacket a été créée à l’origine par SecureAuth, et est aujourd’hui maintenue par l’équipe Core Security de Fortra. La bibliothèque fournit un accès programmatique de bas niveau aux paquets réseau, pour Ethernet, IP, TCP, UDP, mais surtout pour les protocoles propres à Windows, NMB et SMB1/2/3, MSRPC, Kerberos, NTLM et LDAP. Les paquets peuvent être construits de toutes pièces ou analysés depuis des données brutes, avec une API orientée objet qui permet de manipuler des hiérarchies de protocoles imbriquées les unes dans les autres.

Ce choix architectural a une conséquence directe. Un outil qui s’appuie sur les API Windows hérite du comportement, et des limites, imposées par le système d’exploitation. Impacket, en réimplémentant les protocoles elle-même, s’en affranchit : elle peut par exemple s’authentifier avec un hash NTLM directement, sans jamais avoir besoin du mot de passe en clair, ou construire un paquet Kerberos avec des champs que les bibliothèques Windows standard ne permettent pas de modifier aussi facilement.

Une bibliothèque, et une collection de scripts de référence. Impacket n’est pas un outil unique avec une seule commande, c’est avant tout une bibliothèque de développement, livrée avec plusieurs dizaines de scripts d’exemple qui illustrent ce qu’il est possible de construire avec elle. Les plus connus en mission de pentest sont secretsdump.py, qui extrait des secrets d’authentification d’une machine distante, psexec.py et wmiexec.py, qui permettent l’exécution de commandes à distance par des voies différentes, service Windows pour le premier, WMI pour le second, GetUserSPNs.py, qui recense les comptes vulnérables au Kerberoasting, et ntlmrelayx.py, qui relaie une authentification NTLM interceptée vers un autre service.

Le déroulement type d’une utilisation

En mission, Impacket intervient presque toujours après l’obtention d’un premier niveau d’accès, qu’il s’agisse d’un compte de domaine valide, d’un hash NTLM récupéré, ou d’un ticket Kerberos.

Authentification avec ce qui est disponible, pas nécessairement un mot de passe. C’est l’un des apports centraux d’Impacket, ses scripts acceptent indifféremment un mot de passe en clair, un hash NTLM ou un ticket Kerberos comme moyen d’authentification, ce qui reflète directement la réalité d’une mission où le pentester obtient rarement des identifiants en clair.

Choix du script selon l’objectif du moment. Une fois authentifié sur un système, le choix entre plusieurs scripts dépend de ce que le pentester cherche à accomplir, extraire des secrets stockés localement, exécuter une commande à distance pour progresser latéralement, ou interroger l’annuaire pour repérer des comptes exploitables. Chaque script s’appuie sur un protocole ou un service Windows différent, ce qui a une incidence directe sur sa discrétion et sur les traces qu’il laisse.

Interprétation du résultat brut. Impacket renvoie des données brutes, une liste de hashs, une session de commande, un ticket Kerberos exporté. Rien dans l’outil n’indique si ce résultat représente une avancée significative dans la mission, cette lecture reste entièrement portée par le pentester, qui doit ensuite décider s’il poursuit l’exploitation, teste ces identifiants ailleurs sur le périmètre, ou documente simplement le constat.

Impacket face à d’autres outils du même écosystème

Impacket face à Mimikatz. Les deux outils sont souvent cités ensemble, mais répondent à des besoins différents. Mimikatz agit localement, sur la machine où il s’exécute, en lisant directement la mémoire du processus LSASS pour en extraire des secrets d’authentification. Impacket, à l’inverse, agit à distance, par le réseau, en dialoguant avec des services Windows exposés sur d’autres machines. Les deux se complètent naturellement en mission, l’un pour l’extraction locale, l’autre pour la propagation et l’exploitation à distance.

Impacket face à NetExec (l’héritier de CrackMapExec). NetExec est un outil d’orchestration construit au-dessus d’Impacket, qui automatise l’exécution en parallèle d’actions Impacket sur un grand nombre de machines simultanément, test d’un identifiant sur tout un sous-réseau, recherche de sessions actives, exécution de commandes en masse. Impacket reste la brique protocolaire de bas niveau, NetExec en est la couche d’automatisation et de mise à l’échelle. En pratique, un pentester alterne entre les deux, NetExec pour balayer rapidement un périmètre, puis un script Impacket individuel pour approfondir un cas précis avec un contrôle plus fin sur ses paramètres.

Comment l’intégrer côté défense

Impacket n’est pas qu’un outil offensif, c’est aussi une bibliothèque que des outils défensifs et des scripts d’audit interne utilisent pour dialoguer avec les mêmes protocoles, dans un objectif de supervision plutôt que d’exploitation.

Le fait qu’Impacket ne passe pas par les API Windows natives laisse une empreinte reconnaissable. Les sessions SMB ou RPC construites par Impacket diffèrent souvent, sur des détails de négociation ou de séquencement, de celles produites par les bibliothèques Windows officielles. C’est précisément sur cette différence que reposent de nombreuses signatures de détection réseau, disponibles par exemple dans des règles Suricata ou Zeek publiques ciblant les sessions SMB caractéristiques d’Impacket.

Surveiller les artefacts laissés par les scripts les plus utilisés. L’exécution de secretsdump.py sur un contrôleur de domaine s’accompagne typiquement d’une activation inhabituelle du service de registre distant ou de clichés instantanés (VSS), des événements qu’une supervision Sysmon ou EDR correctement configurée peut détecter. De la même façon, psexec.py crée un service Windows temporaire dont le nommage suit un schéma reconnaissable, tandis que wmiexec.py laisse des traces caractéristiques dans les journaux d’activité WMI.

Corréler plutôt qu’observer un seul signal isolé. Un volume anormal d’authentifications NTLM, une session RPC provenant d’un poste qui n’a normalement aucune raison de dialoguer avec un contrôleur de domaine, et la création d’un service Windows au nommage inhabituel, pris séparément, ne prouvent rien. Corrélés dans une fenêtre de temps courte, ils dessinent un scénario d’exploitation par Impacket beaucoup plus fiable qu’une seule alerte isolée.

Une équipe de sécurité interne peut également s’appuyer directement sur Impacket, ou sur des outils qui en dérivent, pour auditer elle-même la surface d’exposition de ses services Windows, dans une logique proche de celle qui pousse certaines organisations à exécuter BloodHound sur leur propre domaine avant qu’un attaquant ne s’en charge.

Comment nos pentesters l’intègrent en mission

Impacket fait partie de la boîte à outils mobilisée par nos pentesters lors des missions d’audit Active Directory, lorsque le contexte de la mission le justifie, typiquement une fois un premier niveau d’accès obtenu et lorsque l’objectif consiste à progresser latéralement ou à valider l’exploitabilité réelle d’identifiants récupérés ailleurs dans la mission, par exemple via une chaine identifiée grâce à BloodHound ou via un Pass-the-Hash.

Le choix du script précis dépend systématiquement du contexte, de la discrétion attendue et du périmètre défini avec le client. Nos pentesters privilégient toujours l’option la moins intrusive qui permet de répondre à la question posée par la mission, plutôt que d’enchaîner mécaniquement tous les scripts disponibles.

Ce que l’outil ne fait pas

Impacket exécute fidèlement ce qu’on lui demande, dialoguer avec un protocole, extraire une donnée, ouvrir une session distante. Mais rien dans son fonctionnement ne mesure l’impact réel de ce qu’elle vient d’accomplir.

Un hash extrait par secretsdump.py n’est pas un mot de passe compromis, encore faut-il pouvoir le casser hors ligne ou le rejouer avec succès ailleurs sur le périmètre pour qu’il représente une avancée réelle. Une session ouverte par psexec.py sur une machine ne dit rien de la sensibilité des données qu’elle contient, ni de la valeur métier de ce qui vient d’être atteint. Impacket ne scanne pas non plus un périmètre à grande échelle par elle-même, cette fonction relève d’outils d’orchestration construits au-dessus d’elle, ni ne gère la discrétion face à une détection, un script mal choisi dans un contexte surveillé peut déclencher une alerte immediate.

C’est le pentester qui transforme un résultat brut d’Impacket en un constat de mission exploitable, en évaluant si l’accès obtenu constitue réellement un chemin vers l’objectif convenu avec le client, et en documentant cette évaluation plutôt que le seul fait technique d’avoir exécuté un script avec succès.

Cadre légal et éthique

Impacket manipule des identifiants d’authentification et permet l’exécution de commandes sur des systèmes distants, ce qui en fait un outil sensible au même titre que Mimikatz ou BloodHound. Son usage sur un système sans autorisation explicite constitue une infraction, indépendamment du caractère open source et légitime de la bibliothèque elle-même. En mission de pentest, son emploi est systématiquement encadré par un contrat définissant précisément le périmètre autorisé, les systèmes concernés et les actions permises.