Le ransomware Qilin surpris en train de voler des identifiants stockés dans Google Chrome

Au cours d’une récente enquête sur une violation perpétrée par le ransomware Qilin, l’équipe Sophos X-Ops a identifié une activité malveillante qui a débouché sur un vol massif d’identifiants stockés dans les navigateurs Google Chrome au niveau d’un sous-ensemble de systèmes endpoint connectés au réseau : une technique de collecte d’identifiants avec des implications potentielles pouvant aller bien au-delà de l’organisation de la victime d’origine. Il s’agit d’une tactique inhabituelle, qui pourrait constituer une nouvelle tendance lucrative amplifiant toujours un peu plus le chaos déjà inhérent aux attaques de ransomware.

Le ransomware Qilin

Le groupe de ransomware Qilin est opérationnel depuis un peu plus de deux ans. Il a fait la une des journaux en juin 2024 suite à l’attaque contre Synnovis, un fournisseur de services gouvernemental travaillant pour divers prestataires de santé et hôpitaux britanniques. Avant l’activité malveillante que nous allons vous présenter dans cet article, les attaques du ransomware Qilin impliquaient souvent une “double extorsion” : à savoir le vol des données de la victime, le chiffrement des systèmes de celle-ci, puis la menace de révéler ou de vendre les données volées si la victime ne veut pas payer pour la clé de déchiffrement, une tactique que nous avons récemment abordée dans notre étude intitulée “Turning the Screws”.

L’équipe Sophos IR a observé l’activité décrite dans cet article en juillet 2024. Pour vous fournir un certain contexte précisons que cette activité a été repérée sur un seul contrôleur de domaine au sein du domaine Active Directory de la cible ; d’autres contrôleurs de domaine de l’AD concerné ont été infectés mais affectés différemment par le ransomware Qilin.

Manœuvres de départ

L’attaquant a obtenu un premier accès à l’environnement via des identifiants compromis. Malheureusement, cette méthode d’accès initial n’est pas nouvelle pour le ransomware Qilin (ou d’ailleurs pour d’autres gangs de ransomware). Notre enquête a indiqué que le portail VPN ne disposait pas d’une protection par authentification multifacteur (MFA).

Le temps de séjour de l’attaquant entre l’accès initial au réseau et ses déplacements ultérieurs était de dix-huit jours, ce qui peut (ou non) indiquer qu’un courtier d’accès initial (IAB) a permis d’effectuer la véritable incursion. Quoi qu’il en soit, dix-huit jours après l’accès initial, l’activité des attaquants sur le système a augmenté, avec des artefacts montrant un mouvement latéral vers un contrôleur de domaine utilisant des identifiants compromis.

Une fois que l’attaquant a atteint le contrôleur de domaine en question, il a modifié la stratégie par défaut pour introduire une GPO (Group Policy Object/Stratégie de groupe) de type connexion/logon et contenant deux éléments. Le premier élément, un script PowerShell nommé IPScanner.ps1, a été écrit dans un répertoire temporaire au sein du partage SYSVOL (SYStem VOLume) (à savoir le répertoire NTFS partagé situé sur chaque contrôleur de domaine au sein d’un Active Directory) sur le contrôleur de domaine spécifique impliqué. Il contenait un script de 19 lignes qui tentait de collecter les données d’identification stockées dans le navigateur Chrome.

Le deuxième élément, un script batch nommé logon.bat, contenait les commandes permettant d’exécuter le premier script. Cette combinaison a abouti à la collecte des identifiants enregistrés dans les navigateurs Chrome sur les machines connectées au réseau. Étant donné que ces deux scripts étaient liés à une GPO de type connexion/logon, ils s’exécutaient sur chaque ordinateur client lors de la connexion.

Sur les systèmes endpoint

Chaque fois qu’une connexion se produisait sur un système endpoint, logon.bat lançait le script IPScanner.ps1, qui à son tour créait deux fichiers : un fichier de base de données SQLite nommé LD et un fichier texte nommé temp.log, comme le montre la figure 1.

Figure 1 : Nous appelons cet appareil de démonstration Hemlock car il est effectivement vraiment toxique : voici les deux fichiers créés par le script de démarrage sur une machine infectée.

Ces fichiers ont été réécrits dans un répertoire nouvellement créé sur le partage SYSVOL du domaine et nommés d’après le nom d’hôte du (ou) des appareils sur lesquels ils ont été exécutés (dans notre exemple, Hemlock).

Le fichier de base de données LD contient la structure illustrée à la figure 2.

Figure 2 : Dans LD, le fichier de base de données SQLite est placé dans SYSVOL

Signe d’un certain niveau de confiance quant à sa capacité à ne pas se faire attraper ou bien à ne pas perdre son accès au réseau, l’attaquant a laissé cette GPO active sur le réseau pendant plus de trois jours. Cette stratégie a donné aux utilisateurs de nombreuses possibilités de se connecter à leurs appareils et, à leur insu, de déclencher le script de collecte d’identifiants sur leurs systèmes. Encore une fois, puisque l’activité malveillante s’appuie sur une GPO de type connexion/logon, chaque utilisateur allait ainsi subir ce vol d’identifiants à chaque connexion.

