Introduction aux missions RedTeam

Nous intervenons régulièrement sur des missions dites de "Red Team". Ce type d'audit s'adresse aux entreprises ayant déjà une bonne maturité en termes de sécurité de leur système d'information et de leurs pratiques organisationnelles. Le but est alors pour les auditeurs de se glisser dans la peau d'un attaquant qui, sans informations préalables sur le SI, va devoir infiltrer celui-ci sans être détecté par l'équipe de défense et obtenir des "trophées", définis au préalable. Ces trophées peuvent être de différente nature : accès aux partages de fichiers, accès à une salle ou un bâtiment, à des informations confidentielles, à des comptes d'utilisateurs, etc. Les "Red Team" empruntent des techniques à différents types d'audit : audit externe, phishing, audit interne, audit web, ... dans le but de remplir les objectifs fixés. Il s'agit donc du type de scénario le plus proche de ce qu'il pourrait se passer si votre système d'information était la cible d'un attaquant. Dans cet article, nous allons voir comment se déroule une mission Red Team et revenir sur un exemple d'exercice que nous avons effectué chez l'un de nos clients.

Comment se déroule un audit Red Team ? - La théorie

Poser le cadre

Un Red Team doit s'effectuer silencieusement : le but de l'auditeur est de ne pas se faire remarquer par l'équipe informatique ou le SOC au cours de ses opérations. La communication entre les équipes d'attaque et de défense est plus restreinte que pour un audit classique. Par ailleurs, le périmètre est extrêmement vaste car il correspond souvent à toute la surface d'attaque exposée par l'entreprise cible. Il est donc nécessaire, dans un premier temps et pour éviter toute mauvaise surprise à l'auditeur comme à l'audité, de poser un cadre précis à l'exercice. Les questions suivantes sont notamment considérées :

• les contacts d'urgence : qui doit-on prévenir en cas de découverte d'une faille critique, d'un problème technique, d'une interception au cours d'une intrusion physique, etc. ?

• le périmètre : quels sont les serveurs, bâtiments, sites web, domaines, etc. pouvant être audités ? De même, lesquels ne sont pas compris dans le scope et ne doivent pas être touchés ?

• les objectifs de l'exercice : quels sont les trophées à récupérer et les scénarios envisagés, la conduite à adopter en cas de repérage par un employé ?

• les actions autorisées ou non, par exemple : les attaques par ingénierie sociale, l'intrusion physique sont-elles autorisées ?

• les prérequis : quel est le point de départ des auditeurs ?

• quelle sera la durée de l'audit et quand aura-t-il lieu ?

Toutes ces informations vont aussi servir de cadre juridique à la prestation et permettre aux auditeurs et audités de partir sur une base claire des actions qui vont être ou ne pas être menées. Comme pour tout audit de sécurité, le but n'est pas de mettre en danger l'infrastructure ou de réaliser des attaques pouvant compromettre l'intégrité des données. Le pentesteur ne teste pas d'attaque pouvant avoir un impact négatif sur le périmètre : c'est ainsi qu'il se différencie d'un attaquant.

La phase de reconnaissance

Une fois les bases posées, l'auditeur commence le travail par une phase de reconnaissance du périmètre. Suivant le temps alloué à la mission, la phase de reconnaissance va être plus ou moins longue : plus il y a de temps, plus les chances de réussite augmentent.

La recherche en sources ouvertes ou OSINT permet de prendre connaissance de la cible et de récupérer des informations qui seront ensuite très utiles pour mener une attaque par ingénierie sociale (phishing, vishing, etc.) ou une intrusion physique. Cela peut aussi permettre de récupérer des données ayant fuité sur Internet, telles que des mots de passe pouvant être réutilisés pour se connecter au réseau interne ou des documents confidentiels. Les informations fournies sur les réseaux sociaux, notamment LinkedIn, peuvent permettre d'établir une liste des employés et donnent aussi des informations sur les évènements en cours, les recrutements, etc.

