Une analyse des artefacts Windows du prestataire s'impose pour déterminer comment l'attaquant s'est introduit sur le réseau de FIZZ-IC ainsi que ses actions.
Le prestataire nous accorde donc, sous couvert d'un accord de non-divulgation, de récupérer certains de ses artefacts et évènements Windows. Il indique aussi que la pièce jointe compromettante se nomme `comptabilite_octobtre_2024.xlsm` ainsi que la date de réception du mail : `2024-11-15 14:26:00`.
Nous savons aussi, avec le travail réalisé à l'étape précédente, que les accès à la base SQL avec le compte de celui-ci ont été faits le 22 novembre 2024.
Avec ceci, nous serons alors capables de retracer l'attaque dans sa globalité jusqu'aux actions réalisées dans l'Active Directory de FIZZ-IC grâce à la configuration des logs au préalable.
Pour cette partie, nous ouvrons les logs PowerShell qui ont été compilés sous forme d'un fichier JSON. Après un rapide parcours de haut en bas, nous remarquons qu'ils ont déjà été filtrés sur la durée qui nous intéresse.
Une relecture rapide de la déclaration nous permet d'identifier un axe de recherche.
plusieurs applications se sont lancées toutes seules, mais sans la fameuse invite de commande, celle qu’on voit toujours apparaître quelques secondes dans les attaques…
Cependant, ici ce sont les logs PowerShell que nous avons. Une rapide recherche sur Internet sur comment cacher la fenêtre PowerShell lors d'exécution de macros indique la piste à suivre.
Ainsi, nous étudions plus précisément les logs PowerShell pour ce cas.
Cependant, il est aussi possible de récupérer la date exacte d'exécution de la macro : 2024-11-18T9:30:01.1762896.
Désormais, une archive est mise à notre disposition. Elle contient le Prefetch Windows compilé avec une suite d'outils. Le plus simple est d'ouvrir le fichier d'index dans un navigateur au choix.
À nouveau, un rapide parcours du fichier montre que peu d'évènements sont datés d'une période pré 2025. Il suffit alors de parcourir le fichier pour chaque processus ayant encore une exécution le 18 novembre 2024.
Nous allons lister les processus ayant encore des données exploitables dans la tranche de date, car le Prefetch sauvegarde uniquement les 8 dernières dates de lancement d'un processus, donc cela peut entraîner une perte d'informations :
- CHROME.EXE
- FIREFOX.EXE
- GIT-CREDENTIAL-MANAGER.EXE
- GIT-REMOTE-HTTPS.EXE
- NOTEPAD.EXE
- ONEDRIVE.EXE
Avec ceci, il est déjà possible de se faire une idée de ce qui est réalisé par la macro.
Tout d'abord, le fait que les processus chroment et Firefox soient toujours présents indique que le prestataire ne les utilise pas comme navigateur par défaut. En effet, une recherche approfondie montre que l'exécutable msedge.exe est lancé plusieurs fois par jour.
Cependant, à cette date précise, ils se sont déclenchés en même temps à quelques secondes d'intervalles. Il s'agit là d'un cas typique de voleur d'informations d'identification. Il tente d'ouvrir tous les navigateurs présents sur le PC. Il a ensuite écrit les informations obtenues via une commande appelant le bloc note. Enfin, il est aussi possible de déduire que l'attaquant a réalisé son exfiltration en utilisant une base de code.
Le Prefetch enregistre aussi les dossiers et les fichiers auxquels un processus fait des accès lors de son exécution. Nous avons donc vu que GIT.EXE a été lancé, et donc un dossier a dû lui être précisé.
Nous n'avons ici que la racine et les fichiers associés qui contiennent souvent les informations à envoyer. Il reste néanmoins un processus lancé à cette même date que nous n'avons pas encore décortiqué. Une recherche du mot postgre nous permet alors de trouver le chemin entier du fichier.
L'attaquant a fait une erreur ! Il a mal supprimé le dossier utilisé pour l'exfiltration. Celui-ci étant maintenant entre nos mains, nous pouvons finaliser la compréhension de l'attaque.
Ainsi, il n'y a qu'un seul commit, celui d'un fichier chiffré. Au vu de la date de l'attaque, il est impossible de récupérer la clé en mémoire. Nous ne pouvons donc pas savoir exactement ce qu'il a récupéré si ce n'est les informations que le prestataire enregistrait dans le navigateur.
Cependant, afin de pouvoir exfiltrer, celui-ci est passé par une clé d'accès personnel. Pour la retrouver, il suffit de se rendre dans le fichier de configuration. Alors, nous y retrouvons plusieurs informations comme son utilisateur, l'entreprise de gestion de bases de code, la clé et enfin le dossier en ligne.
Pour cette partie, nous allons utiliser un outil en ligne afin d'afficher les logs plus simplement.
Voici les axes de recherche au départ :
- alexis.arval
- son adresse IP, une fois qu'un log associé a été trouvé
Nous commençons par retirer les logs correspondant aux EventId suivants :
- 4674 : Une tentative a été faite pour effectuer une opération sur un objet.
- 4670 : Modification des autorisations sur un objet.
- 5447 : Un filtre de la Plateforme de filtrage Windows (WFP) a été modifié.
- 5156 : Le pare-feu Windows (WFP) a autorisé une connexion.
Bien qu'ils puissent être importants, ils sont à l'origine de la surcharge de logs, et il est très peu probable qu'ils soient nécessaires d'entrée de jeu.
Désormais, il est possible de procéder de différentes manières. Soit en utilisant les axes, soit en regardant les évènements qui sont très peu présents.
Nous allons utiliser la première méthode. Trouver le log avec alexis.arval est au final l'étape la plus dure, car la fonction de recherche ne marche pas extrêmement bien. Nous sommes donc passés par un convertisseur d'XML dans un premier temps et avec une simple recherche, nous tombons sur ce log.
L'évènement 4741 correspond à l'ajout d'un ordinateur dans le domaine. Ensuite, il est possible d'ajouter des nouveaux filtres.
Ainsi, nous pouvons désormais utiliser uniquement l'interface web et avec des filtres.
En triant cette fois selon le nom du compte machine créé, nous pouvons identifier rapidement les évènements portant sur lui.
Ici, l'évènement 4742 correspond à la modification d'un compte ordinateur.
Dans les champs modifiés, il est possible de voir que le nom de DNS hôte a été changé afin de contenir le compte machine administrateur de l'Active Directory.
Peu de temps après, une demande de certificat est émise par le compte ordinateur, selon un certain schéma. Avec ces informations, il est possible de déterminer la vulnérabilité d'exposition commune et ce qu'elle permet.
Un accès à un tel compte permet notamment d'utiliser les droits de réplications. Il s'agit d'une étape plus complexe à détecter car Windows ne l'indique pas directement. Il faut trier selon 4662, qui correspond à un accès aux objets de l'AD.
Avec ceci, on voit qu'un tel accès est réalisé directement après l'utilisation du compte machine de l'attaquant. Ainsi, en regardant les propriétés de l'accès, celui-ci semble plus que illégitime. En effet, celles-ci permettent notamment la lecture des secrets...
Désormais, il faut alors partir du principe que l'attaquant a les clés du domaine et qu'il peut faire ce qu'il veut.
Parmi les affirmations, il est possible de vérifier l'accès aux registres en triant selon le canal IPC et l'évènement 5145 qui correspond à la modification dans un partage SMB.
Avec le compte pascal.gentilhomme et l'ID 5145, il est possible de voir les différents accès réalisés sur le partage SMB Tools et notamment le nom des fichiers déposés.
