Les attaquants s’attardent sur les ordinateurs des agences gouvernementales avant de déployer le ransomware Lockbit

Lors d’une attaque au cours de laquelle des groupes d’acteurs malveillants inconnus ont passé au moins cinq mois à fouiller dans le réseau d’une agence gouvernementale régionale américaine, les données de log comportementales suggèrent que deux voire plusieurs de ces groupes étaient actifs avant que le dernier groupe ne déploie, au début de cette année, la charge virale du ransomware Lockbit.

Tout au long de la période durant laquelle les attaquants ont été actifs sur le réseau de la cible, ils ont installé puis utilisé le navigateur Chrome pour rechercher (et télécharger) des outils de piratage sur l’ordinateur ‘Patient Zero’, à savoir un serveur, au niveau duquel ils ont obtenu leur premier accès. Bien que les attaquants aient supprimé de nombreux logs d’événement des machines qu’ils contrôlaient, ils ne les ont pas tous supprimés.

Les analystes ont trouvé des preuves, reconstruites à partir des logs, qui indiquaient que les acteurs malveillants avaient recherché (puis téléchargé) des outils à l’aide d’un navigateur Chrome qu’ils avaient installé sur le serveur compromis

Sophos a pu reconstituer le déroulement de l’attaque à partir de ces logs non altérés, qui ont offert un aperçu très précis des actions lancées par des attaquants, qui d’ailleurs n’étaient pas particulièrement sophistiqués, mais toujours aussi efficaces.

Par exemple, les logs révèlent que les attaquants avaient installé divers outils commerciaux d’accès à distance sur des serveurs et des postes de travail qui étaient accessibles. Il semble que ces derniers aient particulièrement apprécié l’outil de gestion IT ScreenConnect, mais ils ont ensuite utilisé AnyDesk pour tenter d’échapper à nos contre-mesures. Nous avons également trouvé des logs de téléchargement de divers outils d’analyse RDP, d’exploitation et d’attaque de mot de passe par force brute, ainsi que des enregistrements d’utilisations réussies de ces outils, prouvant ainsi l’implication du Remote Deskop de Windows.

En plus de divers scripts personnalisés et fichiers de configuration utilisés par les outils de piratage installés par les attaquants, nous avons trouvé une grande variété d’autres malwares, des brute-forceurs de mot de passe aux cryptomineurs, en passant par les versions piratées d’un logiciel client VPN commercial. Nous avons également trouvé des preuves que les attaquants utilisaient des outils gratuits tels que PsExec, FileZilla, Process Explorer ou GMER pour exécuter des commandes, déplacer des données d’une machine à une autre et tuer ou contourner les processus qui pouvaient entraver leurs actions.

Les preuves laissées montrent que les attaquants ont utilisé des outils tels que GMER, IObit Unlocker et Process Hacker pour essayer de désactiver la protection endpoint

De manière critique, les techniciens gérant le réseau cible ont laissé une fonction de protection désactivée après avoir achevé leurs activités de maintenance. Par conséquent, certains systèmes sont devenus vulnérables aux actions de sabotage menées par des attaquants, qui ont pu ainsi désactiver la protection endpoint sur les serveurs et certains postes de travail. Sans protection en place, les attaquants ont installé ScreenConnect pour bénéficier d’une méthode de sauvegarde d’accès à distance, puis se sont déplacés rapidement pour exfiltrer les fichiers présents au niveau des serveurs de fichiers sur le réseau vers le fournisseur de stockage Cloud Mega.

L’attaquant Lockbit a utilisé plusieurs connexions RDP internes ainsi que le client Windows SSH PuTTY, et a installé ScreenConnect, et ce en peu de temps

Au fur et à mesure, nous avons constaté que les tactiques des attaquants avaient changé, dans certains cas de manière si radicale que nous avons eu l’impression qu’un attaquant aux compétences très différentes était entré en jeu. La nature de l’activité récupérée à partir des logs et des fichiers historiques du navigateur sur le serveur compromis nous a donné l’impression que les acteurs malveillants qui ont pénétré dans le réseau en premier n’étaient pas des experts, mais plutôt des novices. Ainsi, il est fort probable qu’ils aient ensuite transféré le contrôle de leur accès distant à un ou plusieurs groupes différents et plus sophistiqués qui, finalement, ont lancé la charge virale du ransomware Lockbit.

Reconstitution de l’attaque à partir des logs