Si une intrusion physique est envisagée, la phase de reconnaissance va aussi passer par une observation des bâtiments, caméras de surveillance, portiques de sécurité et autres dispositifs. L'objectif est aussi bien d'observer les protections de sécurité mises en place que d'établir une liste d'informations pouvant servir ultérieurement. Il n'y a pas d'attaque ou d'intrusion au cours de cette étape : tout se fait de manière passive et les informations obtenues sont toutes accessibles publiquement.

Trouver un point d'entrée

Les informations récoltées vont être utilisées pour obtenir un point d'entrée sur l'infrastructure auditée. Au cours de cette étape, les actions menées deviennent actives : des interactions avec les serveurs et attaques sont effectuées sur le SI. Dans un premier temps, l'auditeur peut tenter de réutiliser les mots de passe récupérés au cours de la phase précédente pour se connecter aux différents portails exposés sur Internet. Il va aussi réaliser une série de tests s'approchant de ceux qui peuvent être effectués lors des audits externes dans le but de trouver une faille de sécurité exploitable permettant d'arriver sur le réseau interne de l'entreprise.

Il est aussi envisageable, lors de cette étape, de réaliser une campagne de phishing pour obtenir les identifiants d'utilisateurs ayant des accès privilégiés. Lors des recherches en sources ouvertes, l'auditeur a pu créer une liste d'employés ayant des postes et accès stratégiques ainsi qu'obtenir des informations lui permettant d'établir un prétexte. En ingénierie sociale, le prétexte désigne le scénario et/ou l'identité endossée par l'attaquant pour influencer sa cible et l'amener à réaliser une action particulière : donner une information, entrer ses identifiants, acheter un produit, ouvrir un fichier malveillant, etc. Ce prétexte peut être construit sur des informations diverses comme la liste des prestataires, les évènements en cours, la marque des équipements, le nom du responsable informatique, etc. L'auditeur va alors construire un email de spear phishing (ou hameçonnage ciblé en français) adressé spécifiquement à sa cible, dans le but de récupérer ses identifiants ou exécuter du code sur sa machine. Si les recherches préalables ont montré que le mécanisme d'authentification à double facteur était activé, il est possible de pousser l'attaque un peu plus loin pour arriver à contourner la 2FA.

L'intrusion physique dans les locaux de l'entreprise peut aussi être un bon moyen d'obtenir un accès au réseau interne. Ici aussi, l'auditeur va utiliser un prétexte et différentes techniques d'ingénierie sociale pour entrer dans les locaux. Une fois à l'intérieur, différentes approches peuvent être envisageables. L'auditeur peut, par exemple, rechercher des postes déverrouillés pour brancher une clef USB agissant comme un clavier, qui va exécuter un bout de code permettant d'ouvrir un accès sur la machine. Une autre solution est de chercher à placer un implant réseau : un nano-ordinateur tel qu’un Raspberry Pi ou similaire que l'on branche sur une prise réseau et sur lequel pourra se connecter, à distance, l'auditeur. A noter que, suivant les objectifs définis en amont, l'intrusion physique à elle seule peut aussi représenter un trophée.

La phase d'exploration

Une fois un pied dans le réseau, il faut maintenant se déplacer sur ce dernier pour obtenir les trophées et remplir les objectifs de l'audit. Cette phase va donc être grandement variable en fonction de ce qui est attendu. Obtenir un accès au réseau interne peut parfois être l'objectif final, mais dans certains cas il faut aller plus loin pour obtenir des éléments spécifiques. Les étapes déroulées durant cette phase peuvent s'apparenter à celles d'un audit interne : l'auditeur recherche des failles et des défauts de configuration qui lui permettront d'élever ses privilèges, se déplacer sur d'autres machines du réseau ou accéder à des informations confidentielles.

Si certains objectifs concernent une intrusion physique dans un lieu particulier, l'auditeur va jouer sur les différentes techniques d'influence et prétextes lui permettant d'atteindre son objectif. Un travail d'ingénierie sociale poussé s'étalant sur une longue période de temps est souvent nécessaire !

Et après ?

Une fois que les trophées ont été obtenus ou que l'auditeur a été efficacement détecté et bloqué par les collaborateurs, c'est le moment pour l'auditeur de sortir du schéma de pensée "attaquant" pour se focaliser sur l'amélioration de la sécurité, ce qui est l'objectif final de l'exercice.