Pour rendre plus difficile l’évaluation de l’étendue de la compromission, une fois les fichiers contenant les identifiants collectés, volés et exfiltrés, l’attaquant a supprimé tous les fichiers et effacé les logs d’événement du contrôleur de domaine et des machines infectées. Après avoir supprimé les preuves, ils ont procédé au chiffrement des fichiers et à l’envoi de la demande de rançon, comme le montre la figure 3. Ce ransomware laisse une copie de la demande de rançon dans chaque répertoire de l’appareil sur lequel il s’exécute.

Figure 3 : Une demande de rançon Qilin

Le groupe Qilin a de nouveau utilisé une GPO comme mécanisme pour affecter le réseau en lui faisant créer une tâche planifiée pour exécuter un fichier batch nommé run.bat, qui a ensuite téléchargé et exécuté le ransomware.

Impact

Dans cette attaque, le script IPScanner.ps1 ciblait les navigateurs Chrome, à savoir statistiquement le choix le plus susceptible de générer une collecte abondante de mots de passe, puisque Chrome détient actuellement un peu plus de 65% du marché des navigateurs. Le succès de chaque tentative dépendait alors de la quantité d’identifiants que chaque utilisateur stockait dans le navigateur (en ce qui concerne le nombre de mots de passe pouvant être acquis sur chaque machine infectée, une enquête récente indique que l’utilisateur moyen possède 87 mots de passe professionnels et environ deux fois plus de mots de passe personnels).

Une compromission réussie de ce type implique que non seulement les défenseurs doivent changer tous les mots de passe Active Directory ; mais ils doivent également (en théorie) demander aux utilisateurs finaux de modifier leurs mots de passe pour des dizaines, voire des centaines, de sites tiers pour lesquels les utilisateurs ont enregistré leurs combinaisons nom d’utilisateur/mot de passe dans le navigateur Chrome. Les défenseurs n’auraient bien sûr aucun moyen d’obliger les utilisateurs à effectuer tous ces changements. Concernant l’expérience d’un point de vue utilisateur final, même si pratiquement tous les internautes ont reçu à ce stade au moins une notification du type “vos données ont été volées” provenant d’un site qui a perdu le contrôle des données de leurs utilisateurs, dans cette situation particulière, c’est l’inverse : un utilisateur est associé à des dizaines ou des centaines de violations distinctes.

Il est peut-être intéressant de noter que, dans cette attaque spécifique, d’autres contrôleurs de domaine du même Active Directory ont été chiffrés, mais que le contrôleur de domaine sur lequel cette GPO spécifique a été initialement configurée n’a pas été chiffrée par le ransomware. Les raisons pouvant expliquer cette absence de chiffrement, à savoir un raté, un oubli, des tests A/B de l’attaquant, dépassent le cadre de notre enquête (et de cet article).

Conclusion

Comme on pouvait s’y attendre, les groupes de ransomware continuent de changer de tactique et d’enrichir leur gamme de techniques. Le groupe de ransomware Qilin a peut-être décidé qu’en ciblant simplement les actifs réseau de ses organisations cibles, il passait à côté de potentielles opportunités.

Si ce groupe, ou d’autres attaquants, ont décidé d’exploiter également les identifiants stockés au niveau des systèmes endpoint, ce qui pourrait fournir un potentiel accès à une cible ultérieure, ou bien des mines d’informations sur des cibles de grande valeur à exploiter par d’autres moyens, alors il est clair qu’un nouveau chapitre, plutôt sombre, vient peut-être de s’ouvrir dans l’histoire actuelle de la cybercriminalité.

Remerciements

Anand Ajjan des SophosLabs, ainsi qu’Ollie Jones et Alexander Giles de l’équipe Incident Response, ont contribué à cette analyse.

Réponse et remédiation

Les entreprises et les particuliers doivent s’appuyer sur des gestionnaires de mots de passe qui utilisent les meilleures pratiques du secteur en matière de développement de logiciels et qui sont régulièrement testés par des organismes tiers indépendants. L’utilisation d’un gestionnaire de mots de passe basé sur un navigateur s’est avérée à maintes reprises non sécurisée, cet article en étant la preuve la plus récente.

L’authentification multifacteur aurait été une mesure préventive efficace dans une telle situation, comme nous l’avons déjà dit précédemment. Bien que l’utilisation du MFA continue d’augmenter, une étude Lastpass de 2024 indique que même si l’adoption du MFA dans les entreprises de plus de 10 000 employés atteint un taux pas vraiment extraordinaire de 87 %, ce niveau d’adoption chute brutalement, en passant de 78 % pour les entreprises de 1 001 à 1 000 employés à un taux de 27 % pour les entreprises de 25 employés ou moins.  Pour parler franchement, les entreprises doivent faire beaucoup mieux, pour leur propre sécurité, et dans ce cas-ci, pour celle des autres entreprises également.

Notre propre requête Powershell.01 a joué un rôle déterminant dans l’identification des commandes PowerShell suspectes exécutées au cours de l’attaque. Cette requête est disponible gratuitement sur notre Github, parmi bien d’autres.

Sophos détecte le ransomware Qilin sous le nom Troj/Qilin-B avec des détections comportementales telles que Impact_6a et Lateral_8a. Le script décrit ci-dessus est détecté sous le nom Troj/Ransom-HDV.

Billet inspiré de Qilin ransomware caught stealing credentials stored in Google Chrome, sur le Blog Sophos.