Propriétés de la campagne

Une campagne détectée par l'application NSX Network Detection and Response est caractérisée par plusieurs propriétés.

Voici les propriétés de campagnes et leurs définitions.

Nom de la propriété	Description
Nom	ID de campagne qui identifie de manière unique la campagne.
Hôtes	Hôtes affectés par la campagne.
Menace	Menaces détectées pour la campagne.
Étapes d’attaque	Phases du cycle de vie de l'adversaire correspondant aux activités détectées. Reportez-vous à À propos des étapes d’attaque pour plus de détails.
Durée	Intervalle de temps pendant lequel les activités associées à une campagne ont été observées.

À propos des étapes d’attaque

Les étapes d'attaque sont les phases du cycle de vie d'une vulnérabilité qui correspond aux activités détectées par l'application NSX Network Detection and Response.

Un modèle adversaire décrit les actions qu'un adversaire peut entreprendre pour compromettre et agir au sein d'un réseau d'entreprise. L'application NSX Network Detection and Response utilise le modèle https://attack.mitre.org/ATT&CK™ (Adversarial Tactics, Techniques, and Common Knowledge) de MITRE pour décrire les comportements adversaires. Dans ce modèle, les techniques qu'un adversaire peut utiliser sont regroupées en plusieurs catégories de tactiques, qui correspondent à différentes étapes du cycle de vie des attaques.

Dans le système, l'activité associée à chaque événement détecté peut être associée à une étape d'attaque spécifique et peut fournir une indication de la progression de la campagne tout au long de son cycle de vie. (Les activités rencontrées au cours de différentes phases d'attaque peuvent ne pas être associées à une étape d'attaque spécifique.) Actuellement, les étapes d’attaque suivantes sont utilisées.

Nom de l'étape d'attaque	Description
Livraison	Étape à laquelle les attaquants envoient la charge utile à la cible. Les mécanismes de livraison courants incluent les exploits distants, les pages Web de téléchargement furtif et les lecteurs USB ou autres lecteurs amovibles malveillants.
Exploitation	Étape à laquelle la charge utile de l’attaquant est déployée dans le réseau cible. Par conséquent, un ou plusieurs terminaux du réseau cible sont compromis et sous le contrôle de l’attaquant.
Commande et contrôle	Étape à laquelle les attaquants communiquent avec les systèmes sous leur contrôle au sein du réseau cible, ce qui permet d'obtenir efficacement un accès « pratique » à distance à ces systèmes.
Accès aux informations d'identification	Étape à laquelle les attaquants obtiennent un accès ou un contrôle sur les informations d'identification du système, du domaine ou du service utilisées dans l'environnement cible. Généralement, les attaquants tentent d'obtenir des informations d'identification légitimes auprès de comptes d'utilisateur et d'administrateur afin d'emprunter l'identité ou de créer de nouveaux comptes.
Détection	Étape à laquelle les attaquants tentent de trouver plus d'informations sur l'environnement cible. Les attaquants tentent souvent d'identifier des périphériques supplémentaires dans le réseau, qu'ils peuvent utiliser pour leurs objectifs.
Déplacement latéral	Étape à laquelle les pirates se déplacent sur le réseau cible en obtenant l'accès et le contrôle des systèmes distants.
Collection	Étape à laquelle les attaquants identifient et collectent des informations à partir d’un réseau cible avant l’exfiltration.
Exfiltration	Étape à laquelle les attaquants suppriment des fichiers et des informations d'un réseau cible.

À propos des règles de corrélation

En général, les incidents sont regroupés en une campagne lorsqu'il existe une preuve indiquant que les activités malveillantes ou les attaques correspondantes sont liées.

Comme ces règles de corrélation s'exécutent dans le service de cloud NSX Advanced Threat Prevention, elles peuvent être améliorées ou étendues indépendamment des cycles de publication de NSX-T. En outre, la liste des règles de corrélation ou le comportement spécifique d'une règle peut changer dans le temps.

Voici les règles de corrélation actuellement prises en charge.

Événement d’anomalie