Dans un premier temps, les résultats de l'audit vont être analysés et quantifiés en fonction des objectifs, de la maturité de l'entreprise et du niveau de sécurité attendu pour donner un ordre d'idée du niveau de sécurité actuel. Cette analyse sera contenue dans un rapport avec le détail de tous les défauts identifiés et des recommandations à implémenter pour consolider les protections existantes et offrir un meilleur niveau de sécurité.

Par la suite, plusieurs sessions de sensibilisation peuvent être organisées pour renforcer la sécurité du facteur humain qui est bien souvent le maillon le plus faible. Le but est de rappeler les bonnes pratiques générales ainsi que d'insister sur les points identifiés comme critiques au cours de l'audit. Le contenu des sessions peut varier suivant le public visé : administrateurs, postes à responsabilités, RH, développeurs, etc. Les problématiques et l'exposition rencontrées par chaque corps de métier sont souvent différentes.

Et en pratique ça donne quoi ? - Retour d'expérience sur une opération Red Team

Prenons maintenant un exemple concret : l'exercice Red Team que nous avons mené récemment chez l'un de nos clients. L'audit peut être découpé en différentes étapes :

Cadre et objectifs

Dans un premier temps, le scope défini pour l'audit était la totalité du périmètre exposé sur Internet par l'entreprise. Nous devions aussi réaliser une campagne de phishing ainsi qu'un test d'intrusion physique sur l'un des sites. Le but était d'obtenir un accès depuis une situation de boite noire : en partant de l'externe et sans informations de départ, nous devions nous infiltrer sur le réseau de l'entreprise et voir à quel type de données nous pouvions accéder facilement.

Un audit interne était prévu par la suite pour examiner en détail la sécurité du réseau. Nous devions donc trouver un maximum de points d'entrée donnant un accès stable, sans être repérés par l'équipe informatique. La durée prévue pour réaliser l'audit était de 1 mois, au cours de laquelle est intervenue une équipe de deux consultants.

Phase d'OSINT

Au cours de la phase d'investigation, nous avons recherché plusieurs types d'information aussi bien sur l'infrastructure technique que sur la vie en entreprise. Dans un premier temps, différentes recherches et scans passifs nous ont permis d'obtenir des informations sur les équipements et logiciels exposés sur l'externe : pares-feux, sites web, etc. Globalement, peu de machines semblaient ouvertes sur l'externe ce qui est une bonne pratique de sécurité mais un équipement industriel semblait toutefois être exposé sur internet ce qui peut être critique.

Par ailleurs, à l'aide de LinkedIn, réseau social sur lequel sont enregistrés la plupart des employés, nous avons créé une liste des collaborateurs, leur poste et le site géographique sur lequel ils interviennent. Hunter.io nous a aidé à trouver le format utilisé pour les adresses mail, permettant de créer une liste d'adresses valides pour la société.

Nous avons ensuite recherché des fuites de mot de passe sur Internet et avons établi une liste d'identifiants que nous pourrons réutiliser. Ces fuites peuvent être anciennes: il n'y a aucune garantie que les mots de passe relevés soient encore utilisés, mais certains peuvent nous donner une indication sur la forme de la politique de mot de passe implémentée.

D'autres informations ont aussi été relevées : participation à des évènements récents ou à venir, actualités, technologies utilisées et potentiels prestataires.

Audit externe et web

Une fois la reconnaissance effectuée, nous nous sommes attaqués aux équipements exposés sur Internet en essayant de rester le plus discret possible. Dans un premier temps, il s'agissait de confirmer les résultats que nous avons pu observer précédemment en lançant des scans actifs sur l'infrastructure.

