Réponse à incidents et investigation numérique en open source

Chère lectrice, cher lecteur, le jour que tu redoutais tant est finalement arrivé : une machine de ton réseau - professionnel ou domestique - a été compromise, ou piratée, ou hackée ou pwnée. Peu importe le mot, les faits sont là : quelqu’un que tu ne connais pas (encore) et que tu n’as pas invité a mis ses cyber-pieds dans ton LAN.

Face à cette dure réalité, tu appelles ton ami Morpheus qui te propose de prendre la pilule bleue, ce qui consiste à réinstaller la ou les machines compromises et à restaurer tes données à partir des dernières sauvegardes (si sauvegardes il y a…) ou de prendre la pilule rouge, ce qui consiste à engager un processus d’investigation afin de savoir comment tout cela est arrivé.

1. Introduction à la Réponse à Incidents et Investigation Numérique

Si tu lis ces lignes, Neo, c’est que tu as choisi la pilule rouge. C’est courageux sinon téméraire, mais pas suicidaire. Nous allons donc te guider dans la quête qui fera de toi un Incident Handler, jeune Padawan.

Avant de te lancer aux trousses des cybermalotrus qui ont mis le bocson dans ton réseau, il te faut apprendre les bases du Digital Forensics and Incident Response (DFIR) ou Réponse aux Incidents et Investigation Numérique (RIIN) en Français.

Dans la série N.C.I.S., Abby est une geekette un peu gothique (ou une gothique un peu geekette) qui reverse du code et déchiffre des flux réseau en deux temps, trois mouvements et quatre clics de souris. Seulement voilà : Abby n’existe pas. Dans la vraie vie, une investigation numérique (IN) est une procédure longue et souvent moins « sexy » que l’image qu’en donnent les séries TV. L’Incident Handler (IH) doit adopter un comportement et un discours d’une neutralité absolue. Là où Oeil-de-feu écrira : « L’armée chinoise a piraté 50 serveurs critiques ! » il devra se contenter de constater : « Nous observons des connexions initiées depuis une adresse IP que la base Maxmind mise à jour le 15 novembre 2014 à 16h02 (GMT+2) localise à Shanghai (République Populaire de Chine). Nous ne pouvons pas valider cette géolocalisation de façon plus précise ». Vous en conviendrez, cela n'a pas le même charme.

1.1. Définitions

1.1.1. Qu’est-ce qu’un incident de sécurité informatique ?

Si l’on s’en tient à la définition donnée par la norme ISO 27035, un incident de sécurité est un ou plusieurs événements liés à la sécurité de l’information indésirables ou inattendus présentant une probabilité forte de compromettre les activités de l’organisation et de menacer la sécurité de l’information.

Concrètement, cela peut être une infection par un code malveillant, une intrusion après l’exploitation d’une faille de sécurité ou d’un défaut de configuration d’un équipement de type firewall, le défacement d’un site, l’installation d’un webshell sur un serveur, etc. Cela peut aussi être une exfiltration de données comme un vol de fichiers par un employé indélicat qui aura abusé de ses accès légitimes au système d’information de l’organisation victime de l’incident.

Ce sont autant de cas où une investigation numérique peut être nécessaire.

1.1.2. Qu'est-ce que la Réponse à Incidents ?

On regroupe sous le vocable de « Réponse à Incidents » les différentes actions mises en œuvre lors de la découverte et la simple suspicion d'un incident de sécurité. On peut comparer cette étape aux gestes de premiers secours tels qu'ils sont enseignés dans les (bons) cours de secourisme.

Ces actions précèdent et préparent l'Investigation Numérique, s'il est jugé nécessaire de s'engager dans un tel processus. Cette décision va essentiellement dépendre de la nature et de l'étendue de l'incident auquel on fait face.

1.1.3. Qu'est-ce que l'Investigation Numérique ?

L'Investigation Numérique (IN) est la suite logique de la Réponse à Incidents. Pour continuer dans l'analogie « Premiers secours », on peut voir la Réponse à Incidents comme l'intervention des pompiers et du S.A.M.U. et l'Investigation Numérique comme la prise en charge du blessé par un service hospitalier spécialisé.

1.2. Principes, méthodes et bonnes pratiques

L’art de l’Investigation Numérique (IN) - si tant est que ce soit un art - repose sur quelques principes simples, mais essentiels.

Si tu aimes les puzzles et le Cluedo, tu ne seras pas trop dépaysé. Une IN consiste à trouver les pièces d’un puzzle avant de les assembler jusqu’à ce qu’apparaisse le portrait de l’assassin du docteur Lenoir. Enfin, pas tout à fait : dans le cas d’une IN, c’est un peu comme si à chaque minute passée, une pièce du puzzle disparaissait. Plus il se passe de temps entre la date de la compromission et celle de l’investigation, plus il manquera de pièces au puzzle. Dans le meilleur des cas, le nombre de pièces sera suffisant pour avoir une image suffisamment fidèle des événements. Dans le pire des cas, il y en aura juste assez pour ne reconstituer que le contour du puzzle.

Comme au Cluedo, les objectifs de l’IN seront de répondre aux questions suivantes : quand s’est passé l’incident ? Comment s’est-il produit (quelles sont les failles techniques ou humaines qui ont été exploitées) ? Par où sont entrés les attaquants ? Combien de machines ont été impactées, et à quel degré ? Des données ont-elles été volées ou modifiées ou effacées, et lesquelles ?

Tu auras noté qu’il manque une question à cette liste : qui a fait ça ?

