Un plongeon dans l’univers de Turla PowerShell | WeLiveSecurity

Un plongeon dans l’univers de Turla PowerShell

Des chercheurs d'ESET analysent les nouvelles TTP attribuées au groupe Turla qui utilisent PowerShell pour exécuter uniquement des logiciels malveillants en mémoire.

Des chercheurs d’ESET analysent les nouvelles TTP attribuées au groupe Turla qui utilisent PowerShell pour exécuter uniquement des logiciels malveillants en mémoire.

Turla, aussi connu sous le nom de Snake, est un tristement célèbre groupe d’espionnage connu pour ses logiciels malveillants complexes. Pour confondre la détection, ses opérateurs ont récemment commencé à utiliser des scripts PowerShell qui permettent le chargement et l’exécution directs en mémoire des exécutables et des bibliothèques de logiciels malveillants. Cela leur permet de contourner la détection qui peut se déclencher lorsqu’un exécutable malveillant est déposé sur le disque.

On croit que Turla serait en activité depuis au moins 2008, date à laquelle elle a réussi à faire subir à l’armée américaine une brèche de données. Plus récemment, elle a été impliquée dans des attaques majeures contre le ministère allemand des Affaires étrangères et l’armée française.

Ce n’est pas la première fois que Turla utilise des chargeurs en mémoire PowerShell pour augmenter ses chances de contourner les produits de sécurité. En 2018, Kaspersky Labs publiait un rapport analysant un chargeur Turla PowerShell basé sur le projet open-source Posh-SecMod. Cependant, il comprenait plusieurs bogues et conduisait à des plantages.

Après quelques mois, Turla a amélioré ces scripts et les utilise maintenant pour charger un large éventail de logiciels malveillants personnalisés à partir de son arsenal traditionnel.

Les victimes sont habituelles pour Turla. Nous avons identifié plusieurs entités diplomatiques en Europe de l’Est qui ont été compromises en utilisant ces écritures. Cependant, il est probable que les mêmes scripts soient utilisés plus globalement contre de nombreuses cibles Turla traditionnelles en Europe occidentale et au Moyen-Orient. Ainsi, ce billet de blog a pour but d’aider les défenseurs à contrer ces scripts PowerShell. Nous présenterons également diverses charges utiles, y compris une porte dérobée basée sur RPC et une porte dérobée utilisant OneDrive comme serveur de commande et de contrôle (C&C).

Loadeur PowerShell

Le chargeur PowerShell comporte trois étapes principales : la persistance, le déchiffrage et le chargement en mémoire de l’exécutable ou de la bibliothèque intégrée.

Persistance

Les scripts PowerShell ne sont pas de simples droppers; ils amènent la persistance sur le système car ils ne chargent régulièrement en mémoire que les exécutables intégrés. Nous avons vu des opérateurs Turla utiliser deux méthodes de persistance :

  • Un abonnement à Windows Management Instrumentation (WMI)
  • Modification du profil PowerShell (fichier ps1).

Windows Management Instrumentation

Dans le premier cas, les attaquants créent deux filtres d’événements WMI et deux consommateurs d’événements WMI. Les consommateurs sont simplement des lignes de commande lançant des commandes PowerShell codées en base64 qui chargent un gros script PowerShell stocké dans le registre Windows. La figure 1 montre comment la persistance est établie.

Figure 1. Persistance utilisant WMI

Ces événements se dérouleront respectivement à 15:30:40 et lorsque le temps de fonctionnement du système est compris entre 300 et 400 secondes. La variable $HL39fjh comprend la commande PowerShell codée en base64 présentée à la Figure 2. Il lit la clé de registre Windows où la charge utile chiffrée est stockée et contient le mot de passe et le sel requis pour déchiffrer la charge utile.

Figure 2. Commande de PowerShell WMI consommateur

Enfin, le script stocke la charge utile chiffrée dans le registre Windows. Notez que les attaquants semblent utiliser un emplacement de registre différent pour chaque organisation. Il ne s’agit donc pas d’un indicateur utile pour détecter des intrusions similaires.

Profile.ps1

Dans ce dernier cas, les attaquants modifient le profil PowerShell. Selon la documentation de Microsoft :

Un profil PowerShell est un script qui s’exécute au démarrage de PowerShell. Vous pouvez utiliser le profil comme script de connexion pour personnaliser l’environnement. Vous pouvez ajouter des commandes, alias, fonctions, variables, snap-ins, modules et lecteurs PowerShell.

La figure 3 montre un profil PowerShell modifié par Turla.

Figure 3. Fichier profil.ps1 piraté

