Ramsay : une boîte à outils pour le cyberespionnage adaptée aux réseaux air gapped

Les chercheurs d’ESET ont découvert un cadre de cyber-espionnage jusqu'alors non signalé que nous avons nommé Ramsay et qui est adapté à la collecte et à l'exfiltration de documents sensibles et est capable de fonctionner dans des réseaux de type « air-gapped ».

Nous avons d'abord trouvé un exemple de Ramsay dans VirusTotal. Cet échantillon a été téléchargé depuis le Japon et nous a permis de découvrir d'autres composants et versions du cadre, ainsi que des preuves substantielles permettant de conclure que ce cadre en est à un stade de développement, ses vecteurs de diffusion étant encore en cours d'affinement.

La visibilité actuelle des cibles est faible. D'après la télémétrie d'ESET, peu de victimes ont été découvertes à ce jour. Nous pensons que cette rareté des victimes renforce l'hypothèse selon laquelle ce cadre est en cours de développement, bien que la faible visibilité des victimes puisse également être due à la nature des systèmes ciblés qui se trouvent dans des réseaux à espace aérien.

Des artefacts partagés ont été trouvés à côté de la backdoor Retro. Ce logiciel malveillant est associé à Darkhotel, un groupe APT notoire connu pour avoir mené des opérations de cyberespionnage depuis au moins 2004, ayant ciblé des entités gouvernementales en Chine et au Japon dans le passé.

Vecteurs d'attaque

En même temps que la découverte des différents cas de Ramsay, nous avons constaté qu'ils étaient exploités à l'aide d'une série de vecteurs d'attaque. Il s'agit de :

Figure 1. Vue d'ensemble des versions de Ramsay découvertes

Les documents malveillants déposant la version 1 de Ramsay

Ce vecteur d'attaque est constitué de documents malveillants exploitant le CVE-2017-0199 destiné à déposer une ancienne version de Ramsay.

Ce document fournit un script Visual Basic initial, représenté dans la capture d'écran ci-dessous sous le nom de OfficeTemporary.sct, qui va extraire dans le corps du document Ramsay, en se faisant passer pour une image JPG en ayant un PE codé en base64 sous un en-tête JPG.

Tableau 1. Disposition des objets OLE contenus dans le fichier RTF de Ramsay version 1 vus par oletools

Nous avons remarqué que l'instance spécifique de Ramsay déposée par ces documents montrait une faible complexité dans sa mise en œuvre et manquait de nombreuses fonctionnalités plus avancées que les versions ultérieures de Ramsay ont permis d'exploiter.

Plusieurs exemples de ces mêmes documents malveillants ont été trouvés téléchargés vers des moteurs de bac à sable publics, étiquetés comme des artefacts de test tels que access_test.docx ou Test.docx, indiquant un effort continu pour tester ce vecteur d'attaque spécifique.

Compte tenu de la faible complexité de l'agent Ramsay fourni, les acteurs de la menace peuvent intégrer ce cas spécifique dans ces documents malveillants à des fins d'évaluation.

Le faux installateur déposant la version 2.a de Ramsay

Nous avons trouvé une instance téléchargée sur VirusTotal de Ramsay se faisant passer pour un installateur 7zip.

La raison pour laquelle nous avons nommé ce logiciel malveillant Ramsay est liée à certaines des chaînes de caractères contenues dans cle binaire, dont les suivantes :

Figure 2. Chaînes de caractères contenant « Ramsay »

Cette version de Ramsay montre un net raffinement de ses tactiques d'évasion et de persistance ainsi que l'introduction de nouvelles fonctionnalités telles qu'un composant Spreader et un rootkit. Le composant Spreader est documenté plus en détail dans cette partie de la section Capacités.

Documents malveillants déposant la version 2.b de Ramsay

Ce vecteur d'attaque consiste en la livraison d'un document malveillant différent abusant de la norme CVE-2017-11882. Ce document supprime l’installateur Ramsay lmsch.exe, comme indiqué dans le tableau 2.

Tableau 2. Disposition des objets OLE contenus dans le fichier RTF de Ramsay version 2.b vu par oletools

