Comment bloquer PsExec ? Voici quelques pistes…
Sommaire
I. Présentation
Dans ce tutoriel sur PsExec, je vais évoquer quelques pistes afin de bloquer PsExec, car c'est un outil très puissant, mais qui peut effrayer certaines personnes. En même temps, c'est tout à fait compréhensible compte tenu de son potentiel, alors si on en fait pas l'usage, pourquoi laisser la possibilité de l'utiliser ? N'oublions pas qu'il n'y a pas de que des gentils...
Ce n'est pas parce que vous n'utilisez pas PsExec sur votre infrastructure que les logiciels malveillants ne pourront pas l'utiliser, mais dans ce cas, il peut être intéressant de mettre en place des mesures de protection pour tenter de le bloquer.
Avant de lire cet article, je vous recommande la lecture de mon premier article au sujet de PsExec :
II. Solutions pour bloquer PsExec
A. Désactiver les partages administratifs
Chaque machine Windows, que ce soit du Windows desktop ou du Windows Server est livrée par défaut avec des partages administratifs, dont le partage "admin$" sur lequel s'appuie PsExec.
Pour désactiver les partages Administratifs de Windows, en l'occurrence "admin$" qui est utilisé par PsExec, il ne suffit pas d'accéder aux paramètres de Windows et d'arrêter de partager. En effet, ces partages sont liés au service "LanmanServer" (Serveur) et à chaque fois que ce service va redémarrer, il va recréer les partages. C'est le cas aussi à chaque fois que l'on va redémarrer le serveur.
Pour désactiver les partages administratifs de Windows, il faut s'appuyer sur le Registre Windows.
Il y a une valeur de Registre différente à créer sur les postes de travail (Windows 7, Windows 10, Windows 11) et les serveurs (Windows Server), mais le résultat est le même : les partages administratifs "admin$" et "c$" seront désactivés, ce qui empêche PsExec de fonctionner !
Attention, certaines applications s'appuient sur les partages administratifs pour fonctionner. Par exemple, c'est le cas de la solution PDQDeploy qui est un logiciel tiers de déploiement de logiciels à distance. Avant de désactiver les partages administratifs à grande échelle, il est fortement recommandé de tester et de mesurer l'impact de ce changement.
- Pour les éditions clientes de Windows
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v AutoShareWks /t REG_DWORD /d 0 /f
- Pour les éditions serveurs de Windows
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v AutoShareServer /t REG_DWORD /d 0 /f
Bien entendu, ces valeurs de Registre peuvent être déployées par l'intermédiaire d'une GPO pour nous faciliter la tâche.
B. La clé de Registre "Debugger"
Sous Windows, il existe la clé de Registre "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options" qui sert à définir le programme de débogage pour chaque exécutable présent sur la machine. C'est une fonctionnalité pratique pour les développeurs, mais qui peut être détournée par les pirates informatiques (MITRE ATT&CK) et que, nous aussi, on va pouvoir détourner pour empêcher l'exécution de PsExec.
De cette façon, lorsque "psexec.exe" sera exécuté sur la machine locale (même si c'est pour cibler une machine distante), ce sera l'exécutable associé au débogage de PsExec qui sera lancé !
À partir de l'éditeur du Registre Windows (regedit), il faut créer une nouvelle nommée "psexec.exe" à cet emplacement :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
Au sein de cette clé, une nouvelle "Valeur chaîne" nommée "Debugger" doit être créée avec la valeur "svchost.exe" (même si l'on pourrait mettre autre chose). Ce qui donne :
Avec "REG ADD", cela donne :
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\psexec.exe" /v Debugger /t REG_SZ /d "svchost.exe"
À la place de "svchost.exe", vous pouvez mettre "calc.exe" et vous verrez, lorsque PsExec est utilisé, c'est la Calculatrice qui va s'exécuter à sa place ! Vous pouvez tester rapidement, car il n'est pas nécessaire de redémarrer pour appliquer cette modification. PsExec n'est plus exploitable, car dès qu'on l'exécute, c'est "calc.exe" qui s'ouvre !
Bien entendu, cette clé et cette valeur peuvent être créées à partir d'une GPO :
Configuration ordinateur > Préférences > Paramètres Windows > Registre
L'inconvénient de cette méthode basée sur la valeur "Debugger", c'est qu'elle s'applique uniquement sur les serveurs et postes de travail de votre domaine Active Directory (ou ceux de votre entreprise en groupe de travail). Ainsi, si l'une de vos machines est compromise, l'utilisation de PsExec sera plus difficile et l'exécution pourrait même être déjouée sur une attaque automatisée. Néanmoins, si la personne malintentionnée est connectée à votre réseau via sa propre machine, elle pourra exploiter PsExec sans aucune difficulté. L'autre inconvénient de cette méthode, c'est que l'on peut la contourner facilement : il suffit de renommer "psexec.exe" en "psexec2.exe" et le tour est joué !
C. La stratégie AppLocker
La solution de protection AppLocker, disponible sur les versions Entreprise et Education de Windows, permet de bloquer l'exécution de certaines applications (exécutables ou Modern App), certains scripts, etc... Grâce à ces règles définies par GPO. Il y a quelques mois, j'ai mis en ligne un article complet au sujet de cette fonctionnalité : Tutoriel AppLocker. Pour bloquer un exécutable, on peut s'appuyer sur un chemin d'accès, mais aussi le hash de cet exécutable, ce qui sera intéressant dans le cas de PsExec.
Tout d'abord, avec PowerShell et le cmdlet Get-FileHash, on peut obtenir le hash d'un fichier très simplement :
Get-FileHash PsExec.exe
Nous pouvons voir, et c'est normal, que PsExec.exe et PsExec64.exe ont un hash différent.
Dans une stratégie AppLocker, nous pouvons ajouter une nouvelle règle basée sur le hachage du fichier pour bloquer l'utilisation de PsExec. Ainsi, on spécifiera les deux exécutables et Windows va calculer le hash tout seul comme un grand.
Si l'on prend une stratégie AppLocker basique, nous obtenons le résultat suivant :
Une fois la GPO appliquée sur les ordinateurs de mon domaine, si j'essaie d'utiliser PsExec, que ce soit avec un compte utilisateur lambda ou administrateur, j'obtiens un message qui m'indique que ce programme est bloqué ! Une excellente nouvelle.
Cette méthode s'applique sur les machines que vous gérez (en groupe de travail ou domaine) donc elle ne vous protège pas si une personne malveillante se connecte à votre réseau afin d'utiliser PsExec. Il faut savoir également que le hash d'un exécutable peut être modifié, et que d'une version à l'autre de PsExec, il va varier (heureusement Microsoft met à disposition uniquement la dernière version, sans donner accès à l'historique des versions). Néanmoins, AppLocker reste une solution recommandée et très intéressante pour sécuriser ses machines.
Note : si vous souhaitez vous orienter vers la mise en place d'AppLocker, j'insiste sur le fait que vous devez regarder mon tutoriel à ce sujet pour bien configurer la GPO.
D. Les autres solutions à explorer
En complément des trois solutions évoquées dans cet article, il y a d'autres pistes à explorer, notamment le pare-feu local de la machine. Que ce soit à partir du pare-feu Windows ou à partir du pare-feu de votre Endpoint (antivirus), la gestion des flux au sein du pare-feu local est importante, car pour fonctionner, le pare-feu doit autoriser les accès sur le port 445/TCP (groupe de règles "Partage de fichiers et d’imprimantes").
Sur un contrôleur de domaine ou un serveur de fichiers, ce flux sera forcément autorisé, car les postes clients ont besoin d'accéder à des fichiers via le réseau. Néanmoins, ce n'est pas forcément vrai pour d'autres types de serveurs et pour les postes de travail. En vous appuyant sur l'Endpoint qui protège vos machines, et selon ses fonctionnalités, vous avez peut-être la possibilité de créer une règle afin de bloquer PsExec.
Plus largement, c'est l'architecture de votre système d'information qui doit être pensée de façon à interdire ou limiter les communications entre des appareils inconnus (personnes externes) et vos postes de travail et serveurs. Ainsi, vous pouvez interdire l'utilisation de PsExec sur vos machines (via AppLocker, par exemple), tout en évitant qu'une machine externe soit en mesure de contacter vos serveurs. Cette règle ne s'applique pas uniquement à PsExec qui dans ce cas n'est qu'un exemple, mais c'est plutôt un grand principe afin d'avoir un réseau sécurisé en appliquant cette règle de base.
Si vous connaissez d'autres solutions pour bloquer PsExec ou si vous souhaitez faire un retour d'expérience, n'hésitez pas à laisser un commentaire sur cet article. 🙂