La commande PowerShell codée en base64 est très similaire à celle utilisée par les consommateurs WMI.

Déchiffrage

La charge utile stockée dans le registre Windows est un autre script PowerShell. Il est généré à l’aide du script open-source Out-EncryptedScript.ps1 du framework de test d’intrusion PowerSploit. De plus, les noms des variables sont randomisés pour obscurcir le script, comme le montre la figure 4.

Figure 4. Routine de déchiffrage

La charge utile est déchiffrée à l’aide de l’algorithme 3DES. Le vecteur d’initialisation, PINGQXOMQFTZGDZX dans cet exemple, est différent pour chaque échantillon. La clé et le sel sont également différents pour chaque script et ne sont pas stockés dans le script, mais seulement dans le filtre WMI ou dans le fichier profile.ps1.

Chargeur PE

La charge utile déchiffrée à l’étape précédente est un chargeur réfléchissant PowerShell. Il est basé sur le script Invoke-ReflectivePEInjection.ps1 du même framework PowerSploit. L’exécutable est codé en dur dans le script et est chargé directement dans la mémoire d’un processus choisi au hasard qui est déjà exécuté sur le système.

Dans certains échantillons, les attaquants spécifient une liste d’exécutables dans lesquels le binaire ne doit pas être injecté, comme le montre la figure 5.

Figure 5. Exemple d’une liste des procédés exclus

Notons que les noms avp.exe, avpsus.exe, klnagent.exe et vapm.exe font référence aux exécutables Kaspersky Labs. Il semble que les opérateurs Turla veulent vraiment éviter d’injecter leurs logiciels malveillants dans les logiciels Kaspersky.

Contournements de l’AMSI

Dans certains échantillons déployés depuis mars 2019, les développeurs de Turla ont modifié leurs scripts PowerShell afin de contourner l’Antimalware Scan Interface (AMSI). Il s’agit d’une interface permettant à toute application Windows de s’intégrer avec le produit anti logiciel malveillant installé. Celui-ci est particulièrement utile pour PowerShell et les macros.

Ils n’ont pas trouvé de nouveau pontage mais ont réutilisé une technique présentée à Black Hat Asia 2018 dans l’exposé The Rise and Fall of AMSI. Il s’agit du patch en mémoire du début de la fonction AmsiScanBuffer dans la bibliothèque msi.dll.

Le script PowerShell charge un exécutable.NET pour récupérer l’adresse d’AmsiScanBuffer. Ensuite, il appelle VirtualProtect, afin d’autoriser l’écriture à l’adresse récupérée.

Enfin, le patch se fait directement dans le script PowerShell comme le montre la Figure 6. Il modifie le début de AmsiScanBuffer pour toujours retourner 1 (AMSI_RESULT_NOT_DETECTED). Ainsi, le produit anti logiciel malveillant ne recevra pas le buffer, prévenant ainsi toute analyse.

Figure 6. Mise à jour de la fonction d’AmsiScanBuffer

Payloads

Les scripts PowerShell que nous avons présentés sont des composants génériques utilisés pour charger diverses charges utiles, tels qu’une backdoor (ou porte dérobée) RPC et une backdoor PowerShell.

Backdoor RPC

Turla a développé toute une série de portes dérobées en s’appuyant sur le protocole RPC. Ces portes dérobées sont utilisées pour effectuer des mouvements latéraux et prendre le contrôle d’autres machines du réseau local sans dépendre d’un serveur C&C externe.

Les fonctionnalités implémentées sont assez simples : téléchargement de fichiers, téléchargement de fichiers et exécution de commandes via cmd.exe ou PowerShell. Cependant, le logiciel malveillant prend également en charge l’ajout de plugins.

Cette porte dérobée RPC est divisée en deux composants : un serveur et un client. Un opérateur utilisera le composant client pour exécuter des commandes sur une autre machine où le composant serveur existe, comme le résume la Figure 7.

Figure 7. Utilisation de la porte dérobée RPC

Par exemple, l’échantillon identifié par le hachage SHA-1 suivant EC54EF8D79BF30B63C5249AF7A8A3C652595B923 est une version client. Ce composant ouvre le pipe nommé \\pipe\\atctl avec la séquence de protocole ncacn_np via la fonction RpcStringBindingComposeW. L’échantillon peut alors envoyer des commandes en appelant la fonction NdrClientCall2. La procédure exportée HandlerW, responsable de l’analyse des arguments, montre qu’il est également possible d’essayer de se faire passer pour un token anonyme ou de voler le token de processus d’un autre pour l’exécution d’une commande.

