Face à la multiplication des cyberattaques, le partage de renseignements sur les menaces sous forme d’informations à forte valeur, de tendances et d’échantillons est crucial pour lutter efficacement contre les nouvelles et les anciennes menaces. Des chercheurs en sécurité indépendants du monde entier contribuent aux efforts en matière de défense via différents référentiels, qui jouent un rôle clé en permettant à d’autres experts et analystes en sécurité de développer des règles de détection et des tactiques de réponse pour garder une longueur d’avance sur les menaces émergentes. L’une d’entre elles, le malware Loki, mérite d’être détaillée dans cet article.
Contexte
En parcourant les uploads récents sur MalwareBazaar, une base de données complète d’échantillons de malwares connus, nous avons découvert un échantillon du malware Loki appartenant à une famille de malwares jusqu’alors non analysée.
Loki est un type de malware voleur d'informations (information-stealing) connu pour exfiltrer des données sensibles, telles que des identifiants, des portefeuilles de crypto-monnaie et d'autres informations personnelles, ciblant souvent les systèmes Windows. Il utilise généralement diverses techniques de persistance, d’obfuscation et de communication avec ses serveurs command-and-control (C2), ce qui en fait une menace majeure dans le cyber-paysage.
Intrigués par son potentiel unique, nous l’avons sélectionné pour une analyse plus approfondie. Dans cet article de blog, nous nous concentrerons exclusivement sur les premières étapes de l’infection.
Analyse de l’échantillon
Lors de l'analyse dynamique, l'échantillon a présenté plusieurs comportements familiers souvent observés chez d'autres malwares que nous rencontrons régulièrement. Cependant, en approfondissant, nous avons remarqué une série de fonctions sous-jacentes qui le distinguaient. Il est intéressant de noter qu’au moment de cette analyse, les sites de diffusion initiaux de ce malware étaient toujours actifs.
Une fois l’échantillon téléchargé, passons à l’analyse. Le fichier HTA initial contient plusieurs couches de codage d'URL. Après le décodage, nous avons constaté que la charge virale était encore plus obfusquée à l'aide du codage Base64 et d'une technique de substitution de caractères.
Nous avons obtenu une commande PowerShell qui, une fois décodée, a révélé ce qui suit :
Voici le code déchiffré :
La charge virale utilise PowerShell pour exécuter des actions supplémentaires. Plus précisément, il charge urlmon.dll et exploite ses fonctions pour télécharger une charge virale à partir de l'URL : hxxp://104[.]168[.]7[.]52/35/picturewithattitudeeventforallthings.tif
. Une fois téléchargé, ce fichier est enregistré sous le nompicturewithattitudeeventforallthings.vbs
dans le répertoire %user%\AppData\Roaming\
.
Une fois le fichier VBS exécuté avec wscript.exe
, la commande suivante a été exécutée :
Une fois de plus, le codage Base64 et l'insertion de caractères inutiles ont été utilisés pour obfusquer la commande. Le but de cette commande est de télécharger une image depuis Google Drive à l'URL hxxps://drive[.]google[.]com/uc?export=download&id=1UyHqwrnXClKBJ3j63Ll1t2StVgGxbSt0.
La stéganographie a été appliquée à l'image pour masquer des instructions supplémentaires codées en Base64.
Le script récupère la charge virale Base64 obfusquée et inversée de l'image Google Drive, la décode, la charge en tant qu'assembly .NET, puis appelle une méthode au sein de cet assembly. Chaque étape comprend des couches d'obfuscation, telles que la concaténation de chaînes, l'insertion de fichiers inutiles, l'inversion Base64 et les remplacements dynamiques, pour gêner l'analyse et échapper à la détection. Cette technique, couramment utilisée dans les malwares, permet de charger dynamiquement du code malveillant sans être directement écrit sur le disque.
Voici la charge virale codée en Base64, qui a été intégrée dans un ordre inversé au sein de l'image.
En résumé, la charge virale VBS demande au système de visiter une image hébergée sur Google Drive, où il récupère une charge virale cachée, codée en Base64. Cette partie codée est ensuite inversée, décodée et le code est injecté dans le processus aspnet_regbrowsers.exe
comme indiqué dans l'arbre des processus ci-dessous.
Ensuite, le processus injecté commence à communiquer avec C2 et tente de diffuser d'autres charges virales dans le système qui, au moment des tests, était déjà à l’arrêt et n'a donc pas pu observer d'autres activités.
Détection du malware Loki avec Logpoint SIEM
Comme le démontre l’échantillon du malware Loki analysé ci-dessus, les techniques employées sont couramment utilisées par d’autres chargeurs/loaders et droppers initiaux pour échapper à la détection. La détection de ces techniques est essentielle, car elles reflètent une tendance croissante des malwares à contourner les défenses conventionnelles.
Pour détecter efficacement ces comportements, il est crucial de disposer de configurations d'audit appropriées pour garantir la génération de logs pertinents. Des sources de log spécifiques sont fondamentales pour une détection et une chasse efficaces aux menaces. Vous trouverez ci-dessous une liste des sources clés requises pour notre stratégie de détection avec Logpoint SIEM:
-
Windows
-
La création de processus avec audit en ligne de commande doit être activée.
-
-
Windows Sysmon
-
Pour commencer, vous pouvez utiliser notre configuration de base sysmon.
-
-
Logs réseau
-
Logs Firewall et IDS/IPS
-
Vous trouverez ci-dessous une liste d'alertes provenant d’éditeurs qui peuvent aider à détecter les techniques susmentionnées utilisées par les malwares.
-
Modèle de processus MSHTA suspect
L'exécution initiale de la charge virale de .vbs
a été effectuée avec mshta.exe
, un binaire interne de Windows. Cette alerte peut détecter un tel comportement car elle recherche l'exécution de mshta.exe
à partir d'emplacements suspects ou l'exécution d'un fichier à partir d'un chemin non standard.
2. Sous-chaîne de paramètre PowerShell suspecte détectée
Étant donné que de nombreuses étapes d'attaque utilisaient PowerShell et ses cmdlets, cette alerte détecte l'utilisation des commandlets PowerShell suspectes, généralement liées à des activités malveillantes, telles que l'exécution de charges virales codées en Base64 ou le téléchargement de fichiers distants via des cmdlets PowerShell.
3. Utilisation de la commande de requête Web
Plusieurs étapes de charges virales ont été téléchargées, cette alerte peut donc être utilisée pour détecter de tels événements dans lesquels des commandes binaires Windows et PowerShell ont été utilisées pour télécharger des fichiers.
4. Exécution de fichiers suspects à l'aide de Wscript ou Cscript
La charge virale VBS a été exécutée à l'aide de wscript.exe
, rendant ainsi cette alerte efficace pour détecter l'exécution de fichiers de script tels que les fichiers vbs
via wscript.exe ou cscript.exe.
Recommandations
-
Bloquer l'exécution des types de fichiers suspects et des binaires Windows :
Bloquez les types de fichiers potentiellement exploités tels que.vbs
,.hta
, et.msi
, qui sont couramment utilisés par les acteurs malveillants pour la distribution de charges virales. Autorisez les exceptions uniquement pour les processus système approuvés ou pour des utilisateurs spécifiques afin d'éviter de perturber les cas d'usage légitimes -
Restreindre les autorisations des utilisateurs et l'installation de logiciels :
Limitez la capacité des utilisateurs à installer et exécuter des logiciels non autorisés. -
Mises à jour régulières du logiciel :
Assurez-vous que les appareils, navigateurs et autres applications logicielles soient régulièrement mis à jour pour vous protéger contre les vulnérabilités connues et les cybermenaces. -
Mettre en œuvre des solutions EDR (Endpoint Detection and Response) :
Déployez des outils EDR avancés pour surveiller les activités suspectes, en particulier autour de l'exécution de scripts et des téléchargements de binaires. Cette stratégie permet de détecter rapidement les comportements des malwares, en particulier lorsque des techniques non conventionnelles, comme celles observées dans l'analyse des malwares de Loki, sont utilisées. -
Surveiller et restreindre la navigation Web :
Surveillez les habitudes de navigation des utilisateurs sur le Web et limitez l’accès aux sites Web ou aux contenus potentiellement dangereux pouvant conduire au téléchargement de malwares. -
Améliorer la surveillance et la journalisation (logging) du système :
Une journalisation (logging) appropriée, une visibilité des actifs et une surveillance du système sont essentielles à la cybersécurité. Mettez en œuvre des audits réguliers pour suivre l’activité des utilisateurs et identifier les anomalies. Une collecte complète des logs sur tous les systèmes est essentielle pour une détection et une analyse efficaces des menaces. -
Garantir une conservation et une visibilité adéquates des logs :
Établissez une politique de conservation des logs pour stocker les logs système et réseau pendant au moins six mois. Cette stratégie vous fournira suffisamment de données pour retracer l’origine et la chronologie de tout incident de sécurité, garantissant ainsi une réponse complète.