Un proverbe dit : « Quand l’investigateur montre une trace, le mendiant regarde la Chine ». Ce qui nous amène au principe n°0 de l’investigation numérique : tu identifieras des fichiers, des machines, des logiciels, peut-être même des comptes (mail, Facebook, FTP, etc.), mais tu te garderas de les lier à une personne. Dans une intrusion informatique, tout du moins lorsqu’elle est réalisée à distance, il n’y a et n’aura jamais ni empreintes digitales ni traces ADN.

Il te faudra donc éviter l’écueil qui consiste à attribuer à une personne physique (ou à un pays d’Asie) des actes parce que tu auras trouvé dans tes fichiers de logs une IP chinoise ou des identifiants de connexion.

1.2.1. Méthode et rigueur

Une investigation numérique peut être définie comme une procédure méthodique, rigoureuse et quasi-scientifique de collecte et d’analyse d’éléments relatifs à un incident de sécurité informatique.

Tout au long du processus d’investigation, et tout particulièrement durant les opérations d’acquisition des données, il faudra impérativement documenter chaque action réalisée dans le cadre de l’investigation. Une bonne pratique consiste à s’armer d’un bon vieux carnet papier et d’un stylo pour y noter scrupuleusement la date et l’heure ainsi qu’une description de ce qui a été fait. Par exemple : « 15 novembre 2014 - 15h23 - Rendez-vous avec M. Martin, au 42 rue de la Chance bureau 404 pour faire l’acquisition des données de son ordinateur ».

Il est bien entendu possible de remplacer cet arsenal 1.0 par une tablette ou un laptop.

Autre accessoire indispensable : un appareil photo. Il ne faut pas hésiter à prendre des photos de la « scène de crime », à savoir la machine dont on va acquérir les données et son environnement. Cela peut paraître futile ou « hype », mais une photographie peut être très utile : serez-vous capable de dire dans quelle prise USB était branchée la souris ou le clavier, quelques semaines après votre intervention ? Comment prouverez-vous un tribunal que la clef USB que vous avez versée au dossier était bien pluggée sur l’ordinateur du stagiaire soupçonné d’exfiltration de données ? Sage précaution : s’assurer que l’horloge interne de l’appareil est à l’heure. Activer ou non la géolocalisation des clichés est laissé à l’appréciation de l’Incident Handler.

Qui dit « investigation numérique » dit « numérique » : l’investigation, notamment l’analyse, ne portera pas sur les éléments « bruts » recueillis, mais sur une copie de ces éléments, qu’il s’agisse des images disques ou mémoire, de fichiers, des traces réseau, etc. Ces données présentent cet avantage de pouvoir être copiées, clonées, si l’on peut dire, autant de fois que nécessaire.

Ces données doivent être conservées et manipulées en respectant la « chain of custody », terme qui recouvre tout aussi bien la notion de séquestre que de traçabilité. Il s’agit de s’assurer que les copies sont conformes aux données originales - cela se traduit par le calcul du « hash » des données - et de savoir qui y a eu accès - ainsi que pourquoi - depuis l’acquisition jusqu’à la destruction des données (une fois l’investigation et les éventuelles procédures judiciaires y afférent terminées).

Dans la pratique, la conformité des données repose sur le calcul d’empreintes (hash) cryptographiques. Quant à la traçabilité, tout moyen sera bon pour la garantir : fichier Excel, formulaire imprimé, etc.

Il va sans dire que dans l’idéal, les données sont conservées depuis leur acquisition jusqu’à leur destruction de façon sécurisée (mise au coffre, chiffrement, etc.).

1.2.2. Artefact ! Artefact ! Est-ce que j’ai une gueule d’artefact ?

Si tu t’es un tantinet intéressé à l’investigation numérique avant de lire cet article, tu auras entendu parler d’artefact. Mais qu’est-ce donc qu’un artefact ?

Un artefact est le résultat d'une altération d’un système à la suite des actions d’un processus en exécution. Cela peut être : une clef de registre, une entrée dans la MFT (Master File Table, la table de fichiers principale), une URL dans l’historique de navigation Internet, etc.

Tu entendras aussi parler d’evidence (note le « e » et non  le « é »). Cet anglicisme peut se traduire par « indice » ou « élément de preuve ». Dans le domaine numérique, ce sera une donnée stockée, traitée, produite ou transmise sous forme électronique et utile à l’investigation. Cela peut être une ligne de log, un fichier ou une partie de fichier, une capture de trafic réseau, une adresse électronique, une adresse IP, etc.

Artefact et evidence sont les principales pièces du puzzle que tu vas devoir reconstituer.

1.2.3. Dura lex sed lex

Ton investigation peut te conduire à un dépôt de plainte auprès des services compétents, selon une formule consacrée.

Ce dépôt de plainte peut être le choix de l’organisation concernée : par exemple si l’incident a provoqué des pertes financières importantes ou a porté atteinte à l’image de l’entreprise. Mais dans certains cas un dépôt de plainte sera quasi-obligatoire : par exemple, si un serveur compromis a été utilisé pour stocker des contenus illégaux ou si des ordinateurs piratés ont participé à une attaque de type « DDoS » (déni de service distribué).

Cette éventualité va fortement influer sur la conduite de l’investigation, car les données collectées devront respecter les critères requis pour être produites devant un tribunal.

En premier lieu, les données versées au dossier doivent avoir été récupérées en respectant le principe de loyauté qui implique que les données soient collectées sans recourir à des moyens illicites ou déloyaux. Donc : non, on ne pwne pas le serveur C&C du malware qui a compromis une de nos machines et non, on ne piège pas les intrus à l’aide d’honeypots !

