Mon trafic est chiffré, un NDR ne verra rien … On parie ?

Depuis 2018, nous constatons une évolution marquée du chiffrement des flux réseaux sur Windows, Android, Chrome, Linux, ou Mac, supposant ainsi la fin de l’analyse réseau.

Cette fin semblait en effet se dessiner avec notamment l’arrivée de la dernière version de chiffrement TLS 1.3, comme l’annonçaient de nombreux experts. Pourtant, la réalité fut tout autre. Cette version de chiffrement est venue s’ajouter aux nombreux protocoles de chiffrement existants comme HTTPS, DNS, VoIP etc., et a renforcé la banque d’outils de chiffrement disponible, sans pour autant mettre fin aux enjeux de l’analyse réseau.

Par conséquent, avec le renforcement de ce processus de chiffrement, existe-t-il une réelle nécessité de déchiffrer le trafic réseau pour détecter les attaques ?

Pour pouvoir trancher ce débat, revenons sur le besoin concret au sein du monde de l’entreprise qui diffère de celui du monde privé. L’enjeu du chiffrement pour les particuliers réside dans la garantie de la confidentialité de ses activités. Celle-ci se traduit par le maintien de sa navigation privée par exemple, ou encore par la sécurisation de ses données lors d’un achat sur internet. A contrario, une entreprise exprime, quant à elle, un besoin diamétralement opposé puisque le chiffrement n’est pas une option. L’entreprise doit garder un contrôle sur l’ensemble des activités au sein de son réseau. Elle utilisera ainsi des protocoles totalement différents de ceux de la sphère privée, où le DoH est interdit et les requêtes DNS sont surveillées, pour par exemple contrôler et stocker son historique. De plus, avec l’évolution des normes et des lois en vigueur, le besoin de contrôler l’activité réseau grandit de plus en plus au sein des entreprises.

A partir de ce constat, nous pouvons déduire qu’il n’est pas forcément essentiel de déchiffrer le trafic réseau, même si cela serait préférable dans une perspective de détection. Toutefois, il faut garder en tête que le déchiffrement prend des formes différentes en fonction du secteur auquel il s’applique (privé/professionnel). De plus, l’approche dans le déchiffrement et l’analyse d’informations ne sera pas la même et dépendra des capacités des protocoles utilisés.

Sommes-nous alors capables de tout déchiffrer ? Il existe, en effet, un grand nombre de technologies qui participent au déchiffrement comme le Network Packet Broker (NPB) ; TAP SSL ; Agent / EDR ; WAF ; Load Balancer ; FirewallProxy …

Toutefois, chacune d’entre elles dispose de ses spécificités et d’une efficacité variable en fonction des milieux au sein desquels elles interviennent respectivement. Par exemple, le Proxy va intercepter certaines requêtes mais, dans certains cas, ne va pas les déchiffrer car TLS 1.3 sera présent. Tout dépend de l’endroit où il va être positionné.

Quel que soit les technologies utilisées, il n’y a aucune garantie que 100% du contenu soit entièrement déchiffré, d’autant plus que certains éditeurs utilisent des techniques qui empêchent l’interception de certificats. Même dans un monde idéal où tout serait déchiffrable, si une attaque d’ampleur se produit, cela n’aurait que peu d’impact sur sa remédiation car le contenu de la donnée (payload) resterait chiffré

En outre, le chiffrement des données n’est pas forcément bloquant car il existe aujourd’hui d’autres ressources que nous pouvons utiliser pour analyser le réseau et détecter les attaques sans pour autant que le contenu soit totalement déchiffré.

Une autre variable est également à prendre en compte dans un protocole de déchiffrement : la métadonnée. Mais concrètement, de quoi parle-t-on ? en quoi change-t-elle la donne en matière de détection ?

Sur un flux chiffré, la métadonnée correspond à l’ensemble des informations qui vont être échangées, sans pour autant rendre le payload accessible. Elle permet d’assurer le bon fonctionnement d’algorithmes d’analyses statistiques et de Machine Learning, en quête de données supplémentaires pour perfectionner son analyse.

