7.5.8. Analyse des alertes Retrohunt

7.5.8.1. Introduction

Pour plus d'informations, voir les paragraphes suivants :

7.5.8.1.1. Gestion du moteur Retrohunt

Pour les informations sur le moteur, voir le paragraphe Visualisation de l'état du moteur.
Pour les informations sur la mise à jour du moteur, voir le paragraphe Mise à jour CTI.
Pour les informations sur la configuration du moteur, voir le paragraphe de Configuration du moteur.

7.5.8.1.2. Événements générés par le moteur

Les événements générés par le moteur Retrohunt sont des alertes.
Celles-ci sont affichées :
  • dans l'interface principale nommée Web UI du GCenter dans l'écran `Alerts`
    L'interface principale nommée Web UI est décrite dans la Présentation de la WebUI.
  • Pour ne visualiser que ces alertes, sélectionner le filtre moteur `Retro hunt`.
    Voir la présentation de l'Ecran `Alerts` de la WebUI.
    ../../_images/GCE103_RETRO_ALERT_4.png

  • Dans l'interface nommée Kibana UI :

    • Cliquer sur l'icône `Hunting` dans la barre de menu gauche de la WebUI.
      L'interface affichée est l'interface nommée Kibana UI (décrite dans l'Interface graphique Kibana).

    • Sélectionner la catégorie `Retro hunt` de la section `Alerts` dans Kibana puis l'onglet `Overview` ou `Messages`.

    • Cliquer sur l'onglet `Messages`.

  • Pour consulter des informations sur une alerte spécifique :

7.5.8.1.3. Informations essentielles pour comprendre le contexte de l'alerte

7.5.8.1.3.1. Quels sont les champs clés d'une alerte et leur signification ?

  • Afin d'entreprendre l'investigation ou la qualification de l'alerte, il convient de rechercher l'IoC sur la plateforme OpenCTI de Gatewatcher CTI obtenir plus d'informations concernant la menace et comprendre le contexte.
    Pour ce faire, il faut d'abord déterminer quel est l'IoC :

  • si l'alerte est levée sur un paquet DNS, la valeur de l'IoC se trouve dans le champ ``dns.query.rrname`` de l'alerte

  • si l'alerte est levée sur un paquet HTTP, la valeur de l'IoC se trouve dans le champ ``http.hostname`` de l'alerte

Note

Ces éléments sont visibles dans la fenêtre `Alert details`.

Il est également possible de rechercher l'IoC sur la plateforme OpenCTI.
Pour ce faire :

  • rechercher la valeur de l'IoC dans la barre de recherche générale située en haut à droite de la page d'accueil.

  • puis sélectionner l'IoC parmi les IoC présents après la recherche

Sur la page de l'IoC, se trouve :
  • sa description
    La description de l'IoC est composée de :

    • sa valeur

    • le type d'IoC
      Dans le cas d'une alerte ActiveCTI, les alertes sont associées à des domaines ou des URL, mais de manière générale la plateforme comporte des hash de fichiers, des noms de fichiers et des IP.

  • s'il est en Detection ou non, voir la Procédure de traitement d'une alerte

  • ses labels, qui peuvent correspondre :

    • Au type de menace associé
      Ce champ peut prendre différentes valeurs dont phishing, trojan, hacktool suivant comment la menace a été catégorisée par Gatewatcher CTI.
    • Au nom du malware associé
      Dans le cas d'un hash de fichier ou d'une URL ou domaine à l'origine du téléchargement d'un fichier, si ce fichier est catégorisé comme appartenant à une famille de malware, alors le nom apparaîtra dans les labels.
      Par exemple : mirai, qbot, redline stealer.
    • Au nom du threat actor associé
      De la même manière que pour les malwares, si la menace est associée à un acteur de la menace, son nom apparaîtra dans les labels.
      Par exemple : ta505, lockbit, lazarus group.
  • ses références externes
    Il s'agit d'articles ou analyses externes dans lesquels l'IoC est présent et qui apportent un contexte supplémentaire.

Dans les informations affichées dans les alertes Kibana, les éléments clés sont les suivants :

  • `type`
    Il s'agit du type d'IoC remonté.
    Ce champ peut prendre comme valeur SHA256, SHA1, MD5, Filename, URL, Host.
  • `value`
    Correspond à la valeur de l'IoC, c'est-à-dire l'IoC lui-même.
  • `signature`
    Lorsque disponible, la signature se compose des champs :
    • `type` : s'il s'agit d'un hash, d'une IP, d'un domaine.
    • `categories` : catégorie de menace correspondante à l'IoC. Par exemple : phishing, trojan, ransom, backdoor.
    • `families` : famille de malware correspondante à l'IoC. Par exemple : Cobalt Strike, Mirai, gh0st RAT.
    • `threat_actor` : threat actor associé à l'IoC. Par exemple : TA505, Medusa, SilverTerrier.
    • `relations` : correspond à d'autres IoCs présents dans la plateforme associés à l'IoC.

7.5.8.2. Procédure de traitement d'une alerte

7.5.8.2.1. Comment vérifier l'exactitude d'une alerte et déterminer si elle représente une menace réelle ?

Pour évaluer l'exactitude d'une alerte et déterminer si elle représente une menace réelle, plusieurs étapes peuvent être suivies.
Voici un aperçu des actions fréquemment entreprises lors de l'analyse d'une alerte générée.
Le premier élément à vérifier est le champ usage_mode de l'alerte dans Kibana.
Il peut prendre deux valeurs : `detection` ou `hunting`.
  • Si l'usage_mode de l'IoC a pour valeur `hunting`, ce qui peut être le cas pour un domaine ou une adresse IP, cela signifie que la ressource n'a pas plus être contactée.
    Sur un réseau, cela peut par exemple arriver quand un ressource malveillante tente de contacter un domaine qui n'est plus actif.
  • En revanche, si l'usage_mode a pour valeur `detection`, l'IoC est toujours actif et représente dans ce cas une menace actuelle.

7.5.8.2.2. Comment catégoriser la menace en fonction des informations recueillies ?

Pour catégoriser la menace, explorer plusieurs pistes :

  • Vérifier le type de la menace :

    • Dans le cas d'une URL ou d'un domaine, les menaces associées sont le plus souvent du phishing ou le téléchargement d'un fichier malveillant.
      Ces informations sont présentent dans les labels de l'IoC.
      Si les labels ne permettent pas de déterminer le type de menace, la valeur de l'IoC peut donner l'information.
      Les URL de phishing contiennent généralement des mots-clés qui trahissent une tentative d'usurpation d'un service ou d'une entreprise, là ou le téléchargement d'un fichier malveillant se fait souvent à partir d'une IP et dont le nom du fichier peut être indiqué dans le chemin.
      Dans d'autres cas, l'IoC peut se rapporter à une domaine de Command and Control, caractérisé par un nom de malware spécifique.

  • Rechercher des menaces sur des plateformes CTI externes :

    • Pour plus d'informations sur le niveau d'activité malveillante ou pour télécharger la menace sous la forme d'un fichier, il convient de se tourner vers des plateformes externes de renseignement sur les menaces, telles que VirusTotal ou MalwareBazaar.

  • Vérifier l'adresse IP d'origine de l'alerte dans le GCenter :

    • Si l'alerte est liée à une adresse IP externe, examiner le niveau de réputation de cette adresse.
      Une adresse IP ayant une mauvaise réputation est plus susceptible d'être associée à des activités malveillantes.

    • À noter également, ce n'est pas parce qu'il s'agit d'une adresse IP interne qu'il s'agit d'un faux positif.

  • Consulter l'historique des alertes :

    • Consulter l'historique des alertes similaires générées par ActiveCTI.
      Si des alertes similaires ont été confirmées comme des menaces réelles dans le passé, cela renforce la probabilité que l'alerte actuelle soit également une menace.
      En fonction des observations, la menace pourra être catégorisée comme réelle ou non.

    • Si besoin, utiliser la fonctionnalité File transactions présentée au paragraphe précédent pour obtenir la majorité de ces informations via une vue condensée.

7.5.8.2.3. Quelles réponses à apporter en cas de confirmation de la menace ?

Note

Cette procédure permet d'approfondir l'investigation et évaluer l'étendue de l'incident après confirmation d'une menace générée par le moteur ActiveCTI.

De manière générale, il convient de :

  • Déterminer l'étendue de l'infection : identifier les machines infectées par la menace

  • Isoler le système : isoler immédiatement le système contaminé et s'assurer qu'il ne peut pas causer de dommages supplémentaires

  • Notifier : informer les parties concernées de la détection de la menace

Selon les cas, on s'oriente vers différentes remédiations :

  • si la menace est un domaine ou une IP associé au téléchargement d'un ressource malveillante, dans ce cas il s'agit probablement du transfert d'un outil malveillant vers ou au sein de l'environnement infecté :

    • supprimer le fichier ou logiciel malveillant de la ou les machines infectées

    • analyser la machine à partir de laquelle la demande a été adressée au serveur malveillant, qui aurait été infectée avant la demande

  • si la menace est associée à un serveur de Command and Control, cela implique qu'une ou plusieurs machines infectées communiquent avec ledit serveur :

    • supprimer la balise malveillante à l'origine des communications vers le serveur de la ou les machines infectées

  • si la menace est associée à du phishing :

    • identifier la cible du phishing

    • interroger le ou les collaborateurs sur les détails de l'attaque pour évaluer l'ampleur des informations communiquées à l'attaquant

Dans un second temps, il convient également de regarder les relations associées à l'IoC via le champ relations ou via les external_links pour :
  • anticiper les actions de l'attaquant
  • surveiller / bloquer les éléments associés à l'IOC

  • si la menace est un hash correspondant à un fichier :

    • Neutraliser la menace en supprimant le fichier, bloquant l'adresse IP d'origine, etc.

    • Analyse dynamique : si possible, exécuter le fichier dans un environnement sécurisé (sandbox) pour observer son comportement (une GBox par exemple).

    • Reverse engineering (si nécessaire) : si la menace est particulièrement complexe, le reverse engineering peut être envisagé pour comprendre en profondeur son fonctionnement interne.
      Cela peut aider à identifier les vulnérabilités exploitées et les mécanismes de propagation.

    • Analyser les logs : examiner les journaux système et réseau pour retracer la propagation de la menace.

Dans un second temps, il convient également de regarder les relations associées à l'IoC via le champ relations ou via les external_links pour :

  • anticiper les actions de l'attaquant

  • surveiller / bloquer les éléments associés à l'IoC

7.5.8.2.3.1. Que faire si une alerte de ce moteur est identifiée comme un faux positif ?

Si une alerte provenant de ce moteur est identifiée comme un faux positif récurrent, il est recommandé de mettre l'alerte en sourdine.
Il n'y a pas de liste blanche pour le moteur Retrohunt.