La RFC 3227 énumère les critères que les données collectées doivent respecter :

• Elles doivent être recevables, c'est-à-dire, comme dit précédemment, que le principe de loyauté a été respecté. Les actions réalisées au cours de leur acquisition et de leur analyse doivent être documentées et reproductibles.
• Elles doivent être authentiques, c'est-à-dire conformes et telles qu'elles ont été collectées (ni altérées ni modifiées).
• Elles doivent être complètes et non parcellaires.
• Enfin, il faut faire en sorte qu'elles soient comprises y compris par des interlocuteurs non techniques (typiquement : un tribunal).

1.2.4. Neutralité et objectivité

Il y a un écueil fréquent dont il faut se prémunir à tout prix : tirer des conclusions hâtives ou émettre des hypothèses douteuses à partir de traces parcellaires durant l'analyse des données.

De même que l’on ne peut déduire de 5 pièces d’un puzzle la nature de l’image obtenue une fois les 9 995 autres pièces assemblées, il faut se garder de toute tentation consistant à élaborer un scénario à chaque découverte ou collecte d’une trace. Il faut s’en tenir aux faits jusqu’au moment où l’on disposera de suffisamment d’éléments pour reconstituer une suite d’événements dans leurs grandes lignes. Comme dans un dessin à points, il faut d’abord trouver les points et leur associer un numéro. Ce n’est qu’à la fin que l’on reliera ces points entre eux. Dans le cas d’une investigation, chaque point sera une trace, une ligne de log, un fichier, etc., et son numéro sera une date (de création, de modification, etc.).

L'analyse obéit à un cycle : on commence par recueillir les données jugées dignes d'intérêt indépendamment les unes des autres. On les ordonne de manière chronologique. Puis, à partir d'un événement pivot, qui peut êtreladate à laquelle l'incident aura été détecté (et qui est différentede celle à laquelle il s'est produit) ou bien le nom d'un fichier détecté comme malveillant par un antivirus, on émet des hypothèses que l'on confirme ou non à l'aune des autres données. On répète ces opérations jusqu'à avoir balayé l'ensemble des hypothèses et avoir éliminé les cas impossibles. En tout état de cause, il devrait ressortir de ce processus une liste limitée de causes possibles expliquant l'incident et ses conséquences.

1.2.5. Principes de Locard

Edmond Locard (1877 - 1966) a fondé le premier laboratoire de police scientifique en 1910 à Lyon. Il est considéré comme le père de la criminalistique moderne. Il a formulé le principe d’échange qui depuis porte son nom et stipule que « tout criminel dépose des traces sur les lieux de son action et emporte sur lui des indices de la scène ». Ce principe s’applique aussi bien au monde réel qu’au monde numérique. Le lancement d’une commande, le téléchargement d’un fichier, son effacement même, sont autant d’actions qui laisseront chacune une trace sur le système.

De même, les actions faites pour mener l’investigation laisseront elles aussi des traces sur le système audité. D'où l'importance de soigneusement consigner toutes les opérations qui auront été effectuées dans le cadre de la collecte de données (date, heure et nature de l’opération). Par exemple, le lancement des utilitaires de la suite SysInternals de Microsoft sur une machine Windows induit la création de nouvelles clefs dans la base de registre. De même que l'utilisation d'un programme d'acquisition de la mémoire vive de la machine se traduira par la présence de ce programme dans le « dump » de la mémoire.

Enfin, E. Locard a mis en évidence l’importance de collecter les traces le plus tôt possible après la commission des faits délictueux : « la recherche des traces n’est fructueuse que dans la mesure où elle est immédiate. Le temps qui passe, c’est la vérité qui s’enfuit ».

2. Réussir une RI&IN

Il n’existe pas à proprement parler de processus unifié et universellement adopté pour mener une investigation numérique. Il existe une RFC sur la collecte d’artefacts, mais pas sur le DFIR en tant que tel. Il existe aussi des documents édités par le NIST américain. Les organismes privés comme publics tels que les CERTs s’entendent cependant pour définir les principales étapes dans la conduite d’une investigation.

On distingue deux grandes étapes, que nous allons détailler par la suite :

• l'acquisition des données ;
• l'analyse des données collectées.

Il est important de noter que les étapes présentées ci-dessous ne sont pas spécifiques à tel ou tel système d'exploitation ni même à tel ou tel type de matériel (ordinateur, tablette, ordiphone).

2.1. La recette d'une bonne RI&IN

Voici les ingrédients d'une bonne investigation numérique :

• des données les plus fraîches possible, que l'on organisera par catégories (artefacts liés à la création de fichiers, au lancement de processus, à l'effacement de données, à la navigation Internet, etc.) en s'inspirant du DFIR Poster 2012 du SANS : http://digital-forensics.sans.org/blog/2012/06/18/sans-digital-forensics-and-incident-response-poster-released. On prendra soin de recueillir pour chacun de ces artefacts au moins une date de création ;
• une frise chronologique (timeline) construite sur la base de la liste des artefacts collectés classés par ordre chronologique d'apparition ;
• un événement-pivot : ce sera l'événement qui a déclenché l'investigation. On insérera ce pivot dans la frise chronologique ;
• à partir de ce pivot, on examinera les événements survenus peu avant ou peu après à la recherche de ceux qui peuvent être liés au pivot. Si aucun événement proche (dans le temps) n'est trouvé, on élargira la recherche - chaque artefact intéressant trouvé au cours de cette étape peut à son tour devenir un nouveau pivot, auquel cas on recommencera ce cycle.