Imaginons-nous dans le « Bureau des Légendes ». Au sein d’un service de renseignement, on souhaite écouter les appels téléphoniques entre plusieurs personnes. Toutefois, ce groupe utilise un contenu chiffré empêchant les services de comprendre ce qu’il se dit. Or les en-têtes et les métadonnées nous donnent déjà un certain nombre d’informations sans pour autant détenir le payload. Parmi ces informations, il est possible de connaître :

-Le nom d’utilisateur, et donc les identités des potentiels interlocuteurs du groupe
-Le nombre d’utilisateur
-Les pics d’appels rapprochés et leur nombre
-La durée des appels
-La volumétrie des données échangées

Certes, on perd en données mais en échange on gagne en métadonnées, reliée à la Threat intelligence. En étudiant les statistiques et la probabilité temporelle des pics d’appels à l’aide du Machine Learning et de l’intelligence artificielle, nous pouvons ainsi récupérer des informations essentielles quant aux échanges des parties prenantes.

Très riches en informations, les métadonnées sont parfaitement adaptées pour l’investigation et l’analyse des flux réseaux.

Dans la détection des attaques ciblées de type APT, le principal enjeu est de détecter la structure utilisée. Mais gare aux faux positifs ! Disposer d’un outil effectuant ces tâches de manière automatique marquerait une réelle évolution dans la capacité à détecter des menaces ciblées. Mais à ce stade, seule l’analyse humaine, très coûteuse en temps et en ressources, est capable d’identifier les faux positifs.

L’usage de serveurs C&C (Command & Control) se développent aujourd’hui de plus en plus et représentent l’une des typologies d’attaques les plus dommageables, notamment avec l’utilisation des frameworks Cobalt Strike ou Brute Ratel. L’attaquant commence par infecter un ordinateur via un courriel de phishing, via des failles de sécurité dans les plugins de navigateur déjà présentes ou par des logiciels infectés précédemment etc. L’attaquant imite le trafic légitime (en modifiant les en-têtes TLS) afin de se cacher des différentes capacités de détection actuelles, et exécute par la suite les commandes du serveur de C&C. Il peut ainsi installer des logiciels supplémentaires, user de l’obfuscation [1], ou encore chiffrer et surchiffrer des données échangées. L’attaquant a maintenant le contrôle total de l’ordinateur de la victime et peut exécuter n’importe quel code malveillant susceptible de se propager généralement à d’autres ordinateurs. De cette façon, un cybercriminel peut obtenir le contrôle total du réseau de l’entreprise.

Nouveau moteur de détection de Gatewatcher, Beacon Hunter analyse les métadonnées pour détecter des distributions statistiques spécifiques

Il identifie les connexions aux C&C même avec du chiffrement et de l’obfuscation, et détecte l’exécution des commandes afin d’anticiper ce qu’il va se passer, toujours sans nécessiter un accès au payload.

Il détecte les nouvelles connexions périodiques suspicieuses et les aléas pouvant être déposés par l’attaquant. Concrètement, plutôt que de se connecter toutes les 60 secondes, ce dernier connectera toutes les 10 à 20 secondes et créera un rythme différent de communication pour être moins détectable sur le réseau. Une analyse humaine simple ne suffit plus. C’est là où l’intégration du moteur Beacon Hunter à notre plateforme NDR prend tout son sens car il est désormais possible d’avoir une vision globale des connexions périodiques (ou non) au sein du réseau.

Grâce à Beacon Hunter, il est désormais possible d’avoir une vision globale des connexions périodiques (ou non) au sein du réseau.

Quel que soit la configuration, les options activées (obfuscation, chiffrement), les versions existantes et futures de Cobalt Strike et Brute Ratel, grâce à Beacon Hunter et AIONIQ, Gatewatcher sera toujours capable de détecter les menaces sans générer de faux positifs. Beacon Hunter et AIONIQ représentent ainsi la solution la plus efficace adaptée à n’importe quel type de contexte, aussi bien de grands comptes que de PME, pour détecter les cybermenaces sur le réseau.

[1] Essayer d’échapper à des méthodes statistiques en jouant sur l’aléatoire ex : ajout de données aléatoires pour éviter certains outils présents sur le Endpoint par exemple