Réseau : les signaux faibles qui pourraient permettre de détecter une attaque du groupe LockBit
Le groupe d’attaquants derrière le rançongiciel LockBit opère depuis 2019 et fait des ravages dans de nombreux systèmes d’information. La France n’est pas épargnée et le groupe est à l’origine notamment, de l’incident subi le 20 août dernier par le Centre Hospitalier Sud Francilien de Corbeil-Essonnes1. Quelques semaines auparavant, il avait également compromis l’opérateur La Poste Mobile avant, là aussi de diffuser une partie des données clients qu’ils avaient pu dérober.
À partir de plusieurs sources reprenant les techniques et outils utilisés par ces attaquants, tentons de découvrir les signaux faibles observables sur le réseau pouvant permettre d’alerter sur une potentielle attaque en cours.
Certaines actions pourraient bien évidemment être détectées via des remontées de logs des systèmes d’exploitation, d’EDR ou encore des pares-feux vers un SIEM. Nous nous intéresserons ici uniquement aux signaux pouvant être observés de façon totalement passive en écoutant le réseau, sans en déchiffrer les flux.
Lors du dernier Congrès National de la Sécurité des SI de Santé, nous présentions2 avec Gérard Gaston, RSSI du Groupe LNA Santé, la solution libre et clé en mains SELKS3, permettant d’exploiter facilement le moteur de supervision réseau orientée sécurité Suricata (IDS / IPS / NSM)4, ainsi que le projet de partage de règles de détection Paw Patrules5.
Une partie du scénario de l’attaque vécue par le CHSF ayant été révélée dans la presse6, nous nous baserons notamment sur les éléments techniques contenus dans cet article, ainsi que les règles partagées via le projet Paw Patrules ainsi que les règles communautaires d’Emerging Threat.
1. AnyDesk
Après s’être apparemment introduit sur le système d’information par le biais d’un accès VPN prestataire compromis, l’outil de contrôle à distance AnyDesk aurait été utilisé pour maintenir facilement l’accès au SI.
La connexion d’un agent AnyDesk est détectable de plusieurs façons. Soit via son agent utilisateur HTTP, soit via une empreinte JA3 (condensat MD5 basé sur les algorithmes de chiffrement acceptés par le client TLS), soit via les certificats auto-signés présentés par les serveurs AnyDesk lors de l’établissement d’une connexion TLS1.2. La méthode de détection la plus fiable à ce jour pour AnyDesk reste les certificats présentés par les serveurs de contrôle, les flux HTTP étant assez rares et l’empreinte JA3 évoluant lors de changements de versions majeures.
Lorsque l’agent AnyDesk est lancé sur une machine connectée à un réseau supervisé par Suricata, plusieurs alertes vont remonter :
Ici plusieurs alertes indiquent que le certificat auto-signé a été présenté par des serveurs AnyDesk.
En bonus, nous constatons également un flux TLS sur un port non standard. En regardant de plus près, on constate qu’une connexion TLS vers un serveur AnyDesk a été établie sur le port 80 :
L’empreinte JA3 d’une version 7 d’AnyDesk pourra également permettre de déceler la présence de la solution :
2. PCHunter
Afin de désactiver les solutions de protection (type EPP / EDR) installées sur des systèmes d’exploitation Windows, les attaquants semblent toujours utiliser l’outil d’administration PCHunter, qui permet notamment de tuer facilement des processus en cours d’exécution. Ils semblent plutôt adeptes de cet outil puisqu’ils l’utilisaient déjà en 2021 lors du déploiement de la version 2.0 de LockBit7.
Il est assez facile à détecter dès lors qu’il est lancé sur une machine disposant d’un accès à internet puisqu’il tente de joindre le serveur de l’éditeur pour vérifier l’existence d’une nouvelle version (même si celui-ci n’est plus maintenu) via une connexion HTTP avec un agent utilisateur reprenant son nom ainsi que l’architecture utilisée (32 ou 64 bits), ici donc « PCHunter64 » :
3. MEGA
Afin d’exfiltrer les données du CHSF, le groupe LockBit aurait utilisé une nouvelle fois le service de partage de fichiers MEGA. Là encore, bien que les flux soient chiffrés et même si le protocole TLS1.3 est utilisé, il sera possible via les requêtes DNS et le sni contenant « mega.co.nz » de détecter une connexion TLS aux serveurs MEGA. Même si certaines rumeurs laissent entendre que le groupe LockBit aurait développé son propre outil d’exfiltration de fichiers, nous nous appuierons pour la démonstration sur Rclone, un outil de copie / synchronisation de fichiers « multi fonctions » très utilisés par les opérateurs du monde du rançongiciel pour exfiltrer des données, notamment vers MEGA.
Avec ces règles en place, une exfiltration de fichiers vers MEGA devrait lever plusieurs alertes.
4. Scan du réseau
Comme indiqué dans la méthodologie d’attaque présentée par Palo Alto8, un scan de ports sur le réseau doit très certainement être effectué lors de la phase de reconnaissance pour chaque attaque. Là encore, ce type d’action a tendance à faire pas mal de bruit sur le réseau, et une règle basée sur un nombre important de SYN / TCP par seconde pourra permettre de mettre en avant un scan de ports.
5. Utilisation du compte administrateur
Le scénario décrit dans l’article n’indique pas si le compte administrateur a été utilisé dans le processus ayant permis d’aboutir au chiffrement des serveurs Windows. Si c’était le cas, son utilisation à distance serait assez facile à détecter.
6. Connexion SSH aux serveurs ESXi
L’article indique que les attaquants se sont connectés via le protocole SSH sur les serveurs hôtes VMware ESXi afin de chiffrer directement les machines virtuelles qu’ils exécutaient. Une connexion SSH sur un serveur ESXi n’étant pas une « tâche d’administration courante », le service est d’ailleurs nativement désactivé par l’éditeur, détecter une telle connexion aurait donc du sens.
Si les serveurs ESXi s’appuient sur un serveur OpenSSH et se présentent comme tel (le numéro de version pourra varier en fonction des versions et des patchs appliqués) lors de l’établissement de la connexion depuis un client SSH (PuTTY dans cet exemple), leur configuration est assez spécifique côté algorithmes de chiffrement utilisés pour pouvoir les identifier grâce à ces informations, en calculant leur HASSH9.
Malgré certaines idées reçues, l’écoute du réseau sans en déchiffrer les flux permet de facilement mettre en lumière des actions suspectes ou mauvaises pratiques. Un mode opératoire comme celui utilisé par le groupe LockBit pour compromettre le système d’information du CHSF le démontre assez bien. Alors, vous aussi, soyez à l’écoute de votre réseau.
1 https://www.chsf.fr/cyberattaque-chsf-communique-de-presse/
3 https://www.stamus-networks.com/selks
8 https://unit42.paloaltonetworks.com/lockbit-2-ransomware/#tactics-techniques-procedures