Par Bhabesh Raj, Associate Security Analytics Engineer
Avec le Patch Tuesday du mois de juin dernier, Microsoft a corrigé, dans Windows, une vulnérabilité (CVE-2021-1675) au niveau du spouleur d’impression (Print Spooler). En parallèle, une vulnérabilité similaire, appelée PrintNightmare, a été découverte par un autre groupe qui a publié par erreur les détails la concernant ainsi que sa preuve de concept (PoC), en raison certainement de la confusion qui régnait alors, transformant ainsi PrintNightmare en une faille zero-day.
Initialement classée, le 21 juin, comme une vulnérabilité d’élévation de privilèges de faible gravité, Microsoft a augmenté la sévérité de CVE-2021-1675 en la désignant comme critique car cette faille permettait l’exécution de code à distance. Par hasard, PrintNightmare permet également l’exécution de code à distance, ce qui n’a fait qu’augmenter la confusion entre ces deux vulnérabilités. Le 2 juillet, Microsoft a finalement généré un nouveau CVE-2021-34527 pour PrintNightmare et a déclaré que CVE-2021-34527 était similaire mais distinct de CVE-2021-1675 bien que les deux soient des failles au niveau des mêmes fonctions. Fait intéressant, les systèmes sont toujours vulnérables à CVE-2021-1675, et ce même après l’installation des correctifs s’ils sont configurés en mode ‘Point and Print’ avec l’option NoWarningNoElevationOnInstall.
La vulnérabilité PrintNightmare vient du fait que tout utilisateur authentifié peut installer un nouveau pilote d’imprimante et spécifier un fichier de pilote hébergé sur un serveur distant. Ainsi, le service spouleur d’impression exécute du code contenu dans une DLL arbitraire (qui a l’apparence d’un pilote d’imprimante) avec les privilèges SYSTEM. Les acteurs malveillants peuvent en plus s’en donner à cœur joie étant donné que plusieurs PoC fonctionnelles sont disponibles, et que la situation se trouve être aggravée par la confusion qui règne, au sein de la communauté de cybersécurité, entre CVE-2021-1675 et PrintNightmare. Les deux failles sont très sérieuses étant donné que le service spouleur d’impression est activé par défaut sauf au niveau du noyau du serveur. Les contrôleurs de domaine restent la cible privilégiée de cette vulnérabilité car ils permettent une compromission complète du domaine.
Aucun correctif n’étant disponible, nous vous conseillons de désactiver le service spouleur d’impression sur les machines qui n’en ont pas l’utilité. Les administrateurs peuvent utiliser les préférences de stratégie de groupe (GPP) pour désactiver le spouleur d’impression sur les machines du domaine ou pour désactiver l’impression distante entrante via la stratégie de groupe autorisant uniquement l’impression locale. N’oubliez pas que la désactivation du service spouleur d’impression désactive effectivement la possibilité d’imprimer à la fois localement et à distance via le serveur.
Il est important de noter que généralement les petites entreprises configurent leurs contrôleurs de domaine pour qu’ils fonctionnent également comme des serveurs d’impression, les empêchant ainsi de désactiver le service spouleur, car cela entraverait leurs activités quotidiennes. Si ce dernier doit s’exécuter sur certains serveurs, les administrateurs peuvent redistribuer la fonction de serveur d’impression du contrôleur de domaine au niveau d’un serveur distinct. Le risque d’exécuter le service d’impression sur les contrôleurs de domaine est trop élevé et ne peut pas être justifié.
LogPoint a publié UseCases version 5.0.2, qui inclut des tableaux de bord et des alertes pour détecter l’exploitation de la vulnérabilité PrintNightmare.
Préparation de vos sources de log
La preuve la plus solide permettant de confirmer la détection d’une exploitation de cette faille nécessite d’avoir accès aux événements provenant des canaux Microsoft-Windows-PrintServer/Admin et Microsoft-Windows-PrintServer/Operational. Vous devez activer manuellement ce dernier. Tout d’abord, préparez votre stratégie avec les administrateurs pour commencer à transférer les logs des sources susmentionnées vers LogPoint. De plus, si vous avez déployé Sysmon dans l’environnement, nous conseillons aux administrateurs de mettre à jour la configuration pour s’assurer que Sysmon puisse détecter les artefacts de PrintNightmare. Enfin, vous pouvez également utiliser les événements IDS/IPS pour récupérer les artefacts réseau générés par PrintNightmare.
Prérequis possibles en matière de sources de données pour la détection de PrintNightmare
Détection des artefacts d’exploitation dans LogPoint
Nous pouvons détecter les artefacts PrintNightmare à partir d’événements au niveau des endpoints et du réseau. Comme indiqué précédemment, le moyen le plus fiable de détecter l’exploitation nécessite de rechercher des ID d’événement tels que 808 et 316. Au niveau de ces deux événements, nous pouvons observer le nom de la DLL malveillante chargée par le service spouleur d’impression. Lors de nos tests, l’ID d’événement 808 n’est pas toujours généré, et même lorsqu’il l’est, la DLL malveillante a été chargée avec succès.
norm_id=WinServer event_source="Microsoft-Windows-PrintService" event_id=808
Vous pouvez rechercher des événements indiquant un échec du chargement d’un plugin d’imprimante.
norm_id=WinServer event_source="Microsoft-Windows-PrintService" event_id=316
Vous pouvez rechercher des événements indiquant l’ajout ou la mise à jour de pilotes d’imprimante.
En utilisant les événements de création de fichiers de Sysmon, nous pouvons rechercher la présence d’une DLL dans le répertoire du pilote du spouleur d’impression.
norm_id=WindowsSysmon event_id=11
path="C:\Windows\System32\spool\drivers\x64\3\*"
Vous pouvez rechercher la présence d’une DLL dans le répertoire des pilotes du spouleur d’impression.
Les DLL présentes sont ensuite chargées par le processus du spouleur d’impression (spoolsv.exe) comme le montrent les événements de chargement d’image de Sysmon.
norm_id=WindowsSysmon label=Image label=Load
source_image="*\spoolsv.exe"
image="C:\Windows\System32\spool\drivers\x64\3\*"
Vous pouvez rechercher le chargement des DLL à partir du répertoire des pilotes du spouleur d’impression.
Les DLL chargées font également leur apparition au niveau des chemins de registre du spouleur d’impression, comme le montrent les événements de registre de Sysmon.
norm_id=WindowsSysmon label=Registry label=Set
target_object IN ["*\Configuration File*", "*\Data File"]
| chart count() by host, image, target_object, detail
Vous pouvez rechercher la liste des DLL nouvellement chargées à partir de l’emplacement du registre du spouleur d’impression
Enfin, les DLL sont supprimées comme le montrent les événements de suppression de fichier de Sysmon.
norm_id=WindowsSysmon event_id IN [23, 26]
source_image="*\spoolsv.exe" image="C:\Windows\System32\spool\drivers\x64\3\*"
Alors que la nouvelle configuration Sysmon est en cours de déploiement au niveau de l’environnement, nous pouvons également utiliser des événements Windows natifs pour rechercher une éventuelle exploitation. Nous pouvons soit rechercher l’apparition de WerFault.exe au niveau du service spouleur d’impression, soit l’arrêt inattendu de ce dernier. Nous pouvons utiliser des événements Windows natifs car le service spouleur va générer une erreur lors du chargement de la DLL contenant la charge virale. Il convient de noter que le sideloading réussi de la DLL empêchera un tel comportement.
((norm_id=WindowsSysmon label="Process" label=Create
parent_image="*\spoolsv.exe" image="*\WerFault.exe")
OR (norm_id=WinServer channel=System event_id=7031
message="The Print Spooler service terminated unexpectedly"))
| timechart count() by event_id, host
Recherchez une erreur générée par le service spouleur d’impression pour identifier l’exploitation réussie ainsi que pour réduire la plage de temps au cas où les événements du service d’impression ou de Sysmon ne seraient pas disponibles.
Alternativement, nous pouvons également utiliser la détection d’exploitation générique en recherchant l’apparition de processus suspects au niveau du service spouleur d’impression.
norm_id=WindowsSysmon label="Process" label=Create
parent_image="*\spoolsv.exe" image IN ["*\cmd.exe", "*\powershell.exe", "*\rundll32.exe"]
Du côté réseau, nous devons rechercher le transfert de la DLL contenant la charge virale via SMB, ce qui est facile si vous avez des IDS/IPS comme Snort et Zeek (Bro) dans l’environnement.
norm_id IN [Snort, SuricataIDS]
(message="ET POLICY SMB2 NT Create AndX Request For a DLL File - Possible Lateral Movement"
OR signature="ET POLICY SMB2 NT Create AndX Request For a DLL File - Possible Lateral Movement")norm_id=BroIDS event_category=files
(file="*.DLL" OR mime_type="application/x-dosexec")
Si vous disposez d’un IDS ou IPS, vous pouvez rechercher le transfert de DLL via SMB.
Concernant les deux requêtes ci-dessus, nous pouvons les affiner davantage en recherchant spécifiquement les contrôleurs de domaine désignés comme destination, mais ce n’est peut-être pas toujours le cas.
Nous devons nous rappeler que PrintNightmare peut également être utilisé pour l’élévation locale des privilèges (LPE) comme par exemple l’utilisation du PowerShell PoC pour créer un utilisateur de type admin local en contournant le besoin de protocoles RPC ou SMB distants. Il est donc conseillé aux administrateurs de rechercher les créations locales de nouveaux utilisateurs après la génération de l’un des artefacts PrintNightmare, comme indiqué ci-dessous.
[ norm_id=WindowsSysmon label=Registry label=Set
target_object IN ["*\Configuration File*", "*\Data File"]]
as s1 followed by [ label=Create label=User ]
as s2 on s1.host=s2.host
| chart count() by s1.host, s1.image, s1.target_object, s1.detail, s2.target_user
Vous pouvez rechercher de nouvelles créations d’utilisateurs suite à l’ajout de nouvelles entrées au niveau de l’emplacement du registre du spouleur d’impression
La configuration de Sysmon est la clé pour détecter l’exploitation
On peut facilement remarquer comment nous avons utilisé Sysmon pour détecter divers artefacts générés par PrintNightmare. Ne négligez pas l’importance de Sysmon dans le paysage des menaces actuel. Vous pouvez utiliser Sysmon pour enrichir les logs d’événement Windows de base en complétant les sources existantes telles que la création de processus. Vous pouvez également ajouter la prise en charge de nouvelles sources de données telles que les créations de tubes qui sont vitales pour détecter les menaces dans le paysage actuel. Cependant, la configuration de Sysmon reste un jeu d’équilibriste délicat entre la détection d’un large éventail d’événements tout en évitant d’être littéralement submergé de logs. Pour résumer, l’essentiel est de configurer correctement les règles dans la configuration Sysmon qui sont spécifiquement adaptées à l’environnement dans lequel vous allez le déployer.
La configuration Sysmon de SwiftOnSecurity reste l’un des meilleurs points de départ pour commencer à configurer Sysmon en l’adaptant à son environnement. La configuration Sysmon doit inclure des règles de détection d’événements importants tels que la suppression de DLL et d’EXE, mais également une exclusion pour les applications légitimes qui génèrent un bruit important, comme les processus système intégrés tels que svchost, AV, EDR, les scanners de vulnérabilité et les bases de données telles que MSSQL. Commencez par déployer la configuration de base sur certains systèmes et surveillez le volume de logs. Ensuite, continuez en configurant les exclusions pour les événements susceptibles de générer du bruit. Répétez ce processus jusqu’à ce que le stockage du SIEM puisse gérer le volume de logs une fois déployé sur tous les systèmes de l’environnement.
Les nouvelles versions de Sysmon introduisent de nouveaux événements, alors assurez-vous de disposer de la version minimale de Sysmon requise pour générer les événements qui vous intéressent. Enfin, avant d’utiliser aveuglément une détection qui s’appuie sur Sysmon, assurez-vous d’avoir vérifié si la configuration déployée peut générer les événements requis par la détection. Les angles morts dans la configuration de Sysmon sont un phénomène courant, et vous devez les éviter grâce à des tests rigoureux avant son déploiement complet au sein de votre environnement.
Attendez-vous à ce que PrintNightmare soit utilisé par les acteurs malveillants
Étant donné que nous ne savons toujours pas quand Microsoft publiera un correctif pour PrintNightmare, les défenseurs des entreprises doivent rester vigilants car nous nous attendons à ce que les acteurs malveillants de tous niveaux commencent à exploiter la vulnérabilité pour élever les privilèges une fois qu’ils auront eu accès à l’environnement en question. Même si Microsoft a déclaré que seuls les contrôleurs de domaine sont concernés et que des investigations étaient en cours pour identifier les autres rôles potentiellement concernés, il est préférable de partir du principe que toutes les versions de Windows sont concernées. Nous vous recommandons de corréler les événements provenant de plusieurs sources pour obtenir une détection fiable, ce qui ne devrait pas être un problème pour les entreprises qui ont mis en œuvre une approche de défense en profondeur.
Nous conseillons vivement aux administrateurs d’effectuer une traque complète des tentatives d’exploitation à l’échelle de l’entreprise dès le début du mois de juin, d’appliquer les mesures de mitigation nécessaires, de satisfaire aux exigences des sources de données et de rechercher en permanence les futures tentatives d’exploitation par les acteurs malveillants jusqu’à ce que Microsoft publie un correctif.
