L’attaque SolarWinds, qui a réussi en utilisant le malware sunburst, a choqué l’industrie de la cybersécurité. Cette attaque a atteint la persistance et a pu échapper aux systèmes internes assez longtemps pour accéder au code source de la victime.

En raison des déploiements de grande envergure de SolarWinds, les auteurs ont également pu s’infiltrer dans de nombreuses autres organisations, à la recherche de propriété intellectuelle et d’autres actifs.

Parmi les co-victimes: le gouvernement américain, les entrepreneurs du gouvernement, les entreprises de technologie de l’information et les ONG. Une quantité incroyable de données sensibles a été volée à plusieurs clients après l’installation d’une version cheval de Troie de l’application SolarWinds sur leurs structures internes.

En regardant les capacités techniques du malware, comme vous le verrez, cette attaque particulière était assez impressionnante. Un fichier particulier, nommé SolarWinds.Orion.Core.BusinessLayer.dll est un composant signé numériquement SolarWinds du framework logiciel Orion.

Les acteurs de la menace ont installé une porte dérobée qui communique via HTTP avec des serveurs tiers. Après une période d’inactivité initiale pouvant aller jusqu’à deux semaines, il récupère et exécute des commandes, appelées «Jobs», qui incluent la possibilité de transférer des fichiers, d’exécuter des fichiers, de profiler le système, de redémarrer la machine et de désactiver les services système.

Alors, comment pourrait-on protéger l’organisation contre Sunburst ou une attaque similaire? Les attaques de la chaîne d’approvisionnement ont l’avantage d’établir une première implantation sous le couvert d’un tiers de confiance. Mais c’est là que s’arrête la distinction; à partir de là, ils progressent comme n’importe quelle autre attaque, et ils peuvent être détectés si on sait où chercher.

Développement de règles SIEM, en utilisant l’attaque SolarWinds comme exemple

Commençons par les règles Sigma; ceux-ci créent une sorte de langage commun pour créer et partager des requêtes de qualité quel que soit le SIEM utilisé par votre organisation. le Cymuler La plate-forme produira des règles Sigma pour que vous puissiez télécharger ces requêtes sur votre SIEM. Cela permettra aux équipes des opérations de sécurité de créer les éléments nécessaires pour détecter les futures attaques. Comme vous pouvez le voir ci-dessous dans les 3 exemples, la règle Sigma est la même, mais la requête personnalisée est spécifiquement pour la langue de ce SIEM. En cliquant sur un bouton, vous pouvez basculer vers votre SIEM préféré.

Exemple 1: Splunk:

Exemple 2: Qradar:

Exemple 3: Azure Sentinel:

Bien que les règles Sigma soient principalement conçues pour les requêtes, on peut les utiliser pour créer une règle SIEM ou EDR anti-chaîne d’attaque complète. Dans le cas de l’attaque SolarWinds Sunburst et de nombreuses autres attaques, les règles Cymulate Sigma sont des requêtes qui recherchent les IOB de l’attaque. Chaque règle sigma interrogera le SIEM pour un IOB d’une étape de l’attaque.

Lorsque les IOB des règles sigma sont combinés, ils peuvent aboutir à une règle spécifique pour le système cible – quelque chose qui peut, avec un degré élevé de confiance, signaler l’attaque sans «inventer la roue» une fois de plus. Tous les IOB requis sont en place – dans les règles Sigma – il vous suffit de tendre la main et de les prendre.

Examinons le cas spécifique d’une attaque SolarWinds recréée sur la plate-forme Windows et traquons-la ensemble.

Chasse à SolarWinds sur Microsoft Windows

La plate-forme Cymulate nous offre la possibilité de répliquer l’attaque de la chaîne d’approvisionnement, qui commence par une exportation de la boîte aux lettres du serveur Exchange. Les étapes suivantes de l’attaque, disponibles sur la plateforme Cymulate pour simuler l’attaque, sont visibles sur la capture d’écran.

Le premier événement ne sera pas déclenché par Windows, mais il sera écrit dans divers journaux réseau. Puisque l’événement lui-même ne peut pas être très spécifique, nous le laisserons comme facultatif pour le placement dans une règle générale. Nous allons continuer.

