Common Events & Incidents

Cette leçon abordera les événements de sécurité courants observés par les équipes chargées des opérations de sécurité et vous donnera un aperçu des enquêtes quotidiennes typiques qui ont lieu. Nous verrons également comment certains événements courants peuvent se transformer en incidents et les mesures prises par les défenseurs pour analyser correctement la situation. Les événements que nous couvrirons sont les suivants :

• Numérisation à distance vers local
• DoS/DDoS local à distance
• Numérisation d'un local à un autre
• Échecs de connexion

Avant d'aborder ces événements de sécurité, nous voulons expliquer ce que l'on entend par « distance vers local », « local vers distant » et « local vers local ». Lorsque nous examinons le réseau privé d'une organisation, nous utilisons le terme interne, car il est interne à l'organisation. Tout ce qui se trouve en dehors de l'organisation, comme les sites Web qui ne sont pas hébergés par l'entreprise et les adresses IP publiques, est considéré comme externe ou distant.

Ainsi, toute activité qui se produit entre deux systèmes au sein d'un réseau privé se fait du local vers le local, tandis que l'activité provenant d'une adresse IP externe vers une adresse IP publique appartenant à l'organisation se ferait à distance par rapport au local. Tout au long de cette leçon, nous utiliserons les abréviations suivantes :

• R2L — Du distant au local
• L2R : du local au distant
• L2L — Du local au local

Numérisation du port R2L

Dans le cadre de cette activité, une adresse IP publique externe analyse les adresses IP publiques détenues par l'organisation. Cela est généralement effectué pour voir quelles adresses IP sont utilisées par l'organisation, lesquelles d'entre elles sont utilisées et quels ports sont ouverts. Ce type d'activité est susceptible de se produire toute la journée, tous les jours, et il s'agit sans doute du type d'alerte le plus courant auquel les analystes seront confrontés, selon la manière dont l'organisation en question surveille cette activité.

Dans le schéma simplifié ci-dessus, nous avons montré comment un système présent sur Internet est capable d'effectuer une analyse des ports par rapport aux systèmes de la DMZ en parcourant une liste d'adresses IP publiques appartenant à l'organisation. Les lignes rouges représentent le système qui envoie une demande à une adresse IP sur un port spécifique, tandis que les lignes bleues représentent une réponse du système (à condition qu'un système soit actif sur cette adresse IP).

Détection

Pour cela, nous souhaiterions collecter des journaux à partir de pare-feux périmétriques et de parefeux d'applications Web. La règle rechercherait plusieurs connexions dans un court laps de temps à un certain nombre de ports différents du système. En général, les serveurs Web ne doivent être contactés que sur les ports 80 (http) et 443 (https). Un système distant qui commence à se connecter aux ports 93, 1195, 1959 et à d'autres ports aléatoires non standard est très probablement en train de scanner le système ou de prendre ses empreintes digitales.

Incidence potentielle

La numérisation se produit tout le temps, et il y a rarement un impact immédiat. Les systèmes plus anciens peuvent être affectés par le scan s'il n'y a pas d'évolutivité et si l'acteur effectue une analyse intensive. Cela pourrait consommer beaucoup de bande passante et empêcher les autres systèmes de s'y connecter, ce qui provoquerait un déni de service (DoS).

DoS/DDoS R2L

Dans le cadre de cette activité, une ou plusieurs adresses IP externes (DDoS) envoient un volume élevé de requêtes ou de paquets mal formés à un système cible dans le but de le bloquer.

Le schéma de gauche montre une attaque par déni de service R2L, au cours de laquelle une adresse IP tente d'envoyer plus de paquets au système cible qu'elle ne peut en traiter, ce qui provoque son blocage, empêche le trafic légitime de l'atteindre, ce qui entraîne un déni de service.

Le schéma de droite montre une attaque par déni de service distribué R2L, au cours de laquelle plusieurs adresses IP tentent de planter ou de consommer les ressources du système cible afin que celui-ci ne puisse pas traiter des demandes légitimes, ce qui entraîne un déni de service.

Détection

Nous pouvons utiliser des règles qui surveillent le nombre de demandes que les systèmes de la zone démilitarisée reçoivent. Établissez une base de référence pour les niveaux de trafic « normal » qui

devraient être reçus par ces systèmes, et créez une règle qui générera une alerte lorsqu'un seuil supérieur au seuil de référence est observé.

Incidence potentielle

Les attaques par déni de service, bien que dépendantes d'un certain nombre de facteurs, sont susceptibles de mettre les systèmes hors ligne. Cela peut entraîner une perte de confiance des clients, une baisse des ventes et même des dommages au système concerné. Prenons un exemple : si l'organisation A est un détaillant en ligne et que son site Web est touché par une attaque DDoS et qu'il est mis hors ligne, les clients ne pourront pas passer de commandes, ce qui entraînera des pertes de ventes. Les clients qui apprennent comment le site a été « attaqué », sans contexte approprié ni connaissances en matière de cybersécurité, peuvent penser que le site a été piraté et se lancer dans une autre activité. En 2016, une attaque DDoS a été lancée contre Dyn, un fournisseur de DNS. Cela a conduit les entreprises à utiliser Dyn pour se déconnecter également, car les utilisateurs qui tentaient de visiter les sites n'arrivaient pas à résoudre l'adresse IP à partir du nom de domaine. Cette attaque a touché des entreprises telles qu'Amazon, BBC, PayPal, Reddit et Twitter. Pour en savoir plus sur cette attaque DDoS très médiatisée, cliquez ici.

