Utilisation de l'analyseur de performances en live forensic Windows

Magazine
Marque
MISC
Numéro
77
|
Mois de parution
janvier 2015
|
Domaines


Résumé
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.

Body

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.

architecture_etw

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).

perfmon_win7_v2

Interface graphique de l'analyseur de performances sous Windows 7.

Dérouler le menu Ensemble de collecteurs de données situé dans le volet d’arborescence (gauche). Choisir Définis par l'utilisateur, effectuer un clic droit Nouveau > Ensemble de collecteurs de données. Nommer l'ensemble (on utilise ici le nom « forensic ») et choisir Créer manuellement (avancé). Cliquer sur Suivant et choisir Données de suivis d’événements. Cliquer sur Suivant et ajouter le fournisseur Suivi du noyau Windows. Choisir la propriété Mots clés (au choix) et cliquer sur Modifier. Cocher les cases process et net, 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 Terminer. 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 Démarrer. De la même façon, choisir Arrêter 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 Microsoft-Windows-TCPIP et Microsoft-Kernel-Process. Il faut modifier la propriété Propriétés de ce dernier fournisseur pour choisir de faire apparaître l'identité sous laquelle s’exécute un processus en cochant la case sid.

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 Ouvrir le journal enregistré 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 Observateurs d’événements > Journal enregistré.

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 Détails 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 Affichages Personnalisés et par le menu contextuel choisir Créer une vue personnalisée. Cocher Par Journal et choisir le journal enregistré précédemment créé. Dans l'onglet XML, cocher Modifier la requête. 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 Rechercher. 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 Propriétés.

propriete_collecteur_v2

Interface de configuration des propriétés d'un collecteur de données.

Dans l'onglet Condition d’arrêt, rubrique Limites, cocher l’option Redémarrer l’ensemble de collecteurs dès qu’une limite est atteinte 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 format du nom de sous-répertoire situé dans l'onglet Répertoire. 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 Planification, puis cliquer sur Ajouter. La date et l'heure de début de la session peuvent être alors configurées. L'option Durée globale de l'onglet Condition d'arrêt 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


Sur le même sujet

Stack Buffer Overflow

Magazine
Marque
MISC
HS n°
Numéro
21
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Cet article retrace un historique des stack buffer overflow tels qu'ils étaient exploités au début des années 2000 puis passe en détail les protections logicielles et matérielles qui ont été mises en œuvre pour les faire disparaître, ainsi que les mesures créées par les attaquants pour les contourner.

Les enjeux de sécurité autour d’Ethernet

Magazine
Marque
MISC
HS n°
Numéro
21
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Quand nous parlons attaque, cela nous évoque souvent exploit, faille logicielle, ou même déni de service distribué. Nous allons revenir à des fondamentaux réseaux assez bas niveau, juste après le monde physique, pour se rendre compte qu’il existe bel et bien des vulnérabilités facilement exploitables par un attaquant. Nous verrons également qu’il existe des solutions pour s’en protéger.

Introduction à Zero Trust 

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

La sécurité informatique adore les modes. Le « Zero Trust » fait partie de ces concepts qui sont devenus populaires du jour au lendemain. Et comme le sexe chez les adolescents, « tout le monde en parle, personne ne sait réellement comment le faire, tout le monde pense que tous les autres le font, alors tout le monde prétend le faire* ».

Anti-leurrage et anti-brouillage de GPS par réseau d’antennes

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

La localisation, la navigation et le transfert de temps (PNT) par constellation de satellites, et notamment le Système de Positionnement Global (GPS), sont devenus omniprésents dans notre quotidien. Le brouillage – volontaire ou non – et le leurrage de ces signaux très faibles sont désormais accessibles à tout le monde, mais les subir n’est pas une fatalité : nous allons aborder les méthodes pour se protéger de tels désagréments afin de retrouver les services d’origine en annulant ces interférants par une approche multi-antennes.

Partagez vos fichiers volumineux facilement et de manière sécurisée avec Firefox Send

Magazine
Marque
Linux Pratique
Numéro
120
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Firefox Send est un service de Mozilla de partage de fichiers en ligne. Pour des utilisateurs non techniques, qui ne sauraient pas utiliser un serveur FTP ou tout autre partage réseau, c’est une très bonne alternative web pour mettre en ligne des fichiers volumineux de manière simple. Il existe déjà de nombreux services similaires, parfois gratuits et souvent propriétaires. Dans cet article, nous allons voir comment utiliser ce service pour partager de manière sécurisée vos fichiers, et surtout pour héberger votre instance.

De l'utilisation d'une bibliothèque à l'exécution d'un code arbitraire

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Dans cet article, nous présentons une vulnérabilité de la version 3.1 de Commons Collections. Cette vulnérabilité, nommée « CommonsCollections1 », permet à un attaquant l’exécution d’un code arbitraire ou Remote Code Execution (RCE). Ce travail reprend certains concepts des deux articles publiés dans les versions précédentes de MISC en 2018 et 2019 [1,2].

Par le même auteur

Collecte de logs d’installations industrielles isolées

Magazine
Marque
MISC
Numéro
100
|
Mois de parution
novembre 2018
|
Domaines
Résumé

La mise en place d’un SOC est un projet bien moins technique qu’organisationnel. Dans le cadre de la supervision sécurité d’installations industrielles isolées, la collecte de logs peut cependant présenter quelques spécificités techniques qu’il semble intéressant d'aborder dans cet article.Les postes de supervision et les serveurs de contrôle-commande constituant un point d'entrée important vis-à-vis d'une malveillance informatique sur un système industriel, leurs journaux systèmes représentent une source d'informations intéressante à collecter. L'article propose un retour d'expérience sur la mise en œuvre d'une infrastructure de collecte des journaux Windows et de leurs transferts vers un SOC, dans le respect d'une exigence d'isolation.

Détecter la persistance WMI

Magazine
Marque
MISC
Numéro
91
|
Mois de parution
mai 2017
|
Domaines
Résumé
Les mécanismes de démarrage automatique de programme disponibles sous Windows sont nombreux. Le nombre d’onglets de l’outil Microsoft « Autoruns » suffit pour s’en convaincre. Parmi ceux-ci, l’utilisation de la technologie WMI (Windows Management Instrumentation) à des fins de persistance malveillante semble prendre de l’importance depuis quelques années. Rappelons qu’un tel mécanisme implique un contexte post-compromission (avec privilèges administrateur dans le cas présent). La persistance WMI a été abordée dans un précédent article de MISC n°80 (« WMI : la menace silencieuse ») qui permet de prendre la mesure des limites de la journalisation standard à des fins de détection. En effet, le challenge n’est pas tant de détecter cette persistance lors d’une analyse sur incident : des méthodes et outils existent pour l’identifier (si elle est toujours active). La véritable difficulté est de pouvoir alimenter facilement un SIEM afin de la détecter lors de son installation et permettre une réaction avant que la bombe logique n’explose. Seul Windows 10 marque une avancée dans ce domaine et en permet une détection native. L’article présente un axe d’amélioration possible pour les versions antérieures de Windows, permettant d’être plus réactif vis-à-vis de cette menace.

Utilisation de l'analyseur de performances en live forensic Windows

Magazine
Marque
MISC
Numéro
77
|
Mois de parution
janvier 2015
|
Domaines
Résumé
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.