Le prochain événement de l’attaque est le téléchargement de contenu avec PowerShell. Un tel événement peut être surveillé avec les ID d’événement Windows 4103 et 4104, qui peuvent également afficher le code réel en cours d’exécution, mais nous ne voulons pas nous limiter à une méthode spécifique car, avouons-le: PowerShell n’est pas le seul outil l’attaquant peut utiliser.

Ce qui est commun à tous les outils, c’est que lors du téléchargement du contenu, un objet est créé dans le système, et pour cela, il existe un ID d’événement Windows 4663 avec un indicateur de masque d’accès 0x1 ou, si vous utilisez Sysmon, l’ID d’événement 11.

Vous trouverez ci-dessous une capture d’écran générale d’un ID d’événement 4663 avec les champs appropriés en surbrillance. C’est l’événement que la règle Cymulate Sigma détecte, et c’est également le premier IOB de la règle que nous allons créer. Vous pouvez en savoir plus sur cet ID d’événement ici.

La prochaine étape de l’attaque est la suivante: Planificateur de tâches: Masquer les tâches déclenchées sur l’écran de verrouillage de Windows pour un mouvement latéral. Une fois de plus, il est indifférent de savoir exactement quelles tâches sont masquées; ce qui est important, c’est qu’il existe des ID d’événement Windows qui peuvent nous aider à identifier cette chaîne d’événements.

Les ID d’événement sont:

4698 – tâche créée

4700 – Tâche planifiée activée.

4702 – Tâche planifiée mise à jour.

4699 – Tâche planifiée supprimée.

Ce qui est pertinent pour nous est, bien sûr, le 4698 car cela apparaîtra lorsqu’une nouvelle tâche est créée. Les événements de mise à jour, d’activation et / ou de suppression d’une tâche sont une bonne amélioration mais facultative. Personnellement, je recommanderais d’ajouter une option de 4699, car il y a toujours une possibilité que l’attaquant souhaite supprimer la tâche après l’achèvement pour couvrir ses traces.

Donc, ce que nous voudrons pour les exigences minimales est 4698 avec un ensemble d’expressions régulières spécifiques dans le champ « Commande » de l’événement, qui correspondent aux types d’exécutables connus, par exemple:

– ‘.exe’ – ‘.py -‘ .ps1 ‘-‘ .msi – ‘.msp’ – ‘.mst’ – ‘.ws’ – ‘.wsf’ – ‘.vb’ – ‘.vbs’ – ‘ .jst ‘-‘ .cmd ‘-‘ .cpl ‘

Pour les cas complexes, des expressions régulières, telles que celles ci-dessous, peuvent être utilisées:

1. – ‘^ ([A-Za-z0-9+/]{4}) * ([A-Za-z0-9+/]{3} = |[A-Za-z0-9+/]{2} ==)? $ ‘
2. – ‘^ ([A-Za-z0-9 /]{4}) * ([A-Za-z0-9 /]{3} = |[A-Za-z0-9 /]{2} ==)? $ ‘

Faites particulièrement attention aux deux derniers IOB (regex): ceux-ci correspondent à un modèle base64. Bien que « Scheduled Task » reçoive une chaîne comme entrée, il est possible d’y écrire une forme obscurcie / chiffrée d’une commande. Par exemple, « python » comme commande et « base64.b64decode (une charge utile en base64) « comme argument, faisant ainsi efficacement de votre tâche un outil de » décodage de la charge utile base64 « .

Encore une fois, tous les indicateurs se trouvent dans les règles Sigma fournies par Cymulate. Nous appellerons cette liste et d’autres listes à venir de la «liste IOB pertinente» de l’IOB pour des raisons de commodité. Vous trouverez ci-dessous la vue générale de l’ID d’événement 4698 de création d’une nouvelle tâche.

Donc, à présent, nous avons couvert deux événements de la chaîne. Celles-ci devraient se produire sur la même machine et avec le même nom d’utilisateur. Après cela, le processus de votre tâche sera exécuté, ce qui entraînera 4688 ID d’événement avec le nom du processus de créateur: TaskScheduler ou TaskScheduler.dll ou taskeng.exe (selon la version de build que vous utilisez), et Nouveau nom de processus aura un de ces IOB dans la liste des exécutables. Donc, à ce stade, notre règle ressemble à ceci:

(4663 + masque d’accès 0x1) 🡪 (4698 et liste IOB correspondante) 🡪 (4688 + liste du nom du processus créateur pertinent + liste des IOB pertinents dans le cadre du nouveau nom du processus)

OU ALORS

4663 + Masque d’accès 0x1 ou Sysmon 11) 🡪 [(4698 + relevant IOB list) 🡪(4688+(TaskScheduler.dll or taskeng.exe))]

Le signe 🡪 représente l’opération « suivi de »

La prochaine étape de l’attaque consiste à exécuter un fichier DLL avec rundll32. Il s’agit d’un IOB simple qui, d’ailleurs, peut également être exécuté lors d’une étape précédente. Dans ce cas précis, il s’agit de 4688 + rundll.32

Vient ensuite ADFind: énumération d’un groupe AD à l’aide d’ADFind masqué comme csrss.exe. Cette étape est un peu délicate. Au cours de cette étape, un attaquant se fait passer pour son outil d’énumération comme un fichier légitime. Cependant, avant que cela ne puisse se produire, le fichier illégitime doit être écrit quelque part sur l’un de vos lecteurs (de préférence dans le dossier système) avec le nom légitime.

Dans ce cas précis, il s’agit de csrss.exe, mais il existe un assez grand nombre de noms de fichiers qui pourraient être utilisés dans le même but, par exemple:

– «svchost.exe». – rundll32.exe. – services.exe. – powershell.exe. – regsvr32.exe. – spoolsv.exe

– lsass.exe. – smss.exe. – csrss.exe. – conhost.exe. – wininit.exe. – winlogon.exe. – explorer.exe

– taskhost.exe. – Taskmgr.exe. – sihost.exe – RuntimeBroker.exe – smartscreen.exe.

Encore une fois, pas besoin de les rechercher tous, ils sont déjà fournis dans la règle Sigma correspondante.

Vous trouverez ci-dessous un exemple d’une règle Sigma possible pour cette étape spécifique, qui détecte la création d’un fichier avec l’un des noms spécifiés ci-dessus. Mais avec un hachage différent de l’original. Qu’il s’agisse de remplacer un fichier système ou de créer un nouveau chemin, il en résultera toujours un ID d’événement 4663 (ou un ID d’événement Sysmon 11), et l’un des noms ci-dessous sera trouvé dans la charge utile.

Travailler avec les fichiers système nécessite également un accès privilégié, il y aura donc inévitablement une élévation de privilèges, qui est également documentée comme ID d’événement 4688 (accès aux fichiers) et type d’élévation de jeton de %% 1936 ou %% 1937, qui sont des types d’accès système et administrateur. respectivement.

Vous trouverez ci-dessous une capture d’écran de l’ID d’événement 4688 avec les champs pertinents en surbrillance.

Vous pouvez éventuellement rechercher l’ID d’événement 4672 avec l’une des chaînes d’escalade de privilèges, mais l’événement d’escalade de privilège peut se produire à n’importe quelle étape de l’attaque. Nous recommandons une règle distincte pour cela, qui devrait être corrélée à la règle que nous construisons.

Jetons un coup d’œil à notre règle à ce stade:

(4663 + masque d’accès 0x1 ou Sysmon 11) 🡪 [(4698 + relevant IOB list) 🡪(4688+(TaskScheduler.dll or taskeng.exe)) 🡪 (4688 and rundll32) 🡪 (4663 or Sysmon 11 + generic list of system files) 🡪 (4688 and 1 of files in list and Token Elevation Type (%%1936 OR %%1937))]

La prochaine étape est « Exécuter PowerShell encodé en base64 à partir du registre Windows« . Ce qui se passe ici, c’est qu’un attaquant exécute un code obscurci précédemment écrit dans une valeur de registre. Comme vous pouvez le comprendre, avant de pouvoir le faire, il doit créer une nouvelle valeur de registre ou modifier une valeur existante.

Un ID d’événement Windows 4657 et un modèle de base64 correspondant à une valeur (qui peut être identifié avec des expressions régulières que nous avons déjà vues à une étape précédente) peuvent aider à identifier cette étape. L’événement peut inclure «Valeur de registre existante modifiée» ou «Création d’une nouvelle valeur de registre» comme Type d’opération. Tous les IOB, comme mentionné précédemment, peuvent être obtenus à partir des règles Sigma fournies.

