« Le thème que je veux vraiment que vous reteniez [de cette présentation] est : si vous voulez vraiment protéger votre réseau, vous devez vraiment connaître votre réseau. » TAO Chief, NSA, USENIX Enigma 2016
Une partie essentielle de la « connaissance de votre réseau » consiste à suivre les mécanismes de persistance des endpoints : la myriade de façons dont un système d’exploitation peut charger et exécuter automatiquement le code. Depuis plus d’une décennie, les services d’arrière-plan sont l’un des emplacements de persistance les plus couramment utilisés dans Windows. Disponibles depuis l’ère de Windows NT et XP, les services offrent un moyen fiable de charger discrètement les processus et les bibliothèques en arrière-plan lors du démarrage du système, de la connexion de l’utilisateur ou des conditions déclenchées. Bien qu’une grande attention soit souvent accordée au suivi des techniques de persistance secrètes et nouvelles, il est important de ne pas perdre de vue les bases, en particulier compte tenu de la prévalence des logiciels malveillants basés sur les services.
Il était auparavant impossible de surveiller de près les services système qui s’exécutaient dans toute une entreprise. L’état de l’art il y a deux ans serait un audit mensuel avec une analyse manuelle approfondie pour détecter les anomalies. Aujourd’hui, cela peut être fait de manière continue et automatisée à l’aide de la plateforme Tanium et de son module de réponse aux incidents.
Les outils d’accès à distance (Remote Access Tools, RAT) et autres logiciels malveillants peuvent persister en tant que services de trois manières différentes : en tant qu’exécutables de service autonomes, modules de service hébergés et composants COM+. Dans cette publication, je vais examiner les différentes façons dont les attaquants abusent des services Windows, et comment Tanium peut vous aider à les détecter.
Services autonomes
Les services autonomes exécutent un fichier exécutable ou une ligne de commande spécifiée dans la valeur « ImagePath » dans leurs clés de registre de configuration respectives. Le registre Windows contient les paramètres de configuration pour tous les services actuels sous la clé parent « HKLM\System\CurrentControlSet\Services ».
Tanium a longtemps fourni la possibilité de surveiller les services Windows à grande échelle (sur l’ensemble de l’inventaire Windows). Le sensor « Service Status with MD5 hash », par exemple, collecte et compare le nom du service, l’état (Exécution, Arrêté, etc.), la ligne de commande, le hachage ImagePath et le contexte utilisateur dans lequel le service est exécuté. Cela signifie que les services autonomes se démarqueront avec un faible nombre de fréquences de survenue si leur configuration ou leur état est inhabituel, ou diffère entre les instances nommées à l’identique. Les utilisateurs Tanium ont utilisé ce sensor pour identifier les services mal configurés mais légitimes en fonction du statut (tels que les services antivirus arrêtés), ainsi que les services indésirables en fonction de leur nom, contexte d’utilisateur, ligne de commande ou hachages ImagePath différents pour les instances de service de nom identique.
Du point de vue d’un attaquant, les services autonomes ne sont pas aussi populaires, car le chemin exécutable est facilement disponible à l’aide des requêtes Task Manager, tasklist.exe ou Service Control Manager. Envisagez un pirate informatique qui souhaite dissimuler un logiciel malveillant sous le nom de service légitime « Print Spooler ». Ce service a un chemin exécutable de « c :\windows\system32\spoolsv.exe ». Une instance altérée du service peut charger un binaire malveillant à partir d’un nom de fichier ou d’un emplacement avec des modifications subtiles, telles que « c :\windows\spoolsv.exe » ou « c :\windows\system32\spoolsvc.exe ». Cette technique peut efficacement masquer les logiciels malveillants de l’analyse « en un coup d’œil », mais elle est facilement contournée par l’empilement statistique d’ImagePath ou de la ligne de commande. Les sensors Tanium tels que « Service Status with MD5 hash » empileront rapidement ces valeurs aberrantes à la périphérie du troupeau pour l’analyse et l’enquête de suivi.
Services hébergés et applications COM+
Les services hébergés sont mis en œuvre sous forme de bibliothèques, généralement des bibliothèques de liens dynamiques (DLL), plutôt que sous forme de fichiers exécutables autonomes. Ils sont généralement chargés par le processus d’hébergement de service Windows, « svchost.exe ». La capture d’écran ci-dessous montre la sortie du sensor « Service Status with MD5 Hash » de Tanium pour plusieurs services hébergés, tels que « Application Management » et « Base Filtering Engine ». Pour chaque service, le hachage fourni est celui de « svchost.exe » plutôt que celui de la DLL hébergée.
Comment Windows sait-il quelle DLL charger pour un service hébergé donné ? La configuration du registre pour chacun de ces services inclut une sous-clé et une valeur, « \Parameters\ServiceDLL », qui pointe vers la DLL à charger. Pour des raisons d’efficacité et de sécurité, Windows charge également les services hébergés en groupes sous des instances partagées du processus d’hébergement (par opposition à la génération d’une instance distincte de « svchost.exe » pour chacun).
Les groupes de services hébergés sont configurés sous la clé de registre « HKLM\Software\Microsoft\Windows NT\CurrentVersion\Svchost ». Chaque groupe fournit différents niveaux d’accès ; « netsvcs » est l’un des groupes les plus privilégiés pour les services avec accès réseau, et est donc fréquemment utilisé par les attaquants. La valeur « netsvcs » est un ensemble de chaînes de noms de service à charger dans ce groupe, comme décrit dans la capture d’écran ci-dessous.
Les attaquants peuvent abuser des services hébergés pour charger une DLL malveillante de plusieurs manières. Une approche consiste à choisir un nom de service hébergé qui est « inutilisé », c.-à-d. pour lequel aucun service n’est configuré sous « HKLM\SYSTEM\CurrentControlSet\services ». Les droppers de logiciels malveillants peuvent parcourir ces entrées inutilisées, créer les clés de registre requises (y compris un paramètre ServiceDLL) et ainsi maintenir la persistance en tant que service hébergé. Par exemple, sur les anciennes versions de Windows, les attaquants ciblaient souvent le service “6to4” , présent dans le groupe « netsvcs », mais souvent inactif sans configuration correspondante. L’attaquant peut configurer ce service pour qu’il pointe vers un nom DLL d’apparence raisonnable, tel que « c :\windows\system32\6to4svc.dll » et passe probablement l’inspection visuelle. Une autre approche consiste simplement à modifier le paramètre ServiceDLL pour un service Windows existant mais désactivé, puis à le configurer pour démarrer automatiquement.
Les services système COM+ sont une autre variante sur le thème des services hébergés qui peuvent charger des DLL malveillantes. Dans ce cas, le processus « dllhost.exe » charge l’application COM+ qui peut comprendre plusieurs composants sous forme de DLL. Par exemple, le service ComSysApp répertorié dans la capture d’écran ci-dessous est responsable de l’hébergement des applications COM+. La ligne de commande affiche le chemin vers « dllhost.exe » et un GUID « Processid » qui identifie l’application COM+, et dans le code, les « composants » peuvent être répertoriés. Les composants sont des DLL utilisées pour implémenter l’application.
Pour résumer, les services hébergés et COM fournissent un moyen caché et largement utilisé de RAT persistants et d’autres logiciels malveillants. Les analystes doivent aller au-delà de la surveillance des processus de base ou de l’examen des noms de service et des chemins d’image, pour détecter les services qui chargent des DLL malveillantes.
Identifier les DLL de service indésirables avec Tanium
Tanium fournit plusieurs sensors qui peuvent vous aider à détecter et analyser facilement les DLL de service à l’échelle de l’entreprise. Tout d’abord, nous présenterons un nouveau sensor, « Détails du module de service », à inclure dans la prochaine version 3,0 de notre solution de réponse aux incidents à la fin du mois. La capture d’écran ci-dessous montre la sortie partielle de ce sensor (« la colonne de nombre » est omise).
Ce sensor fournit une vue empilable des trois types de services décrits ci-dessus. Notez l’inclusion d’une colonne « Chemin du module », ainsi que le Nom du service et ImagePath. Les deux premières lignes de cet exemple affichent le chemin vers les DLL à deux composants pour l’application COM+ nommée « COMSysApp ». Les autres résultats sont tous hébergés par « svchost.exe » et incluent le chemin vers chaque DLL de service respectif. L’analyse de pile de ces données, comme avec tous les sensors Tanium, se produit en temps réel. Cela signifie que vous pouvez trouver des instances aberrantes de services qui chargent des DLL indésirables en quelques secondes sur des dizaines ou des centaines de milliers de systèmes.
Identifier les membres indésirables des groupes de services hébergés
Le trimestre dernier, la mise à jour du module Réponse aux incidents de Tanium comprenait un autre sensor d’analyse de service appelé « Audit du nom du service hébergé ». La capture d’écran ci-dessous montre un exemple de sa sortie pour le groupe « netsvcs ».
La sortie de ce sensor est utile pour inspecter rapidement l’ensemble des services au sein des groupes de services à l’échelle. Pour chaque groupe, la colonne « Liste triée des noms de service hébergés » fournit une liste alphabétique des noms de service. Cela garantit que la sortie de chaque système « empile » ; les systèmes contenant un service inhabituel au sein d’un groupe, ainsi séparés en valeurs aberrantes. Bien sûr, les systèmes peuvent avoir des ensembles de services différents en fonction du système d’exploitation et du rôle, mais nous avons constaté que la sortie du sensor génère des clusters autour de la version du système d’exploitation et du type de plateforme. Les utilisateurs Tanium peuvent utiliser la fonction d’analyse approfondie pour interroger facilement les systèmes avec des résultats aberrants, ou passer à Tanium Trace pour examiner les données judiciaires historiques entourant la création d’un service indésirable.
Vous souhaitez voir Tanium en action ? Planifiez une démo individuelle ou participez à notre webinaire hebdomadaire. Discutez avec nos experts Tanium lors de nos prochains événements.
