2.1.3. Moteur Shellcode detect

2.1.3.1. Introduction

2.1.3.1.1. Pour quels types de menaces ce moteur est-il conçu ?

Le moteur Shellcode detect permet de détecter et d'analyser les shellcodes.
Un Shellcode est un code binaire conçu pour être injecté et exécuté dans un programme en exploitant une vulnérabilité.
Semblable à un logiciel malveillant miniature, son objectif est généralement de prendre le contrôle du système infecté, mais n'importe quel type d'action peut être exécuté.
Les shellcodes ont souvent de nombreuses contraintes liées à la vulnérabilité exploitée (taille limitée, octets interdits, ...).
Ainsi, un attaquant l'utilisera généralement pour « s'ouvrir les portes » du système, avant de passer à des techniques plus avancées.
Un shellcode peut être utilisé pour ouvrir une porte dérobée sur la machine, pour permettre à l'attaquant d'agir en direct, ou pour télécharger directement dans la mémoire un logiciel malveillant et l'exécuter.
Un Shellcode peut également être obscurci, « encodé », pour éviter d'être détecté par des modèles, tout en restant exécutable tel quel.
Il doit pouvoir s'auto-décoder, on parle alors de polymorphisme.
Il existe sur internet de nombreux algorithmes d'encodage pour les shellcodes, plus ou moins complexes.
En raison de sa nature, le shellcode est difficile à détecter :

  • ce n'est pas un fichier

  • il est directement exécuté en mémoire dans un programme sain

  • sa petite taille réduit les possibilités de détection des modèles

  • il peut être obscurci pour éviter la détection de modèles

Un shellcode peut également être utilisé dans un logiciel malveillant afin de brouiller les pistes lors d'une analyse antivirus.

2.1.3.1.2. Comment ce moteur détecte-t-il les menaces ?

La détection des shellcodes se fait en plusieurs étapes :

  1. La première étape consiste à analyser les échantillons pour y déceler les encodages du shellcode.
    En effet, ces algorithmes sont spécifiques aux shellcodes, ils ne peuvent être retrouvés dans un autre contexte.
    Ce processus permet une identification précise et incontestable des shellcodes.
  2. Si un ou plusieurs encodages sont identifiés, le shellcode est extrait et envoyé à l'étape d'analyse.
  3. Si aucun codage n'a été identifié, l'échantillon fait l'objet d'une recherche approfondie des indicateurs.
    Ce processus effectue une recherche intelligente, basée sur l'émulation, pour tenter d'identifier le comportement typique d'un shellcode.
  4. La dernière étape consiste à analyser le shellcode identifié afin de valider la détection et d'extraire autant d'informations que possible.
    Ce processus effectue une émulation complète du shellcode et enregistre toutes les fonctions système appelées.

2.1.3.1.3. Comment fonctionne le moteur Shellcode detect dans le GCenter?

Le moteur :

2.1.3.1.3.1. Données saisies du moteur Shellcode detect

Tout paquet passant par le réseau sera soumis à une recherche de modèles intelligents afin d'identifier ceux qui pourraient contenir un shellcode.
Ces paquets sont ensuite extraits et envoyés au GCenter pour une analyse plus approfondie par le moteur Shellcode detect.
Une fois l'analyse terminée, si un shellcode a été identifié, une alerte est lancée avec toutes les informations recueillies.

Note

Actuellement, seuls les shellcodes pour les machines Linux et Windows, sous architecture Intel x86 et x64, sont détectés.
L'identification du codage ne sera possible que pour un ensemble défini d'algorithmes, mais cela n'empêchera pas la détection des shellcodes dont le codage n'a pas pu être identifié.
La détection des shellcodes intégrés dans les logiciels malveillants est possible et suivra le même chemin d'analyse, mais ne fonctionnera pas s'ils sont « cachés » (cryptage, compression, ...) car elle nécessiterait une analyse dynamique du logiciel malveillant lui-même.
Pour que le moteur soit opérationnel, une première mise à jour de la «Threat DB» devra avoir lieu.

2.1.3.2. Événements générés