La version de Ramsay sur laquelle s'appuie ce document est une version légèrement modifiée de la version 2.a de Ramsay, avec la principale différence de ne pas utiliser la composante de l'épandeur. La fonctionnalité des autres composants est la même par rapport à la version 2.a de Ramsay.

Exécution par le client des fichiers infectés

Comme mentionné précédemment, la version 2.a de Ramsay fournit un composant Spreader qui se comportera comme un infecteur de fichiers, modifiant la structure des fichiers exécutables PE bénins contenus dans les disques amovibles et les disques partagés en réseau afin d'intégrer des artefacts Ramsay malveillants déclenchés lors de l'exécution du fichier hôte.

Le Spreader est très agressif dans son mécanisme de propagation et tout exécutable PE résidant dans les lecteurs ciblés serait candidat à l'infection.

Sur la base des horodatages de compilation parmi les composants des différentes versions de Ramsay trouvés, nous pouvons estimer le calendrier de développement suivant de ce cadre :

Figure 3. Estimation de la chronologie du développement de Ramsay

The analysis of the different compilation timestamps found across different components implies that this framework has been under development since late 2019, with the possibility of currently having two maintained versions tailored based on the configuration of different targets.

Mécanismes de persistence

Dépendamment de la version, Ramsay met en œuvre divers mécanismes de persistance de complexité différente. Certains de ces mécanismes de persistance sont les suivants :

• Clé de registre DLL AppInit

Le système d'exploitation Windows offre la possibilité de charger des DLL personnalisées dans l'espace d'adressage de presque tous les processus de demande via la clé de registre des DLL AppInit. Cette technique n'est pas particulièrement complexe; elle est mise en œuvre dans les premières versions de Ramsay et est courante dans d'autres familles de logiciels malveillants.

• Tâche planifiée via l'API COM

Les tâches planifiées permettent aux administrateurs d'exécuter des tâches ou des "jobs" à des moments précis plutôt qu'à chaque fois que le système est démarré ou que l'utilisateur se connecte. Cette fonctionnalité peut être mise en œuvre via l'API COM de Windows, que les premières versions de Ramsay ont adaptée. Compte tenu du taux élevé de similitude avec la mise en œuvre de Carberp, il est très probable que la mise en œuvre de Ramsay a été adaptée à partir du code source de Carberp, qui est accessible au public.

• Détournement du DLL fantôme

Des versions plus matures de Ramsay dénotent une augmentation de la complexité de ses techniques de persistance, qui comprennent une technique parfois appelée détournement du DLL fantôme (ou Phantom DLL Hijacking en version anglaise).

Le détournement du DLL fantôme abuse du fait que de nombreuses applications Windows utilisent des dépendances dépassées qui ne sont pas strictement nécessaires à la fonctionnalité de l'application elle-même, ce qui permet d'exploiter des versions malveillantes de ces dépendances.

Deux services seront ciblés afin de faire appliquer cette technique. Il s'agit des services suivants :

• WSearch (Windows Search) qui détourne msfte.dll :

Figure 4. Détournement du service de recherche Microsoft msfte.dll

• Le service MSDTC (Microsoft Distributed Transaction Coordinator) détourne une dépendance de l'oracle, présentée ci-dessous commes oci.dll :

Figure 5. Détournement d'une dépendance de service MSDTC oci.dll

Cette technique de persistance est très polyvalente, permettant aux agents Ramsay livrés sous forme de DLL de fragmenter leur logique en sections séparées, mettant en œuvre différentes fonctionnalités adaptées aux processus du sujet où l'agent sera chargé. En outre, l'utilisation de cette technique rend la détection plus difficile puisque le chargement de ces DLL dans leurs processus/services respectifs ne déclenchera pas nécessairement une alerte.

Capacités

L'architecture de Ramsay lui procure une série de capacités surveillées par un mécanisme d'enregistrement destiné à aider les opérateurs en fournissant un flux de renseignements exploitables pour mener des actions d'exfiltration, de contrôle et de mouvement latéral, ainsi qu'en fournissant des statistiques globales sur le comportement et le système de chaque système compromis. La réalisation de ces actions est possible grâce aux capacités suivantes :

• Collecte de fichiers et stockage secret

L'objectif premier de ce cadre est de rassembler tous les documents Microsoft Word existants dans le système de fichiers de la cible. Les étapes générales de la collecte sont illustrées à la figure 6 :

