Connect the dots #5: "Command & Conquer"

Vous vous souvenez du jeu de stratégie "Command & Conquer" ?

(c) Electronic Arts

Il s'agit d'une lutte entre deux (ou plusieurs) équipes pour la domination d'un lieu virtuel. Les bleus, "blue team", c'est nous, les "gentils" et les rouges, "red team", ce sont les autres, les "méchants"...

C2 ou Command & Control: RED TEAM SERVER.

Lors de notre précédent article nous avons vu que les "rouges" ont réussi à contaminer une machine de notre infrastructure lors d'un accès initial. Mais comme son nom l'indique, cet accès initial n'est valable pour les attaquants que si on peut en tirer quelque chose, s'il y a une suite. Sinon, il s'agit d'un simple virus qui va infecter une seule machine. C'est alors qu'est né le concept de "C2" ou "C&C" qui veut dire en cybersécurité "Command and Control", par analogie avec notre jeu de stratégie.  Autrement dit, un serveur positionné quelque part sur Internet sera capable de discuter, de contrôler, la machine contaminée. Toutes les machines contaminées. Il peut y en avoir des milliers ou davantage qui seront toutes contrôlées par ce serveur. On appelle ces machines infectées par milliers un "botnet", tirés de la contraction de "robot" et de "network". Mais comment est-il possible que l'on ait pas repéré et bloqué tous ces serveurs au niveau mondial ? Parce qu'ils communiquent de manière furtive avec leurs cibles en utilisant des canaux autorisés par les défenseurs, comme par exemple le web ou le DNS.

Le concept qui a permis tout cela s'appelle le beaconing. Le balisage (beaconing en français) pratique des communications courtes et régulières depuis l'hôte infecté vers le C2 contrôlé par l'attaquant pour lui faire savoir que la cible est toujours infectée et qu'elle est prête à recevoir ses instructions. Cette "balise" ne fonctionne pas en continu: elle s'active toutes les 5 minutes, par exemple, pour vérifier que la cible répond. Dans certains cas, comme Stuxnet, le beacon s'activait une fois par jour pendant quelques secondes. D'où le nom de "balise" qui "clignote" de temps en temps. La cible contaminée est alors souvent appelée un "zombie" également, c'est à dire qu'elle ne maitrise plus ses actions, qui sont contrôlées en fait par l'entité externe, à savoir le C2. 

(c) Varonis

Les attaquants peuvent alors suivre l'attaque, de manière lente et furtive sur plusieurs jours, semaines, voire mois ou années... 

Mais le fait de devoir communiquer à l'extérieur du réseau de la cible entraine pour les attaquants la nécessité de disposer d'une infrastructure publique avec des adresses IP et des noms de domaines. On pourrait alors les géolocaliser une fois repérés par leur activité, s'ils ne prennent pas suffisamment de précautions avec leur C2. Lors du prochain article sur la post-exploitation, nous verrons comment les attaquants font pour éviter de se faire repérer.

En tous les cas, cette stratégie de beacon permet aux attaquants de gérer à distance toutes les machines qu'ils ont réussi à contaminer. Les infrastructures d'attaque sont donc beaucoup plus complexes qu'un simple ordinateur portable, comme on en voit dans certains films. Il existe souvent trois types de serveurs distribués C2, eux-mêmes bénéficiant de serveurs de "rebond" ou de serveurs proxy en "onion" (TOR): Il y a donc les serveurs de compromission initiaux, des serveurs "lents" pour se maintenir (dans le cas où l'activité serait repérée et bloquée) et des serveurs post-exploitation.

Ces serveurs ont différents objectifs: cartographier la cible, effectuer une post-exploitation en dialoguant avec les cibles contaminées , effectuer des mouvements latéraux (nous en parlerons également dans un prochain article) et se maintenir de manière persistante, d'où l'acronyme donné à ces attaques: APT (Advanced Persistent Threat).

Du coup trois rôles spécialisés se sont dégagés dans une "red team": L'accès initial et la cartographie de la cible, la post exploitation consistant à exfiltrer des données sensibles, des crédentités d'utilisateurs ou de lancer des ransomware pour bloquer l'activité de la cible et demander une rançon et enfin, les "shell sherpas" c'est à dire ceux qui administrent l'infrastructure notamment les beacons, les session de callbacks, la persistance de l'attaque dans la cible... 