Les attaquants suppriment souvent les données de log pour faire disparaître les traces de leur passage, et cet incident n’a pas fait exception à cette règle : en effet, les attaquants ont supprimé manuellement presque toutes les données de log en remontant jusqu’à un mois avant les découvertes faites lors des premières investigations. Cependant, une analyse forensique plus approfondie indique que la compromission initiale a eu lieu près de six mois avant que les investigations ne débutent. La méthode d’infiltration n’avait rien d’extraordinaire : à savoir ouvrir des ports RDP au niveau d’un pare-feu, lequel était configuré pour fournir un accès public à un serveur.

Pendant un certain temps, l’invasion s’est déroulée plutôt calmement. Les attaquants ont eu de la chance car le compte qu’ils ont utilisé pour pénétrer dans le système via le RDP n’était pas seulement celui d’un administrateur local sur le serveur, mais ce dernier avait également des autorisations d’administrateur de domaine, ce qui leur a donné la possibilité de créer des comptes de niveau admin sur d’autres serveurs et ordinateurs de bureau.

Grâce à une reconstruction menée via des recherches dans les logs historiques, restés intacts, au niveau des navigateurs et des applications, les analystes de Sophos ont découvert un réseau mal équipé pour résister à ce type d’attaque, et des attaquants qui semblaient s’être très peu préparés aux actions à mener au-delà de l’obtention de l’accès initial.

Au cours de l’analyse post-attaque, les analystes de Sophos ont déterminé que les attaquants avaient utilisé les serveurs qu’ils contrôlaient à l’intérieur du réseau de la cible pour effectuer des recherches Google concernant de nombreux outils de piratage.

Les logs de navigation reconstruits montrent que l’acteur malveillant a tenté d’obtenir RDP Multi Tool à partir d’un site de téléchargement douteux, et a ensuite été submergé par des annonces publicitaires plutôt agressives

Dans certains cas, en suivant les résultats de recherche concernant ces outils, les attaquants ont pu découvrir toute une variété de sites de téléchargement suspects. Les réseaux publicitaires dont les bannières sont apparues sur ces sites semblent avoir généré des annonces publicitaires qui proposaient le téléchargement d’applications potentiellement indésirables (PUA) alors que les attaquants tentaient de rassembler maladroitement une sélection d’outils d’attaque, brouillant ainsi davantage les pistes et laissant le serveur infecté par des adwares et l’historique du navigateur encombré de redirections.

Un exemple de fausses “pages de téléchargement” qui ont fourni une application potentiellement indésirable à la machine contrôlée par l’attaquant alors qu’il tentait de télécharger des outils de piratage

Les traces forensiques laissées semblent confirmer qu’il s’agissait d’un attaquant novice en train de se former sur le tas, essayant d’installer des outils (après les avoir recherchés sur Google), ouvrant des fichiers texte de manière aléatoire, exécutant un nombre surprenant de tests de vitesse, sans pour autant viser un objectif particulier, ou lançant des actions dans l’urgence.

Les données de log accessibles ont indiqué que l’attaquant avait laissé le serveur tranquille durant plusieurs jours, de manière inattendue (et contre-intuitive), et ce pendant les périodes de vacances américaines. Lorsque ce dernier était sur le système, il semble qu’il ait utilisé une large gamme de services de partage de fichier public, dont les publicités imitaient les liens ou les boutons de téléchargement de fichier dans le but d’inciter les visiteurs à cliquer sur leur annonce au lieu d’utiliser le véritable lien présent sur la page : au final cette publicité a redirigé le visiteur vers un ensemble de sites, sans cesse changeant, proposant des malwares.

Certaines preuves montrent que l’attaquant a, soit cliqué par inadvertance sur le bouton de téléchargement associé à l’une de ces fausses publicités, soit a été victime de publicités de type ‘popup’ ou ‘popunder’. Ces dernières ont alors incité l’attaquant à lancer les téléchargements indésirables, qui ont ensuite permis l’installation d’adwares, faisant croire à l’attaquant qu’il s’agissait sans doute de la véritable copie piratée de l’outil qu’il souhaitait récupérer. Ces auto-infections involontaires ont créé un bruit additionnel au niveau des logs.

Contrairement à de nombreux acteurs malveillants qui préconfigurent des scripts d’attaque qui analysent, par exemple, les réseaux pour générer une liste de cibles, puis exécutent ces scripts pour lancer des charges virales sur des machines internes, les attaquants, dans notre cas, semblaient s’être contentés, pendant des mois, de fouiller et de créer occasionnellement un nouveau compte sur la machine initiale ou bien sur une autre. Certaines des attaques provenaient du dossier Bureau (Desktop) du compte utilisateur que les attaquants avaient initialement compromis, mais d’autres impliquaient des comptes de niveau admin que les attaquants avaient créés avec des noms tels que ASP.NET ou SQL.NET.

