Une investigation numérique requiert de nombreuses étapes. Celles-ci varient en fonction des données disponibles. Une des plus importantes est l’analyse de la mémoire vive (voir MISC N°111 [1]). L’analyse de la mémoire de masse, constituée des événements propres au système d’exploitation apporte de nouveaux éléments. Une fois celles-ci terminées, la corrélation des deux nous permettra de confirmer d’éventuelles hypothèses.
Suite au prélèvement et à l’analyse de la mémoire vive [1], nous avions constaté de manière factuelle la présence de nombreux artefacts. Nous allons compléter cette investigation par l’analyse des prélèvements de la mémoire de masse.
1. Prélèvement et préparation des disques
Nous avons demandé à l'équipe d'administration des serveurs de mettre la machine virtuelle du serveur JBoss en pause afin d’en extraire les données. Ces prélèvements seront stockés sur un disque dur externe. Une empreinte numérique sera effectuée et les différents traitements seront réalisés sur une copie de ces prélèvements. L’objectif de cette approche est de préserver les données provenant du prélèvement initial. Il est ainsi possible de recommencer à tout moment une analyse à partir de la preuve originale.
Nous sommes en présence de nombreux fichiers au format vmdk ayant chacun leurs propres snapshots. À ce stade, il n’est pas simple d’identifier le fichier qui devra être utilisé lors de notre investigation. Nous allons pour cela utiliser le fichier « .vmx » correspondant à la configuration de la machine pour l’identifier.
Dans le cas présent, c’est le fichier « Windows Server 2016-000002.vmdk » qui correspond au disque dur virtuel rattaché à la machine. Ce fichier n’est pas exploitable dans l'état actuel des choses, car il ne prend pas en compte le delta des données modifiées depuis le précédent snapshot,. Nous allons donc devoir fusionner de manière logique tous les snapshots. L'outil qemu-nbd est parfait pour cela.
Nous obtenons après l'exécution de ces quelques commandes un périphérique de stockage nommé /dev/nbd0 représentant le disque dur global du serveur virtuel.
Membre de la suite SleuthKit, mmls permet de lister les partitions d’un périphérique de stockage. Nous avons ainsi pu ainsi confirmer que les différentes partitions étaient désormais accessibles.
Préalablement au traitement des données, nous effectuerons une première analyse au travers d’un antivirus. Les résultats nous permettront d'identifier potentiellement certains artefacts.
2. Analyse automatisée
La recherche de marqueurs nécessite que le système de fichiers soit monté. Pour nous prémunir de toutes écritures sur les « preuves », nous utilisons des bloqueurs de type TD3 Imager de la société Tableau.
Débuter par une analyse antivirale permet de déterminer la présence éventuelle de code malveillant et de confirmer ainsi les éléments identifiés durant la première partie de notre investigation.
loki « Neo23x0/Loki » [2] est un outil intéressant pour compléter cette recherche en scannant les fichiers du système de fichiers à la recherche de concordances avec des signatures YARA et des hashs de fichiers malveillants connus.
Cette première analyse confirme les éléments observés lors de l’analyse de la RAM [1].
Nous pourrons également partir de ce constat pour limiter les traitements à une période restreinte.
3. Timeline
La timeline apporte une vision temporelle et factuelle des événements. Il est primordial de la générer assez tôt, car le processus peut prendre un certain temps. Chacun des résultats de l’investigation y sera ensuite confronté.
3.1 Génération à partir de l'outil « fls »
L'outil fls fait partie de la suite Sleuthkit. Il s'agit d'un outil très efficace et reconnu pour sa rapidité de traitement. Il permet à un analyste d'obtenir à partir de l'analyse de la MFT une timeline des événements passés sur le système de fichiers, et cela en quelques secondes. Nous le combinons avec mactime afin d’obtenir une meilleure lisibilité.
3.2 Génération à partir de l'outil « Log2timeline »
log2timeline va plus loin que l'outil fls. Il analyse le contenu de chacun des fichiers identifiés pour en extraire le maximum d'informations. Il procède ainsi à l’extraction des différents artefacts des données présentes sur le disque dur et les stocke dans une base de données SQLite.
Pour diminuer drastiquement le temps de génération de la timeline, nous avons appliqué des filtres [3] sur les fichiers à analyser. Ces filtres sont écrits sous la forme d’expressions régulières, comme le montre l’illustration ci-dessous.
Cette base de données est ensuite parcourue par l’outil psort qui va exporter les événements dans différents formats tels que CSV, JSON ou bien directement vers le moteur de recherche Elasticsearch. C’est ce dernier que nous avons utilisé. Il s’agit d’un moteur de recherche/base de données permettant d’effectuer rapidement des requêtes sur un volume conséquent de données. La suite ELK a pour avantage de fournir Kibana, un outil offrant un langage de requête (KQL) ainsi qu’une interface de visualisation des données.
Il faut prêter une attention toute particulière au paramètre -z qui indique l’utilisation d’un fuseau horaire spécifique pour l’enregistrement des résultats. Le fuseau horaire UTC est celui à privilégier pour l’ensemble des traitements à effectuer. Un décalage entre les faits et la réalité pourra avoir de sérieuses répercussions sur le déroulé des faits.
Il est également possible de diminuer le temps de traitement en filtrant les données lors de la génération de la timeline en spécifiant une date de début présumée ainsi qu’une date de fin correspondant à une période durant laquelle l’attaque aurait eu lieu.
Cela est cependant risqué, car des évènements connexes risqueraient d’être oubliés. La timeline générée sera utilisée dans les sections suivantes.
4. Analyse manuelle ou la recherche d’artefacts
Par artefacts, comprendre tout élément résultant de l’action d’un humain sur un système d’information. Dans les bonnes pratiques, il est recommandé d’analyser aussi bien la base de registre que la MFT. Dans le cas présent et au regard des éléments trouvés jusque-là, nous avons volontairement passé cette étape pour rester dans le format attendu.
L'outil RegRippy, développé par le CERT d’Airbus, peut également s'avérer très utile pour convertir le contenu d’une ruche de base de registre au format plain/text.
Voici un exemple de commande qui aurait permis de mettre en évidence des services exécutant du powershell, ou des binaires présents dans des répertoires d'utilisateurs et des répertoires temporaires.
Aucun résultat utile durant notre investigation.
LogonTracer [4] développé par le CERT JAPAN, est également un outil très intéressant. Il permet d’effectuer une visualisation sous forme de graphe des authentifications de comptes utilisateurs à partir des fichiers evtx du système d’exploitation.
Il est ainsi possible de visualiser :
- les authentifications ayant des privilèges élevés ;
- les authentifications d’utilisateurs à travers le réseau ;
- les connexions RDP ;
- l’ajout et suppression de comptes utilisateur.
L’outil LogonTracer a été d’une grande aide durant notre investigation mettant ainsi en évidence une attaque par « DCSync » [5] sur le serveur Active Directory, ainsi qu’un mouvement latéral de type « PassThehash » permettant à l’attaquant d’exécuter des commandes en tant que « pepper.potts ». Ces éléments concernent le serveur AD qui n’est pas détaillé ici afin de respecter le format MISC, mais ces derniers seront précisés dans la conclusion afin de présenter l’investigation dans sa globalité.
4.1 Extraction des fichiers suspects
Nous avons recensé certains des fichiers pouvant être en lien avec l’attaque subie. L’étape suivante consiste à les extraire grâce aux outils de la suite sleuthkit fls et icat afin de les soumettre à notre équipe de rétro-ingénierie. Nous retrouvons ainsi la création de la charge « jexws4.war » à l’origine de l’attaque, ainsi que celle des outils powershell exploités.
À ce point de l’analyse, nous avons pu corroborer les éléments identifiés lors de l’analyse de la mémoire vive [1] tels que l’origine attaque et le mode opératoire. Nous allons ensuite nous appuyer sur les eventID caractéristiques au contexte qui nous intéresse.
4.2 Analyse avancée des journaux d’évènements EVTX
Nous utilisons la bibliothèque libevtx-utils qui convertit les fichiers évènements de Windows (evt/evtx) en fichier texte.
Une fois cela effectué, nous recherchons des indicateurs tels que powershell.exe, cmd.exe… :
Nous pouvons visualiser sur la première ligne que la commande netcat a donné un accès distant powershell à l’adresse IP 192.168.205.180. Désactivée par défaut, la journalisation de l’exécution de commandes peut être activée via une configuration de stratégie de groupe [6]. Il en est de même avec la journalisation de blocs de scripts PowerShell [7].
Le contenu de l’événement nous permet d’obtenir un peu plus de précision quant à l’exécution de cette commande.
Nous constatons également le chargement d’une DLL distante à travers l’exécution de l’exécutable rundll32.exe. L’événement nous a permis de contextualiser un peu plus le mode opératoire de l’attaquant.
Nous constatons à nouveau le chargement d’une DLL distante à travers l’exécution du binaire rundll32.exe déjà identifié lors de l’analyse de la mémoire vive.
Les événements Windows contiennent un historique de la plupart des actions menées sur le système. Une analyse rapide a confirmé les résultats obtenus jusqu’à présent.
Voici une liste non exhaustive d’événements utiles à rechercher aussi bien dans un système de détection que lors d’une investigation numérique.
|
Description |
EventID |
Level |
EventLog |
EventSource |
|
Suppression des événements (EVTx) |
104 |
Information |
System |
Microsoft-Windows-Eventlog |
|
Virus détecté |
1006 |
Warning |
Microsoft-Windows-WindowsDefender/Operational |
Microsoft-Windows-Windows-Defender |
|
Suppression des événements d’audit |
1102 |
Information |
Security |
Microsoft-Windows-Eventlog |
|
Ajout d’un nouveau service |
7045 |
Information |
System |
Service Control Manager |
Certains évènements sont plus importants que d’autres. Une investigation approfondie de ces éléments peut aider à mieux comprendre le cheminement d’une attaque. De nombreux référentiels fournis par des agences étatiques reconnues telles que l’ANSSI [8] et la NSA [9] sont intéressants :
- https://github.com/nsacyber/Event-Fowarding-Guidance ;
- https://apps.nsa.gov.fr/iaarchive/library/ia-guidance/security-configuration/applications/assets/public/upload/Spotting-the-Adversary-with-Windows-Event-Log-Monitoring.pdf.
Il est d’ailleurs possible d’identifier tous mouvements latéraux de type « pass-the-hash » via l’analyse des événements systèmes.
|
Event ID |
Log |
Level |
LogonType |
Authentication Package Name |
|
4624 |
Security |
Information |
3 |
NTLM |
Nous nous sommes basés sur l’export des événements réalisés grâce à l’outil evtxexport en filtrant sur l’Event ID 4624, ayant pour LogonType 3. La valeur correspondant au champ LogonType permet d’identifier avec précision la méthode utilisée par un utilisateur pour s’authentifier sur un système. Elle peut être interactive (directement face à la machine), dans ce cas, nous aurions obtenu un LogonType 2. Dans le cas présent, le LogonType 3 correspond à une authentification à travers le réseau. Le dernier critère recherché est une authentification NTLM ne provenant pas du compte « ANONYMOUS LOGON ». Nous trouvons ainsi un mouvement latéral effectué sur le compte de « pepper.potts ».
Conclusion
L’analyse des données du périphérique de stockage effectuée ci-dessus a mis en évidence des événements majeurs. Nous avons ainsi pu corroborer de nombreux éléments déjà identifiés lors de l’analyse de la mémoire vive décrite dans la dernière publication de MISC. Il est désormais possible d’affirmer que l’intrusion a eu lieu suite à l’exploitation d’une vulnérabilité du serveur JBoss ainsi qu’au déploiement d’un outil d’exécution de commande à distance « JexBoss ». Une fois présente sur le système, la personne malveillante a chargé une bibliothèque de liens dynamiques « Dll » lui permettant d’interagir plus facilement sur le système à travers l’interpréteur Windows PowerShell et les outils PowerSploit et PowerUp. Ce dernier est notamment connu pour permettre à un attaquant de tenter d’élever les privilèges de l’utilisateur courant. Cet usage a notamment été relevé à travers l’analyse des journaux d’événements du système d’exploitation et leur corrélation au sein de l’outil LogonTracer.
La méthodologie d'investigation numérique présentée ci-dessus a été appliquée à l’intégralité de l’architecture impactée de notre client, dont notamment un Active Directory. Les résultats obtenus ont été repris en infographie et, vous pourrez le constater, nous permettent de visualiser avec plus de précision le schéma d’attaque.
L’analyse des données provenant des systèmes de stockage de masse est une étape longue et coûteuse en termes de temps et de ressources. La génération de la timeline prend généralement plusieurs heures. Nous avons dans le cas présent utilisé un filtre, car de nombreux éléments nous ont conduits dans une certaine direction, mais bien que le gain de temps ne soit pas négligeable, il faut garder à l’esprit que cette démarche peut nous faire passer à côté de quelque chose d’important.
Références
[2] https://github.com/Neo23x0/Loki
[3] https://github.com/log2timeline/plaso/blob/master/data/filter_windows.txt
[4] https://github.com/JPCERTCC/LogonTracer
[5] https://attack.mitre.org/techniques/T1003/006/
[8] ANSSI : Agence Nationale de la Sécurité des Systèmes d’Information
[9] NSA : National Security Agency