La paramétrage et la préparation d'un C2 va consister alors à la fabrication des beacons, des redirecteurs et du camouflage, du fronting de domaine permettant le dialogue avec les beacons et, à la configuration des beacons eux-mêmes. Ces balises peuvent utiliser le protocole DNS (qui est ouvert lors d'une requête http ou https depuis l'intérieur vers l'extérieur). Il peut s'agir également d'utiliser les canaux SMB qui créent des liens entre machines à l'intérieur de la cible (notamment pour les mouvements latéraux ou pour ne pas se faire repérer avec toujours la même machine) ou de canaux TCP sur un port éphémère, voire d'accès distant comme RDP.

Que peut-on faire pour lutter contre un C2 ? La première chose à faire est de le repérer. Il faut donc analyser tous les flux réseau qui tentent de joindre un serveur, y compris de simples sites web. On doit analyser d'autres flux détournés de leur mission initiale comme DNS (port 53). Bien que les paquets DNS soient anodins et de petite taille par eux-mêmes et donc autorisés, que diriez vous d'une machine qui fait des milliers de requêtes DNS par minute ? Est-on sûr qu'il s'agit bien de requêtes DNS et non pas d'un fichier qui est découpé et transporté en plein de paquets par ce biais? La remède ici est de disposer d'une IA/ML (Intelligence Artificielle dédiée avec Machine Learning) qui va analyser tous les flux réseau. "A la mano" c'est pratiquement impossible de repérer cette activité. On va donc se concentrer sur un comportement potentiellement anormal sur le réseau sous forme d'inférence bayésienne avec un outil approprié. Les analystes de la blue team vont ensuite creuser ce comportement signalé par l'algorithme: Quelqu'un qui court en zigzag dans une foule est peut-être un voleur, mais c'est souvent quelqu'un qui est pressé et qui veut éviter de bousculer les gens... De nombreux faux positifs vont être écartés sans pour autant laisser passer la vraie attaque.

L'autre question que l'on peut se poser est pourquoi on ne scanne pas toutes nos machines pour retrouver le processus qui héberge le beacon ?  Parce qu'il est enfoui comme "enfant" dans un autre processus, qui lui est parfaitement autorisé sur la machine comme explorer.exe, notepad.exe, svchost.exe ou powershell.exe. Nous verrons cela plus en détail dans l'article sur la post-exploitation. N'oublions pas que les attaquants ont d'abord vérifié que le malware de contamination initiale n'était pas repérable par notre logiciel anti-virus. Il faut donc nous concentrer, d'une part sur le comportement de la machine en mémoire et d'autre part sur ses communications réseau. Si on arrive à bloquer intelligemment les processus et les flux malveillants sans pour autant paralyser ou gêner le travail de l'utilisateur, on aura gagné. Cependant, n'oublions pas que les attaquants utilisent des processus whitelistés d'une part et d'autre part des protocoles réseau autorisés en sortie par les firewalls  comme HTTP (port 80), HTTPS (port 443) et DNS (port 53). Si vous voulez que vos utilisateurs puissent travailler il ne faut pas leur bloquer leurs accès à internet, surtout en ce moment ! Se pose donc le problème du filtrage intelligent et de la protection des machines y compris en télétravail ou lorsque ces machines ne font pas partie du parc géré par l'entreprise, comme c'est parfois le cas à la maison. Nous parlerons du paradigme du "zero trust" dans l'article conclusif de cette série "Connect the dots" pour montrer que la seule parade efficace contre ces attaques réside dans le fait de ne plus faire confiance à quoi que ce soit par définition ! La notion de "réseau interne" ou "d'infrastructure interne" aura vécu. Il n'y a plus "d'intérieur" ou "d'extérieur": Nous vivons et travaillons dans un monde numérique global où chaque ordinateur de la planète est joignable et attaquable en moins d'un seconde... Y compris les ordinateurs -soi-disant- à l'intérieur de notre infrastructure.

Remédiations à mettre en place.

Voici donc les éléments qui vont nous permettre de détecter les beacons et le C2 associé avant que les attaquants ne passent à la phase de post-exploitation:

Intervalle de beacon: Y a-t-il une activité régulière vers un domaine précis toutes les 5 secondes (c'est le minimum), chaque minute (c'est le standard rapide), heures (standard lent), jours, semaines (extrêmement difficile à repérer) ?