Les événements générés par le moteur Shellcode Detect sont uniquement 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.
  • Dans l'interface nommée Kibana UI
    • Cliquer sur l'icône `Hunting` de la `WebUI`.
      ../../_images/GCE103_SHELLCODE-08.PNG
      L'interface affichée est l'interface nommée Kibana UI (décrite dans l'Interface graphique Kibana).

    • Cliquer sur l'onglet `Shellcode` (2) de la catégorie `Alerts` (1).

    • Sélectionner l'onglet `Overview` (3).

    • Sélectionner l'intervalle de temps (4) pour afficher les données.
      Il est alors possible de filtrer sur certaines valeurs pour, par exemple :

      • ne pas afficher les machines saines (filtrer les faux positifs)

      • afficher uniquement les alertes provenant d'une adresse IP particulière

      • ne pas afficher les alertes provenant d'un GCap spécifique

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

2.1.3.2.1. Exemple d'alerte Shellcode detect dans la WebUI

../../_images/GCE103_SHELLCODE-02.PNG
La présentation des détails de l'écran `Alert details` est disponible dans la Fenêtre `Alert details`.
Les compteurs sont donnés dans l'annexe Structure des données du journal de bord du moteur.

2.1.3.2.1.1. Structure des données des logs Shellcode

Les logs sont composés de différentes parties :

  • la partie en-tête

  • la partie source définie par "_source"

  • la partie champs définie par "_fields"

Ces informations sont affichées dans l'écran `Expanded document` de Kibana.

2.1.3.2.1.2. La partie en-tête des logs Shellcode

La partie en-tête contient :

"_index": "engines_alerts-2024.12.04-000030",
"_id": "BqIIkpMBe7GX5B2fdvZJ",
"_version": 1,
"_score": 0,

Les informations détaillées sont données dans le tableau (Compteurs de la partie en-tête des journaux).

2.1.3.2.1.3. La partie source des logs Shellcode

La partie source définie par "_source" contient :

Note

Les données affichées dans la WebUI (fenêtre de détails des alertes) font partie des données affichées dans le document étendu de l'interface Kibana.
Toutes les données peuvent être exportées vers un SIEM via syslog (un exemple d'alerte exportée est présenté).
Les informations détaillées sont données dans le tableau (Compteurs de la partie en-tête des journaux).

L'exemple donné ici est un exemple de Kibana.

"event": {
  "created": "2024-12-04T14:17:28.138941+0000",
  "dataset": "alert",
  "severity": 1,
  "module": "shellcode_detect",
  "kind": "alert",
  "category": [
    "network",
    "intrusion_detection"
  ],
  "id": "f22d2438-d436-4391-9e7d-3fe1321ebed0"
},
"@version": "1",
"destination": {
  "port": 9999,
  "ip": "X.Y.Z.A"
},
"source": {
  "port": 33390,
  "ip": "W.S.Q.E"
},
"observer": {
  "log_format_version": "1.0.0",
  "hostname": "gcenter.domain.local",
  "vendor": "gatewatcher",
  "gcap": {
    "ingress": {
      "interface": {
        "name": "monvirt"
      }
    },
    "hostname": "gcap.gatewatcher.com",
    "version": "2.5.4.0"
  },
  "product": "gcenter",
  "uuid": "fc1e66e3-a397-5eb4-9277-754be778f317",
  "version": "2.5.3.103"
},
"ecs": {
  "version": "8.6.0"
},
"shellcode": {
  "sample_id": "12-04-2024T14:17:25_92517a8550cf4130b23466244880c1c7_gcap-int-129-dag.gatewatcher.com",
  "analysis": [
    {
      "args": "{'pathname': '//etc/passwd', 'flags': 'O_WRONLY|O_APPEND', 'mode': 'None'}",
      "_id": 0,
      "call": "sys_open",
      "ret": "4"
    },
    {
      "args": "{'fd': '//etc/passwd (4)', 'buf': 'bob::0:0::/://bin/sh', 'count': 20}",
      "_id": 1,
      "call": "sys_write",
      "ret": "20"
    },
    {
      "args": "{'fd': '//etc/passwd (4)'}",
      "_id": 2,
      "call": "sys_close",
      "ret": "0"
    },
    {
      "args": "{'status': 4}",
      "_id": 3,
      "call": "sys_exit",
      "ret": "0"
    },
    {
      "info": "Stop : End of shellcode (Exit)",
      "_id": -1
    }
  ],
  "sub_type": "Linux_x86_32",
  "encodings": [
    {
      "name": "Shikata_ga_nai",
      "count": 1
    }
  ],
  "id": "8ae5f9d35f3878cac3064fe93e4c311d"
},
"@timestamp": "2024-12-04T14:17:28.138Z",
"network": {
  "protocol": "unknown",
  "transport": "tcp",
  "timestamp": "2024-12-04T14:16:12.828909+0000",
  "flow_id": 1134126449059384

2.1.3.2.1.4. Liste des compteurs de l'alerte

Note

Les compteurs de l'alerte sont visibles :

  • dans l'écran `Alert details` de la WebUI

  • dans l'écran `Expanded document` de Kibana

  • dans l'export vers le SIEM

Les informations détaillées sont données dans le tableau (Compteurs de la partie source des journaux).

2.1.3.3. Gestion du moteur

2.1.3.3.1. Visualisation de l'état du moteur

La visualisation de l'état courant du moteur est donnée dans l'Ecran `Health checks`.

2.1.3.3.2. Mise à jour du moteur

Le moteur est mis à jour à chaque nouvelle version du GCenter.

2.1.3.3.3. Configuration du moteur

L'interface de configuration permet d'activer le moteur :

2.1.3.4. Analyse des alertes

Les alertes sont affichées sur un écran spécifique, cet écran est décrit dans l'Ecran `Alerts` de la WebUI.
La procédure générale de l’analyse des alertes est décrite dans l'Utilisation des tableaux de bord NDR.
La procédure spécifique de l’analyse des alertes Shellcode detect est décrite dans l'Analyse des alertes Shellcode detect.