Pour rester silencieux, nous avons réduit le nombre de paquets envoyés au serveur ainsi que porté une grande attention aux options et outils que nous avons utilisé : la réalisation d'audits Red Team demande une excellente connaissance des logiciels utilisés et leur fonctionnement en détail. Comme constaté précédemment, seuls les pares-feux étaient exposés, et seulement les ports nécessaires étaient ouverts. Les composants logiciels utilisés étaient à jour et ne présentaient pas de vulnérabilités connues. Le PLC n'était pas exposé sur Internet, contrairement à ce que la reconnaissance passive avait remonté. Nous avons donc tourné notre attention vers les sites Internet exposés par l'entreprise.

Plusieurs pages présentant des formulaires d'authentifications étaient exposées, mais des protections étaient activées empêchant les attaques par bruteforce. De plus, ce type d'attaque est facilement détectable. Nous n'avons pas constaté de divulgation d'informations ou de défaut de configuration sur les sites. Les mots de passe retrouvés sur Internet n'étaient plus d'actualité et nous ne pouvions pas les utiliser pour nous connecter.

Réseau industriel

La sécurité en place sur l'infrastructure exposée sur Internet était donc solide et nous n'avons pas réussi à obtenir de point d'entrée de cette façon. Cependant, au cours du temps dévolu à la mission, nous avons mené des scans réseau ponctuels et avons constaté que l'équipement industriel était exposé par instants sur Internet.

Le serveur concerné exposait le port ModBus utilisé pour administrer le réseau industriel à distance à travers un dispositif appelé PLC. La spécificité du protocole ModBus est qu'il n'est pas sécurisé par défaut : il n'y a pas de chiffrement ni d'authentification. Nous avons alors pu réaliser une prise d'empreinte sur cet équipement et récupérer sa version : le PLC utilisait une version ancienne et vulnérable à une attaque nous permettant de réécrire les instructions qui lui sont données. Ce type d'équipement étant très sensible et un dysfonctionnement pouvant entrainer un danger physique pour les opérateurs, nous avons prévenu notre contact pour lui signaler l'exposition et décider avec lui de la conduite à tenir.

Sous contrôle de notre contact, nous avons entrepris de lister le contenu des registres, nous donnant des valeurs spécifiques au fonctionnement de l'équipement. Nous n'avons pas été jusqu'à la modification de ces données pour ne pas impacter la production et mettre en danger les équipes. Une fois la vulnérabilité vérifiée, les équipes de sécurité ont entrepris d'isoler le composant pour bloquer son exposition sur Internet.

Phishing

Grâce aux informations obtenues au cours de la phase de recherches en sources ouvertes, nous avons pu établir une liste des employés ainsi que leur poste et le site auquel ils étaient rattachés. Parmi la liste d'adresses recensées, nous avons sélectionné deux échantillons d'une douzaine de mails appartenant à des personnes de corps de métier différent et intervenant sur des sites distincts. Cela dans le but d'effectuer une campagne discrète tout en testant un maximum de cas possibles.

Pour appuyer la crédibilité de l'email de phishing et gagner en efficacité, nous avons choisi de nous reposer sur deux des 6 principes d'influence définis par Robert Cialdini : l'autorité et la sympathie, en usurpant l'identité du responsable informatique. En effet, les utilisateurs ciblés seront plus en confiance pour effectuer l'action demandée (cliquer sur un lien) si la demande semble provenir d'une personne connue avec qui les échanges sont courants (principe de sympathie) et s'il s'agit d'une figure d'autorité concernant le sujet traité.

Le prétexte utilisé a été le suivant : une erreur de mise à jour des services Microsoft aurait bloqué certains comptes. L'utilisateur était prié de bien vouloir se connecter sur le portail Microsoft fictif de l'entreprise en cliquant sur le lien fourni dans l'email. Pour l'occasion, une adresse email et un domaine imitant celui de l'entreprise avait été réservé.

Aucun mécanisme d'authentification multi facteur n'était activé sur le portail Microsoft, nous n'avons donc pas eu à mettre en place de mécanisme de contournement de la double authentification.

Ces emails de phishing nous ont permis de récupérer les identifiants associés à plusieurs comptes possédant des niveaux d'accès différents.

Phase d'exploration

