FIN 7 : détecter et contrer un acteur important du cybercrime

Le CERT-FR de l’ANSSI avait d’ailleurs publié un rapport très intéressant sur ce groupe l’an dernier [1]. Dans un rapport publié fin décembre par les équipes de Prodaft [2], il est possible de découvrir une « nouvelle » (ou non encore identifiée) méthode utilisée par le groupe pour conserver un accès persistant sur les machines de ses victimes : une porte dérobée s’appuyant sur le protocole SSH.

En observant à l’aide de la plateforme française Onyphe [3], l’exposition sur internet des serveurs dont les adresses IP sont indiquées dans la section IOC du rapport, on constate plusieurs similitudes. Tout d’abord, ces serveurs présentent tous sur des ports non standards, mais similaires, leur service SSH.

Suivant les serveurs rencontrés, un ou plusieurs ports sont actifs, mais même si les 3 ports différents utilisés ne sont pas standards (le port 22/TCP est le port SSH par défaut), ils ne sont pas choisis au hasard : 

- le port 53/TCP (utilisé nativement par le protocole DNS)

- le port 80/TCP (utilisé nativement par le protocole HTTP)

- le port 443/TCP (utilisé nativement par le protocole HTTPS)

Second constat, ils utilisent tous un serveur OpenSSH déployé sur un système Debian.

En poussant un peu plus loin les investigations et en tentant de dialoguer avec ces serveurs, il est, sans réelle surprise, possible de découvrir qu’ils présentent tous les mêmes caractéristiques cryptographiques. À partir de ces informations, il est possible de calculer une empreinte appelée « hassh » [4], pouvant être calculée automatiquement par le moteur de détection Suricata [5] et utilisée dans le cadre d’une règle de détection.

Bon, si on récapitule, un serveur SSH exposé sur les ports non standards 53/TCP, 80/TCP et 443/TCP, présentant un serveur OpenSSH, s’appuyant sur une distribution Debian, avec des caractéristiques identiques, ça devrait pouvoir permettre d’avoir alerte sans générer trop de faux positifs tout ça !

La règle est disponible dans la collection proposée sur le site PAW Patrules [6] et une démonstration de détection est disponible en vidéo [7].

Après quelques recherches effectuées conjointement avec Patrice Auffret, fondateur d’Onyphe que je remercie au passage, nous avons pu observer sans surprise que la règle pouvait générer des faux positifs, mais pas tant que ça, par exemple en se basant sur les mêmes hébergeurs que les serveurs malveillants identifiés par Prodaft, avec les informations identifiées précédemment, les données extraites d’Onyphe présentent une trentaine de serveurs supplémentaires qui répondent aux critères mais qui ne sont pas des serveurs C2 du groupe FIN7. Selon son concurrent Shodan, 2000 machines répondraient à ces critères tout hébergeurs confondus.

Se connecter à un serveur SSH exposé sur un internet, utilisant les ports 53/TCP, 80/TCP ou 443/TCP n’est pas quelque chose de courant, si l’on ajoute encore comme filtre, le type de serveur utilisé, l’OS et les caractéristiques cryptographiques, les chances de faux positifs diminuent, il serait donc dommage de ne pas utiliser cette règle. Dans le cas d’un usage légitime, il est toujours possible de créer une exception via sa solution préférée, comme SELKS [8] par exemple.

Au-delà de la détection, on peut se dire qu’il est également assez facile de bloquer des connexions de ce type en appliquant une analyse protocolaire sur ses flux réseau sortants et en limitant l’accès aux protocoles standards DNS, HTTP et HTTPS, respectivement sur les ports 53/TCP, 80/TCP et 443/TCP.

Les pares-feux français SNS de Stormshield [9] par exemple, sont en capacité de réaliser ce type d’analyse et de bloquer des flux non conformes facilement.

[1] https://www.cert.ssi.gouv.fr/cti/CERTFR-2022-CTI-003/ 

[2] https://www.prodaft.com/resource/detail/fin7-unveiled-deep-dive-notorious-cybercrime-gang 

[3] https://www.onyphe.io/ 

[4] https://github.com/salesforce/hassh 

[5] https://suricata.io/ 

[6] https://pawpatrules.fr/ 

[7] https://youtu.be/Slil40j3TA0 

[8] https://www.stamus-networks.com/selks 

[9] https://www.stormshield.com/ 

L'auteur

Chef de projet sécurité numérique en santé - GCS e-santé Pays de la Loire Charles Blanc-Rolin est également vice-président de l’APSSIS(Association pour la promotion de la Sécurité des Systèmes d'Information de Santé)