2.2. Préparation

Cette étape est souvent négligée, mais elle est primordiale. Qui penserait à sauter d’un avion en vol sans parachute ou sans l’avoir vérifié ?

Au risque d’enfoncer une porte ouverte, pour bien répondre à un incident, il faut s’y être préparé. Cela consiste essentiellement à s’outiller, à se documenter et à se former.

2.2.1. Se documenter

Si Sun Tzu avait rédigé un traité sur l'Art de la RI&IN, gageons qu'il y aurait écrit quelque chose comme : « Connais-toi toi-même et ton Système d'Information, et tu seras invincible ».

Pour conduire dans les meilleures conditions une Réponse à Incidents, il faut posséder un référentiel le plus précis et le plus à jour possible de son parc informatique : nombre de machines, types d'ordinateurs (postes, fixes, ordinateurs portables, serveurs hébergés hors de l'entreprise, etc.), leur utilisation et leur importance.

Ce référentiel doit être complété par une cartographie des réseaux, des points de connexion à Internet et des emplacements géographiques des différents éléments du S.I..

Enfin, un annuaire répertoriant les personnes en charge de l'administration des serveurs et des réseaux sera très utile lorsqu'il faudra demander le mot de passe du compte Administrateur d'une machine.

2.2.2. Boite à outils

C’est en forgeant qu’on devient forgeron et c'est à ses outils qu’on reconnaît l’ouvrier.

Voici une liste - non exhaustive - des outils que tout Incident Handler qui se respecte se doit d’avoir sous la main. Inutile de sortir la calculette : tous les logiciels cités ci-dessous sont gratuits et pour la plupart en open source.

Acquisition
Disque	dd, dd_rescue, guymager
Mémoire	DumpIt, WinPmem, LIME
Réseau	Wireshark, dumpcap
Analyse
Disque	The Sleuth Kit, Gparted
Mémoire	Volatility
Fichiers	Exiftool, hexedit
Données effacées	PhotoRec, Foremost, bulk_extractor

Pour les adeptes du « tout-en-un », il existe des distributions Linux spécifiquement dédiées à la RI&IN : citons notamment la distribution DEFT et la SIFT du SANS. Elles peuvent être installées sur un ordinateur qui sera réservé aux opérations RI&IN ou utilisées sur des supports « bootables » (CD, clef USB).

2.2.3. Se former

De même que ce n’est pas quand on est en train de se noyer qu’il faut apprendre à nager, il ne faut pas attendre que l’incident arrive pour tester les outils. Idéalement, les personnes en charge de la Réponse à Incidents devraient planifier des exercices de façon régulière. À l'instar de tout bon scout, l'Incident Handler se doit d'être prêt, toujours !

2.3. Identification et vérification

La découverte d’un incident de sécurité peut provenir d’une source interne ou externe. En interne, ce peut être un utilisateur qui se plaindra de lenteurs ressenties sur son ordinateur ou de comportements anormaux (échecs de mise à jour de certains logiciels notamment des antivirus, affichages de « pop-up », etc.).

Plus fréquemment, c’est une source externe qui donnera l’alerte. Cela se traduit souvent par un courriel comme celui-ci :

« Madame, Monsieur,

Nous avons constaté qu’une machine de votre réseau est à l’origine de nombreuses attaques détectées par nos équipements de sécurité. Nous vous prions de faire le nécessaire pour stopper ces activités.

Voici un extrait de nos logs relatifs à ces attaques :

<date>, <ip source>, <port source>, etc. »

Comment réagir à ce type de message ?

Tout d’abord, comme Saint Thomas il ne faut croire que ce que l’on voit. La première chose à faire consiste donc à vérifier et valider que le message nous est bien destiné. Il faut vérifier que l’adresse IP nous est bien attribuée. Si on a de la chance, l’entreprise possède des adresses IP publiques et une interrogation WHOIS suffira. Si on a moins de chance, les adresses IP utilisées par l’entreprise sont fixes, mais sont louées par son fournisseur d’accès, qui apparaîtra donc comme étant titulaire des adresses en question. Il sera cependant facile de valider qu’à la date mentionnée dans le courriel, la ou les adresses IP suspectes étaient bien allouées à l’entreprise. Enfin, si l’on n’a pas de chance du tout, l’entreprise est derrière une box et utilise une IP dynamique. Autant dire qu’il va être très compliqué de savoir si l’information relayée dans le courriel est vraie ou fausse…

Même en partant de l’hypothèse que l’IP est bien utilisée par notre entreprise, il reste un gros écueil à surmonter. Il doit être rarissime, sauf s’il s’agit d’un serveur, qu’une entreprise expose ses postes internes sur Internet en leur attribuant à tous une IP publique. Il va donc falloir se plonger dans les logs du pare-feu ou du routeur qui réalise la translation d’adresse (NAT) puisqu’il sera plus que probable que l’IP publique soit celle d’un de ces équipements.

Suivant le type de NAT mis en œuvre (« 1 pour 1 » ou masquerade « 1 pour any ») cette tâche sera plus ou moins aisée, surtout quand un flux traverse plusieurs équipements (routeurs, pare-feu, proxies, etc.) avant de sortir du réseau de l’entreprise. Vérifier que l’alerte concerne bien une machine de son réseau, et plus encore, identifier cette machine, devient alors déjà un casse-tête digne des pires tortures.

2.4. Isolement

