Red Team : objectifs, méthodologie et déroulement d’une mission
·L’essentiel en bref
- Huit semaines de mission : le périmètre externe a tenu, et le domaine est tombé quand même
- L’entrée n’a pas été technique mais humaine et physique — une tenue, une lettre à en-tête, une salle de réunion et une prise réseau libre
- Une campagne de phishing ciblée a produit 260 identifiants valides, restitués de façon agrégée
- Une erreur de configuration de l’autorité de certification (ESC8) a suffi pour obtenir l’administrateur du domaine, le privilège le plus élevé d’un domaine Active Directory
- Aucune défense n’a déclenché d’alerte : le constat principal n’est pas une faille, c’est un défaut de visibilité
- En France, nous cadrons les vecteurs numériques et humains ; un scénario physique est étudié au cas par cas
Avons-nous besoin d’une mission Red Team ?
Imaginez une organisation de plusieurs milliers de collaborateurs, qui prend la sécurité au sérieux et qui investit régulièrement pour protéger ses personnes et ses systèmes. Une question restait pourtant sans réponse : que se passerait-il si un adversaire déterminé et organisé la prenait pour cible ?
Pendant huit semaines, notre Red Team a simulé exactement cela, sans les contraintes de périmètre d’un test d’intrusion classique. Nous avons mené une campagne de phishing depuis un domaine dédié (résultat : 260 identifiants valides), exploité la collecte de renseignement en sources ouvertes (OSINT), franchi les contrôles physiques par un prétexte, une carte d’accès clonée et un implant réseau, puis abusé d’une autorité de certification Active Directory mal configurée pour obtenir les droits d’administrateur du domaine.
Cette chaîne complète, du premier repérage jusqu’au contrôle de l’infrastructure, a mis au jour des faiblesses humaines, techniques et physiques que des tests menés séparément ne font pas apparaître : chacune paraît mineure isolément, et c’est leur enchaînement qui crée le risque.
Qu’est-ce qu’une Red Team, exactement ?
Une mission Red Team évalue la posture de sécurité d’une organisation dans son ensemble, de la frontière numérique jusqu’au comportement des personnes. Elle reproduit ce que ferait un attaquant motivé, ou une menace persistante avancée (APT), s’il choisissait votre organisation comme cible : sans se limiter à un périmètre étroit, sans se limiter à une technique, et avec le temps d’attendre.
C’est ce qui la distingue d’un test d’intrusion. Un pentest répond à la question « ce système est-il attaquable ? » ; une mission Red Team répond à une autre question : « verrions-nous passer une attaque réelle, et jusqu’où irait-elle avant que quelqu’un réagisse ? » Les deux exercices sont complémentaires, et l’ordre compte : une Red Team se justifie lorsque les tests d’intrusion ont déjà été menés et que les correctifs ont été appliqués. Si vous découvrez encore des vulnérabilités connues sur votre périmètre exposé, commencez par là — voir qu’est-ce qu’un test d’intrusion.
Ce récit est la version anonymisée d’une mission réellement conduite, publiée avec l’accord du client. Toutes les actions décrites ont eu lieu dans un périmètre convenu à l’avance, sur mandat écrit d’une personne ayant le pouvoir d’autoriser les tests, et selon des règles d’engagement formalisées. Sans ce mandat, les mêmes actes relèvent des articles 323-1 et suivants du code pénal, qui répriment l’accès et le maintien frauduleux dans un système de traitement automatisé de données. Dernière vérification : 11 septembre 2026.
Les phases de la mission
Nous consacrons beaucoup de temps à la préparation autant qu’à l’exécution, et nous suivons un ensemble de méthodologies Red Team destinées à identifier les vulnérabilités, à apprécier les risques et à vérifier l’efficacité réelle des mesures en place sur plusieurs domaines à la fois. La mission s’est découpée en phases distinctes mais liées :
- Collecte de renseignement en sources ouvertes (OSINT)
- Tests de l’infrastructure externe
- Tests d’intrusion internes selon deux scénarios
- Tentatives d’intrusion physique sur trois sites du client
- Campagne de phishing visant la majeure partie des effectifs
Le périmètre externe a tenu
Comme toujours sur une mission ciblée, nous commençons par les TESTS EXTERNES, c’est-à-dire tout ce qui est accessible depuis Internet. Nous avons examiné avec soin les applications web du client, ses passerelles VPN, ses serveurs de messagerie et l’ensemble de ses autres services, à la recherche de faiblesses, de logiciels obsolètes, d’erreurs de configuration ou de défauts de développement.
Le client s’est révélé bien préparé : ses serveurs étaient entièrement à jour, sans CVE connue exploitable. Le pare-feu était correctement paramétré et les systèmes IDS/IPS surveillaient activement le trafic, sans que nous trouvions d’ouverture. Nos tentatives sur le Wi-Fi ont échoué elles aussi, l’accès exigeant des certificats client et une authentification multifacteur.
C’est un résultat en soi, et il mérite d’être dit tel quel : la partie du travail qui se mesure avec un scanner avait été faite. La suite de la mission montre ce que cette mesure ne couvre pas.
L’OSINT a ensuite montré son importance. Après avoir mobilisé tous les moyens disponibles pour rassembler de l’information sur l’entreprise, nous disposions d’un organigramme, d’une liste de noms de collaborateurs, d’adresses IP, de sous-domaines, ainsi que de données sur les partenariats et les contrats. Peu de salariés affichaient leur appartenance à l’entreprise sur LinkedIn : le client encourageait visiblement la discrétion. Sa taille nous a malgré tout fourni assez de profils pour avancer. Nous avons croisé les données LinkedIn avec d’anciennes bases de données ayant fuité, puis vérifié les adresses de messagerie obtenues. Le moment décisif est venu d’un défaut dans un système interne, qui nous a révélé le format exact des adresses : prenom.nom@entreprise.com.
Nous avons ensuite cherché à franchir le PÉRIMÈTRE PHYSIQUE sur plusieurs sites du client. Lors d’une première visite, nous avons relevé les entrées, les déplacements des agents de sécurité, les angles morts des caméras et d’autres détails utiles. Un véhicule de contrôle des équipements de lutte contre l’incendie stationnait devant le bâtiment : ce serait notre voie d’accès. Après une courte préparation OSINT, nous nous sommes présentés en vérificateur d’extincteurs, avec la tenue complète, le logo de la société de contrôle et un papier à en-tête portant une autorisation écrite de procéder à l’inspection des extincteurs et d’accéder au bâtiment. Ce « technicien extincteurs » a obtenu un accès non accompagné à une salle de réunion, où nous avons repéré une prise RJ45 dissimulée derrière un écran de télévision. En quelques minutes, nous y avons installé un implant conçu par nos soins, doté d’une liaison 4G, nous l’avons camouflé et nous sommes repartis sans déclencher la moindre alarme — ce qui nous a donné un accès persistant et invisible au réseau interne, et préparé la phase suivante.
Nous disposions déjà d’un accès réseau, mais notre objectif restait d’obtenir des identifiants de domaine valides. À partir des adresses vérifiées pendant la phase OSINT, nous avons lancé une CAMPAGNE DE PHISHING très ciblée : pas d’envoi de masse, mais du typosquatting précis sur un domaine ressemblant. Présentée comme l’annonce d’un nouveau système interne de récompenses, la fausse page de connexion à l’intranet a capté des identifiants, après quoi nous avons immédiatement arrêté la campagne afin de limiter le risque de détection. Ces identifiants de domaine, tout juste obtenus, ont ouvert l’exploration interne et préparé la phase d’élévation de privilèges. Les résultats de la campagne n’ont été restitués que de façon agrégée : aucun collaborateur n’a été noté ni identifié individuellement.
Les TESTS INTERNES consistaient en une simulation de poste dérobé et en des tests du réseau interne. Nous y avons découvert une vulnérabilité ESC8 dans l’autorité de certification du client, qui permettait de demander n’importe quel certificat Active Directory, y compris celui du contrôleur de domaine. Après avoir confirmé le défaut avec l’outil Certipy, nous avons utilisé le module Coerce_Plus de Netexec pour contraindre le contrôleur de domaine à s’authentifier auprès de notre serveur de relais, puis nous avons capté et relayé cette authentification avec NTLMRelayX. L’autorité de certification a délivré un certificat de contrôleur de domaine, ce qui nous a conféré les droits d’administrateur du domaine — preuve qu’une défense solide reste contournable avec des tactiques précises. Être administrateur du domaine est le privilège le plus élevé qu’un attaquant puisse atteindre dans un domaine Active Directory : cela équivaut à une compromission complète de l’infrastructure, avec accès à l’ensemble des services et des données sensibles.
Résultats et enseignements
- IDENTIFIANTS COMPROMIS : une campagne de phishing de précision a produit 260 identifiants utilisateurs valides, révélant des faiblesses dans le filtrage de la messagerie comme dans la vigilance des collaborateurs.
- ACCÈS PHYSIQUE OBTENU : notre opérateur a franchi les contrôles de l’accueil et cloné des badges RFID sans être inquiété, ce qui a permis de placer du matériel à l’intérieur de zones sécurisées.
- ÉLÉVATION JUSQU’À L’ADMINISTRATEUR DU DOMAINE : en exploitant l’erreur de configuration de l’autorité de certification Active Directory (ESC8), nous avons fait délivrer un certificat de confiance et obtenu le contrôle administratif complet — sans être détectés.
- AUCUNE DÉTECTION PAR LES DÉFENSES : ni les contrôles périmétriques, ni les IDS/IPS, ni les systèmes de journalisation n’ont signalé nos activités, ce qui met en évidence des lacunes importantes de visibilité.
Ce dernier point est celui qui pèse le plus en comité de direction. Une vulnérabilité se corrige ; une absence de détection se construit, avec des sources de journaux, des règles, des personnes et des procédures. C’est aussi la raison d’être d’une mission Red Team : elle ne mesure pas l’état de vos correctifs, elle mesure votre capacité à voir et à réagir. La gestion des incidents figure d’ailleurs parmi les mesures que la directive (UE) 2022/2555 (NIS 2) demande aux entités qu’elle vise ; cette directive n’est pas transposée en droit français à ce jour.
Nos recommandations
- Renforcez la sécurité physique et les procédures visiteurs : dispositifs contre le passage en double (tailgating), contrôle strict des identités et des visiteurs.
- Auditez régulièrement chaque vecteur : périmètre exposé, systèmes internes, systèmes tiers, autorités de certification et infrastructure réseau.
- Sensibilisez vos collaborateurs au phishing et à l’ingénierie sociale : des exercices fondés sur des scénarios réels entretiennent la vigilance mieux qu’un message annuel.
- Surveillez en temps réel les équipements et l’activité internes : détectez immédiatement un matériel non autorisé et un comportement réseau anormal.
La cybersécurité ne se résume pas à la technique : c’est la combinaison des personnes, des processus et des outils. Tester, apprendre et construire la résilience dans la durée reste indispensable, car un attaquant cherchera toujours le maillon le plus faible. La protection réelle commence dans les réflexes et les attitudes de vos équipes.
Red Team en France : ce que nous cadrons, et ce que nous ne faisons pas
La mission décrite ci-dessus comportait un volet physique, réalisé hors de France. Pour le marché français, nous nous en tenons aux vecteurs numériques et humains : reconnaissance OSINT, attaque du périmètre exposé, phishing et prétexte téléphonique, propagation interne et élévation de privilèges. Un scénario impliquant l’accès à des locaux est cadré au cas par cas, avec vous et votre conseil, parce que le code pénal et le régime français des activités privées de sécurité (CNAPS) posent des questions propres qu’aucune clause de mandat ne règle à elle seule.
Deux autres points méritent d’être posés clairement, parce qu’ils reviennent dans chaque cadrage français :
Une campagne de phishing sur vos salariés traite des données à caractère personnel. Elle suppose donc une information préalable des personnes concernées, une consultation des instances représentatives du personnel lorsqu’elles existent, et des résultats strictement agrégés : pas de reporting nominatif, pas de sanction individuelle. Nous appliquons cette règle par défaut, y compris quand le client ne la demande pas. Le même cadre s’applique aux campagnes menées avec PhishGun, et il prolonge l’obligation de tester régulièrement l’efficacité des mesures de sécurité posée à l’article 32 du RGPD.
Une mission Red Team n’est pas un TLPT. Le règlement (UE) 2022/2554 (DORA) encadre les « tests de pénétration fondés sur la menace » (TLPT) applicables à certaines entités financières et fixe des critères propres aux prestataires qui les réalisent, dans le cadre TIBER-EU décliné en France avec la Banque de France. C’est un régime distinct, avec ses propres exigences d’accréditation : nous ne le délivrons pas et nous ne prétendons pas le délivrer. Une Red Team contractuelle comme celle décrite ici répond à un besoin d’évaluation, pas à une obligation réglementaire sectorielle.
Enfin, sur le traitement des données : Haxoris est un prestataire européen. Les preuves collectées pendant la mission, les captures et le rapport restent dans l’Union européenne, avec une durée de conservation convenue au contrat et une suppression à l’échéance.
Questions fréquentes
Combien de temps dure une mission Red Team ? Celle-ci a duré huit semaines. La durée dépend du nombre de scénarios retenus, du nombre de sites et des objectifs fixés ; elle se fixe au cadrage, pas avant.
Red Team ou test d’intrusion : par quoi commencer ? Par le test d’intrusion, dans la plupart des cas. Il vous dit ce qui est vulnérable sur un périmètre donné. La Red Team vient ensuite : elle vous dit si vous verriez quelqu’un l’exploiter. Le budget suit la même logique — voir combien coûte un test d’intrusion.
Vos équipes de défense sont-elles prévenues ? Non, c’est le principe de l’exercice. Seul un cercle restreint de personnes autorisées connaît la mission, afin de pouvoir l’interrompre à tout moment. C’est ce cercle qui détient le contact d’urgence et les règles d’engagement.
Les collaborateurs sont-ils évalués individuellement ? Non. Les résultats d’ingénierie sociale sont restitués de façon agrégée. La mission mesure l’organisation, pas la personne qui a cliqué — voir qu’est-ce que l’ingénierie sociale.
Que recevez-vous à la fin ? Un rapport en français retraçant la chaîne d’attaque, les preuves et les recommandations priorisées, une restitution en visioconférence avec vos équipes techniques et votre direction, puis un contre-audit pour vérifier les correctifs.
Vous voulez savoir jusqu’où irait un attaquant chez vous ? Parlons du périmètre et des scénarios : demandez un devis, ou découvrez comment nous testons votre infrastructure réseau et comment nous organisons la sensibilisation de vos collaborateurs.