La quantité de beacons transmis dans la même séquence: Notamment sur le protocole DNS qui ne transporte que peu de caractères (512), un nombre considérable de paquets est un signe distinctif d'activité malicieuse. Si on transporte une copie d'écran ou un fichier bureautique, ça peut générer beaucoup de trafic.

Persistance:  Est-ce que le beacon s'arrête de transmettre (la nuit par exemple, ce qui correspond à un humain) ou bien s'agit-il d'un bot qui transmet à intervalles très réguliers ? Est-ce que les horaires correspondent à une plage d'activité de bureau (en tenant compte du fuseau horaire) ou bien est-ce une activité à des heures anormales ? Le test de Turing permettra de séparer le "bot" de l'humain. 

Pour obtenir ces renseignements il faut impérativement que la blue team dispose d'un outil d'agrégation, de corrélation et de recherche de logs de tous les composants réseaux et systèmes, ce que l'on nomme avec l'acronyme SIEM: "Security Information and Event Management". 

(c) Cloud Security Alliance

Naturellement, il faut distinguer les flux licites, des flux liés aux communications entre les beacons et le C2 et les flux pertinents comme les ping de réseau ou les scan, pour voir si les machines sont alive, ou bien les gros fichiers de mise à jour ou métier. Une IA/ML va nous aider à extraire des alertes pertinentes à partir de scenarii typiques que le MITRE.ORG a modélisé dans son système MITRE ATT&CK: https://attack.mitre.org/#

(c) MITRE.ORG

Il y a en tout près de 150 techniques d'attaque principales identifiées et rien que 16 pour l'établissement d'un C2 ! 

Voici quelques exemples de signatures de C2 "classiques":

(c) MITRE.ORG

Lorsque la blue team va repérer un beacon cela permettra donc d'isoler la machine infectée et de l'examiner pour comprendre les mécanisme utilisés. Le plus tôt sera le mieux, car ensuite, si on ne s'en aperçoit de rien et qu'on laisse les beacons communiquer avec le C2, la post-exploitation va commencer avec son lot de ransomwares, de fuites de documents sensibles et de récupération de crédentités et des emails ou des droits d'administration associés.

On peut donc minimiser les dommages en mettant en quarantaine les machines infectées, en les nettoyant des processus suspectés et trouver des Indices de Compromission (IOC) de cette attaque précisément, que l'on va pouvoir ensuite diffuser à tous les systèmes défensifs, voire à des partenaires fournisseurs ou clients, ou même à un pays ou à la communauté internet tout entière. D'où l'intérêt des outils de threat intel que nous avons vus dans le premier article.

Domain fluxing.

Comme promis, je dois vous parler maintenant du domain fluxing (flux de domaines). C'est une technique inventée par les attaquants pour éviter de se "faire griller" le domaine qui contient le C2.  Il s'agit de noyer le nom de domaine des serveurs C2 qui discutent avec les systèmes contaminés parmi des centaines de domaines bidon.

Pour cela, on utilise un DGA (Domain Generation Algorithm) qui est en fait un génération aléatoire de noms de domaine. Un seul sera le domaine réel. La machine contaminée enverra des requêtes DNS par centaines à partir de la liste générée, jusqu'à atteindre le "bon" domaine, celui qui résout l'adresse IP du C2 !  

(c) hackersterminal.com

Le but de cette tactique est de rendre très difficiles les recherches du domaine réel lié au C2 pour le bloquer. De nombreux malwares comme Conficker ou Madmax ont utilisé le DGA pour créer la confusion chez les défenseurs.

En résumé de cet article sur les systèmes de Command & Control des attaquants, voici les principales parades à mettre en œuvre: Une blue team (un SOC - Security Operation Center) va s'équiper d'un SIEM pour agréger et analyser tous les évènements réseau et systèmes. Elle va repérer à l'aide d'outils spécialisés IA/ML les comportements "anormaux" des machines et des communications réseau. Ella va s'appuyer sur des scenarii d'attaque connus comme le MITRE ATT&CK pour distinguer les activités licites de celles illicites, typiques d'un C2. Mention spéciale pour le DNS et l'analyse de ses requêtes typiques du domain fluxing.

Le prochain article "Connect the dots" va décrire les activités de post-exploitation dans le cas où le C2 ne s'est pas fait repérer et bloquer.