Passage à une attaque plus sérieuse

Cependant, cinq mois après l’infiltration initiale, le comportement de l’attaquant a radicalement changé. Après une pause de trois semaines, les logs ont indiqué qu’un attaquant s’était connecté à distance et avait installé Mimikatz, l’outil de récupération de mots de passe. Les protections Sophos l’ont détecté à temps, et ont pu traiter une première tentative d’infection. Malheureusement, le service IT n’a pas tenu compte de cet avertissement et une nouvelle tentative de l’attaquant visant à exécuter Mimikatz via un compte compromis a réussi (les attaquants ont également tenté de collecter des identifiants à l’aide d’un autre outil appelé LaZagne).

Les preuves montrent que les attaquants ont exécuté Mimikatz sur le bureau du compte administrateur de la machine “Patient Zero”

L’application permettant l’extraction (dumping) d’identifiants a fait son travail et, en quelques jours, les attaquants avaient un fichier password.txt sur le bureau des comptes admin qu’ils avaient créés sur le serveur compromis. Ce constat a marqué, d’une certaine manière, un tournant dans l’investigation. En effet, à ce stade, il fallait partir du principe que tout compte qui s’était connecté au serveur en difficulté était effectivement lui-même compromis, et ses identifiants exposés.

Mais un autre évènement a eu lieu : le jour même où le fichier passwords.txt est apparu, un individu a décidé de faire un peu de ménage. L’acteur malveillant initial, ou un attaquant plus récent, a visité des sites Web à la recherche d’instructions pour désinstaller un coinminer malveillant qui avait été installé auparavant sur le serveur compromis.

Le nettoyage des données de log est une action assez classique menée par les attaquants, même lorsque ces derniers ont bénéficié d’un temps de séjour plus court que celui observé dans notre cas. La suppression des logs élimine les informations forensiques utiles concernant la violation. Ainsi, l’attaquant a utilisé un compte compromis pour effacer les logs WitnessClientAdmin, Windows PowerShell et Système. À la fin de l’attaque, aucun log d’événement durant les cinq semaines précédant la fin de cette attaque n’était disponible sur le système.

L’attaquant a également repéré l’installation de Sophos endpoint et a essayé (sans succès) de la supprimer, en passant par une variété d’outils comme GMER et IOBit Uninstaller. Via un autre compte compromis, le ou les attaquants ont installé toute une gamme d’outils populaires de type force brute et proxy, notamment NLBrute.

Une liste partielle des outils utilisés à des fins malveillantes découverts sur le système compromis comprenait les éléments ci-dessous. Il convient de noter que tous ces outils ne sont pas intrinsèquement malveillants, et qu’il n’est pas surprenant de les trouver sur une machine saine et non infectée.

Mais soudainement, plus de quatre mois après la compromission initiale, non seulement les comportements des attaquants sont devenus d’un coup plus clairs, plus ciblés, mais les emplacements des visiteurs malveillants se sont étendus, avec des traces d’adresse IP indiquant des connexions depuis l’Estonie et l’Iran. Au final, le réseau compromis hébergerait des visiteurs malveillants à partir d’adresses IP géolocalisées en Iran, en Russie, en Bulgarie, en Pologne, en Estonie et… au Canada. Mais ces adresses IP pouvaient être aussi des nœuds de sortie Tor.

Paradoxalement, à peu près au même moment, le service IT de la cible a remarqué que les systèmes “agissaient de manière étrange”, redémarrant à plusieurs reprises, peut-être par l’action directe de l’acteur malveillant, peu de temps après la suppression des logs d’événement. Le service IT a alors commencé sa propre investigation et a finalement mis cinq douzaines de serveurs hors ligne pendant qu’il construisait une segmentation réseau pour protéger les appareils à priori sains. Cependant, pour réduire les interférences, le service IT a désactivé la protection antialtération de Sophos (Sophos Tamper Protection).

Les évènements se sont ensuite déroulés dans la frénésie la plus totale. Lors des dix derniers jours de l’infection, des mouvements et contre-mouvements effectués par les attaquants et le service IT, se sont multipliés. Au huitième jour, l’équipe Sophos est entrée en jeu. Jusqu’à la fin du dernier mois de l’attaque, un flux constant d’activités de configuration de table a eu lieu alors que les attaquants récupéraient les identifiants du compte, exécutaient des outils d’énumération du réseau, vérifiaient les capacités RDP et créaient de nouveaux comptes utilisateur, vraisemblablement pour se donner plus d’options au cas où ils seraient interrompus lors d’attaques ultérieures. Les logs ont été effacés plusieurs fois et les machines ont également redémarré pendant cette même période.