Cet événement peut vous montrer d’autres informations précieuses, telles que:

1) Quelle clé était impliquée.

Le format est: REGISTRY HIVE PATH où:

RUCHE:

• HKEY_LOCAL_MACHINE = REGISTRY MACHINE
• HKEY_CURRENT_USER = REGISTRY USER [USER_SID], où [USER_SID] est le SID de l’utilisateur actuel.
• HKEY_CLASSES_ROOT = REGISTRY MACHINE SOFTWARE Classes
• HKEY_USERS = REGISTRY USER
• HKEY_CURRENT_CONFIG = REGISTRY MACHINE SYSTEM ControlSet001 Hardware Profiles Current

2) Quel est le processus d’origine.
3) Quelle est l’ancienne valeur et la nouvelle valeur.

Ci-dessous, vous pouvez voir une représentation générale de l’ID d’événement 4657.

En tenant compte des délais possibles, puisque toute l’opération sera probablement scriptée, nous pouvons affirmer en toute sécurité qu’en cas de succès, les étapes 2 à 6 ne prendront pas plus de 5 secondes. La chaîne entière jusqu’à l’exécution du code stocké dans le registre ne peut durer plus de 10 minutes.

Après avoir ajouté ces variables, nous avons une chaîne d’événements qui peuvent être corrélés:

1. Tout proviendra d’une seule machine.
2. Il sera démarré avec le même utilisateur.
3. La règle opérationnelle ressemblera à celle ci-dessous:

{

(4663 + masque d’accès 0x1 ou Sysmon 11) 🡪

[ (4698 + relevant IOB list) 🡪

(4688+(TaskScheduler.dll or taskeng.exe)) 🡪

(4688 and rundll32) 🡪

(4663 or Sysmon 11 + generic list of system files) 🡪

(4688 and 1 of files in list and Token Elevation Type(%%1936 OR %%1937))🡪 (4657 +New value created OR existing value modified+ base64 matching pattern in value in time frame up to 5s)]

dans un laps de temps de 10 minutes

}

Alors maintenant, si vous avez construit cette règle SIEM ou EDR, en utilisant les règles Sigma fournies par Cymulate, et que vous voyez une alerte de celle-ci – il y a de fortes chances que vous subissiez l’attaque SolarWinds en ce moment.

Si vous avez encore des doutes, vous pouvez toujours ajouter des étapes facultatives et les améliorer encore plus en ajoutant deux étapes suivantes à la règle. Ceux-ci sont Nettoyage de l’exportation de la boîte aux lettres Exchange Server et Exfiltration Exchange à l’aide de la requête HTTP de base, respectivement.

Même si Windows n’a pas d’ID d’événement intégré pour les requêtes HTTP / S, il y aura toujours {4660 sur la boîte aux lettres🡪 (requête HTTP + 4663 de filename.zip/rar/tar/other)}. Afin d’obtenir un événement de requêtes HTTP / S, des systèmes supplémentaires, par exemple un système d’analyse du trafic réseau, peuvent vous aider ici.

Optimisez vos opérations de sécurité avec les règles Cymulate et Sigma

Comme vous l’avez vu dans la répartition de cette attaque particulière, vous pouvez utiliser les IOB dans les règles Sigma. Cela aidera vos opérations de sécurité à contester, évaluer, mesurer et optimiser. Cela peut facilement être accompli par la plate-forme Cymulate dans tous les domaines. Les étapes décrites dans cet article sont destinées à aider à l’optimisation et à vous expliquer comment empêcher une attaque de type SolarWinds. Comme vous l’avez vu sur la plateforme Cymulate, un scénario, qu’il soit simple ou complexe, peut vous aider à optimiser vos règles SIEM ou EDR. Cela améliorera la sécurité de votre organisation contre les menaces les plus sophistiquées avec peu d’efforts.

Bonne chasse à vous!

Et comme on dit aux Hunger Games, «que les chances soient toujours en votre faveur».

Cet article a été rédigé par Michael Ioffe, chercheur principal en sécurité à Cymuler.