Par Bhabesh Raj Rai, Associate Security Analytics Engineer
La traque de l’activité PsExec au sein de votre entreprise
PsExec est un outil gratuit et simple qui peut exécuter des processus de systèmes distants et prend en charge une interactivité totale au niveau des applications de type console. PsExec est un outil précieux dans la boîte à outils d’un administrateur système. En effet, les administrateurs peuvent l’utiliser pour lancer des invites de commande interactives sur des systèmes distants sans avoir à installer manuellement le logiciel client.
Les administrateurs système utilisent couramment PsExec pour télécharger ou uploader un fichier sur des partages réseau ou exécuter des commandes, des scripts ou des binaires sur des systèmes distants. Cependant, si PsExec est plébiscité par les administrateurs système pour sa praticité, il l’est aussi par les acteurs malveillants. En effet, n’oubliez pas que les attaquants peuvent faire passer leurs actions malveillantes pour des activités sysadmin légitimes au sein de votre environnement.
Jusqu’à présent, de nombreux acteurs malveillants ont utilisé PsExec, notamment APT1, menuPass, Turla et Wizard Spider. FIN5, un groupe malveillant motivé financièrement, utilise une version personnalisée de PsExec. De plus, les opérateurs de ransomware comme Ryuk et Maze utilisent massivement PsExec pour les mouvements latéraux.
L’exécution de PsExec génère de nombreux événements que divers capteurs peuvent détecter s’ils sont correctement configurés. Les événements générés les plus notables sont la création de nouveaux services, l’authentification d’un endpoint cible via SMB et la création et la connexion de tubes nommés. De plus, les systèmes de détection d’intrustion (IDS) et les systèmes de prévention d’intrustion (IPS), comme Snort et Suricata, peuvent facilement détecter l’activité PsExec sur le réseau.
Nous nous concentrerons sur la traque de l’activité PsExec dans LogPoint et sur la détection de l’exploitation réussie d’une vulnérabilité d’élévation locale de privilèges (LPE) récemment découverte.
La traque de PsExec dans LogPoint avec Sysmon
Dans LogPoint, vous pouvez afficher un modèle de recherche PsExec pour obtenir un aperçu de toutes les activités associées.
Lors de l’exécution de PsExec (ou de tout autre outil Sysinternals) pour la première fois, il crée une nouvelle clé de registre sur l’hôte source qui documente l’acceptation du CLUF (EULA) par l’utilisateur. La détection de ce changement de registre est simple via les logs d’événement du registre de Sysmon.
norm_id=WindowsSysmon event_id=13 target_object="*\EulaAccepted"
| norm on target_object Sysinternals\<tool:words>
| chart count() by host, image, tool, target_object
Cependant, le changement de registre ne se produit que pour les versions officielles de PsExec publiées par Microsoft. Les versions personnalisées éviteront de changer la clé de registre.
Par défaut, PsExec crée un nouveau service, nommé PSEXESVC, sur le système distant qui peut être détecté via les logs de création de nouveaux services Windows : les ID d’événement 7045 et 4697. La différence étant que ce dernier fournit les informations de compte.
norm_id=WinServer event_id=4697 service=PSEXESVC
| chart count() by host, user, service, file
Le nom du service peut être modifié à partir de la ligne de commande et l’événement seul ne peut pas détecter complètement toutes les exécutions PsExec.
PsExec déposera le binaire PSEXESVC.exe, qui peut être modifié, dans le répertoire SYSTEMROOT d’un système distant qui sera ensuite exécuté par le service nouvellement créé. Les logs des événements de création de fichier de Sysmon peuvent être utilisés pour rechercher la présence de binaires dans le répertoire SYSTEMROOT.
norm_id=WindowsSysmon event_id=11 path="C:\Windows" file="*.exe"
| chart count() by host, file, path
Chaque commande à distance exécutée via PsExec sera générée par le processus PSEXESVC.exe qui peut être récupéré par les événements de création de processus natifs Windows (ID d’événement 4688).
norm_id=WinServer event_id=4688 parent_process="*\PSEXESVC.exe"
| chart count() by host, parent_process, "process", command
L’une des capacités de détection les plus précieuses offertes par Sysmon est la création de tubes (ID d’événement 17) et les événements de connexion (ID d’événement 18).
norm_id=WindowsSysmon event_id IN [17, 18]| chart count() by host, message, pipe order by count() desc
PsExec nécessite de nombreux tubes pour son fonctionnement comme \psexesvc, bien que le nom d’un tube puisse être changé. Les tubes les plus intéressants ont le format suivant : -<stdin|stdout|stderr>. La détection d’une création de tube ou d’une connexion respectant ce format est un indicateur de l’activité de PsExec au niveau d’un endpoint.
norm_id=WindowsSysmon event_id IN [17, 18] pipe IN ["*-stdin", "*-stderr", "*-stdout"]| chart count() by host, message, pipe order by count() desc
Nous pouvons créer un widget qui montre les principaux hôtes sources responsables des exécutions de PsExec.
norm_id=WindowsSysmon event_id IN [17, 18] pipe IN ["*-stdin", "*-stderr", "*-stdout"]| norm on pipe-<source_host:word>-<:word>-<:'stdin|stdout|stderr'>
| chart count() by source_host order by count() desc
La traque de PsExec dans LogPoint sans Sysmon
Les logs d’audit du partage de fichiers de Windows détectent PsExec si Sysmon n’est pas déployé dans l’environnement. Seul, l’audit de base du partage de fichiers est insuffisant, les utilisateurs doivent donc activer l’audit «Partage de fichiers détaillé».
L’audit de base du partage de fichiers (ID d’événement 5140) comprend un nom d’utilisateur, une adresse IP source et des informations sur le nom de partage.
norm_id=WinServer event_id=5140
| chart count() by host, user, source_address, share_name
La principale capacité de détection consiste à effectuer un zoom sur le champ cible relatif avec le même format que le nom de tube enregistré dans les événements de création et de connexion de Sysmon Pipe.
norm_id=WinServer event_id=5145 share_name=IPC$ relative_target IN ["*-stdin", "*-stderr", "*-stdout"]| norm on relative_target -<source_host:word>-<:word>-<:'stdin|stdout|stderr'>
| chart count() by host, user, source_address, source_host
Cependant, pour détecter la version Impacket de PsExec, la requête ci-dessus doit être légèrement modifiée car le champ relative_target d’Impacket/PsExec utilise un format différent : RemCom_(stdin|stdout|stderr)t*. Notez également que dans Impacket/PsExec il existe une perte d’informations au niveau de l’hôte source.
norm_id=WinServer event_id=5145 share_name=IPC$ relative_target IN ["RemCom_stdint*", "RemCom_stderrt*", "RemCom_stdoutt*"]| chart count() by host, user, source_address
Si vous disposez d’un IDS ou d’un IPS, vous pouvez rechercher une correspondance de signature afin de détecter l’activité réseau de PsExec.
Détection IDS et IPS
Nous devons rechercher une correspondance de signature IDS ou IPS qui couvre l’activité réseau de PsExec.
(norm_id=Snort OR norm_id=SuricataIDS) message IN ["Remote Service Control Manager Access*", "PsExec service created*",
"SMB2 NT Create AndX Request For an Executable File*", "Executable File Transfer*"]
Détection de l’exploitation de l’élévation locale des privilèges via PsExec
Le 9 décembre, David Wells, un chercheur chez Tenable Security, a découvert une vulnérabilité LPE dans PsExec qui permettait à un processus non-administrateur de bénéficier d’une élévation vers un statut SYSTEM. La vulnérabilité a été corrigée dans la dernière version de PsExec 2.3.
Détecter l’exploitation réussie de la vulnérabilité est simple en recherchant la création d’un processus enfant de PSEXESVC.exe avec le niveau d’intégrité ‘SYSTEM’.
norm_id=WindowsSysmon event_id=1 integrity_level=SYSTEM parent_image="C:\Windows\PSEXESVC.exe"
Vous pouvez utiliser la requête suivante pour détecter le moment où le binaire utilisé est renommé à l’aide du switch de ligne de commande suivant :
norm_id=WindowsSysmon event_id=1 integrity_level=SYSTEM parent_image="C:\Windows\*.exe" -parent_image="C:\Windows\System32\*.exe"
| chart count() by user, image, parent_image
Détection de PsExec via les règles ASR de Defender
Les règles ASR (Attack Surface Reduction) de Defender sont l’une des principales caractéristiques de Defender Exploit Guard. Elles visent à perturber les types de comportement spécifiques utilisés par les malwares pour infecter des périphériques tels que les macros malveillantes et les scripts suspects. Defender a une règle ASR nommée ‘bloquer les créations de processus provenant de commandes PSExec et WMI’. Si cette règle est activée, Defender bloque les exécutions PsExec et un événement (ID d’événement 1121) est généré avec le GUID de la règle.
norm_id=WinServer event_id=1121 id="D1E49AAC-8F56-4280-B9BA-993A6D77406C" -process_name IN ["*\wmic.exe", "*\wmiprvse.exe"]
| chart count() by host, file, path, process_name
L’activation de la règle ASR de Defender bloque les exécutions PsExec et génère un événement correspondant.
Utilisez plusieurs méthodes de détection pour bénéficier d’une couverture complète
En conclusion, les défenseurs ont diverses possibilités pour détecter PsExec. Cependant, les acteurs malveillants avancés modifient les paramètres de ligne de commande pour éviter les détections simples en se référant à un service ou à un nom binaire. Nous vous recommandons donc de disposer de plusieurs possibilités de détection pour obtenir une couverture complète.
Dans le paysage actuel des menaces, l’activité des ransomwares ne cesse de prendre de l’ampleur. La détection de l’activité PsExec peut empêcher d’éventuels déploiements de Ryuk, Maze ou d’autres ransomwares au sein d’une entreprise. Nous recommandons aux administrateurs système de passer à PowerShell Remoting au lieu de PsExec pour les tâches d’administration et de considérer comme malveillante l’ensemble de l’activité de PsExec au sein de l’environnement.
