Il est parfois nécessaire en traitement d'incident d'analyser une machine pour trouver le processus responsable d'une communication TCP ou UDP jugée suspecte. Les outils permettant d'afficher les communications actives des processus (netstat, resmon...) ne sont alors pas toujours adaptés. Par exemple lorsqu'il s'agit d'identifier l'origine d'une communication UDP ou dans le cas d'une communication nocturne qui implique une analyse a posteriori. Il faut alors pouvoir journaliser les événements de communications réseaux des processus de la machine. L'article présente une méthode simple basée sur un outil standard Windows : l'analyseur de performances.
1. Perfmon, un contrôleur ETW
L’analyseur de performances, perfmon, est un outil présent nativement sur les différentes versions de Windows (depuis Windows 2000). Il permet de recueillir des indicateurs de performances, des événements issus de différents composants du système (fournisseurs), et de collecter des informations de configuration en base de registre. C’est un outil puissant qui permet d’analyser les impacts d’exécution des applications sur les performances de la machine. Ce qui nous intéresse pour la suite est son rôle de contrôleur au sein de l'architecture Event Tracing for Windows (ETW) [1].
ETW est une API bas niveau fournie par le système d'exploitation Windows qui permet le suivi dynamique (à la demande, sans redémarrage nécessaire) des événements déclenchés par les différents composants du système (de l'application en mode utilisateur au pilote noyau). Introduite dès Windows 2000, elle constitue aujourd'hui l'une des technologies d'instrumentation clés sur les plateformes Windows. Elle fonctionne sur le principe de l'enregistrement : toute entité logicielle (driver, application...) peut devenir un fournisseur d'événements à condition de s'enregistrer en tant que tel via une API d'enregistrement.
ETW repose sur quatre éléments principaux :
- les fournisseurs de suivi d'événements (event providers), qui génèrent les événements et les écrivent dans des sessions de suivi d'événements ;
- les sessions de suivi d’événements (event tracing sessions), qui horodatent les événements reçus et les enrichissent de certaines informations en entête (id du processus et du thread de la session, numéro de processeur...) avant de les écrire dans un fichier de log binaire compressé (d’extension .etl pour event trace log) ou de les délivrer directement à un consommateur. Les sessions de suivi utilisent des buffers en mémoire noyau non paginé ;
- les consommateurs d’événements (consumers), qui récupèrent les événements depuis un fichier de log ou en temps réel depuis une session ETW ;
- les contrôleurs (controllers), qui contrôlent les sessions de suivi (démarrage/arrêt) et permettent de choisir les fournisseurs d'événements utilisés dans ces sessions.
Au sein de cette architecture, on retrouve en standard sur tout poste Windows (depuis Windows XP) :
- perfmon.exe, l'analyseur de performances, un contrôleur graphique qui selon son mode d'utilisation agit également comme consommateur d’événements (rapport généré par l'outil) ;
- logman.exe, un contrôleur en ligne de commandes ;
- tracerpt.exe, un consommateur d’événements qui permet d'analyser les journaux générés par les sessions de suivi.
Schéma de l'architecture ETW.
L'évolution des versions du système d'exploitation fait apparaître de nouveaux fournisseurs, contrôleurs et consommateurs. Par exemple, Windows 7 possède plus de six cents fournisseurs en standard quand Windows XP en possède moins de dix. Autre exemple, l'outil netsh devient un contrôleur sous Windows 7 [2]. L'intérêt de présenter une méthode avec le contrôleur perfmon est qu'elle est rejouable sur l'ensemble des systèmes Windows depuis Windows XP.
2. Présentation de la méthode
En prérequis, on considère que l’adresse IP destination avec laquelle la machine à analyser communique (ou tente de communiquer en cas de filtrage par un pare-feu) est connue.
La méthode consiste à exécuter une session de suivi sur la machine avec perfmon, le temps nécessaire pour que les événements sur le flux réseau suspect soient capturés (la durée de la session dépendra donc des caractéristiques de fréquence ou d’horaire du flux suspect).
L'analyse du journal généré doit permettre de trouver l'identifiant de processus (PID) du processus communiquant sur le réseau, en recherchant des événements contenant l'adresse IP destination. Connaissant le PID du processus, on peut alors chercher à identifier le binaire associé :
- si le processus est toujours actif, le passage du PID au binaire recherché (exe, dll) est le plus souvent quasi immédiat et ne sera pas développé dans l'article ;
- si le processus n’est plus actif (ou que le PID a été réaffecté), l'analyse du journal permettra de connaître le nom de l’image qui était associée à ce processus.
2.1 Fournisseurs d’événements requis
Comme indiqué dans l'introduction, les fournisseurs évoluent en fonction des versions du système d'exploitation.
Un fournisseur est présent sur toutes les versions de Windows depuis Windows XP. Il s'agit du fournisseur « Suivi de noyau Windows ». Il possède l'identifiant unique (GUID) : {9E814AAD-3204-11D2-9A82-006008A86939} et s’exécute au sein d'une session de suivi qui lui est réservée, appelée « NT Kernel Logger ». Ce fournisseur permet de tracer des événements TCP/IP (avec le PID du processus communiquant) et également les événements de démarrage/arrêt des processus. En s'appuyant sur ce fournisseur, on peut donc définir une méthode générique utilisable sur tous les systèmes Windows.
Depuis Windows 7 (Windows 2008 R2), deux fournisseurs peuvent être utilisés en remplacement du suivi de noyau. Ces fournisseurs sont :
- Microsoft-Windows-TCPIP (MW-TCPIP)({2F07E2EE-15DB-40F1-90EF-9D7BA282188A});
- Microsoft-Windows-Kernel-Process (MW-Kernel-Process) ({22FB2CD6-0E7B-422B-A0C7-2FAD1FD0E716}).
L’intérêt de les présenter est que le journal de trace généré peut être formaté en journal d’événements Windows (.evtx) et donc être exploité à partir de l'observateur d'événements Windows.
Afin de connaître l'ensemble des fournisseurs ETW enregistrés sur une machine, exécuter la commande suivante depuis une invite de commandes :
logman query providers
Le nom des fournisseurs et leur identifiant unique (GUID) sont alors affichés.
2.2 Utilisation du fournisseur « Suivi de noyau Windows »
Exécuter perfmon.exe en tant qu'administrateur. L'interface de l'analyseur de performances apparaît (l'exemple utilise l'analyseur de performances de Windows 7).
Interface graphique de l'analyseur de performances sous Windows 7.
Dérouler le menu situé dans le volet d’arborescence (gauche). Choisir Définis par l'utilisateur, effectuer un clic droit > . Nommer l'ensemble (on utilise ici le nom « forensic ») et choisir . Cliquer sur et choisir . Cliquer sur et ajouter le fournisseur . Choisir la propriété et cliquer sur Cocher les cases et valider et poursuivre. Choisir l'emplacement des fichiers de logs générés par le collecteur (par défaut dans une sous arborescence de %systemdrive%\PerfLogs\) et cliquer sur . Le collecteur de données forensic est prêt. Il est associé à un fichier journal nommé DataCollector1 et une session de suivi nommée NT Kernel Logger.
Pour démarrer le collecteur, cliquer dessus et par le menu contextuel, choisir . De la même façon, choisir pour terminer le suivi.
Pour analyser le fichier journal généré, en tant qu'administrateur, exécuter la commande :
tracerpt C:\Perflogs\forensic_000001.etl –of csv -o mydump.csv
Un fichier au format CSV mydump.csv est créé dans le répertoire courant. Il contient les événements remontés par le fournisseur.
L’analyse du fichier montre que les événements ont un entête commun (ajouté par la session de suivi). Le nombre de colonnes présent dans l'entête varie en fonction des systèmes Windows, mais on retrouve à minima les colonnes suivantes :
Event Name,Type,TID,Clock-Time,Kernel(ms),User(ms)
Pour une description de ces colonnes, voir http://msdn.microsoft.com/en-us/library/ms971550.aspx
Les autres colonnes sont associées à l'entête User Data. Cette partie est dépendante des événements remontés. On peut obtenir des informations utiles sur la signification de ces colonnes en consultant la définition des classes d’événements [3].
Les événements dont la colonne Event Name vaut TCP/IP ou Udpip remontent les adresses IP en communication ainsi que le PID du processus communicant. Voici à titre d'exemple une trace générée par un système Windows 7 :
Entête tronquée UserData
TcpIp,SendIPV4,[...] 3200,243, 192.168.100.90, 192.168.100.21,443,1859,168914,168915,0,0x0
UdpIp,SendIPV4,[...] 1708,33, 192.168.151.6, 192.168.100.21,53,64374,0,0x0
code
Ainsi la première ligne de log indique que la machine d'adresse IP 192.168.100.21 (machine analysée) est en communication TCP avec l’adresse IP 192.168.100.90 sur le port TCP 443 et que le processus responsable de cette communication a le PID 3200. La deuxième ligne montre que le processus de PID 1708 est responsable d’une communication UDP avec l’adresse IP 192.168.151.6 sur le port UDP 53.
En cas de tentative de connexion TCP échouée (adresse destination filtrée par exemple), les événements de reconnexions ou déconnexions TCP sont remontés :
Entête tronquée UserData
TcpIp, ReconnectIPV4 5772,0,192.168.100.90, 192.168.100.21,445,2286,0,0x0
Dans cet exemple, on observe une tentative de reconnexion TCP du processus 5772 de la machine 192.168.100.21 sur le port TCP/445 (filtré) de la machine 192.168.100.90.
Quelle que soit la version du système d'exploitation, en comptant à partir de la première colonne de l'entête User Data :
- le PID du processus communicant est donné par la première colonne ;
- les adresses IP en communication sont données par la troisième (adresse destination) et quatrième colonne (adresse source) ;
- les ports destination/source sont donnés respectivement par la cinquième et sixième colonne.
Si le processus recherché s’est arrêté (ou a démarré) pendant la session de suivi, les événements de type démarrer ou fin des événements Processus donnent le nom du binaire associé. Le PID du processus est renseigné par la deuxième colonne de User Data (suivi du PID du processus parent). Suivant les versions de Windows, il est soit donné en décimal ou en hexadécimal.
Entête tronquée UserData
Processus,Fin, 0xFFFFFA8006CA1650,0x6AC,0xF50,1,259,0xCCDC000,"\\labo\test","nslookup.exe", "nslookup microsoft.com"
Le processus 1708 (0x6AC) était associé au binaire nslookup.exe qui a été exécuté par l'utilisateur test de la machine labo.
2.3 Utilisation des fournisseurs MW-TCPIP et MW-Kernel-Process
Par la même méthode, exécuter une trace d’événements en configurant un collecteur de données avec les fournisseurs et Il faut modifier la propriété de ce dernier fournisseur pour choisir de faire apparaître l'identité sous laquelle s’exécute un processus en cochant la case .
Il est possible d'exporter les résultats du fichier journal généré dans un format texte (csv, xml) à l'aide de l'outil tracerpt.exe. L’utilisation de l'observateur d’événements est présentée ici, car c'est une méthode simple qui permet de profiter de l'interprétation des données (informations d'affichage). L'observateur d’événements est capable de lire les journaux .etl générés sur les systèmes Windows Vista et ultérieurs.
Exécuter l'observateur d’événements (eventvrw.msc). Par le menu contextuel, choisir et choisir le fichier journal généré avec le nouveau collecteur. Autoriser la création d'une nouvelle copie au format evtx, nommer le journal et valider. Le journal est disponible en parcourant l'arborescence .
Pour les flux TCP (établis ou filtrés), l'Identifiant d’événement (eventid) 1044 du fournisseur Microsoft-Windows-TCPIP remonte les adresses IP sources et destinations (et les ports utilisés) ainsi que le PID du processus communiquant. Les informations d'affichage permettent une interprétation directe :
TCP : l’arrêt de la connexion 0xfffffa802efee990 (locale=192.168.100.21:43032 distante=192.168.100.190:445) a commencé ({Temporisation de périphérique expirée} L’opération d’E/S spécifiée sur %hs n’a pu se terminer avant la fin de la temporisation.). PID = 10996.
Pour les flux UDP, l'eventid 1169 (ou 1170) donne le même type d'informations :
UDP : point de terminaison 0xfffffa8032e7aec0 (AdresseLocale = 192.168.100.21:63317, AdresseDistante = 192.168.151.6:53) envoi de 1 messages et d’un total de 45 octets. PID = 1140.
L'eventid 1 du fournisseur Microsoft-Windows-Kernel-Process donne l’information d'un démarrage de processus :
Le processus 10996 a démarré à […] avec le nom \Device\HarddiskVolume1\Windows\System32\net.exe.
L'eventid 6 donne l'information d'un déchargement d'une image :
Le processus 1140 contenait une image déchargée nommée Device\HarddiskVolume1\Windows\System32\nslookup.exe.
La vue XML dans l'onglet permet alors d'observer l'identité sous laquelle le processus est (ou était) exécuté grâce à l'attribut UserID du nœud Security présent dans l'entête de l’événement.
Afin de filtrer le journal uniquement sur ces événements, une solution est de créer une vue personnalisée dans l'observateur d'événement.
Pour cela, cliquer sur et par le menu contextuel choisir . Cocher et choisir le journal enregistré précédemment créé. Dans l'onglet , cocher Valider le message d'avertissement et appliquer le filtre Xpath suivant :
<QueryList>
<Query Id="0" Path="file://C:\PerfLogs\...\DataCollector01.evtx">
<Select Path="file://C:\PerfLogs\...\DataCollector01.evtx">
*[System[Provider[@Name='Microsoft-Windows-TCPIP'] and (EventID=1044 or EventID=1169 or EventID=1170)]]
</Select>
<Select Path="file://C:\PerfLogs\...\DataCollector01.evtx">
*[System[Provider[@Name='Microsoft-Windows-Kernel-Process'] and (EventID=1 or EventID=6)]]
</Select>
</Query>
</QueryList>
Nommer l'affichage personnalisé et valider.
Depuis cette vue personnalisée, il suffit alors de rechercher l'adresse IP destination suspecte dans le journal via l'action . Cette fonction de recherche se base sur les informations d'affichage : elle est dépendante de la langue du système. Une fois le PID du processus communiquant trouvé, une recherche est alors effectuée pour savoir si ce processus a été déchargé ou non pendant la capture (en recherchant par exemple la chaîne processus valeur_du_PIDsur un système de langue française).
3. Considérations en traitement d’incidents
Le cas idéal est d'utiliser perfmon en gardant la machine à analyser toujours connectée et active sur son réseau d’origine (avec vraisemblablement les communications vers l'adresse destination bloquée par un pare-feu). Lorsqu’il est nécessaire de débrancher physiquement ou logiquement (par désactivation de sa carte réseau) la machine du réseau, la méthode présentée ne fonctionnera pas directement. En effet, les tentatives de communications réseaux sur une couche lien inactive ne remontent pas le PID. Il est nécessaire de garder une couche lien active et donc de prévoir de rebrancher la machine en réseau pour jouer cette méthode.
Afin de limiter les modifications sur la machine à analyser, le journal généré peut être enregistré directement sur un support amovible pour être ensuite analysé sur une machine d'analyse dédiée (prévoir une taille de fichier journal de l'ordre de 4 ou 5 Go pour une capture de 24h sur un poste bureautique). Une machine d'analyse fonctionnant sous Windows 7 (ou version ultérieure) est recommandée : elle possédera ainsi les fournisseurs utilisés sur la machine analysée, ce qui est nécessaire à l'interprétation des événements.
Il est possible de fractionner la sortie de la session en plusieurs journaux, en définissant une limite de durée et/ou de taille par journal. Cela permet d'éviter d'avoir à analyser un seul fichier volumineux. Pour définir ces limites, il faut éditer les paramètres du collecteur de données. Sous Windows 7 par exemple, dans le volet arborescence de perfmon, choisir le collecteur de données et par le menu contextuel choisir .
Interface de configuration des propriétés d'un collecteur de données.
Dans l'onglet , rubrique , cocher l’option et choisir une limite de durée et/ou de taille maximale. Lorsqu’une limite sera atteinte, les collecteurs seront redémarrés et un nouveau fichier sera créé.Il est également très utile de configurer le nom des répertoires générés afin d’y faire figurer leur date de création. Cela permet de cibler le fichier à analyser lorsque l’on connaît a posteriori l'horaire de la communication suspecte recherchée. Pour cela, éditer le situé dans l'onglet. En ajoutant la chaîne \-hhmmss, le nom des répertoires contiendra leur horaire de création.
Perfmon permet de planifier la capture et ne nécessite pas forcément un démarrage et un arrêt manuel. En éditant les paramètres du collecteur de données, choisir l'onglet , puis cliquer sur . La date et l'heure de début de la session peuvent être alors configurées. L'option de l'onglet permet de configurer la durée avant arrêt de la session. Depuis Windows Vista, le service journaux & alertes de performance (acronyme anglais : PLA) chargé de la journalisation des événements est exécuté par le moteur du planificateur de tâches Windows. Lors de la création d'un collecteur de données avec perfmon, une tâche est créée dans l'arborescence \Microsoft\Windows\PLA de la bibliothèque du planificateur de tâches Windows. Il est donc possible de profiter des options avancées du planificateur.
Enfin, il est à noter qu'une fois le collecteur démarré, il n'est pas nécessaire de garder une session ouverte sur le poste à analyser pour que la capture continue de fonctionner.
Conclusion
La méthode proposée a l’avantage de ne nécessiter aucune installation d’outil préalable (ni redémarrage quelconque) et d'être jouable sur toutes les versions de Windows depuis Windows XP. Elle présente également l'avantage d'avoir un impact minime sur les performances de la machine (un outil de mesure de performances se devant d'être le moins consommateur de ressources possible). Elle trouve donc toute sa place dans le cadre d’une analyse forensic live sur une machine Windows. Si la technique de détection du processus communicant sur le réseau est théoriquement contournable (injection de trame directement au niveau Ethernet, par exemple), l'utilisation de perfmon s’avère une méthode efficace dans la pratique.
Références
[1] Event tracing, http://msdn.microsoft.com/en-us/library/windows/desktop/bb968803(v=vs.85).aspx
[2] Network tracing in Windows 7 : Architecture, http://msdn.microsoft.com/en-us/library/dd569137.aspx
[3] Event Tracing MOF Classes, http://msdn.microsoft.com/en-us/library/windows/desktop/aa363799(v=vs.85).aspx
[4] Windows Events, http://msdn.microsoft.com/en-us/library/windows/desktop/aa964766(v=vs.85).aspx
[5] Improve Debugging And Performance Tuning With ETW, http://msdn.microsoft.com/en-us/magazine/cc163437.aspx