Admettons que l’on ait réussi à valider l’alerte - elle nous est bien destinée - et à identifier la ou les machines concernées. Avant de tirer le signal d’alarme et d’appeler la cavalerie, il faut déterminer, à partir des seuls éléments contenus dans l’alerte, si l’on a affaire :

• à un faux-positif : une trame réseau aura matché la signature d’un IDS sans pour autant que cette trame fasse partie d’un flux malveillant ;
• une erreur de configuration : par exemple, une règle de filtrage mal écrite, une ACL mal positionnée, etc.
• une erreur d’attribution : l’analyste qui a rédigé l’alerte est frappé de dyslexie et aura interverti deux chiffres d’une adresse IP.

En un mot : est-on face à un incident de sécurité informatique.

Admettons une fois encore que ces conditions ont été validées. Que faire ?

En priorité : limiter les dégâts. Cela consiste à isoler la ou les machines identifiées, généralement en la débranchant du réseau. Mais cette décision doit être mûrement réfléchie.

Il faut d’abord savoir à quoi servent ces machines : sont-elles utilisées pour faire tourner des services critiques ou essentiels (serveur de messagerie électronique, contrôleur de domaine, par exemple) ?

La décision de déconnecter ou non une machine compromise doit se prendre au regard des risques que fait peser cette machine sur le reste du S.I.. Si l’on suspecte une infection par un ver informatique, si la machine est suspectée d’être utilisée pour lancer des attaques DDoS, si elle héberge des contenus illégaux, on peut raisonnablement tirer le câble réseau, même si l’on risque de perdre de précieuses informations.

L'acquisition des données peut commencer.

3. Acquisition

La première phase d’une réponse à incident est l’acquisition des preuves de compromission. Dans le cadre d’une compromission, les analystes essaient de reconstituer le scénario complet et les différentes phases de l’attaque :

• Exploitation d’une vulnérabilité ;
• Élévation de privilèges ;
• Résilience ;
• Pivot ;
• Remontée dans le réseau ;
• Exfiltration des données.

Grâce à Locard, nous savons qu'à chaque étape de la compromission, des traces ont été laissées par le ou les attaquants. Ces étapes vont se traduire de plusieurs façons au niveau du système.

Pour l’exploitation, du code malveillant peut être retrouvé très souvent tant côté client que côté serveur, cela dépendra du service attaqué. Il faudra récupérer les fichiers de logs sur la machine impactée, mais aussi sur les différents équipements en amont ou en aval (pare-feu, proxies, serveurs DNS).

L’élévation de privilège se caractérise par une exécution de code pour avoir des droits Administrateur sur la machine qui vient d’être compromise. Il doit donc y avoir eu un binaire qui s’est exécuté sur la machine. Il arrive que l’exploitation suffise à être Administrateur sur le système compromis en fonction du contexte d’exécution du service qui a été exploité. Par exemple, un serveur Web Apache (comment ça, il y a des administrateurs qui font encore ça ?) s’exécutant avec les droits root sur la machine, dans le cadre d’une exploitation avec obtention d’un shell, l’attaquant sera directement root sur la machine (heureusement par défaut Apache ne s’installe plus avec ce type de droits…).

Concernant la résilience et le pivot, du code va s’inscrire dans les mécanismes du système d’exploitation pour qu’à chaque redémarrage du système d’exploitation, le code se lance et aille se connecter au serveur d’où il prend les ordres (principe de canal de contrôle).

La remontée de réseau se traduit par des traces laissées au niveau des équipements de bordure (firewall, switch, serveurs). Des traces dans les journaux sont donc possibles ou l’enregistrement complet du trafic avec des outils de capture (tcpdump en tête de la liste).

L’exfiltration de données, de la même manière, va se voir à la fois au niveau réseau (échange de données avec l’extérieur) et sur le système d'où sont exfiltrées les données.

L'acquisition des données peut se faire :

• à chaud, sur un système en marche (on parle de « live forensics ») ;
• à froid, sur un système éteint ou à partir de supports de stockage démontés.

Elle se fait dans un ordre bien précis, déterminé par la volatilité des données que l'on souhaite collecter :

• Mémoire vive ;
• Informations Système : sessions ouvertes, connexions réseau établies, date et heure de l'horloge interne, lecteurs distants montés ;
• Capture Réseau : elle peut être réalisée en parallèle des opérations précédentes ;
• Image du ou des disques après arrêt du système.

L'acquisition des logs sur les équipements amont ou aval se fera par simple copie des fichiers de journalisation, sauf si l'on suspecte ou détecte une compromission de ces équipements.

3.1. La RAM

La mémoire vive est une source privilégiée d'informations sur l'état du système. On peut y trouver :

• les connexions réseaux ;
• les processus lancés (même ceux qui sont cachés ou injectés) ;
• les fichiers ouverts ;
• les librairies linkées par processus ;
• les mutex ;
• les pipes nommées (pour Windows) ;
• les clés de registre (pour Windows) ;
• des empreintes (hash) de mots de passe ;
• le contenu du presse-papier ;
• des bouts de code HTML ou JavaScript.

Cette liste est loin d'être exhaustive.

La capture et l’analyse de la mémoire sont deux vastes sujets de recherche ces dernières années. Très souvent, au vu de la multiplicité des mécanismes pour se cacher et freiner la défense, l’analyse de la RAM est le dernier recours pour détecter les malwares sophistiqués.

Que ce soit sur n’importe quelle machine, cela se fait au niveau kernel. Pour Linux, c’est donc l’utilisation d’un module noyau (exemple Lime ou Pmem) et pour Windows l’utilisation d’un driver (WinPMEM).