Figure 6. Mécanisme de collecte des documents

Les documents Word seront d'abord collectés et stockés dans un répertoire de collecte préliminaire. L'emplacement de ce répertoire peut varier en fonction de la version de Ramsay. Deux des répertoires que nous avons observés utilisés à cette fin étaient %APPDATA%\Microsoft\UserSetting et %APPDATA%\Microsoft\UserSetting\MediaCache.

Selon la version de Ramsay, la collecte de fichiers ne sera pas limitée au lecteur du système local, mais cherchera également sur des lecteurs supplémentaires tels que les lecteurs

Figure 7. Résultat Hex-Rays de la procédure d'analyse des lecteurs amovibles pour la collecte

Figure 8. Résultat Hex-Rays de la procédure de balayage des lecteurs réseau pour la collecte

Les documents collectés sont chiffrés à l'aide de l'algorithme de chiffrement de flux RC4.

La clé RC4 utilisée pour chiffrer chaque fichier sera un hachage MD5 calculé d'une séquence de 16 octets générée de manière aléatoire, salée avec 16 octets codés en dur dans l'échantillon de logiciels malveillants. Les 16 premiers octets de la mémoire tampon où le fichier chiffré sera conservé correspondront à la clé RC4 effectivement utilisée :

Figure 9. Résultat Hex-Rays de la génération et du stockage de la clé RC4

Les fichiers collectés dans le répertoire de collecte préliminaire seront compressés en utilisant une instance WinRAR que l'installateur Ramsay dépose. Cette archive compressée sera sauvegardée dans le répertoire de collecte préliminaire et générera ensuite un artefact de conteneur Ramsay :

Figure 10. Résultat Hex-Rays de la génération d'un conteneur Ramsay

Comme le montre la capture d'écran précédente, ces conteneurs Ramsay contiennent une valeur magique au début du fichier, ainsi qu'un GUID de profil matériel indiquant un identifiant de la machine de la victime; une couche de chiffrement supplémentaire basée sur XOR sera appliquée à l'archive compressée générée. Le schéma suivant montre la structure de ces artefacts :

