Suite à une compromission applicative, il peut être nécessaire pour une entreprise de comprendre la cause de cet incident. Pour ce faire, il existe le Forensic, aussi connu sous le nom d’analyse post-intrusion. Son objectif est d’arriver à répondre aux 5W :
- Who : essayer de trouver l’IP responsable de la compromission initiale.
- What : quelle(s) donnée(s) ou fichier(s) ont été accédé(es) voir exfiltré(es) par l’attaquant.
- Where : quelle(s) machine(s)? Est-ce qu’un rebond sur une autre machine a été réalisé ? L’attaquant a-t-il pu se propager dans le système d’information ?
- When : la date de la compromission initiale. Bien souvent, il faut plusieurs semaines voire plusieurs mois pour se rendre compte de ce type d’incident.
- Why : est-ce une attaque ciblée ou opportuniste ? Quel était l’objectif de l’attaquant : miner de la crypto-monnaie, usurper les données bancaires des clients, etc ?
Forensic : le lancement du projet
Pour réaliser la prestation, il est important de disposer de plusieurs informations que seul le client peut nous transmettre. Tout d’abord, il nous faut l’emplacement des journaux applicatifs : il existe autant de manière d’administrer une machine qu’il existe d’administrateurs systèmes. Ensuite, il faut obtenir un historique rapide des faits (quel constat et quand) afin d’orienter l’analyse vers les bonnes dates.
Enfin, le client et ses équipes doivent nous transmettre les corrections déjà apportées ainsi que leurs horodatages. Sans ces éléments, l’équipe en charge de mener l’analyse pourrait se méprendre et confondre des actions légitimes réalisées dans un but de correction avec celles effectuées par l’attaquant.
Forensic : l’analyse de la compromission
Une fois l’ensemble de ces éléments recueillis, il est temps de démarrer l’analyse des journaux pour cibler les dernières actions effectuées par l’attaquant (accès à une backdoor par exemple) pour ensuite remonter la « pelote de laine ». En effet, il arrive régulièrement de tomber sur un cas où l’attaquant a utilisé plusieurs adresses IP. Dès lors, récupérer l’ensemble des actions effectuées par l’attaquant peut vite devenir une tâche fastidieuse.
Dans ce cas, il est préférable d’élaguer en recourant à une recherche par mot-clé au sein des logs et en se fiant à son expérience d’analyste. Dans notre cas de dépôt de backdoor, voici quelques exemples de ce que nous pourrions rechercher :
- toutes les requêtes POST qui ont retourné un code 200,
- des traces d’injections SQL,
- la mention de noms de fichiers identifiés comme étant malveillants, etc.
Ainsi, nous pourrons retracer les actions précises qui ont mené à la compromission. Et surtout, la méthode qui a été employée par l’attaquant.
A noter également que bien souvent, la compromission résulte de l’utilisation de composants obsolètes au sein du site. Dans ce cas, il peut être intéressant d’identifier la version des composants déployés sur le serveur et de vérifier quelles sont les vulnérabilités qui les impactent. Quand nous avons la main sur le serveur, nous pouvons effectuer cette vérification par nous-même.
De plus, quand cela n’est pas possible, nous utilisons un outil développé en interne, qui se base sur l’outil open source Wappalyser. L’outil que nous employons permet de faire une corrélation entre les versions détectées (via une méthode de fingerprinting) et les vulnérabilités connues associées. Ainsi, une fois la liste des vulnérabilités dressées, il faut encore en trouver une qui a une finalité similaire au résultat que l’on retrouve sur le serveur. Si par chance, une identification fonctionne, nous devons chercher si un exploit public est disponible et comment celui-ci agit. Cela permet de pouvoir affirmer ou infirmer l’utilisation de cette faille pour l’attaque du serveur.
Forensic : l’identification des fichiers suspects
Le scénario de compromission connu, il est intéressant d’examiner les fichiers encore présents sur le serveur. Il faut alors tenter d’identifier des fichiers malveillants parmi eux.
Un des outils que nous utilisons dans le cas d’un Forensic sur un environnement LAMP, est PHPMalwareFinder. Il permet d’identifier rapidement les fichiers suspects qui comportent notamment des fonctions connues comme étant dangereuses ou du code offusqué.
Quand des fichiers malveillants sont identifiés, nous devons les analyser pour comprendre leur utilité et leur fonctionnement. Mais aussi, nous devons nous assurer qu’il ne s’agit pas d’un accès persistant à la machine.
Enfin, une fois cela effectué, nous devons rechercher si l’attaquant a altéré des fichiers de configuration ou le système : création d’utilisateur, ajout d’une tâche récurrente…
Pour conclure sur le Forensic :
Maintenant que nous avons défini les grandes lignes du déroulement de l’attaque et comment l’attaquant est parvenu à compromettre la machine, ce qu’il a réussi à faire ou non, il est l’heure des recommandations.
D’abord et via les résultats de l’analyse, il est nécessaire d’indiquer si un vol de données personnelles a été identifié. En outre si oui, prévenir la victime qu’elle doit impérativement faire part de l’information auprès de la CNIL dans le cadre du RGPD.
Puis, il faut donner au client les actions à mettre en place pour éviter une future compromission de ce type (changement des mots de passe) et les bonnes pratiques à prendre. Si celles-ci avaient été mises en oeuvre plus tôt, elles auraient permis de mitiger, voire bloquer l’attaquant.