Il fut un temps que les moins de 20 ans ne peuvent pas connaître, où, pour dumper la RAM sous Linux, la copie de /dev/mem à l'aide de la commande dd (et de netcat pour les cas d'acquisition à distance) suffisait. Malheureusement, ce temps est révolu. Si vous utilisez encore cette technique, vous vous retrouverez avec un fichier de taille égale à celle de la mémoire physique… mais rempli de 0.

D'où la nécessité d'utiliser des modules spécialisés. Le projet Lime est une réponse à cette problématique. Projet initialement prévu pour de l’analyse de la mémoire d'Android, il est aussi utilisé pour Linux.

Il faut compiler les sources avec la même version de noyau que la machine dont on souhaite extraire la RAM et le charger avec la commande insmod.

Pour Lime, il existe plusieurs formats : raw, Lime, Padded

Comme Volatility sera utilisé pour analyser le dump et qu'il supporte le format Lime, ce format sera donc choisi. La commande est la suivante :

Un fichier contenant une copie de la mémoire est ainsi créé à l’emplacement déclaré par le paramètre path.

Sous Windows, cette mécanique est plus simple. Il existe trois techniques de dump de RAM :

• Positionner un pipe nommé \\device\\PhysicalMemory donnant un accès à la RAM, ouvrir ce pipe nommé comme un handle de fichier et lire le flux de données.
• Utiliser l’API Windows mmapiospace
• Utiliser les PTE mappings en passant directement par les pages mémoires. Cette nouvelle technique permet de contourner les techniques d’antiforensic notamment le blocage du pipe nommé comme le fait le malware bancaire Zeus GameOver.

Ces techniques sont appelables à l'aide d'un même exécutable : winpmem-1.6.exe. Comme elles se passent directement au niveau kernel, il faut charger un driver (action que fait winpmem). Pour cela, un service est créé et le driver est chargé en passant par ce service. Cela évite d’avoir à rebooter l’ordinateur.

Bien que dans GNU/Linux Magazine, à titre indicatif la commande est la suivante :

Par défaut les PTE mappings sont utilisés, mais il est possible de changer de mode.

Voici les options :

• 0 : Use MmMapIoSpace method
• 1 : Use \\Device\PhysicalMemory method (Default for 32bit OS).
• 2 : Use PTE remapping (AMD64 only - Default for 64bit OS).
• 3 : Use PTE remapping with PCI instrospection (AMD64 Only).
• On peut exporter le contenu de la RAM au format ELF, mais attention, Volatility ne supporte pas pour le moment ce type d’export. Seul Rekall (fork de Volatility de Google) supporte le format ELF.

3.2. Les artefacts

Un artefact est le résultat d’une altération du système suite aux actions des processus qui s'y exécutent.

Sous Linux, les artefacts sont globalement des fichiers, le journal du système de fichiers et les logs du système.

Sous Windows, les artefacts sont de natures multiples : le registre, la MFT, les fichiers Prefetch, les pipe nommées, les mutex, les fichiers et les logs du système

Le but est de tracer l’ensemble des processus, des actions des utilisateurs ou administrateurs.

Sous Windows, la principale difficulté vient du fait qu'il n'existe pas un seul format pour tous ces éléments et qu'il faut souvent utiliser un outil pour collecter et analyser chaque artefact. Pour la base de registre, il y a par exemple RegRipper pour extraire l’ensemble des clefs, pour la MFT il y a analyseMFT qui extrait la MFT en fait une chronologie, et ical pour extraire la MFT. L'analyse de Prefetch, des fichiers LNK, etc., nécessitera là encore des outils différents.

Le logiciel FastResponder a été développé par le CERT Sekoia pour collecter l’ensemble de ces artefacts sous Windows à l'aide d'un seul outil. Développé en Python, le but de cet outil est de collecter de manière simple (en un clic de souris) et de manière « scalable » l’ensemble des artefacts Windows. Elle ne dépend pas de la taille du disque dur.

Il est possible de customiser la collecte sur des sources spécifiques soit en ligne de commandes :

Soit en définissant un profil de collecte :

Puis d'exécuter :

L’ensemble des résultats est dans des fichiers texte CSV en UTF-8. Il est ensuite possible d’indexer ces résultats grâce à Elasticsearch pour pouvoir faire des recherches, des filtres spécifiques.

L’autre finalité est le déploiement et la collecte dans un SI immense ou finalement très peu de données seront collectées dans le but de comprendre l’ensemble d’une attaque ou la propagation d’un malware (par exemple une clé de registre positionnée pour redémarrer à vérifier en ne collectant que les autoruns).

3.3. Le disque

L’acquisition de disque peut être un exercice assez périlleux. Entre les différents drivers du matériel, le type de connecteur, les volumes RAIDs logiciel et matériel, il peut être compliqué de faire une image disque.

On privilégiera donc une distribution Live Linux orientée Acquisition qui embarque un certain nombre de drivers.

La distribution DEFT répond souvent à l’ensemble des problématiques rencontrées. Distribution basée sur Ubuntu, elle propose de nombreux logiciels qui répondent à ces problématiques. La première est la reconnaissance du disque et son montage en lecture seule. L’utilitaire disks est très pratique pour cela (voir figure 1).

Gparted, également présent, permet d'inspecter la physionomie des disques (nombre et type de partitions).

Pour une copie bit-à-bit d'un disque, si la ligne de commandes vous rebute, votre choix se portera sur Guymager présenté en figure 2. Cet utilitaire supporte 3 formats d'image : raw (brut), EWF et AFF.