Figure 11. Structure du conteneur <{i> de Ramsay

Ramsay met en œuvre une méthode décentralisée de stockage de ces artefacts dans le système de fichiers de la victime en utilisant des lignes de crochets appliquées sur deux fonctions de l'API Windows, WriteFile et CloseHandle.

Le but principal de la procédure WriteFilehookée (ou crochetée) est de sauvegarder le gestionnaire de fichier du fichier objet pour écrire et installer un autre crochet (hook) dans la fonction CloseHandlede l'API. La procédure CloseHandle crochetée vérifiera ensuite si le nom du fichier objet a une extension .doc; si c'est le cas, elle ajoutera à la fin du document objet l'artefact du conteneur Ramsay suivi d'un flux de 1024 octets indiquant un pied de page de document Microsoft Word.

Ceci est fait comme une mesure d'évasion afin de camoufler l'artefact incorporé dans le document objet :

Figure 12. Sortie en rayons hexadécimaux du code pour l'ajout d'un pied de page de document Word à la fin du document cible

Les conteneurs Ramsay annexés à des documents Word seront marqués afin d'éviter que des artefacts redondants ne soient annexés à des documents déjà affectés et le répertoire de stockage préliminaire sera nettoyé afin de générer un nouvel artefact Ramsay par intervalles.

Même si les documents concernés seront modifiés, cela n'affectera pas leur intégrité. Chaque document Word concerné reste pleinement opérationnel après l'ajout de l'artefact.

L'exfiltration de ces artefacts se fait via un composant externe que nous n'avons pas pu récupérer. Cependant, sur la base de la méthodologie décentralisée mise en œuvre par Ramsay pour le stockage des artefacts collectés, nous pensons que ce composant permettrait de scanner le système de fichiers de la victime à la recherche des valeurs magiques du conteneur Ramsay, afin d'identifier l'emplacement des artefacts à exfiltrer.

• Exécution de commandes

Contrairement à la plupart des logiciels malveillants classiques, Ramsay ne dispose pas d'un protocole de communication C&C basé sur le réseau et n'essaie pas de se connecter à un hôte distant à des fins de communication. Le protocole de contrôle de Ramsay suit la même philosophie décentralisée que celle mise en œuvre pour le stockage des artefacts collectés.

Ramsay analyse tous les partages réseau et les lecteurs amovibles (à l'exception des lecteurs A: and B:. Habituellement réservés aux disquettes) à la recherche d'éventuels fichiers de contrôle. En premier lieu, Ramsay recherche les documents Word et aussi, dans des versions plus récentes, les PDF et les archives ZIP :

Figure 13. Résultat Hex-Rays de la procédure de numérisation Ramsay pour la recherche de fichiers de contrôle

Ces fichiers sont analysés pour détecter la présence d'un marqueur magique spécifique au format du fichier de contrôle. Plus précisément, Ramsay recherche l'un des deux GUIDs de profil matériel encodés donnés. L'un de ces GUID est codé en dur comme le montre la figure 14, tandis que l'autre est généré dynamiquement en fonction de la machine de la victime compromise. Si l'un des identifiants du sujet est trouvé, l'analyse pour une signature de commande sera tentée.

Figure 14. Résultat Hex-Rays de l'analyse du fichier de contrôle Ramsay

La recherche de ces deux instances de GUID implique que les documents de contrôle de Ramsay peuvent être délibérément conçus pour être « agnostiques aux victimes », capables de déployer la même instance de document de contrôle sur un certain nombre de victimes en exploitant un GUID "global" au sein des documents de contrôle. D'autre part, les documents de contrôle peuvent être élaborés en intégrant un GUID spécifique destiné à être délivré exclusivement sur la machine d'une seule victime. Cet indicateur de la mise en œuvre du protocole de contrôle de Ramsay implique que son homologue dorsal peut être quelque peu automatisé.

Le protocole de contrôle Ramsay prend en charge trois commandes différentes :

Tableau 3. Commandes de contrôle de Ramsay

Après la récupération d'une signature de commande donnée, l'artefact contenu à exécuter sera extrait dans le corps du document de contrôle pour être ensuite restauré, en modifiant le document de contrôle en question pour lui redonner sa forme originale après l'exécution de la commande.

• Diffusion

Parmi les différents fichiers déposés par les dernières versions de Ramsay, on trouve un composant Spreader. Cet exécutable tentera d'analyser les partages réseau et les lecteurs amovibles, à l'exclusion des lecteurs A: and B: :

Figure 15. Résultat Hex-Rays des routines d'analyse du composant spreader

Il est important de noter qu'il y a une corrélation entre les lecteurs cibles des scanners Ramsay pour la propagation et la récupération des documents de contrôle. Cela permet d'évaluer la relation entre les capacités de propagation et de contrôle de Ramsay en montrant comment les opérateurs de Ramsay exploitent le cadre pour le mouvement latéral, ce qui indique la probabilité que ce cadre ait été conçu pour fonctionner au sein de réseaux aériens.

La technique de propagation consiste principalement en une infection de fichier, un peu comme un infecteur de fichier prepender, afin de générer des exécutables de structure similaire à celle des installateurs de leurres de Ramsay pour chaque fichier PE accessible dans les lecteurs ciblés mentionnés ci-dessus. Le schéma suivant illustre les changements appliqués aux exécutables ciblés après que l'infection a eu lieu et la manière dont ces composants interagissent lors de l'exécution :

Figure 16. Modifications de la structure des fichiers pendant une infection et une exécution

Tous les différents artefacts impliqués dans le stade de l'infection sont soit dans le contexte de l'épandeur, soit déposés précédemment par un autre élément Ramsay. Certains des artefacts sont analysés pour les jetons suivants :

Figure 17. Sortie des tokens par rayons hexadécimaux pour la recherche de différents artefacts liés au spreader

Après qu'un fichier donné a été infecté, il sera marqué par l'écriture d'un jeton spécifique à la fin de celui-ci afin de fournir au diffuseur un identifiant pour éviter une infection redondante.

En outre, certains composants de Ramsay ont mis en œuvre un scanner réseau destiné à la découverte des machines du sous-réseau de l'hôte compromis qui sont sensibles à la vulnérabilité EternalBlue SMBv1. Ces informations seront contenues dans toutes les informations enregistrées que Ramsay collecte et pourront être exploitées par les opérateurs afin d'effectuer d'autres mouvements latéraux sur le réseau à un stade ultérieur via un canal différent.

Remarques complémentaires

La version 2.a du composant Spreader de Ramsay s'est avérée avoir réutilisé une série de jetons vus auparavant dans le Backdoor Retro de Darkhotel. Ces tokens sont les suivants :

Figure 18. Résultats Hex-Rays de la réutilisation de tokens avec Retro

Figure 19. Réutilisation de tokens lors de la création rétroactive d'URL

Ramsay sérialise les victimes en utilisant l'API GetCurrentHwProfile pour ensuite récupérer un GUID pour la machine spécifique de la victime. Cette méthode est également mise en œuvre dans Retro. Ils utilisent tous deux le même GUID par défaut en cas d'échec de l'appel à l'API :

Figure 20. Génération de GUID par Ramsay et Retro

Ramsay et Retro partagent tous deux le même algorithme de codage pour coder le GUID récupéré.

Figure 21. Schéma d'encodage du GUID Ramsay et Retro

Le GUID récupéré par GetCurrentHwProfile est spécifique au matériel du système mais pas à l'utilisateur ou à l'instance du PC. Par conséquent, il est probable qu'en exploitant simplement ce GUID, les opérateurs puissent rencontrer des doublons destinés à sérialiser différentes victimes.

L'objectif de ce système est de générer un GUID moins susceptible d'être dupliqué en le « salant » avec l'adresse de l'adaptateur ethernet de la machine. Cela implique que Retro et Ramsay partagent le même schéma pour générer des identifiants uniques.

Nous avons également constaté des similitudes dans la manière dont Ramsay et Retro ont enregistré certains de leurs fichiers journaux, partageant une convention de nom de fichier similaire :

Figure 22. Quelques-unes des conventions de Ramsay et Retro pour les noms de fichiers

Il est important de souligner que parmi les techniques documentées de Retro, elle exploite des instances malveillantes de msfte.dll, oci.dll et lame_enc.dll, et via le détournement de DLL fantôme. Comme indiqué précédemment, Ramsay utilise également cette technique dans certaines de ses versions utilisant également msfte.dll et oci.dll.

En outre, nous avons également observé des similitudes entre Ramsay et Retro en ce qui concerne les outils open-source utilisés parmi leurs ensembles d'outils, tels que l'utilisation de l’UACMe pour l'escalade des privilèges et l’ImprovedReflectiveDLLInjection pour le déploiement de certains de leurs composants.

Enfin, nous avons remarqué des métadonnées en langue coréenne dans les documents malveillants exploités par Ramsay, indiquant l'utilisation de modèles basés sur le coréen.

Figure 23. Métadonnées des documents malveillants, indiquant le mot coréen signifiant « titre »

Conclusion

Sur la base des différents exemples de cadre trouvés, Ramsay est passé par diverses étapes de développement, ce qui dénote une progression croissante du nombre et de la complexité de ses capacités.

Les développeurs en charge des vecteurs d'attaque semblent essayer différentes approches telles que les anciens exploits pour les vulnérabilités de Word à partir de 2017 ainsi que le déploiement d'applications trojanisées.

Nous pensons que les développeurs ont une compréhension préalable de l'environnement des victimes et qu'ils adaptent des vecteurs d'attaque qui s'introduiraient avec succès dans les systèmes ciblés sans qu'il soit nécessaire de gaspiller des ressources inutiles.

Certaines étapes du cadre de Ramsay sont encore en cours d'évaluation, ce qui pourrait expliquer la faible visibilité actuelle des victimes. Puisque les cibles visées par Ramsay peuvent se trouver sous des réseaux de surveillance aérienne, ceci aurait également un impact sur la visibilité des victimes.

Nous continuerons à suivre les nouvelles activités de Ramsay et publierons les informations pertinentes sur notre blog. Pour toute question, contactez-nous à l'adresse suivante : threatintel@eset.com. Des indicateurs de compromis sont également disponibles dans notre dépôt GitHub.

Indicateurs de compromission (IoCs)

Techniques MITRE ATT&CK