Son homologue serveur s’occupe du levage des charges lourdes et met en œuvre les différentes commandes. Il vérifie d’abord si la valeur de la clé du registre HKLM\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters\NullSessionPipes contient atctl. Si c’est le cas, le serveur définit le descripteur de sécurité sur l’objet pipe à « S:(ML;;NW;;;S-1-16-0)”  via la fonction SetSecurityInfo. Cela rendra l’objet pipe accessible à tous (niveau d’intégrité non fiable/anonyme).

L’image suivante montre le descripteur de stub MIDL correspondant ainsi que la syntaxe et l’ID d’interface similaires.

Figure 8. À gauche, le MIDL du client de la porte dérobée RPC backdoor. À droite, le, serveur .

Comme mentionné précédemment, cette porte dérobée supporte également les plugins de chargement. Le serveur crée un thread qui recherche les fichiers correspondant au modèle lPH*.dll suivant. Si un tel fichier existe, il est chargé et sa fonction d’exportation ModuleStart est appelée. Parmi les différents plugins que nous avons localisés jusqu’à présent, il est possible de voler des fichiers récents et des fichiers de clés USB.

De nombreuses variantes de cette porte dérobée RPC sont utilisées dans la nature. Parmi certains d’entre eux, nous avons vu des proxies locaux (utilisant upnprpc comme terminal et ncalrpc comme séquence de protocole) et des versions plus récentes intégrant PowerShellRunner pour exécuter des scripts directement sans utiliser powershell.exe.

Serveur Spoof RPC

Au cours de nos recherches, nous avons également découvert un exécutable portable avec le chemin pdb intégré C:\Users\Devel\source\repos\RPCSpoofer\x64\Release_Win2016_10\RPCSpoofServerInstall.pdb(SHA-1: 9D1C563E5228B2572F5CA14F0EC33CA0DEDA3D57).

Le but principal de cet utilitaire est de récupérer la configuration RPC d’un processus qui a enregistré une interface. Pour trouver ce type de processus, il itère à travers la table TCP (via la fonction GetTcpTable2) jusqu’à ce qu’il trouve le PID du processus qui a ouvert un port spécifique, ou récupère le PID du processus qui a ouvert un tube nommé spécifique. Une fois ce PID trouvé, cet utilitaire lit la mémoire du processus distant et tente de récupérer l’interface RPC enregistrée. Le code pour cela, vu dans la Figure 9, semble extrait de ce dépôt Github.

Figure 9. Bribes de code recherchant la section .data de rpcrt4.dll dans un processus à distance (capture d’écran Hex-Rays)

Au début, nous n’étions pas certains de la façon dont l’information récupérée était utilisée, mais un autre échantillon (SHA-1: B948E25D061039D64115CFDE74D2FF4372E83765) nous a aidé à comprendre. Comme le montre la Figure 10, cet exemple récupère l’interface RPC, désactive l’indicateur RPC_IF_ALLOW_SECURE_ONLY, et patche la « table de répartition » en mémoire en utilisant la fonction WriteProcessMemory. Ces opérations permettraient à l’échantillon d’ajouter ses fonctions RPC à une interface RPC déjà existante. Nous croyons qu’il est plus discret de réutiliser une interface RPC existante que d’en créer une personnalisée.

Figure 10. Extrait de code récupérant la table d’envoi RPC du processus en cours (capture d’écran Hex-Rays)

PowerStallion

PowerStallion est une porte dérobée PowerShell légère utilisant Microsoft OneDrive, un service de stockage dans le cloud, comme serveur C&C. Les informations d’accès sont codées en dur au début du script, comme l’indique la figure 11.

Figure 11. Informations d’identification OneDrive dans le script PowerStallion

Il est intéressant de noter que les opérateurs Turla ont utilisé à nouveau le fournisseur d’email gratuit GMX, comme c’était le cas avec la backdoor Outlook Backdoor et dans LightNeuron. Ils ont également utilisé le nom d’un employé réel de l’organisation ciblée dans l’adresse électronique.

Ensuite, il utilise lacommande net use pour se connecter au lecteur réseau. Il vérifie ensuite, en boucle, comme le montre la figure 12, si une commande est disponible. Cette porte dérobée ne peut exécuter que des scripts PowerShell supplémentaires. Il écrit les résultats de la commande dans un autre sous-dossier OneDrive et les crypte avec la touche XOR 0xAA.

Figure 12. Boucle principale de la porte dérobée PowerStallion

Un autre artefact intéressant est que le script modifie dans cet exemple les temps de modification, d’accès et de création (MAC) du fichier journal local pour correspondre aux temps du fichier légitime desktop.ini, comme le montre la Figure 13.

