FR 3035984 A1 20161111 FR 1553992 A 20150504 PROCEDE DE DETECTION D'UN LOGICIEL MALVEILLANT DOMAINE DE L'INVENTION L'invention se situe dans le domaine de la sécurité informatique. Elle s'applique, en particulier, à l'analyse du comportement de programmes informatiques afin de détecter un éventuel comportement malveillant. CONTEXTE DE L'INVENTION Il existe à ce jour divers outils permettant d'analyser des programmes malveillants (malwares en anglais), notamment présents sur des supports de stockage externes. Par ailleurs, lors de l'exécution d'un programme donné sur une machine, la mémoire vive (ou mémoire volatile) utilisée par le système d'exploitation installé sur cette machine est modifiée. Dans ce contexte, l'analyse de cette mémoire vive peut aider à déterminer la nature malveillante ou non du programme exécuté. Une telle analyse est généralement menée dans un environnement de test spécifique appelé machine virtuelle (ou sandbox en anglais), dans lequel le système d'exploitation a été préalablement installé. Cet environnement émule les différents éléments d'un ordinateur réel (processeur, mémoire vive, disque dur, carte réseau, etc.) afin de reproduire au mieux le contexte dans lequel s'exécute le programme. Il permet d'exécuter celui-ci dans un cadre contrôlé, sans mettre en péril la sécurité de l'ordinateur hôte. La détermination de la nature malveillante d'un programme suppose généralement l'instrumentation de la machine virtuelle dans lequel il s'exécute, pour permettre l'analyse in situ du contenu de la mémoire vive virtuelle. Toutefois, une telle instrumentation est de mieux en mieux détectée par les programmes malveillants, qui adaptent leur comportement en conséquence. De fait, les malwares sont de plus en plus furtifs et parviennent même pour certains à se comporter de manière totalement transparente pour le système d'exploitation, par exemple en utilisant des fonctions non-documentées ou encore en modifiant directement la mémoire vive utilisée par le système d'exploitation afin d'altérer certaines structures de données pouvant potentiellement les faire repérer. Certains processus cachés (rootkits en anglais), peuvent ainsi agir de manière 3035984 2 malveillante sur le système d'exploitation, à l'insu de celui-ci mais aussi à l'insu des programmes visant à analyser leur comportement. Face à l'augmentation du nombre de programmes malveillants et au perfectionnement de leurs techniques de détection, il existe un besoin pour un procédé 5 d'analyse adapté permettant notamment d'identifier les programmes malveillants furtifs (rootkits en anglais). RESUME DE L'INVENTION La présente invention a ainsi pour objet de pallier au moins un de ces 10 inconvénients. Dans ce contexte, un premier aspect de l'invention concerne un procédé d'analyse d'un programme, caractérisé en ce qu'il comprend les étapes suivantes : capture d'un premier état de la mémoire vive d'une machine virtuelle dans laquelle est installé un système d'exploitation ; 15 lancement de l'exécution dudit programme dans ladite machine virtuelle ; après une durée prédéterminée, capture d'un second état de la mémoire vive de ladite machine virtuelle ; analyse comparative du premier et du second états capturés ; et identification d'au moins un marqueur de compromission dudit programme, 20 en fonction du résultat de l'analyse comparative. Ainsi, l'invention permet l'analyse d'un programme afin de déterminer sa nature malveillante ou non, sans mettre en péril la sécurité de l'ordinateur hôte sur lequel il s'exécute et sans que ce programme s'aperçoive qu'il est analysé. En effet, le programme est exécuté dans une machine virtuelle qui émule 25 les attributs habituels d'un ordinateur tout en isolant le programme des composants essentiels au fonctionnement de l'hôte. De plus, les captures d'état (ou image) de la mémoire vive de la machine virtuelle permettent d'obtenir des informations sur l'état de cette mémoire vive à un instant donné, sans intervention in situ. Ainsi, le comportement du programme et les 30 effets de son exécution ne seront pas modifiés par rapport à un contexte classique d'exécution (par exemple non sécurisé) puisque le programme ne perçoit pas d'intervention particulière lors de la capture de l'état de la mémoire vive. La comparaison de ces captures permet ainsi de rendre compte du comportement et des effets réels du programme afin de repérer la présence de 3035984 3 marqueurs de compromission caractéristiques permettant de conclure sur la nature malveillante du programme. D'autres caractéristiques du procédé selon des modes de réalisation de l'invention sont décrites dans les revendications dépendantes. 5 Dans des modes particuliers de réalisation, l'analyse comparative du premier et du second état capturés comprend les étapes suivantes : parcours, au sein desdites captures, de structures de données parmi une liste de structures de données prédéterminées ; et évaluation d'au moins un critère de compromission basé sur une 10 comparaison desdites structures de données entre les premier et second états capturés. Avantageusement, l'analyse comparative ne porte pas sur l'intégralité des structures de données du système mais se focalise sur des structures connues comme sensibles, limitant ainsi la durée de l'analyse. 15 Dans des modes particuliers de réalisation, le procédé comprend également l'affichage, en fonction dudit au moins un marqueur de compromission identifié, d'un graphe reliant lesdites structures de données parcourues répondant audit critère de compromission évalué. L'affichage d'un tel graphe permet avantageusement d'extraire l'essentiel 20 des informations relatives à l'aspect malveillant du programme analysé. Par exemple, les structures de données prédéterminées présentes dans la liste sont par exemple relatives à des processus, des pilotes, des connexions réseau, des gestionnaires d'objets, ou encore des tables de descripteurs d'interruptions. Le critère de compromission diffère selon la nature des structures de 25 données parcourues. Dans des modes particuliers de réalisation, la durée prédéterminée est égale ou supérieure à la durée d'une phase de décompression du code dudit programme. Ainsi, l'image capturée reflète bien l'état de la mémoire vive après que le 30 programme ait commencé à s'exécuter. Par exemple, la durée prédéterminée est égale à 10 minutes. Dans des modes particuliers de réalisation, les différentes étapes du procédé précité sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre par un 3035984 4 microprocesseur, ce programme comprenant des instructions adaptées à la mise en oeuvre des étapes du procédé tel que mentionné ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code 5 source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un microprocesseur, et comprenant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. 10 Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple une ROM de microcircuit, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou encore une mémoire flash. 15 D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur une plateforme de stockage d'un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans 20 lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Le support d'informations et le programme d'ordinateur précités présentent des caractéristiques et avantages analogues au procédé qu'ils mettent en oeuvre. 25 BREVE DESCRIPTION DES FIGURES D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les figures ci-jointes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures : 30 - La Figure 1 représente sous forme d'organigramme des étapes générales d'un procédé d'analyse conforme à des modes de réalisation de l'invention ; - Les Figures 2 et 3 représentent sous forme d'organigrammes des exemples d'étapes d'analyse comparative, conformes à des modes de réalisation particuliers de l'invention ; 3035984 5 - La Figure 4 est constituée par les Figures 4a, 4b et 4c, avec les Figures 4a et 4b qui illustrent un exemple de données utilisées pour construire le graphe de la Figure 4c pouvant être affiché lors de la mise en oeuvre d'un procédé d'analyse conforme à des modes de réalisation de l'invention. 5 DESCRIPTION DETAILLEE DE L'INVENTION Un des objectifs de l'invention est d'obtenir des informations pertinentes sur le comportement d'un programme suspect, de manière non détectable par celui-ci. Pour ce faire, une analyse dite post-mortem (forensics en anglais) de la mémoire vive 10 est réalisée à l'extérieur de la machine virtuelle (sandbox) dans laquelle le programme suspect s'exécute. Autrement dit, il s'agit de capturer l'état de la mémoire vive du système (c'est-à-dire une image de celle-ci) avant exécution du programme suspect et de le comparer avec un état ultérieur de la mémoire vive de ce système, capturé après le lancement de l'exécution du programme suspect. 15 Dans ce document, une machine virtuelle est un programme informatique qui, lorsqu'il s'exécute sur un ordinateur hôte, permet d'émuler les ressources matérielles d'un ordinateur virtuel et leur fonctionnement. Cet ordinateur virtuel peut alors, tout comme un ordinateur classique, être doté d'un système d'exploitation, identique ou différent de celui de l'ordinateur hôte, et exécuter tout programme 20 informatique compatible avec ce système d'exploitation. Le fonctionnement de l'ordinateur virtuel est indépendant du fonctionnement du système hôte qu'il ne peut corrompre. Ces techniques de virtualisation sont aujourd'hui bien connues et largement utilisées dans divers domaines de l'informatique. On peut, par exemple, citer les produits de virtualisation fournis par la société VMware (marque déposée). 25 Dans les exemples suivants, le système d'exploitation installé dans la machine virtuelle est Windows (marque déposée). Toutefois, l'invention n'est pas limitée à ce système d'exploitation, et peut s'appliquer à d'autres systèmes d'exploitation comme Linux (marque déposée), ou encore Android (marque déposée). A titre d'exemple, des modes de réalisation de la présente invention peuvent 30 notamment permettre de détecter, notamment par l'analyse de la mémoire du système, certains rootkits Linux dont le but est de détourner des appels système en supprimant les routines de gestion de ces appels système. La Figure 1 représente des étapes générales d'un procédé d'analyse selon l'invention. 3035984 6 Le système Windows gère sa mémoire via certaines structures de données, par exemple les structures EPROCESS pour les processus. Ces structures de données sont généralement chaînées par des pointeurs. Dans l'exemple représenté, un état initial Si de la mémoire vive du 5 système exécuté dans la machine virtuelle est capturé au cours d'une étape EO en utilisant typiquement une fonction de capture de la machine virtuelle. Cette capture est externe à la machine virtuelle et n'a pas d'impact détectable au sein de celle-ci. De manière générale, une telle capture, aussi appelée image ou dump en anglais, permet d'accéder à des structures de données afin par exemple de les parcourir de proche en 10 proche. Il est également possible de les parcourir en détectant leur signature, c'est-à- dire par exemple en repérant une ou plusieurs séquence(s) de bits caractéristique(s) de ces structures. En pratique, à partir de l'image capturée Si, on recherche une structure de données interne du système comprenant des informations sur le processeur en cours 15 d'utilisation par le système. Cette structure comprend également des pointeurs vers d'autres structures d'intérêt telles que les processus actifs, les connexions réseau actives, les pilotes chargés, etc. On cherche à établir une cartographie d'un ensemble de structures bien choisies du système d'exploitation. Ces structures particulières sont choisies car elles comportent des éléments susceptibles d'être modifiés par un 20 programme cherchant à dissimuler son activité. Certaines modifications de ces structures par un programme permettent donc de suspecter un comportement malveillant, elles peuvent caractériser ce qu'on appelle par la suite des marqueurs de compromission. Le choix des structures étudiées est fait préalablement et résulte d'une expertise du fonctionnement du système d'exploitation. A noter que ces structures sont 25 identifiables facilement car ce sont des éléments documentés pour le système Windows. Bien entendu, l'invention n'est pas limitée à ces éléments, comme on le verra par la suite. A titre d'exemple pour le système Windows, un outils appelé Windows debugger permet d'accéder à la structure KPCR (pour Kernel Processor Control 30 Region) à partir de l'image capturée Si. Bien entendu, d'autres moyens peuvent permettre d'accéder à cette structure, comme par exemple le logiciel Volatility développé par la Volatility Foundation. En pratique, la définition de la structure KPCR se trouve par exemple à l'adresse virtuelle OxFFDFF000 de l'image capturée Si, pour les systèmes d'exploitation Windows XP. 3035984 7 La structure KPCR comprend un certain nombre d'entrées pouvant comprendre des pointeurs vers d'autres structures. Notamment, les entrées appelées I DT ou PrcbData. ProcessorState.Special Reg isters.Idtr pointent vers une structure 5 représentant une table des descripteurs d'interruptions du système, dont chaque entrée pointe vers une structure appelée KIDTENTRY apportant des informations sur une interruption particulière. Egalement, l'entrée KdVersionBlock de la structure KPCR mène vers la structure DBGKD GET VERSION64, qui elle-même comprend une entrée 10 DebuggerDataList contenant un pointeur vers la structure LIST ENTRY. Le premier élément de cette structure pointe vers la structure KDDEBUGGER DATA64 qui contient de nombreux pointeurs utiles dans le cadre de l'analyse d'un programme suspect selon l'invention, par exemple : l'entrée PsActiveProcessHead pointe vers une structure EPROCESS 15 représentant le premier processus actif d'une liste chaînée de processus actifs liés par des pointeurs ; l'entrée PsLoadedModuleList pointe vers une structure LDR DATA TABLE ENTRY représentant le premier pilote chargé d'une liste chaînée de pilotes chargés liés par des pointeurs ; 20 l'entrée ObpRootDirectoryObject pointe vers une structure Object Directory représentant la racine du gestionnaire d'objet Windows. De retour au procédé de la Figure 1, au cours d'une étape E2, l'exécution d'un programme suspect à analyser est lancée dans la machine virtuelle. En pratique, 25 ce lancement est suivi d'une période d'attente E3. Le but de cette attente est de garantir que le programme étudié ait commencé son exécution. En effet, certains programmes malveillants utilisent des outils d'encodage et/ou de chiffrement appelés packers en anglais permettant d'obfusquer leur code ou une partie de celui-ci et ainsi empêcher ou ralentir une analyse statique et/ou 30 dynamique de celui-ci. Ainsi, avant toute chose, ces programmes malveillants doivent effectuer l'opération inverse de décodage (dé-packing en anglais), avant de pouvoir s'exécuter sur la machine cible (ici la machine virtuelle). L'analyse doit donc débuter après cette phase de décodage pour être pertinente, car généralement c'est seulement après cette phase que commence l'exécution « utile » du programme suspect, c'est-à- 35 dire celle qui produit des effets sur le système. 3035984 8 La durée de l'étape E3 est donc au moins égale à la durée d'une phase de décompression du code du programme et varie selon le type de « packing » utilisé. En particulier le type des opérations cryptographiques utilisées pour l'obfuscation joue sur le temps de décodage. De plus, certains programmes malveillants ont recours à des 5 temporisations visant à retarder leur exécution. Les inventeurs ont déterminé que la durée du décodage, correspondant ici au décodage proprement dit et à d'éventuelles temporisations initiales, dépasse souvent les 6 minutes. De façon avantageuse, allonger la période d'attente E3 jusqu'à 10 minutes procure des résultats d'autant plus satisfaisants, et ce pour une grande 10 partie des programmes malveillants existants. Bien évidemment, cette durée d'attente pourra être modifiée et adaptée à l'évolution des programmes malveillants. Au cours d'une étape E4, une seconde capture d'état S2 (c'est-à-dire une image) de la mémoire vive est réalisée, toujours à l'extérieur de la machine virtuelle. Cette étape est similaire à l'étape EO de capture de l'état Si. Les deux images 15 capturées Si et S2 sont ainsi comparables. Au cours d'une étape E6, une analyse comparative différentielle des images capturées Si et S2 est mise en oeuvre à l'extérieur de la machine virtuelle. Cette analyse comparative différentielle a notamment pour but d'extraire les éléments des structures de données qui ont été modifiés, ajoutés ou supprimés, au 20 cours du fonctionnement normal du système ou par l'action du programme suspect dont l'exécution a été lancée à l'étape E2, lequel est potentiellement malveillant. En pratique, compte tenu du nombre important de structures accessibles pour une image, seulement certaines structures de données particulières prédéterminées sont parcourues. Ces structures particulières, dont quelques exemples 25 ont été donnés précédemment, représentent par exemple des processus actifs, des pilotes chargés, des descripteurs d'interruption, des connexions actives ou des demandes de connexion (socket). D'autres types de structures de données peuvent être examinés, par exemple relatifs aux appels systèmes, aux clés de registre, ou à d'autres fichiers. 30 Il s'agit ensuite d'évaluer au moins un critère de compromission basé sur une comparaison desdites structures de données entre les premier et second états de la mémoire vive capturés aux étapes EO et E4. Divers critères de compromissions peuvent être évalués, selon le type de structure examiné. Par exemple, le critère de compromission peut être : 3035984 9 la disparition d'un processus de la liste des processus actifs, alors que ce processus n'est pas indiqué comme terminé, signalant ainsi un processus déchaîné de la liste des processus ; l'apparition inexpliquée d'une tâche (thread en anglais) supplémentaire 5 dans un processus ; le chargement d'un nouveau pilote pourtant absent de la liste des nouveaux pilotes chargés; la disparition d'un pilote de la liste des pilotes chargés, alors que ce pilote n'est pas déchargé, signalant qu'un pilote a été déchaîné de la 10 liste des pilotes ; le déchargement inexpliqué d'un pilote ; l'ouverture inattendue d'un port par un processus suspect; la modification inexpliquée du gestionnaire d'objets, par exemple création d'un sémaphore d'utilisation exclusif d'une ressource (mutex 15 en anglais) ; la modification d'un descripteur d'interruption devenu non intègre. En pratique, pour pouvoir conclure qu'un programme est malveillant, il faut repérer un faisceau d'indices rendant le programme particulièrement suspect. Autrement dit, la vérification de certains critères de compromission peut ne 20 pas suffire pour conclure avec une certitude raisonnable sur le caractère malveillant d'un programme. C'est le cas par exemple de la création d'un port réseau, ou encore d'un mutex. En effet, la création d'un nouveau port réseau (ou d'un mutex) n'est pas, en soi, un évènement préjudiciable ou néfaste pour le système. Toutefois, un tel évènement deviendra critique lorsqu'il est causé par exemple par un processus qui a 25 disparu de la liste des processus actifs, alors que ce processus n'est pas indiqué comme terminé. Ainsi, au cours d'une étape E8, au moins un marqueur de compromission est identifié, en fonction du résultat de l'étape E6. Par exemple, la disparition d'un processus de la liste des processus actifs alors que ce processus n'est pas indiqué 30 comme terminé, permet d'identifier le déchaînage d'un processus de la liste des processus, c'est-à-dire un processus caché. Selon un autre exemple, le chargement d'un nouveau pilote absent de la liste des nouveaux pilotes chargés ou la disparition d'un pilote de la liste des pilotes chargés permet d'identifier un pilote caché. Ainsi, l'analyse des captures successives permet de faciliter la détection 35 des processus cachés (rootkits en anglais), et de déterminer plus précisément le 3035984 10 comportement des programmes malveillants complexes, y compris lorsqu'ils sont furtifs. Au cours d'une étape optionnelle E10, certaines structures parcourues présentant un intérêt particulier, par exemple parce qu'elles vérifient le critère de 5 compromission évalué à l'étape E8, peuvent être affichées sous forme d'un graphe. Cette cartographie a l'avantage de présenter essentiellement les informations pertinentes du système relatives au comportement malveillant du programme analysé. Plusieurs exemples d'analyse comparative, correspondant à l'étape E6 décrite précédemment, vont maintenant être décrits en référence aux Figures 2 et 3. 10 La Figure 2 représente un exemple détaillé d'analyse comparative, conforme à un premier mode de réalisation particulier, dans lequel les structures parcourues représentent chacune un processus. Ainsi, on cherche dans cet exemple à déterminer le comportement du programme dont l'exécution a été lancée à l'étape E2 de la Figure 1 par rapport aux 15 processus. Dans cet exemple, ce sont des structures EPROCESS. Chaque structure EPROCESS décrit les principaux paramètres liés à un processus, à savoir l'identifiant du processus (PID), son nom, le nombre de tâches en cours associées, la date et l'heure de création, etc. 20 Tel qu'évoqué précédemment, une structure EPROCESS peut être accédée via l'entrée PsActiveProcessHead de la structure KDDEBUGGER DATA64, qui comprend un pointeur vers le premier processus (i.e. la première structure EPROCESS) d'une liste chaînée des processus actifs (i.e. des structures EPROCESS). Dans chaque structure EPROCESS, l'entrée ActiveProcessLinks 25 contient un pointeur vers le processus EPROCESS suivant. Ainsi, une liste de processus est obtenue en parcourant ces pointeurs de proche en proche. L'invention n'est pas limitée au pointeur de l'entrée PsActiveProcessHead, et d'autres listes chaînées de processus actifs peuvent être accédées pour le système Windows par d'autres biais. 30 Au cours d'une étape E20, la liste des processus obtenue à partir de la première image capturée Si et la liste des processus obtenue à partir de la deuxième image capturée S2 sont parcourues. Il peut être utile à ce stade de les comparer, afin par exemple d'évaluer un premier critère de compromission. Par exemple, ce critère de compromission correspond à une différence du 35 nombre de tâches (threads en anglais) associées à un processus donné entre les deux 3035984 11 images capturées Si et S2. Ce changement peut être légitime ou non. En effet, une tâche supplémentaire peut signifier que le programme malveillant s'est injecté dans ce processus afin d'être plus furtif. Par ailleurs, comme évoqué précédemment, certains programmes 5 malveillants ont la capacité de supprimer les pointeurs vers les processus modifiés par leur exécution. De telles modifications passent alors inaperçues lors du parcours de la liste chaînée des processus. Or, le fait qu'un processus apparaisse ou non dans la chaîne des EPROCESS n'affecte en rien le fait qu'il soit ordonnancé ou non par le système d'exploitation. Autrement dit, la suppression d'un pointeur ne supprime pas la 10 structure EPROCESS visée par ce pointeur. En effet, si celle-ci disparait de la liste chaînée des processus lorsqu'on les parcourt de proche en proche, il n'en demeure pas moins que le processus correspondant est toujours actif. Dans le but de contourner cette difficulté, au cours d'une étape E22, les structures EPROCESS peuvent être parcourues indépendamment des pointeurs entre 15 ces processus, afin de repérer les éventuelles incohérences existant entre les parcours des images capturées Si et S2. En pratique, la récupération des structures EPROCESS est réalisée par signature. Il s'agit de repérer une ou plusieurs séquence(s) de bits caractéristique(s) des structures EPROCESS dans les images capturées Si et S2. On peut ensuite déterminer une incohérence entre les deux 20 images, par exemple une structure présente dans l'une des images et pas dans l'autre. Ainsi, le fait d'afficher et de parcourir les structures de plusieurs manières différentes puis de la comparer permet de confondre le programme malveillant qui chercherait à cacher certains indicateurs de son caractère malveillant. Au cours d'une étape E24, pour chaque structure EPROCESS présentant 25 une incohérence entre les deux images capturées Si et S2, on détermine si la structure correspond à un processus toujours en cours d'exécution. En pratique, on récupère la valeur d'un code de retour (par exemple dans l'entrée ExitStatus). Puis, si le code de retour indique que le processus n'est plus en cours d'exécution, cela signifie que le processus est simplement terminé. 30 En revanche, si le code de retour indique que le processus est en cours d'exécution, on vérifie si le processus en question apparait dans la liste chaînée correspondant à la capture initiale Si (avant l'exécution du programme à analyser). Si ce processus actif (i.e. identifié par son PID) est absent de la liste chaînée avant exécution du programme, cela indique que le pointeur vers la structure EPROCESS 35 correspondante a été supprimé. 3035984 12 Ainsi, au cours de cette étape E24, un autre critère de compromission est évalué, à savoir la disparition d'un processus actif d'une capture d'état à une autre. La vérification de l'ensemble des critères de compromission (ici, le premier critère et le second critère mentionnés ci-avant) permet d'identifier un marqueur de 5 compromission à l'étape E26 du procédé, à savoir un processus caché. En revanche, si par exemple on observe uniquement une modification du nombre de tâches, sans détecter de processus caché (étape E24), l'analyse comparative des images ne permettra pas d'identifier de marqueur de compromission relatif à un processus caché pour ce programme. Dans une première variante de ce 10 premier mode de réalisation, on considère des pilotes (drivers en anglais) à la place des processus. Ainsi, on cherche dans cette variante à déterminer le comportement du programme dont l'exécution a été lancée à l'étape E2 (voir Figure 1) par rapport aux pilotes chargés dans la machine virtuelle. Ces pilotes sont représentés par des structures de type 15 LDR DATA TABLE ENTRY. On accède à la liste chaînée des pilotes chargés via l'entrée PsLoadedModuleList de la structure KDDEBUGGER DATA64. Dans chaque structure LDR DATA TABLE ENTRY, l'entrée InLoadOrderLinks contient un pointeur vers le pilote suivant. Ainsi l'étape d'analyse comparative basée sur les structures représentant des pilotes est très similaire à celle décrite pour les structures 20 EPROCESS. Cette première variante de réalisation permet également de détecter les programmes malveillants furtifs en recherchant les pilotes nouvellement chargés à l'aide de leur signature (et indépendamment des pointeurs), mais n'apparaissant pas comme tel dans la liste chaînée des structures LDR DATA TABLE ENTRY. De même que décrit précédemment pour les processus, il s'agit de repérer les séquences de bits 25 caractéristiques des structures de type LDR DATA TABLE ENTRY à l'intérieur des images capturées. Dans une seconde variante envisageable du premier mode de réalisation décrit ci-dessus, plus haut-niveau dans le système, les structures parcourues au cours de l'analyse comparative appartiennent au gestionnaire d'objets du système. Pour 30 rappel, le gestionnaire d'objets est un arbre de structures utilisé pour stocker l'état de certains objets nécessaires au bon fonctionnement du système d'exploitation. L'étude des nouveaux objets dans ce gestionnaire (ou la modification d'objets existants) peut donner des indications pertinentes sur l'aspect potentiellement malveillant du programme dont l'exécution a été lancée à l'étape E2 (voir Figure 1), comme par 3035984 13 exemple l'apparition d'objets suspects pointant vers un nouveau périphérique, ou encore un nouveau pilote. Tel qu'évoqué précédemment, le gestionnaire d'objet peut être accédé via l'entrée ObpRootDirectoryObject de la structure KDDEBUGGER_DATA64, qui 5 comprend un pointeur vers la structure Object Directory représentant la racine du gestionnaire d'objet Windows. Cette structure racine comprend une entrée pointant vers un tableau HashBuckets listant les éléments de chaque niveau hiérarchique, chacun étant une liste chaînée de structures OBJECT DIRECTORY ENTRY correspondant soit à une feuille de l'arbre ou être de type Directory, auquel cas on peut 10 la parcourir de manière récursive de la même manière que la racine pour au final récupérer tous les éléments du gestionnaire. Dans cette seconde variante, on peut évaluer plusieurs critères de compromission correspondant à l'apparition d'objets (i.e. de structures OBJECT DIRECTORY ENTRY) suspects, pointant par exemple vers un nouveau 15 périphérique, un nouveau pilote ou encore un nouveau Mutex. La vérification de ces critères pourra permettre d'identifier des marqueurs de compromission caractéristiques du caractère malveillant du programme exécuté. A titre d'exemple non limitatif, une nouvelle structure OBJECT DIRECTORY ENTRY pointant vers un objet représentant le périphérique 20 \Device\TCPZ-X85D est repérée au cours de l'analyse comparative entre les images capturées Si et S2 (voir étape E6 de la Figure 1). En l'occurrence, l'apparition de ce nouveau périphérique, qui constitue un marqueur de compromission, est observée suite à l'exécution d'un programme malveillant (étape E2 de la Figure 1) appelé Neeris, qui modifie les paramètres TCP/IP du système pour augmenter le nombre de paquets 25 pouvant être envoyés par seconde, permettant ainsi d'augmenter le taux d'infection lors d'une propagation par exploitation d'une vulnérabilité distante. On observe également l'apparition d'un nouvel objet de type Pilote (voir première variante) nommé \Driver\sysdrv32 ainsi qu'un nouvel objet de type Mutex, nommé LxLXsithwarlordXLxL. A noter que le nom des nouveaux objets peut parfois 30 faciliter le repérage d'un programme malveillant. Selon une troisième variante du premier mode de réalisation, on s'intéresse aux descripteurs d'interruptions représentés par des structures KIDTENTRY accessibles via la table des descripteurs d'interruptions du système, elle-même accessible via des pointeurs compris dans les entrées IDT ou 35 PrcbData.ProcessorState.SpecialRegisters.Idtr de la structure KPCR. 3035984 14 Pour rappel, les descripteurs d'interruptions permettent de prévoir le code qui sera exécuté dans le cas où une telle interruption se produit. Ainsi, ces structures sont particulièrement vulnérables et sont donc souvent visées par les programmes malveillants qui pourront les utiliser pour faire exécuter du code malveillant. De plus, 5 comme le système Windows utilise un modèle pour instancier ces structures, la modification de ce modèle entraine la modification de toutes ces instances. Un critère de compromission à évaluer peut ainsi être par exemple la modification de ce modèle et/ou l'intégrité de certains descripteurs d'interruptions. La modification du modèle constitue un marqueur de compromission 10 lorsqu'elle est initiée par un processus non identifié. De même, en fonction de la nature et de son origine, la modification de certains descripteurs d'interruption peut être identifiée comme un marqueur de compromission. Toutes ou partie de ces variantes peuvent être avantageusement combinées dans certains modes de réalisation augmentant ainsi la fiabilité de la détection des programmes malveillants. 15 La Figure 3 représente un exemple détaillé d'analyse comparative (voir étape E6 de la Figure 1), conforme à un second mode de réalisation particulier, dans lequel les structures parcourues sont relatives à l'activité du réseau. Ainsi, on cherche dans cet exemple à déterminer le comportement du programme dont l'exécution a été lancée à l'étape E2 (voir Figure 1) par rapport à 20 l'activité réseau. Par exemple, on détermine si le programme analysé a mis en écoute un port de communication. Sur Windows XP, deux principales structures de données stockent les informations liées au réseau, à savoir les structures ADDRESS OBJECT représentant des prises réseau (Socket en anglais) dès lors qu'une activité réseau est demandée, et 25 les structures TCPT OBJECT lorsque des connexions sont effectivement établies avec un tiers. De même que décrit en référence à l'étape E22 de la Figure 2, cette détection utilise la signature spécifique de ces structures de données, par exemple des séquences de bits caractéristiques de celles-ci. Ainsi, au cours d'une étape E30, les 30 structures de prise réseau et les structures de connexion sont parcourues à partir des images capturées Si et S2. Puis, au cours d'une étape E32, le port local associé à chaque structure ADDRESS OBJECT, correspondant à une prise réseau, récupéré à l'étape E30 est identifié. 3035984 15 Au cours d'une étape E34, on évalue le critère de compromission suivant : absence du port local récupéré à l'étape E32 des structures de connexion parcourues à l'étape E30. Ce critère est notamment vérifié lorsque le port est sur écoute, ce qui permet d'identifier le port comme un marqueur de compromission (étape E36). 5 La Figure 4 constituée des Figures 4a, 4b et 4c illustre un exemple de données pour construire le graphe affiché à l'issu de l'analyse comparative, tel que décrit en référence à l'étape E10 de la Figure 1, ainsi que le graphe lui-même. L'état d'une machine virtuelle est stocké sous la forme d'une suite de structures Python contenant le détail (nom, valeur) des différents champs et de liens 10 entre ces structures, sous forme sérialisée (module cPickle de Python). Un des objectifs de l'invention étant de réaliser une cartographie visuelle de la mémoire vive ou du moins des structures de données parcourues répondant aux critères de compromission évalués décrit précédemment, chaque pointeur entre structures pertinentes est sauvegardé dans une chaîne de caractères respectant le 15 langage de description de graphes DOT. La Figure 4a représente la liste ordonnée 40 des liens récupérés depuis la lecture de la structure KPCR 41, en passant par le parcours complet 42 de la liste chaînée des processus (structures EPROCESS), jusqu'à la boucle finale sur l'entrée PsActiveProcessHead. 20 Sur la Figure 4b apparait un exemple de structure 45 stockant les informations sur un processus. La structure 45 comprend notamment le nom 46 du processus, la structure correspondante 47, ainsi qu'un commentaire 48 indiquant qu'il s'agit d'un processus caché. La Figure 4c représente le graphe correspondant aux données des 25 Figures 4a et 4b, notamment la liste chaînée 42 des processus (structures EPROCESS) de la Figure 4a. Sur cette figure, les processus actifs chaînés sont référencés 400-1 à 400- 15. Les lignes en grisé référencées 415-1 à 415-8 correspondent à des éléments nouveaux ou modifiés détectés lors de l'analyse comparative des captures de la 30 mémoire vive. En l'occurrence, la mise en oeuvre de l'analyse comparative a permis de repérer deux processus particuliers 420 et 425, qui n'apparaissent pas dans la liste chaînée des processus 400-1 à 400-15. Le processus 420 est absent de la liste chaînée des processus actifs, mais dans cet exemple, ce processus est terminé. Par conséquent, il ne s'agit pas d'un 3035984 16 processus caché. Cette information est affichée en commentaire dans la ligne grisée du processus 420. En revanche, le processus 425, qui est également absent de la liste des processus actifs, n'est pas indiqué comme terminé dans le champ pertinent. En 5 conséquence, il s'agit d'un marqueur de compromission du programme, représentant un processus caché. Cette information est affichée en commentaire dans la ligne grisée du processus 425. Au vu de ces marqueurs affichés, il est désormais possible de conclure quant à la nature malveillante du programme exécuté. 10 De plus, l'invention permet d'obtenir des informations pertinentes sur le comportement du programme et notamment sur ses effets, comme par exemple la création d'un mutex particulier ou d'un port, notamment grâce au faisceau d'indices révélé lors de l'analyse comparative. Avantageusement, de telles informations sont mises à disposition de 15 l'utilisateur d'une manière intelligente, puisqu'elles ne sont pas noyées dans la masse des informations relatives au fonctionnement normal du système (création classique de ports, de mutex, de processus, fermeture de processus, etc.). Par exemple, le processus 425 affiché à côté du graphe sur la Figure 4c permet de d'indiquer clairement des caractéristiques du malware correspondant, à 20 savoir le fait que son exécution a pour effet de créer un processus caché, car il est encore à l'état actif bien que non présent dans la liste chainée des processus. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas. Tous ces modes de réalisation sont librement combinables entre eux. 25 REVENDICATIONS1. Procédé d'analyse d'un programme, caractérisé en ce qu'il comprend les étapes suivantes : capture (E0) d'un premier état de la mémoire vive d'une machine virtuelle dans laquelle est installé un système d'exploitation ; lancement (E2) de l'exécution dudit programme dans ladite machine virtuelle ; après une durée prédéterminée (E3), capture (E4) d'un second état de la mémoire vive de ladite machine virtuelle ; analyse comparative (E6) du premier et du second états capturés ; et identification (E8) d'au moins un marqueur de compromission dudit programme, en fonction du résultat de l'analyse comparative. 2. Procédé d'analyse selon la revendication 1, caractérisé en ce que ladite analyse comparative (E6) du premier et du second état capturés comprend les étapes suivantes : parcours, au sein desdites captures, de structures de données parmi une liste de structures de données prédéterminées ; et évaluation d'au moins un critère de compromission basé sur une comparaison desdites structures de données entre les premier et second états capturés. 3. Procédé d'analyse selon la revendication 2, caractérisé en ce qu'il comprend l'affichage (El 0), en fonction dudit au moins un marqueur de compromission identifié, d'un graphe reliant lesdites structures de données parcourues répondant audit critère de compromission évalué. 4. Procédé d'analyse selon l'une quelconque des revendications 2 à 3, caractérisé en ce que ladite liste de structures de données prédéterminées comprend des structures de données relatives à certains éléments de la liste suivante : processus, pilotes, connexions réseau, gestionnaires d'objets, tables de descripteurs d'interruptions. 3035984 18 5. Procédé d'analyse selon l'une quelconque des revendications 1 à 4, caractérisé en ce que la durée prédéterminée correspond à la durée d'une phase de décompression du code dudit programme. 5 6. Procédé d'analyse selon la revendication 5, caractérisé en ce que la durée prédéterminée est égale à 10 minutes. 7. Procédé d'analyse selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ledit au moins un marqueur de compromission est un processus 10 caché ou un pilote caché. 8. Programme d'ordinateur comprenant des instructions pour la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 7, lorsqu'il est chargé et exécuté par un microprocesseur. 15 9. Support d'informations lisible par un microprocesseur, comprenant les instructions d'un programme d'ordinateur pour mettre en oeuvre un procédé selon l'une quelconque des revendications 1 à 7. 20