Les chercheurs en sécurité de chez ESET ont découvert un nouveau malware destructeur de données, surnommé SwiftSlicer, qui a un objectif bien précis : détruire votre domaine Active Directory !
Derrière SwiftSlicer, se cache le groupe de pirates russes Sandworm, et ce malware a été découvert par les chercheurs en sécurité d'ESET à la suite d'une cyberattaque contre une entité basée en Ukraine. Dernièrement, le groupe Sandworm s'en est pris à plusieurs reprises à l'Ukraine, notamment avec le destructeur CaddyWiper. Même s'il est question de Windows dans le cas présent, le groupe Sandworm utilise également des malwares "compatibles" Linux.
Codé en Go, qui est un langage très apprécié par les cybercriminels, le malware SwiftSlicer veut clairement détruire les domaines Active Directory car il s'en prend directement au répertoire "%CSIDL_SYSTEM_DRIVE%\Windows\NTDS" qui contient la base d'annuaire Active Diretory. Cette base d'annuaire Active Directory contient les informations du domaine, ainsi que l'ensemble des objets.
Pour détruire les données, le malware écrase le contenu des fichiers en les remplissant avec des blocs de 4096 octets, générés aléatoirement. L'action de destruction effectuée par SwiftSlicer peut être particulièrement dévastatrice. En effet, en détruisant la base d'annuaire, c'est tout le fonctionnement de l'infrastructure qui peut être perturbé, notamment l'ouverture de session, l'accès à des ressources (partages, applications, imprimantes, etc... Compte tenu de la place importante que prend l'Active Directory dans les organisations où il est déployé.
Pour procéder à la destruction du domaine Active Directory, les pirates doivent bénéficier des droits admins car ils utilisent une stratégie de groupe (GPO) pour exécuter SwiftSlicer sur les machines. Les chercheurs d'ESET ont également constaté que SwiftSlicer détruisait les clichés instantanés ainsi que des pilotes Windows, en plus de la base Active Directory en elle-même.
Une fois encore, cette menace montre à quel point il est important d'avoir un système de sauvegarde fiable et qu'il est indispensable de sauvegarder les contrôleurs de domaine, même s'il y en a plusieurs pour assurer la disponibilité du service Active Directory.
Au sein d’une future version majeure, Windows 11 pourrait bénéficier du système de fichiers ReFS : une nouveauté intéressante pour ce système d’exploitation destinés aux postes de travail.
Lorsque l’on installe Windows 11 (ou Windows 10), le système est installé sur un volume formaté avec le système de fichiers NTFS. C’est le cas depuis de nombreuses versions de Windows. Toutefois, cela pourrait changer pour Windows 11 puisque, dernièrement, la firme de Redmond a mis en ligne la build 25281 (preview) et celle-ci permet d’utiliser le système de fichiers ReFS à la place de NTFS pour le volume système.
Microsoft n’a pas documenté cette possibilité et ne l’a pas précisé dans la liste des changements, mais des petits malins sont parvenus à obtenir cette information et à trouver comment activer la fonctionnalité. D'ailleurs, cette information a circulée sur Twitter via les comptes @XenoPanther et @PhantomOfEarth.
Bien que le système de fichiers NTFS soit beaucoup plus populaire, ReFS n’est pas nouveau puisqu’il existe depuis l’époque de Windows 8 et Windows Server 2012. Il s’agit d’un système de fichiers dont Microsoft est propriétaire et qui est déjà utilisé sur les serveurs dans certains cas. Par exemple, sur un serveur de messagerie Exchange dans le but de stocker la base de données (qui contient les boîtes aux lettres, notamment).
En comparaison de NTFS, le système de fichiers ReFS (pour Resilient File System) se veut plus moderne et apporte des fonctions supplémentaires pour améliorer l’intégrité des données, la disponibilité et la scalabilité. Par exemple, on peut citer la fonction "Block Clone" qui permet de réduire les entrées/sorties et d'augmenter les performances.
Sur le site de Microsoft, on peut trouver la liste des fonctions exclusives à ReFS en comparaison de NTFS :
Activer la prise en charge ReFS sur Windows 11
Pour être plus précis et activer cette possibilité, cela nécessite d’utiliser ViveTool (disponible gratuitement sur GitHub). Ensuite, il faut exécuter la commande suivante en tant qu'administrateur :
c:\vivetool\vivetool /enable /id 42189933
Cela va permettre, en lançant l'ISO d'installation de Windows 11, d'avoir la possibilité d'utiliser ReFS !
Reste à savoir quand le support de ReFS sera ajouté à une version stable de Windows 11 (pour le système), et quelles sont les éditions qui pourront en profiter ? Seulement les éditions Enterprise et Éducation, ou également les éditions Pro et Famille ? La question reste en suspend pour le moment. Attendons d’en savoir plus sur les travaux de Microsoft à ce sujet.
Dans ce tutoriel, nous allons apprendre à configurer une zone de recherche inversée sur un serveur DNS lié à l'Active Directory, sous Windows Server 2022. Nous verrons également comment créer des enregistrements PTR, propres à ce type de zone.
La zone de recherche inversée va permettre de résoudre les adresses IP en nom, ce qui revient à faire l'inverse de ce que l'on demande habituellement à un serveur DNS. Ainsi, si je demande à mon serveur DNS à qui correspond l'adresse IP "192.168.100.11", il devrait me retourner le nom d'hôte correspondant. Par défaut, ce n'est pas le cas, car la zone de recherche inversée n'existe pas. On peut le constater en effectuant une requête nslookup :
C'est là que la zone de recherche inversée et les enregistrements PTR entrent en scène...
Personnellement, je vous recommande de créer une zone de recherche inversée pour vos différents sous-réseaux, notamment parce que c'est très utile en phase de troubleshooting. Ce n'est pas mis en place par défaut, mais c'est une bonne pratique d'effectuer cette configuration.
II. DNS - Créer une zone de recherche inversée
Sur votre contrôleur de domaine, qui doit être également serveur DNS, ouvrez la console DNS. Bien entendu, vous pouvez aussi utiliser un serveur d'administration sur lequel sont installés les outils RSAT. Au sein de cette console, vous pouvez visualiser vos deux "Zones de recherche directes", tandis que la section "Zones de recherche inversée" est vide.
Effectuez un clic droit sur "Zones de recherche inversée" puis cliquez sur "Nouvelle zone...".
L'assistant de création d'une nouvelle zone se lance. Tout d'abord, vous devez choisir "Zone principale" et cocher l'option en bas de page pour que la zone soit inscrite dans l'Active Directory, au même titre que la zone DNS du domaine. Poursuivez.
Cette zone doit être répliquée vers l'ensemble des serveurs DNS associés à ce domaine pour que la résolution DNS inversée fonctionne sur l'ensemble du réseau local. Choisissez la seconde option comme sur l'image ci-dessous.
Sélectionnez "Zone de recherche inversée IPv4", car ici je travaille sur un réseau local adressé en IPv4, et poursuivez.
L'étape "Nom de la zone de recherche inversée" est importante, car elle contient le champ "ID réseau" où on doit déclarer le sous-réseau concerné par la zone de recherche inversée. J'indique "192.168.100", car cette zone est associée au réseau "192.168.100.0/24". On peut voir que la zone sera nommée : 100.168.192.in-addr.arpa.
L'étape suivante concerne les mises à niveau dynamique, cochez "N'autoriser que les mises à jour dynamiques sécurisées" pour protéger cette zone à minima. Option classique en environnement Active Directory.
Voilà, c'est la fin de la création de la zone. Cliquez sur "Terminer".
La zone est immédiatement disponible et visible dans l'interface du serveur DNS.
III. Créer un enregistrement PTR
C'est bien beau, la zone existe, mais que fait-on maintenant ?
À partir de l'interface DNS, vous pouvez créer un nouvel enregistrement PTR via un clic droit "Nouveau pointeur (PTR)".
Toutefois, il est important que je vous explique la notion de pointeur. Un enregistrement PTR permet de fournir le nom de domaine (FQDN) associé à une adresse IP, en l'occurrence ici, il va permettre de retourner le nom DNS d'un hôte à partir de son adresse IP. C'est un enregistrement spécifique aux zones de recherche inversée.
Par défaut, les machines Windows sont configurées pour s'enregistrer dans le DNS (enregistrements A et PTR), y compris les machines adressées en DHCP. Pour les machines avec une adresse IP fixe, que l'on peut appeler des hôtes statiques (par exemple : un serveur en adresse IP fixe), on peut créer manuellement les enregistrements.
De ce fait, vous pouvez créer un enregistrement PTR pour le contrôleur de domaine, en spécifiant son adresse IP puis le nom d'hôte complet : nom de la machine couplé au nom du domaine Active Directory.
Validez. L'enregistrement PTR est créé. Cet enregistrement PTR créé manuellement est statique donc il n'expire pas.
Pour vérifier qu'il est opérationnel, on peut réutiliser l'outil "nslookup" comme au tout début, avant que la zone DNS soit créée. Cette fois-ci, nous n'avons pas d'erreur, mais une réponse satisfaisante puisque le nom d'hôte est indiqué !
nslookup 192.168.100.11
La zone de recherche inversée pour ce sous-réseau est opérationnelle au sein du serveur DNS !
Sachez qu'il est possible de créer un enregistrement PTR avec une commande PowerShell afin de gagner du temps s'il y a un ensemble d'hôtes à intégrer. Dans l'exemple ci-dessous, on crée le même enregistrement que celui créé précédemment en mode graphique.
-Name : adresse IP de l'hôte, en l'occurrence "11" car c'est l'IP "192.168.100.11"
-PtrDomainName : nom d'hôte (FQDN)
-TimeToLive : durée de la mise en cache de cet enregistrement (facultatif)
Vous pouvez aussi faire un script qui récupère vos enregistrements DNS A (statique ou correspondants à vos serveurs), pour générer les enregistrements PTR car il s'agit d'inverser les informations. A ce sujet pour vous aider :
Voilà, vous venez de mettre en place une zone de recherche inversée au sein de votre serveur DNS ! Désormais, vous pouvez faire de la résolution de noms en adresses IP mais aussi de la résolution d'adresses IP en noms ! Au sujet des mises à jour dynamiques dans le DNS, vous pouvez consulter la documentation de Microsoft :
Quand un utilisateur ouvre sa session pour la première fois sur une machine Windows 10 ou Windows 11, il y a une animation qui est affichée à l'écran. Comment peut-on désactiver cette animation par GPO ? C'est ce que nous allons voir dans ce tutoriel !
Cette animation s'affiche pendant que Windows travaille en tâche de fond puisqu'il crée le profil de l'utilisateur sur la machine, ce qui implique la création du dossier dans "C:\Users", l'application des paramètres de stratégies, des applications, etc... Personnellement, sur les infras où je suis intervenu pour mettre en place des GPOs, j'ai pris pour habitude de désactiver cette animation qui s'affiche à la première connexion, car elle permet de gagner quelques secondes.
Je fais référence à l'animation qui dit "Bonjour. Préparation des informations pour vous. Cette opération peut prendre quelques minutes..." et qui s'affiche avant de donner accès au bureau.
II. Désactiver l'animation de première connexion par GPO
Le paramètre que nous allons configurer s'applique au niveau des machines, c'est-à-dire que c'est un paramètre ordinateur. Vous pouvez le configurer dans une GPO existante ou configurer une nouvelle GPO. Ce paramètre se situe à l'emplacement suivant :
Configuration ordinateur > Stratégies > Modèles d'administration > Système > Ouverture de session
Ici, vous allez trouver un paramètre nommé "Afficher l'animation à la première connexion".
Ce paramètre doit être configuré afin d'être défini sur l'état "Désactivé" comme sur l'image ci-dessous.
Il n'y a que ce paramètre à configurer pour désactiver l'animation de Windows qui s'affiche à la première connexion d'un utilisateur ! Ce paramètre est le même pour les différentes versions de Windows, dont Windows 10 et Windows 11. Désormais, il ne reste plus qu'à attendre ou effectuer un "gpupdate /force" sur une machine pour tester !
Ce paramètre correspond à la valeur de Registre nommée "EnableFirstLogonAnimation" (voir ici) qui peut être modifiée manuellement ou avec PowerShell (implique les droits admin puisque l'on touche à la ruche HKLM de Windows).
Dans ce tutoriel, nous allons simuler le fonctionnement d'un ransomware à l'aide de PSRansom, un outil basé sur deux scripts PowerShell, particulièrement simple à utiliser ! Pourquoi écrire un article à ce sujet ? Tout simplement, à des fins éducatives, de tests, de démonstration, de sensibilisation, mais aucun cas pour vous inciter à réaliser ce type d'acte malveillant. Par ailleurs, sur un environnement de tests et isolé de votre production, vous pouvez effectuer cette simulation pour voir comment réagissent vos outils de sécurité !
On entend régulièrement parler des attaques par ransomware, et on espère ne pas avoir à faire face à cette situation, mais qu'en est-il en pratique ? Comment cela fonctionne ? Même s'il existe de nombreuses manières de chiffrer des données, et qu'il y a plein de ransomwares différents, avec des fonctionnalités diverses et variées, grâce à l'outil PSRansom nous allons pouvoir effectuer une simulation réaliste. Cela est d'autant plus vrai que nous allons pouvoir appliquer le principe de la double extorsion !
PSRansom va permettre de mettre en œuvre un scénario basé sur deux machines :
Un serveur de Command & Control (C2) destiné à recevoir les données exfiltrées par le ransomware via des requêtes HTTP
Un serveur où sera exécuté le logiciel malveillant de type ransomware représenté par un script PowerShell qui va chiffrer les données du volume ou répertoire spécifié
Le chiffrement est réalisé en AES-256, à l'aide d'une fonction d'une fonction PowerShell
Une fois que les données seront chiffrées (réellement), un fichier texte sera créé sur le serveur et ce dernier contient la clé de déchiffrement pour restaurer les données. Ainsi, le ransomware fictif intègre une fonction de restauration de données permettant de faire un retour arrière.
Le projet PSRansom est disponible à cet emplacement :
Attention : même s'il s'agit d'une simulation, ce n'est pas sans risque notamment si une mauvaise manipulation est effectuée donc utilisez cet outil sur un environnement de tests.
II. Déployer le serveur C2
Mon serveur C2 sera représenté par une machine sous Kali Linux, mais vous pouvez utiliser une autre distribution Linux, voire même une machine Windows. Sur cette machine, nous avons besoin de Git et de PowerShell puisque PSRansom est codé en PowerShell. Ce qui donne :
Ensuite, on peut cloner le projet PSRansom en local pour récupérer les sources de notre ransomware fictif :
git clone https://github.com/JoelGMSec/PSRansom
Dans ce répertoire, il y a deux scripts intéressants :
C2Server.ps1 à exécuter sur le serveur C2 pour le démarrer et qu'il soit en écoute
PSRansom.ps1 à exécuter sur le serveur compromis pour chiffrer les données
À partir d'une console PowerShell ou de votre Shell, exécutez la commande ci-dessous pour que le serveur C2 soit en écoute sur toutes ses interfaces et sur le port 80 :
pwsh ./C2Server.ps1 + 80
On peut voir qu'il passe en attente de connexion :
Vous pouvez remplacer "+" par une adresse IP spécifique et configurée sur la machine locale. Si vous exécutez le serveur C2 sur une machine Windows, vous devez préciser "*" à la place de "+" pour écouter sur toutes les interfaces. Ici, j'utilise le port d'écoute "80" mais vous pouvez utiliser un autre port.
À partir du moment où le serveur C2 est démarré, vous pouvez accéder à la page Web en précisant l'adresse IP et le port, ce qui permet de vérifier le bon fonctionnement.
III. Simuler l'attaque par ransomware
Maintenant, nous allons pouvoir simuler l'attaque par ransomware sur la machine Windows compromise ! Ici, on va à l'essentiel en exécutant manuellement le script "PSRansom.ps1" sur l'hôte Windows puisque l'on ne s'intéresse pas à toute la phase de compromission de la machine en elle-même menant jusqu'à l'exécution de la charge finale.
Note : nous pourrions imaginer un scénario où le script PSRansom.ps1 est hébergé sur le serveur C2, et dans ce cas, il pourrait être chargé depuis le serveur compromis pour exécuter la charge utile.
Pour l'exemple, je vais m'attaquer aux données situées dans le répertoire "C:\Partage" :
Quant au script PSRansom, on peut consulter l'aide (depuis Windows ou Linux) avec cette commande :
# Windows
.\PSRansom.ps1 -h
# Linux
pwsh ./PSRansom.ps1 -h
De ce fait, après avoir consulté l'aide, on peut démarrer le chiffrement des données en utilisant la commande suivant :
Plus précisément, le ransomware fictif va chiffrer les données situées dans "C:\Partage" et exfiltrer les données en clair vers le serveur C2 accessible à l'adresse 192.168.100.71:80.
Du côté du serveur C2, on peut voir qu'une connexion est établie, et nous avons des détails sur l'hôte compromis. La clé de déchiffrement est également spécifiée, ainsi que le nom des fichiers reçus par le serveur C2.
D'ailleurs, les fichiers exfiltrés sont visibles dans le répertoire "C2Files" présente sur le serveur C2.
Sur le serveur compromis, les données ont hérité de l'extension ".psr" et elles sont illisibles, car elles sont chiffrées !
IV. Restaurer les données
Pas de panique ! Dans le fichier "readme.txt" déposé à la racine du répertoire "C:\Partage", on peut récupérer la clé de déchiffrement ! Lorsque l'attaque est réelle, ce fichier prend la forme d'une note de rançon où l'on va retrouver les informations pour contacter les cybercriminels et entrer en négociation, notamment au sujet du montant de la rançon dans le but d'obtenir la clé de déchiffrement.
Pour finir cette simulation, il ne reste plus qu'à déchiffrer les données avec cette commande :
.\PSRansom.ps1 -d "C:\Partage" -k <clé de déchiffrement>
Attention, si vous ne fournissez pas la bonne clé de déchiffrement, les données seront supprimés d'après les tests effectués. Après cette opération, les données sont de retour dans leur état d'origine !
V. Conclusion
Grâce à PSRansom, on peut simuler facilement une attaque par ransomware et faire une démonstration en quelques minutes. Le fait que tout soit fait via PowerShell le rend multi-OS et ne nécessite pas d'installer de nombreuses dépendances. Ce qui est intéressant dans le fonctionnement, c'est que ce sont les fichiers chiffrés qui sont transmis du serveur compromis vers le serveur C2, et ce dernier déchiffre les données en local. Même s'il s'agit d'un flux HTTP, les fichiers qui transitent sur le réseau sont chiffrés.