Figure 13. Modification des temps MAC du fichier log local

Nous pensons que cette porte dérobée est un outil d’accès de récupération dans le cas où les portes dérobées principales de Turla, telles que Carbon ou Gazer, sont nettoyées et que les opérateurs ne peuvent plus accéder aux ordinateurs compromis. Nous avons vu des opérateurs utiliser cette backdoor aux fins suivantes :

  • Surveillance des logs anti logiciels malveillants.
  • Surveillance de la liste des processus Windows.
  • Installation de ComRAT version 4, l’une des portes dérobées du deuxième étage Turla.

Conclusion

Dans un billet publié en 2018, nous avions prédit que Turla utiliserait de plus en plus d’outils génériques. Cette nouvelle étude confirme nos prévisions et montre que le groupe Turla n’hésite pas à utiliser des cadres de tests d’intrusion open-source.

Toutefois, cela n’empêche pas d’attribuer de telles attaques à Turla. Les attaquants ont tendance à configurer ou modifier ces outils open-source pour mieux répondre à leurs besoins. Il est donc encore possible de séparer différents groupes d’activités.

Enfin, l’utilisation d’outils open-source ne signifie pas que Turla a cessé d’utiliser ses outils personnalisés. Les charges utiles fournies par les scripts PowerShell, la porte dérobée RPC et PowerStallion, sont en fait très personnalisées. Notre récente analyse de Turla LightNeuron est une preuve supplémentaire que ce groupe développe encore des logiciels malveillants complexes et personnalisés.

Nous continuerons à suivre les nouvelles activités de Turla et publierons des informations pertinentes sur notre blog. Pour toute demande de renseignements, contactez-nous à l’adresse threatintel@eset.com. Des indicateurs de compromission peuvent également être trouvés sur notre GitHub.

Indicateurs de compromission (IoCs)

Hashes

SHA-1 hashDescriptionESET detection name
50C0BF9479EFC93FA9CF1AA99BDCA923273B71A1PowerShell loader with encrypted payloadPowerShell/Turla.T
EC54EF8D79BF30B63C5249AF7A8A3C652595B923RPC backdoor (client)Win64/Turla.BQ
9CDF6D5878FC3AECF10761FD72371A2877F270D0RPC backdoor (server)Win64/Turla.BQ
D3DF3F32716042404798E3E9D691ACED2F78BDD5File exfiltration RPC pluginWin32/Turla.BZ
9D1C563E5228B2572F5CA14F0EC33CA0DEDA3D57RPCSpoofServerInstallerWin64/Turla.BS
B948E25D061039D64115CFDE74D2FF4372E83765RPC interface patcherWin64/Turla.BR

Noms de fichier

  • Composants RPC
    • %PUBLIC%\iCore.dat (fichiers log, XOR 0x55 1 bit)
    • \\pipe\\atctl (nom de pipe)
  • PowerStallion
    • msctx.ps1
    • C:\Users\Public\Documents\desktop.db

Clés de registre

  • • Composants RPC
    • HKLM\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters\NullSessionPipes contains atctl

MITRE ATT&CK

TacticIDNameDescription
ExecutionT1086PowerShellThe loaders are written in PowerShell.
Some RPC components can execute PowerShell commands.
PersistenceT1084Windows Management Instrumentation Event SubscriptionThe PowerShell loaders use WMI for persistence.
Defense EvasionT1027Obfuscated Files or InformationThe RPC backdoor and PowerStallion encrypt the log file.
T1140Deobfuscate/Decode Files or InformationThe PowerShell loaders decrypt the embedded payload.
T1055Process InjectionThe PowerShell loaders inject the payload into a remote process.
T1099TimestompPowerStallion modifies the timestamps of its log file.
DiscoveryT1083File and Directory DiscoveryThe RPC plugin gathers file and directory information.
T1120Peripheral Device DiscoveryThe RPC plugin monitors USB drives.
T1012Query RegistryThe server component of the RPC backdoor queries the registry for NullSessionPipes.
T1057Process DiscoveryPowerStallion sent the list of running processes.
CollectionT1005Data from Local SystemThe RPC plugin collects recent files from the local file system.
T1025Data from Removable MediaThe RPC plugin collects files from USB drives.
Command and ControlT1071Standard Application Layer ProtocolThe RPC backdoor uses RPC and PowerStallion uses OneDrive via SMB.
ExfiltrationT1041Exfiltration Over Command and Control ChannelPowerStallion exfiltrates information through the C&C channel.
et

Discussion