Numérisation L2L

Dans le cadre de cette activité, une adresse IP privée interne analyse une ou plusieurs autres adresses IP privées.

Dans le schéma simplifié ci-dessus, nous avons montré comment un système du réseau privé scanne d'autres systèmes du même réseau, envoie des requêtes et reçoit des réponses, les utilise pour déterminer quels systèmes sont actifs et effectue des activités de prise d'empreintes digitales pour identifier le système d'exploitation et tous les services en cours d'exécution sur d'autres hôtes.

Détection

Les règles SIEM peuvent être configurées pour générer des alertes lorsqu'une adresse IP privée établit des connexions rapides avec d'autres adresses IP privées internes. Des seuils ou des modèles doivent être utilisés pour empêcher les faux positifs, car les systèmes internes établiront des connexions légitimes les uns avec les autres, mais il est très peu probable que les systèmes internes scannent les ports ou se prennent leurs empreintes digitales les uns les autres ! Les scanners de vulnérabilité internes doivent être ajoutés à la liste blanche en fonction de toutes les règles d'analyse L2L, car si l'équipe de sécurité lance une analyse de vulnérabilité interne, le SIEM génère une alerte lorsque le scanner commence à scanner d'autres systèmes internes.

Incidence potentielle

Si un système interne a été compromis, la prochaine étape probable pour un attaquant, une fois la persistance atteinte, serait d'identifier les autres systèmes du même réseau afin qu'ils puissent effectuer des mouvements latéraux, c'est-à-dire passer d'un système à un autre. Ils identifieront d'autres systèmes en effectuant des analyses à l'aide d'ARP, UDP, TCP ou ICMP pour voir quelles autres adresses IP sont utilisées et quels ports et services s'y exécutent, à la recherche d'un moyen d'accéder à la machine.

Échecs de connexion

Il existe trois raisons typiques pour lesquelles cette activité se produit :

1. Un utilisateur a régulièrement réinitialisé son mot de passe et a oublié son nouveau mot de

passe.

2. Un utilisateur a simplement oublié son mot de passe actuel et l'a mal saisi à plusieurs

reprises.

3. Un acteur malveillant tente d'obtenir un accès non autorisé à un compte utilisateur et a mal

deviné le mot de passe.

Heureusement, dans les domaines Windows Active Directory, nous pouvons obtenir des informations utiles auprès du contrôleur de domaine, ce qui nous permet de contextualiser les échecs de connexion. Dans l'événement d'échec de connexion, ID d'événement du journal de sécurité Windows

4625, se trouve un champ réservé aux « informations d'échec » qui contiendra l'un des codes suivants :

Ces codes nous fournissent des tonnes d'informations utiles, ce qui nous permet de comprendre pourquoi la connexion a réellement échoué. Par exemple, si nous avons reçu une alerte concernant plusieurs échecs de connexion et que nous avons vu le code d'état 0xC0000071, nous savons que la connexion a échoué car le mot de passe a expiré et doit être réinitialisé. Si nous avons reçu une autre alerte SIEM avec le code d'état 0xC0000064, cela signifie que quelqu'un essaie de se connecter avec un nom d'utilisateur qui n'existe pas réellement.

Détection

Dans un environnement Windows, nous pouvons surveiller l'ID d'événement 4625 du journal de sécurité Windows et définir des seuils pour détecter plusieurs échecs de connexion au contrôleur de domaine pour le même nom d'utilisateur. Les analystes seront alors en mesure d'enquêter en consultant le code d'état figurant dans le journal de sécurité et de prendre des mesures en fonction de l'activité d'alerte. Les attaques par pulvérisation de mots de passe peuvent également être détectées en surveillant un petit nombre d'échecs de connexion (2/3) pour un grand nombre d'utilisateurs sur une courte période.

Incidence potentielle

Les utilisateurs bloqués ne peuvent pas travailler, ce qui entraîne une baisse de productivité. En général, les utilisateurs appellent ou se rendent à leur centre de service informatique pour déverrouiller leur compte. Il ne s'agit donc pas d'un problème majeur et il est généralement résolu très rapidement. Toutefois, les échecs de connexion lorsque le nom d'utilisateur n'est pas reconnu (0xC0000064) ou que le compte est verrouillé en raison d'un trop grand nombre d'échecs de connexion (0xC00000234) peuvent être le signe qu'un attaquant tente d'accéder à des comptes

internes à l'aide d'une liste de mots de passe et de nom d'utilisateur, utilisant une attaque par dictionnaire, indiquant ainsi qu'un système interne a été compromis.