Vous êtes dans : Accueil > Tribunes libres >

Microsoft risque de faire grincer des dents quelques analystes SOC

Charles Blanc-Rolin, MARDI 20 FéVRIER 2024

Le travail d’analyste SOC consiste souvent à jongler entre alertes pertinentes, signaux faibles nécessitant de creuser et faux positifs. Si l’IA est au cœur de nombreuses discussions, plaquettes commerciales et articles en tout genre, cette tâche, parfois ingrate, d’analyse des alertes de sécurité reste toujours confiée à des êtres humains.

Pourquoi préférer un humain ? Pour son bon sens tout d’abord, si, si, je vous promet, il en reste encore, sa connaissance du contexte, bon l’IA pourrait peut-être tenter rivaliser ici, peut-être pas à 100 %, mais il y a aussi sa capacité à investiguer, communiquer (si si là aussi, je vous jure que c’est possible, pas chez tout le monde, mais c’est possible) et mettre face tous les éléments pour en tirer une conclusion : les alertes, le contexte, les résultats des investigations et les données collectées de par les échanges qu’ils ont pu avoir avec les équipes IT ou les utilisateurs, et là, l’IA n’a pas encore gagné le combat.

Ces alertes peuvent être de plusieurs formes et provenir de plusieurs sources. Analyse des fichiers (sur disque ou en mémoire), journaux d’évènements des postes, serveurs, équipements réseau, de sécurité… et analyses des flux réseau, qui, pour certains dispositifs, reste la seule source d’information pour détecter d’éventuelles menaces. Je pense notamment à tout les systèmes OT et biomédicaux sur lesquels il n’est pas possible d’installer un agent ou même venir collecter des logs.

L’analyse des flux réseaux est un domaine très, très, très vaste, et la capacité à créer des règles de détection est certainement plus grandes que celle à réaliser des attaques, à condition que ces attaques aient été analysées et que des règles de détection aient été écrites pour générer des alertes, nous sommes bien d’accord. Il faut garder en tête que tout évolue, les technologies, le contexte, les attaques etc, et les règles de détection nécessitent parfois d’être mise à jour elles aussi.

Parmi les règles les plus basiques que l’on peut observer dans le cadre de l’analyse des flux réseau, on retrouve notamment celles qui sont basées sur tout ce qui transite encore en clair via le protocole HTTP. Si vous pensiez que du fait que vous voyez un petit cadenas dans votre navigateur à chaque fois (ou presque) que vous consultez une page Web fait que tous les flux sont chiffrés aujourd’hui, vous vous trompez. On pourrait parler des requêtes OCSP qui permettent de voir passer le « user-agent HTTP » et par conséquent d’identifier plus ou moins précisément quel client établit la connexion.

Il y a également de nombreux logiciels et systèmes d’exploitation qui téléchargent toujours leurs mises à jour en HTTP, mais il a aussi de nombreux logiciels malveillants qui utilisent toujours ce protocole.
On pourrait citer l’exemple de Pikabot apparu il y a tout juste un an et qui, dans de nombreux cas observés se connecte dans la première phase de téléchargement via son loader, en HTTP à l’aide de l’utilitaire curl, directement à des adresses IP publiques, avec des chemins de téléchargement formatés de façon spécifique, pouvant être détectés via des expressions régulières.

Oui dans quelques cas il se connecte en HTTPS, mais on peut aussi le détecter à l’aide d’une empreinte JA3.
Revenons à HTTP. L’établissement d’une connexion HTTP à une machine présentée sur Internet via son adresse IP publique (sans utilisation d’un FQDN / nom de domaine pour faire court et approximatif) peut faire partie des signaux faibles intéressants à mettre de côté s’ils génèrent trop d’alertes sur un SI pour ne pas mériter une analyse directe.
Le téléchargement d’un exécutable en HTTP, en passant directement par une adresse IP publique pour atteindre le serveur, c’est aussi une règle susceptible d’intéresser les analystes. Vous vous demandiez sûrement à quel moment j’allais en venir à Microsoft, et bien c’est le moment (enfin !). Depuis le 13 février, date de publication du dernier patch tuesday de Microsoft, j’observe que Windows réalise le téléchargement de certaines mises à jour en utilisant directement l’adresse IP des serveurs pour s’y connecter. Pourquoi s’embêter avec des FQDN, c’est surfait… Il s’avère que ces adresses appartiennent à l’hébergeur StackPath, mais ce n’est pas une raison… On peut sous-traiter en créant des enregistrements DNS qui pointent chez son prestataire.
Pour tous ceux qui n’utilisent pas une solution de téléchargement des mises à jour centralisée telle que SCCM / WSUS ou qui ont des postes dont les mises à jour ne sont pas centralisées, la volumétrie d’alertes de ce type pourrait bien exploser...


Certains vont être ravis..

L'auteur

Chef de projet sécurité numérique en santé - GCS e-santé Pays de la Loire Charles Blanc-Rolin est également vice-président de l’APSSIS (Association pour la promotion de la Sécurité des Systèmes d'Information de Santé)

 

#sécurité#dsih#logiciels#microsoft