L’une des deux demandes de rançon, trouvée sur les systèmes où les fichiers avaient été renommés avec un nouveau suffixe de fichier, mais non chiffrés. Le retour au suffixe d’origine a permis de restaurer l’accès aux fichiers

Le premier jour du sixième mois de l’attaque, l’attaquant a lancé une action majeure en exécutant Advanced IP Scanner et en commençant presque immédiatement un mouvement latéral vers plusieurs serveurs sensibles. Les protections Sophos ont mis fin à plusieurs nouvelles tentatives d’installation de fichiers malveillants, mais des identifiants compromis ont permis à l’attaquant de contourner ces protections.

En quelques minutes seulement, le ou les attaquants ont eu accès à une multitude de fichiers personnels et d’achat sensibles, et ils ont alors travaillé dur pour lancer une nouvelle récupération d’identifiants.

La deuxième demande de rançon, trouvée sur des machines chiffrées avec succès avec LockBit

Le lendemain, la cible a décidé d’impliquer Sophos. Les analystes de nos Labs ont identifié 91.191.209.198:4444 comme étant une adresse de type ‘phone-home’ avec un shellcode associé, maintenant détecté sous le nom : ATK/Tlaboc-A et ATK/Shellcode-A. Pendant plusieurs jours, l’équipe IT et les analystes de Sophos ont recueilli des preuves, puis ont rapidement stoppé les serveurs qui fournissaient aux attaquants un accès à distance et ont alors travaillé pour supprimer le malware des machines qui n’avaient pas encore été chiffrées.

Heureusement pour la cible, sur au moins quelques machines, les attaquants n’étaient pas allés au bout de leur mission, car nous avons trouvé des fichiers qui avaient été renommés avec un suffixe de fichier lié au ransomware Lockbit, mais n’avaient pas été chiffrés. Dans ce cas précis, l’action de nettoyage impliquait tout simplement de renommer les fichiers pour restaurer les suffixes de fichier d’origine.

Conseils et détection

Au cours de l’investigation, un élément a semblé se dégager : l’équipe IT de la cible a fait une série de choix stratégiques qui ont permis aux attaquants de se déplacer librement et d’accéder aux ressources internes, et ce sans entrave. Le déploiement du MFA aurait empêché l’accès des acteurs malveillants, tout comme une règle de pare-feu bloquant l’accès à distance aux ports RDP en l’absence de connexion VPN.

Répondre rapidement aux alertes, voire aux avertissements concernant des performances réduites, aurait empêché de nombreuses phases d’attaque de porter leurs fruits. La désactivation de fonctionnalités telles que la protection antialtération au niveau des logiciels de sécurité endpoint semble avoir été le levier essentiel dont les attaquants avaient besoin pour supprimer complètement la protection et terminer leur travail sans entrave.

Les acteurs malveillants ayant utilisé le ransomware Lockbit ont également ajouté un appel à l’aide dans leur demande de rançon. Néanmoins, notre recommandation est la suivante : les insiders ayant accès à des informations sensibles doivent s’abstenir purement et simplement de commettre de tels cybercrimes en aidant les acteurs malveillants cherchant à déployer ces ransomwares.

Les binaires du ransomware Lockbit déployé lors de cette attaque sont détectés à l’aide de CryptoGuard et les divers outils d’attaque à double usage utilisés sont détectés comme présenté ci-dessous. Tous les fichiers ne sont pas systématiquement détectés car bon nombre de ces utilitaires ont un objectif légitime en termes d’administration IT.

Tous les autres IOC partageables liés à cette attaque sont indiqués ci-dessus. Sophos ne partage que des indicateurs et des échantillons qui ne peuvent pas être liés à une cible spécifique pour protéger la confidentialité de cette dernière.

Remerciements

Les SophosLabs souhaitent remercier les analystes Melissa Kelly, Peter Mackenzie, Ferenc László Nagy, Mauricio Valdivieso, Sergio Bestulic, Johnathan Fern, Linda Smith et Matthew Everts pour leur travail de reconstitution de cette attaque.

Billet inspiré de Attackers linger on government agency computers before deploying Lockbit ransomware, sur le Blog Sophos.