Une fois des identifiants obtenus via la campagne de phishing, nous avons pu nous connecter au VPN de l'entreprise ainsi qu'aux comptes Microsoft. Cela nous a donné accès aux emails et documents contenus sur le SharePoint pouvant exposer des informations sensibles. Via le VPN, nous avons pu obtenir un accès RDP sur la machine de deux employés. Nous avons commencé l'exploration avec l'un des deux comptes et avons récupéré des informations sensibles en parcourant les partages réseau : mots de passes contenus dans un fichier, factures, noms de prestataires, données personnelles et médicales, etc.

Cependant, peu après la campagne de phishing, l'employé a signalé l'email au service informatique qui a forcé le changement de mot de passe : nous avons alors perdu accès à ce compte. Les identifiants n'ont toutefois pas été changées pour le second compte avec accès RDP à notre disposition : sa compromission n'a pas été détectée.

Intrusion physique

La dernière étape prévue au cours de cet audit était l'intrusion physique. Nous devions utiliser les informations obtenues au cours de la phase de reconnaissance pour entrer dans les locaux de l'un des sites et poser un implant réseau. Pour cela, nous avons choisi de nous faire passer pour un prestataire gérant les imprimantes de la société. En amont de l'intrusion, nous avons préparé le matériel nécessaire : faux badges, carnets d'intervention, faux mail provenant du responsable informatique de la société nous demandant d'intervenir, etc. Nous avons emporté divers sacs d'intervention contenant du matériel réseau, clefs USB malveillantes, ainsi que l'implant que nous devions poser.

Le jour de l'intervention, nous avons commencé par réaliser un audit du réseau wifi depuis les abords du bâtiment. Le protocole utilisé n'était pas le plus sécurisé mais nous n'avons pas réussi à nous connecter sans informations préalables. Néamoins, en utilisant un compte utilisateur récupéré au cours de la campagne de phishing, nous avons pu nous connecter et accéder au réseau interne depuis n'importe quel appareil mobile.

Par la suite, nous sommes entrés dans les locaux et avons présenté notre prétexte à l'employé à l'accueil. Cette personne a alors eu de très bons réflexes : malgré les preuves que nous lui présentions et les techniques d'influence utilisées, elle nous refusait l'entrée, car l'intervention sortait du protocole habituel. Elle souhaitait contacter le commanditaire par téléphone avant de nous donner le feu vert, pour s'assurer que cela était bien prévu. En effet, en temps normal, elle recevait une notification par mail quelques jours avant l'intervention, ce qui n'avait pas eu lieu ici. Le responsable n'a pas répondu à ces appels et malgré plusieurs tentatives, nous n'avons pas réussi à entrer dans les locaux.

Fin d'audit

Nous sommes revenus sur le site concerné après la fin de l'audit pour féliciter l'employé à l'accueil pour ses bons réflexes et l'inciter à rester vigilant. Une session de sensibilisation a été organisée pour tous les collaborateurs ayant des accès privilégiés et ceux ayant été piégés par la campagne de phishing. Des recommandations techniques ont été fournies dans un rapport pour pallier aux défauts de configuration et vulnérabilités identifiées. Dans ce rapport, nous avons aussi détaillé tous les scénarii que nous avions identifiés et qui aurait permis à un attaquant d'obtenir un accès au réseau. Cela donne aux équipes informatiques une vision claire des risques encourus et des actions à prioriser pour renforcer la sécurité du SI.

Conclusion

Les audits Red Team permettent d'évaluer de manière approfondie le niveau de sécurité d'un système d'information en le confrontant à des attaques réalistes. Le but est aussi d'observer la réponse des équipements informatiques et des équipes de sécurité de même que celle de tous les collaborateurs. S'adressant à des entreprises ayant déjà un bon niveau de maturité SSI, ils permettent d'élever le niveau de sécurité un cran plus haut en adressant des défauts de sécurité qui ne sont pas toujours pris en compte au cours d'audits plus classiques. Chaque infrastructure et chaque entreprise étant différente, les audits Red Team ont aussi la particularité d'être très flexibles et peuvent s'adapter à tous les contextes. N'hésitez pas à nous contacter si ce type d'audit vous intéresse pour que nous réfléchissions ensemble aux solutions les plus adaptées !