Cette règle met en corrélation les événements de détection de la fonctionnalité Trafic suspect NSX avec des événements de type infection à impact supérieur. Par exemple, un événement d'anomalie de la fonctionnalité Trafic suspect NSX coïncide avec un événement réseau à impact élevé pour les mêmes hôtes.

Exfiltration

Cette règle met en corrélation des événements d'exfiltration qui sont précédés d'événements de type infection. Par exemple, un événement réseau Commande et contrôle est suivi d'un événement réseau que nous savons être l'exfiltration des données.

Transfert de fichiers (basé sur le hachage)

Cette règle met en corrélation des transferts de fichiers malveillants. Par exemple, si le même fichier malveillant est téléchargé sur un certain nombre d'hôtes du réseau, la règle met en corrélation tous ces transferts en une intrusion. La similarité des transferts de fichiers malveillants est déterminée en fonction du hachage SHA-1 du fichier transféré.

Transfert de fichiers (analyse basée sur des balises)

Analyse de vulnérabilité

Cette règle met en corrélation différents types d'événements réseau qui indiquent tous potentiellement une analyse de vulnérabilité. Par exemple, plusieurs événements de type à infection sortant ou NTA sont observés d'un hôte unique vers un ou plusieurs hôtes de destination internes.

Vague

Ce groupe de règles identifie les « vagues » d'attaque dans lesquelles la même attaque (c'est-à-dire, des incidents pour la même menace) est observée sur plusieurs hôtes sur le réseau au cours d'une certaine fenêtre de temps.

Ce groupe de règles est utile pour identifier les hôtes du réseau qui font partie de la même infrastructure Commande et contrôle ou qui ont été exposés au même vecteur d'attaque (par exemple, une attaque furtive ou une attaque par distribution de programmes malveillants). Par conséquent, ces règles sont limitées aux menaces de classe Commande et contrôle, furtives, de distribution de programmes malveillants, de sinkhole, de faux antivirus et d'exploration de chiffrement.

Les règles de ce groupe se déclenchent dans les cas suivants.