Le format raw est celui que l'on obtient à l'aide de la commande dd, mais il est très consommateur de temps et place. Le format AFF (la dernière version est la 4) est un format open source qui prend en compte la compression, mais aussi l'enregistrement d'informations permettant de vérifier l’intégrité de l’acquisition. Malheureusement, ce format est obsolète. Il est conseillé de travailler avec le format raw ou EW (voir http://sourceforge.net/p/guymager/wiki/AFF%20format%20deprecated/).

Le format EWF a été créé par la société EnCase. Il a été reversé par Joachim Metz et de nombreux utilitaires sont disponibles pour utiliser ce format ; citons le package ewf-tools et libewf. L'acquisition dans ce format utilise la compression, propose de découper l'image dans des fichiers de taille fixe avec un fichier de logs reprenant l’ensemble des informations et un condensé pour vérifier l’intégrité après acquisition. Il est aussi possible à chaud pendant l’acquisition de demander un contrôle d’intégrité.

Une fois l’acquisition faite, pour avoir monté une image au format EWF, il suffit de taper la commande suivante :

3.4. Le réseau

La star incontestée pour la capture (et l'analyse) du trafic réseau est Wireshark, qui a détrôné le vénérable, mais toujours respectable tcpcump (et snoop pour Solaris). Utilisable en mode graphique ou en ligne de commandes (tshark et dumpcap), Wireshark permet de capturer le trafic au format PCAP ou PCAPng. Si l'on souhaite analyser les paquets capturés à l'aide d'outils comme Snort ou Suricata, on privilégiera le format PCAP. Vous voici maintenant avec quelques Gigaoctets de données, il est temps de passer au plat de résistance : l'analyse.

4. Analyse

Une fois l’ensemble des données collectées, il faut les analyser pour comprendre les phases de l’attaque.

L'analyse de la RAM est l'une des premières choses à faire : dans les cas les plus simples, tous les éléments relatifs à un incident s'y trouveront. Cela est particulièrement vrai si l'acquisition a été faite peu de temps après la compromission… et à condition que l'ordinateur n'ait pas été redémarré !

4.1. Volatility : à la recherche de code malveillant

On ne devrait plus avoir à présenter Volatilty, LE logiciel d'analyse de RAM par excellence. Développé en Python, il est composé de modules dédiés à l'extraction des informations utiles à l'Incident Handler. Volatility fonctionne sous Windows et il est aussi capable d'exploiter un « dump » de RAM Linux ou Mac OS X. Pour l'analyse de RAM Linux, le lecteur est invité à lire l’article « Volatilisons Linux » de MISC n°76 (novembre/décembre 2014).

Volatilty s’utilise souvent de cette façon :

La première chose intéressante à faire est de lister l’ensemble des processus. On utilisera pour cela les modules pslist et pstree. Ce plugin parcourt la liste doublement chaînée que maintient le système d’exploitation, liste les différents processus et les représente sous forme d’un arbre (père, fils). Ces deux modules sont cependant insuffisants avec les malwares qui s’injectent dans des processus existants ou se détachent de cette liste doublement chaînée.

Les modules psscan, psxview et malfind sont plus intéressants pour détecter des malwares plus sophistiqués. Le module psscan va reconstruire les structures _EProcess sans prendre en considération les informations que peut donner le système d’information. Si un processus se cache dans la mémoire (pas d’un processus), il sera donc listé.

Le module psxview est plus intéressant, car il reprend pscan et va croiser des informations avec d’autres tables que maintient le système d’exploitation et expliciter les informations découvertes.

Le module malfind quant à lui va lister les processus qui semblent être injectés par un autre programme. Il va vérifier les pages mémoire qui sont en lecture/écriture/exécution d’un processus.Par exemple, si en début d’une page mémoireon trouve le « marqueur »4D5A (« Mz ») qui est le début d’unen-tête d’un exécutable Windows,il y aune forte chance qu’il y ait une injection de code dans une page mémoire d’un processus non prévu à cet effet. Le malware s’injecte en utilisant Virtualloc et setPermission de la page du processus qu’il souhaite injecter pour modifier les droits de cette page et ensuite s’exécuter.

Il y a d'autres modules intéressants : les librairies chargées par les processus. Le premier de ces modules, dlllist (similaire à pslist), liste les librairies par processus en se basant sur les informations enregistrées par le système d’exploitation :

Si le code malveillant contourne cet enregistrement, la librairie ne sera pas visible.

Comme pour psscan, le module lrdmodules reconstruit les objets Windows _DLL.

En ajoutant -p <pid> pour les deux modules, on obtient les librairies chargées du process ayant le pid passé en paramètre.

D'autres informations intéressantes sont les connexions établies : on utilise alors le module netscan qui a le même fonctionnement que psscan pour les objets réseaux.

Ce module liste les connexions réseaux par processus. Il est très utile pour détecter des malwares sophistiqués by passant bon nombre de mécanismes. Mais la partie communication avec l’extérieur est difficile à cacher.

Tous les ans, l’équipe de Volatility organise un concours de développement de plugins qui viennent enrichir l'outil. Cette année, un module très utile a été développé par Thomas Chopitea pour lister les programmes se lançant au démarrage du système d’exploitation.

Il existe d’autres modules très intéressants à expliciter, mais cela demanderais un hors-série complet. Il est donc laissé en exercice au lecteur. Le livre Art of Memory par les créateurs de Volatility est paru cet été et il détaille toutes les techniques pour la découverte et l’analyse de code malveillant.

4.2. Plaso : faites parler vos données

Nous l'avons dit plus haut : construire une frise chronologique (timeline) à partir des données collectées est un critère de réussite de votre investigation. Plaso est un logiciel open source développé en Python avec différents modules en C. À partir d’une image disque ou d’un point de montage, chiffré avec BitLocker ou des images de système de virtualisation (Qemu, VMware, VirtualBox et HyperV), il va faire une timeline de toutes les actions que le système d’exploitation a enregistrées dans son système de fichiers, dans les journaux, et, pour Windows, dans la base de registre, la MFT et les shadows copy. Il remplace log2timeline, utilitaire développé en Perl, mais qui n’est plus maintenu.

Pour installer Plaso, il est vivement conseillé d'utiliser soit le PPA de Sans Institute, soit celui du développeur :

Pour les plus téméraires, il est possible de compiler ce logiciel au travers des sources. Le lecteur est invité à utiliser l’utilitaire https://github.com/libyal/libyal en mode download pour télécharger les bonnes versions et dans le répertoire utils des sources de plaso, le script check_dependancies.py qui va vérifier si tout est installé correctement sur le système.

Plaso utilise différents modules pour décoder un grand nombre d’items : BitLocker, events logs, Sleuthkits pour la partie journalisation du système de fichier et MFT (voir dans la suite de l'article), disques virtuels (VirtualBox, VMware, Qemu, HyperV), etc. Plaso récupère toutes ces données horodatées pour en faire une chronologie (timeline). La création de la timeline se fait par étapes. La première est l’extraction des données par log2timeline.py :

Ensuite, l’utilitaire psort transforme le dump dans le format que l’on souhaite. La ligne de commandes est la suivante :

Il est possible de positionner des filtres de date ou de types d’objets. La notion de slice est aussi très importante. Lorsqu’un événement à une date précise est important, il est possible d’avoir juste la partie de la timeline avec un temps dans un intervalle de +x et -x minutes. On positionne donc un slice et un intervalle de temps que l’on souhaite par l’option --slice pour la date de pivot et --slice_size pour la taille de l’intervalle de temps.
peut être extraite directement dans elasticsearch pour pouvoir faire des recherches avec Kibana (voir figure 3). Il suffit d’installer cette extension : https://github.com/rhec/pyelasticsearch.git. Il devient alors possible de lancer la commande suivante :

4.3. Sleuth Kit

The Sleuth Kit (TSK) est une suite d'utilitaires spécifiquement développés pour l'analyse de disque et de systèmes de fichiers. Il mériterait un article à lui tout seul tant les fonctionnalités qu'il offre sont nombreuses et utiles. C'est un « must have » dans votre trousse à outils.

4.3.1 À la recherche des fichiers perdus ou effacés

À partir d'une image disque, il est possible de récupérer tout ou partie du contenu de fichiers effacés. Deux utilitaires sortent du lot pour cela : PhotoRec et foremost.

Dans les deux cas, ces utilitaires passent outre le système de fichiers du disque et analysent directement la surface (blocs). Les traces contenues dans les blocs non alloués sont alors extraites et remises bout à bout. Il n'est pas rare de pouvoir reconstituer ainsi le contenu de fichiers quasi-intacts que l'on pensait perdus à jamais.

4.3.2 Réseau

L'analyse de captures réseau mériterait un article à elle toute seule. Wireshark – encore lui ! - vient en premier à l'esprit. Mais si les captures réseau ont été stockées au format PCAP, sachez que de très nombreux outils permettent de les décortiquer. Citons, sans ordre de préférence :

• Snort ou Suricata : ces deux logiciels de détection d'intrusion réseau (IDS) savent en effet lire le contenu d'un fichier PCAP. Il est très judicieux de parser un dump réseau à l'aide d'un de ces outils et de signatures à jour à la recherche de traces d'activités réseau malveillantes.
• ngrep : ce petit outil est une transposition du fameux grep dans le monde TCP/IP. Il permet de parser un PCAP à l'aide d'expressions régulières.
• foremost : déjà cité, cet utilitaire sait extraire les fichiers contenus dans un dump.

4.4 Fichiers

Une boite à outils d'Incident Handler ne serait pas complète sans l'utilitaire exiftool. Cette commande permet d'analyser les métadonnées des principaux formats de fichiers (image, vidéo, documents Office). Et c'est fou ce que l'on peut extraire des métadonnées de certains fichiers : coordonnées GPS pour les photos (si cela n'a pas été désactivé par l'utilisateur), date d'impression pour un document Office, ainsi que la durée de la dernière ouverture du document, type d'appareils (photo, imprimantes, etc.) utilisés.

Ceux qui auront suivi un tant soit peu l'affaire Snowden comprendront tout de suite l’intérêt de ces metadata...

Conclusion

L'investigation numérique n'est pas un long fleuve tranquille. Il y a loin du mythe – le génie du clavier qui reverse un malware étatique en trente secondes – à la dure réalité. Pour un Cliff Stoll qui met à jour une campagne de cyber-espionnage menée par des pirates allemands sponsorisés par le K.G.B., combien d'analystes se seront cassé les dents sur un malware bancaire, un faux antivirus ou un rançongiciel ?

Et encore nous n'avons fait qu'effleurer le sujet dans cette introduction. Ceci dit, c'est également un domaine en constante évolution et, quelque part, un territoire vierge. Chaque mise à jour de tel ou tel OS, chaque sortie d'un nouvel ordiphone offrent à l'explorateur de nouvelles perspectives et de nouveaux challenges.

Tant qu'il y aura des incidents, il y aura des données, là tout autour, qu'il faudra trouver et analyser.