Il existe des événements de signature réseau dans lesquels la classe de menace est Commande et contrôle, ce qui affecte plusieurs hôtes.
Il existe des événements de signature réseau dans lesquels la classe de menace est la distribution de programmes malveillants, ce qui affecte plusieurs hôtes.
Il existe des événements de signature réseau dans lesquels la classe de menace est furtive et l'entrée (adresse IP ou nom d'hôte) dans laquelle les détections ont eu lieu sont les mêmes, ce qui affecte plusieurs hôtes.
Il existe des événements de réputation malveillants pour la même entrée (adresse IP ou nom d'hôte) et la classe de menace est Commande et contrôle, ce qui affecte plusieurs hôtes.
Il existe des événements de réputation malveillants pour la même entrée (adresse IP ou nom d'hôte) et la classe de menace est la distribution de programmes malveillants, ce qui affecte plusieurs hôtes.

Dans ce cas, la fenêtre de corrélation est définie sur trois jours. Par conséquent, deux incidents pour la même menace affectant différents hôtes sont considérés comme étant liés s'ils se produisent dans cet intervalle de temps limité.

Note :

Ces règles peuvent créer des campagnes composées uniquement d'un hôte et d'un incident.

Furtivité confirmée

Ce groupe de règles identifie les campagnes dans lesquelles un hôte interne est exposé à une attaque furtive réussie. Une attaque furtive sur un hôte est considérée comme réussie si elle est suivie d'une activité Commande et contrôle, téléchargement de programmes malveillants, sinkhole ou faux antivirus. Les règles de ce groupe se déclenchent dans les cas suivants.

Furtivité suivie de près par l'activité de téléchargement de programmes malveillants : dans ce cas, la fenêtre de corrélation est de 10 minutes, car nous nous attendons à ce que le téléchargement soit immédiatement causé par un exploit réussi du navigateur.
Furtivité suivie de près par l'activité de faux antivirus : dans ce cas, la fenêtre de corrélation est de 10 minutes, car nous nous attendons à ce que l'activité de faux antivirus suive immédiatement un exploit furtif.
Furtivité suivie de près par l'activité Commande et contrôle : dans ce cas, la fenêtre de corrélation est de quatre heures, car la configuration du canal de Commande et contrôle peut prendre un certain temps.
Furtivité suivie de près par l'activité du récepteur : dans ce cas, la fenêtre de corrélation est de quatre heures, car l'activité vers un serveur malveillant rémanent sur un canal Commande et contrôle peut prendre un certain temps à être configurée.

Note :

Ces règles peuvent créer des campagnes composées d’un seul hôte.

Téléchargement du fichier confirmé

Ce groupe de règles identifie les campagnes dans lesquelles un fichier malveillant est téléchargé et exécuté avec succès sur un hôte. Un fichier téléchargé est considéré comme ayant été exécuté avec succès sur un hôte si, peu après le téléchargement, il existe des événements réseau pour les activités qui correspondent à l'activité observée lors de l'analyse du fichier.

En particulier, l'analyse de fichiers peut fournir deux autres informations pour analyser l'activité observée au cours de l'analyse.

Informations sur les programmes malveillants: Si le comportement du fichier correspond au comportement d’une menace connue, le nom du logiciel malveillant devient disponible.
Informations de l'IoC réseau: Si, au cours de l'analyse, l'exemple génère un trafic réseau correspondant aux signatures réseau ou aux informations sur les menaces, des indicateurs du trafic sont mis à disposition. Autrement dit, des informations sur les réputations malveillantes et les correspondances de signatures réseau sont fournies.

Les règles de ce groupe se déclenchent dans les deux cas suivants, selon le type d’informations dérivées de l’analyse du fichier.

Cas basé sur des programmes malveillants
- Un fichier est téléchargé sur un hôte.
- L'analyse de fichiers attribue une menace spécifique au fichier (par exemple, le logiciel malveillant Emotet).
- Par la suite, un événement réseau pour la même menace (c'est-à-dit, Emotet) est détecté pour l'hôte qui a téléchargé le fichier.
Cas basé sur l'IoC réseau
- Un fichier est téléchargé sur un hôte.
- L’analyse du fichier identifie l'IoC réseau du fichier.
- Ultérieurement, l'hôte qui a téléchargé le fichier tente de contacter une adresse IP ou un nom d'hôte inclus dans l'IoC de réputation malveillante extrait pour le fichier et ce trafic correspond à une signature réseau.

L'application NSX Network Detection and Response définit la fenêtre de corrélation dans ce cas sur trois jours.

Note :

Cette règle peut créer des campagnes composées d’un seul hôte.

Déplacement latéral

Ce groupe de règles identifie les attaques dans lesquelles les pirates ont établi une « tête de pont » en compromettant certains hôtes, puis tentent de les déplacer ultérieurement au sein du réseau pour compromettre des hôtes supplémentaires.

Ce groupe comprend deux règles, chacune d'elles détectant une étape distincte de la campagne du mouvement latéral.

Déplacement latéral sortant: Cette règle met en corrélation l'activité de déplacement latéral sortant d'un hôte dans le réseau domestique et les infections sur cet hôte qui se sont produites avant les détections de déplacement latéral (mais dans la fenêtre de corrélation).
Déplacement latéral entrant: Cette règle met en corrélation l'activité de déplacement latéral entrant vers un hôte dans le réseau domestique configuré et l'activité généralement observée après un compromis initial (commande et contrôle, sondage et collecte d'informations d'identification) qui s'est produit sur le même hôte après les détections de déplacement latéral.

Notez que ces règles ne se déclencheront que pour les hôtes dans le réseau domestique, c'est-à-dire que la campagne est créée uniquement si les hôtes source et de destination des activités de déplacement latéral appartiennent au réseau domestique. Si le réseau domestique n'est pas configuré, le système utilise des plages RFC1918 par défaut.

Promotion des événements INFO

L'application NSX Network Detection and Response détecte plusieurs activités dans un réseau protégé qui peuvent être intéressantes pour un analyste, mais qui ne sont probablement pas malveillantes. Ces détections génèrent des événements INFO, qui peuvent être affichés en définissant une valeur appropriée du filtre « résultat de l'événement ».

L'application NSX Network Detection and Response ne tient pas compte des événements INFO à des fins de corrélation.

Ces détections posent un défi : la même activité d'événement INFO peut être normale ou fortement suspecte, selon le réseau dans lequel l'application NSX Network Detection and Response l'a détectée. Par exemple, l'utilisation du protocole RDP (Remote Desktop Protocol) peut être normale dans un environnement où cet outil est utilisé à des fins administratives légitimes, mais peut également être une indication fortement suspecte qu'un attaquant peut tenter de contrôler à distance un hôte victime.

La logique de détection d'anomalie peut déterminer quand certains types de détections INFO sont inhabituels pour le réseau surveillé et pour les hôtes source et les hôtes de destination spécifiques impliqués. Lorsque le système détermine qu'une détection INFO est inhabituelle, l'événement est promu en mode « détection » et, par conséquent, s'affiche parmi les événements particulièrement fréquents. Ce scénario est pertinent dans le contexte de règles de corrélation pour le déplacement latéral, car la détection de l'activité de déplacement latéral entraîne souvent la création d'événements INFO.

Réseau local

La configuration du réseau domestique a l'effet suivant sur les règles de corrélation de campagne.

Toutes les règles de corrélation de campagne ignorent les événements qui se sont produits sur les hôtes en dehors du réseau domestique.
Si aucun réseau domestique n'est configuré, le système utilise par défaut les plages RFC1918.

Le réseau domestique est configuré dans Sécurité > Paramètres généraux > Plages d'adresses IP privées.

Mise sous silence de l'hôte

La configuration de mise sous silence de l'hôte a l'effet suivant sur les règles de corrélation de campagne.

Si la mise sous silence de l'hôte est configurée, toutes les règles de corrélation de campagne ignorent les événements qui se sont produits sur les hôtes silencieux.
Si aucune mise sous silence de l’hôte n’est configurée, tous les hôtes sources détectés dans un événement sont considérés comme valides pour la corrélation.

Pour vous assurer que la mise sous silence d'hôte n'inclut pas par erreur les hôtes dont l'activité doit être incluse dans les campagnes, vous devez vérifier la configuration de mise sous silence de votre hôte.

À propos de la preuve

L'application NSX Network Detection and Response signale les actions observées lors de l'analyse d'un événement, d'un incident ou d'une campagne.

La preuve contient les informations suivantes.

Preuve de détection de base : réseau

Type de preuve RÉPUTATION

Indique que le trafic réseau a été détecté vers une adresse IP ou un domaine associé à une menace connue.

Un champ OBJET et une adresse IP ou un domaine s'affichent. Par exemple : réputation : evil.com (événement de référence), 6.6.6.6 (événement de référence) ou bad.org (événement de référence).

Ces domaines et adresses IP incorrects sont généralement bloqués. Des informations supplémentaires sur la réputation s'affichent si elles sont disponibles.

Les adresses IP peuvent être annotées avec un emplacement (indicateur de pays).

Type de preuve SIGNATURE

Indique que le trafic réseau qui correspond à une signature réseau pour une menace connue a été détecté.

Un champ Détecteur qui est le nom/identifiant unique de la signature correspondante s'affiche. Par exemple, Detector: et:2014612 ou Detector: llrules:1490720342088.

Type de preuve ANOMALIE

Semblable à SIGNATURE à la différence que la détection est basée sur un heuristique qui a détecté un élément anormal. Par exemple, Anomaly: anomaly:download_smb.

Type de preuve TÉLÉCHARGEMENT DE FICHIER

Un fichier malveillant ou suspect a été téléchargé.

Un task_uuid, l'identifiant d'une analyse (détonation dans sandbox) et la severity, le score de cette analyse, s'affichent. Par exemple, File download: a7ed621.

L’élément suivant répertorie des informations facultatives supplémentaires provenant de l’événement de référence.

URL à partir de laquelle a été téléchargé le fichier
Type de fichier (généralement exécutable)
Nom du fichier

Type de preuve UNUSUAL_PORT

Indique qu'un port TCP ou UDP est utilisé, ce qui est rare et correspond à ce qui est attendu de cette menace spécifique.

L'adresse IP ou le domaine impliqué dans le trafic qui utilisait le port inhabituel s'affiche dans le champ OBJET.

Type de preuve URL_PATH_MATCH

Semblable à un port inhabituel, avec la différence que la détection est basée sur un chemin d'URL. Par exemple, http://evil.com/evil/path?evil=threat, la détection est déclenchée par la partie /evil/path de l'URL.

Type de preuve DGA

DGA représente « Algorithme de génération de domaine », une approche utilisée par certains logiciels malveillants, où au lieu d'utiliser un petit nombre de domaines pour la commande et le contrôle, le logiciel malveillant inclut un algorithme qui génère des milliers de nouveaux domaines à l'apparence aléatoire chaque jour. Il tente ensuite de contacter chacun d'eux. Pour contrôler ses logiciels malveillants, le pirate enregistre simplement un ou plusieurs de ces domaines. L'utilisation de DGA est très visible sur le réseau en raison de tentatives de résolution de nombreux domaines de ce type.

La preuve DGA est actuellement utilisée en plus des preuves de réputation régulières, lorsque plusieurs domaines incorrects provenant d'un algorithme DGA en cours de résolution sont détectés.

Preuve de la corrélation de plusieurs événements

Preuve de la corrélation de plusieurs événements

Les types de preuve suivants sont créés dans les cas où la combinaison de plusieurs événements réseau sur un hôte augmente la confiance qu'une menace a été correctement détectée. Les types de preuve peuvent être, par exemple, la même entrée de réputation malveillante contactée ou la même signature réseau déclenchée.

Dans chacun de ces cas, la menace peut être marquée comme suit.

Repeated : la menace spécifique a été vue trois fois ou plus.
Periodic : la menace spécifique s'est également produite à intervalles réguliers.

Une étiquette est affichée sur la preuve de réputation/signature correspondante.

Dans l'exemple de preuve RÉPUTATION, si des preuves répétées et périodiques pour bad.org sont détectées, une balise REPEATED ou PERIODIC s'affiche.

Type de preuve CONFIRMED_EXECUTION

Cela est associé à des menaces, telles que LE TÉLÉCHARGEMENT DE FICHIERS MALVEILLANTS. Cela signifie que le comportement réseau est détecté à partir de l'hôte qui a téléchargé le fichier qui confirme que le fichier téléchargé a bien été exécuté.

C'est-à-dire :

Un fichier malveillant a été téléchargé sur l'hôte 1.2.3.4.
Lorsqu'il est exécuté dans un sandbox, ce fichier a contacté l'hôte evil.com.
Peu après, le trafic Commande et contrôle de l'hôte 1.2.3.4 vers evil.com est observé, confirmant que le fichier malveillant a été exécuté.

L'événement de référence lié se situe à l'endroit où le fichier a été téléchargé.

Des preuves supplémentaires peuvent fournir une confirmation de la menace, telles que les informations suivantes sur le fichier.

UUID de tâche
Score
Nom du fichier
URL depuis lequel il a été téléchargé

Type de preuve CONFIRMED_C&C

Comme pour CONFIRMED_EXECUTION, cette preuve est ajoutée à la détection Commande et contrôle pour la menace spécifiée, car l'hôte a précédemment téléchargé un fichier pour cette menace.

Type de preuve CONFIRMED_DRIVE_BY

Cela est ajouté dans les situations où une attaque furtive a été détectée suivie d'une indication indiquant que l'attaque a réussi. Par exemple :

L'hôte 1.2.3.4 semble être la victime d'une attaque furtive.
Peu après, l'hôte 1.2.3.4 a soit :
- Téléchargé un fichier malveillant
- Exécuté un trafic Commande et contrôle

Cette preuve est ajoutée à l'événement de référence de l'événement furtif initial.

Type de preuve DRIVEBY_CONFIRMATION

Comme pour la preuve CONFIRMED_DRIVEBY, cette preuve est ajoutée en tant qu'événement de référence aux détections de téléchargement de fichiers malveillants ou de détections commande&control qui se sont produites peu après une attaque furtive.