Quand on parle de Red Team, on pense souvent au scénario final : un phishing réussi, un implant actif sur le poste d’un utilisateur ou encore un mouvement latéral jusqu’au contrôleur de domaine.
Mais avant d’en arriver là, un travail moins visible est déterminant pour la réussite de l’exercice : construire l’infrastructure qui va porter l’opération de bout en bout.
Une infrastructure mal protégée peut compromettre rapidement l’opération. Si le SOC du client identifie et bloque l’adresse IP du serveur de commande et contrôle (Command and Control, ou C2), l’implant peut perdre tout contact avec son opérateur.
À l’inverse, une infrastructure bien construite permet de maintenir une opération réaliste et de confronter les défenses du client à des conditions proches de celles rencontrées face à un attaquant motivé et outillé.
Dans cet article, nous détaillons comment nous construisons ce type d’infrastructure lors d’une mission Red Team. Nous présentons le rôle de chaque composant et la manière dont l’ensemble s’articule, du poste de la victime jusqu’au serveur C2.
Infrastructure Red Team : pourquoi une infrastructure « à nu » ne tient pas
Le point de départ est simple. Sans protection, l'implant posé sur la machine de la victime communique directement avec le serveur C2.
Sans intermédiaire, l’adresse IP réelle du serveur C2 est directement exposée à la victime et à son SOC.
Concrètement, l’adresse IP réelle de l’infrastructure Red Team peut apparaître dans les logs réseau de la victime, les règles de pare-feu ou les alertes de l’EDR.
Face à un SOC réactif, cette adresse IP peut être identifiée en quelques minutes. Une fois blacklistée, l’implant perd tout contact avec son opérateur et la mission peut s’arrêter avant d’avoir atteint son objectif.
Il faut donc un intermédiaire capable de remplir deux fonctions :
- Cacher l’adresse IP réelle du C2 et
- Filtrer le trafic.
Seules les requêtes légitimes de nos implants doivent être transmises; le reste est redirigé vers un site anodin. C’est le rôle du redirecteur, une brique essentielle de l’infrastructure Red Team.
Testez votre sécurité face à un scénario d’attaque réaliste
Nos équipes Red Team reproduisent les méthodes d’un attaquant afin d’évaluer jusqu’où une compromission pourrait mener au sein de votre système d’information.
Architecture d'une infrastructure Red Team : vue d'ensemble
Avant d'entrer dans le détail, regardons l'infrastructure cible sous trois angles : son fonctionnement, les composants techniques déployés et la chronologie de son déploiement automatisé.
Fonctionnement de l'infrastructure : point de vue de la victime
Depuis le poste de la victime, la chaîne reste simple. Le navigateur ou l’implant contacte un nom de domaine hébergé sur un CDN (Content Delivery Network) légitime, qui évite d’exposer directement l’adresse IP du redirecteur.
Seul le trafic présentant le bon User-Agent et la bonne URL, correspondant aux paramètres définis pour l’implant, est transmis jusqu’au serveur C2. Les autres requêtes, notamment celles d’un analyste ou d’un scanner automatisé, sont redirigées vers un site bénin, par exemple un moteur de recherche connu.
Les composants techniques de l'infrastructure Red Team
Derrière ce principe, l’infrastructure déployée sur AWS assemble plusieurs composants automatisés et reliés entre eux.
| Composant | Rôle dans l'infrastructure Red Team |
|---|---|
| DNS OVH | Associe le sous-domaine utilisé pendant l'opération à l'infrastructure déployée. |
| CloudFront | Ajoute une couche intermédiaire devant le redirecteur et évite d'exposer directement son adresse IP. |
| EC2 (Apache2 + mod_rewrite) | Joue le rôle de redirecteur et transmet les communications autorisées vers le serveur C2. |
| Serveur C2 | Permet à l'équipe Red Team de piloter les communications avec les machines compromises. |
| S3 Bucket | Centralise les logs générés par CloudFront afin de faciliter leur analyse. |
L’ensemble est orchestré par un outil interne en ligne de commande. Celui-ci automatise la création et la mise en relation des composants via Ansible, sans nécessiter une configuration manuelle de chaque brique.
Comment construire une infrastructure Red Team étape par étape ?
Étape 1 : déployer le redirecteur EC2 avec Apache
La première étape consiste à placer un serveur relais entre la victime et le C2. Il s’agit d’une machine virtuelle Linux hébergée dans le cloud par exemple un EC2 sur AWS.
Ce serveur fait tourner Apache avec un fichier de règles (.htaccess / mod_rewrite). Chaque requête entrante est inspectée. Si le User-Agent et l’URL correspondent à ceux configurés pour notre implant, la requête est transmise au serveur C2. Dans le cas contraire, elle est redirigée vers un site légitime.
Pourquoi utiliser un redirecteur EC2 ?
Premièrement, l'adresse IP exposée à la victime, et donc potentiellement à son SOC, est celle du redirecteur et non celle du véritable serveur C2. Si le relais est détecté et bloqué, l'infrastructure de commande reste intacte et peut être redéployée derrière un nouveau redirecteur.
Deuxièmement, un analyste qui inspecte le trafic observe du HTTP/HTTPS ressemblant à du trafic web classique vers un serveur ordinaire, plutôt qu'un pattern de C2 évident.
Cette étape est indépendante du framework offensif utilisé. Que l'équipe s'appuie sur Cobalt Strike, Sliver, le principe reste identique. Seuls les User-Agents et les URIs à filtrer changent selon les implants utilisés pendant la mission.
Selon l'architecture retenue, ce serveur relais remplit une fonction de redirection du trafic comparable à celle d'un reverse proxy entre la victime et le backend C2. Cette qualification doit toutefois rester cohérente avec la configuration technique réellement déployée.
Mettez vos capacités de détection à l’épreuve
Confrontez vos défenses à des techniques d’attaque réalistes et identifiez les points d’amélioration de vos mécanismes de détection et de réaction.
Étape 2 : configurer le DNS OVH et le nom de domaine
Une fois le redirecteur en place, il faut lui attribuer un nom de domaine crédible plutôt qu'une adresse IP brute. L'API du registrar OVH génère automatiquement un sous-domaine aléatoire, immédiatement pointé vers l'adresse IP publique de l'EC2 créé à l'étape précédente.
Pourquoi utiliser un nom de domaine ?
Une adresse IP brute peut attirer l'attention d'un analyste ou d'un outil de threat intelligence. Un nom de sous-domaine plausible se fond davantage dans le trafic d'entreprise.
Autre avantage opérationnel : si l'EC2 est détecté et neutralisé (« brûlé ») par le client, un nouveau sous-domaine peut être généré et repointé rapidement. L'équipe peut ainsi adapter l'infrastructure sans reconstruire toute la chaîne de communication.
Étape 3 : ajouter AWS CloudFront devant le redirecteur
La troisième étape ajoute une couche CDN. Une distribution AWS CloudFront est créée devant l'EC2. La victime communique alors avec un nom de domaine CloudFront, tandis que le CDN assure le routage du trafic vers l'EC2.
Pourquoi utiliser CloudFront ?
Trois avantages se cumulent. D'abord, l'adresse IP de l'EC2 n'est plus directement exposée à la victime ni à son réseau.
Ensuite, un blocage global des domaines CloudFront peut être difficilement envisageable dans une entreprise utilisant elle-même des services AWS.
Enfin, le trafic observé ressemble à de la navigation vers une infrastructure CDN largement utilisée. Cela ajoute une couche supplémentaire entre la victime et le serveur relais.
Étape 4 : centraliser les logs avec Amazon S3
La dernière brique technique n’est pas offensive mais opérationnelle. Les requêtes traitées par CloudFront sont journalisées dans un bucket S3 dédié, créé et nommé automatiquement d’après le sous-domaine utilisé pour la mission.
Pourquoi journaliser les requêtes dans S3 ?
Ces journaux permettent d'analyser précisément les sollicitations du redirecteur : adresses IP, horaires et User-Agents.
Ils fournissent également un signal utile pendant la mission. Un pic de requêtes provenant d'adresses IP inhabituelles ou d'outils de scan peut indiquer que le domaine est analysé par le SOC ou les équipes Blue Team du client. L'équipe Red Team peut alors adapter sa posture.
Architecture finale de l'infrastructure Red Team
Une fois les briques assemblées, la chaîne devient : Victime → DNS OVH → CloudFront → EC2 Apache → serveur C2.
Le DNS fournit un nom de domaine crédible plutôt qu’une adresse IP brute. CloudFront évite d’exposer directement l’adresse IP du redirecteur. Le EC2 Apache assure le filtrage applicatif avant de transmettre le trafic autorisé au C2.
Si une requête ne correspond pas à la signature attendue de l’implant, elle est redirigée vers un site bénin. Les requêtes traitées par CloudFront sont parallèlement journalisées dans Amazon S3.
Automatiser le déploiement d'une infrastructure Red Team
Sur le terrain, ces briques ne sont pas déployées manuellement une par une. Une commande unique de notre outil interne orchestre la séquence de déploiement.
- Génération du fichier de filtrage : Le profil de l’implant C2 est analysé afin d’en extraire les User-Agents et URIs légitimes attendus. Ils sont ensuite écrits dans un fichier de configuration prêt à être déployé.
- Création de l’instance EC2 : Une machine virtuelle Ubuntu/Debian est provisionnée sur AWS. L’outil récupère ensuite son adresse IP publique.
- Création du DNS OVH : Un sous-domaine aléatoire est généré via l’API OVH puis pointé vers l’adresse IP publique de l’EC2.
- Déploiement d’Apache via Ansible : Le serveur web est installé. Un certificat SSL/TLS Let’s Encrypt est généré pour chiffrer le trafic, puis le fichier de filtrage est copié sur l’EC2.
- Création du bucket S3 : Un bucket nommé d’après le sous-domaine est créé afin de recevoir les journaux d’accès.
- Création de la distribution CloudFront : Le CDN est configuré pour router le trafic vers le sous-domaine de l’EC2.
- Mise en service du redirecteur : La chaîne est vérifiée de bout en bout. Le trafic destiné au C2 transite alors par CloudFront puis par l’EC2 avant d’atteindre le serveur de commande.
L’intérêt de cette automatisation dépasse le simple gain de temps. Chaque redirecteur suit la même procédure de déploiement, ce qui réduit le risque d’erreur de configuration.
Une mauvaise règle de filtrage ou un certificat TLS manquant peut suffire à rendre un redirecteur immédiatement suspect.
Une infrastructure compatible avec plusieurs frameworks C2
Cette infrastructure n'est pas conçue pour un seul framework de Command and Control. Le schéma fonctionne selon le même principe avec Cobalt Strike, Sliver.
La principale variable d'une mission à l'autre concerne le fichier de filtrage. Pour Cobalt Strike, il est généré automatiquement à partir du Malleable C2 profile utilisé par l'opérateur.
Pour Sliver, l'équipe fournit les règles correspondant aux User-Agents et URIs de ses implants. Le reste de la chaîne - DNS, CDN, filtrage applicatif et journalisation - conserve le même fonctionnement.
Cette portabilité permet à l'équipe Red Team de choisir l'outil adapté au contexte de chaque mission : niveau de furtivité recherché, contraintes du client ou comportements à simuler. L'infrastructure de communication n'a pas besoin d'être reconstruite à chaque changement de framework.
L’impact de cette infrastructure Red Team pour nos clients
L'objectif n'est pas de « gagner » contre les équipes de détection du client. Il s'agit de reproduire des conditions proches d'une attaque réelle, menée par un groupe qui chercherait lui aussi à protéger son infrastructure.
Un exercice Red Team dont le C2 est exposé directement peut être interrompu très rapidement. Il teste alors peu la capacité du client à détecter une opération plus préparée.
À l'inverse, une infrastructure conçue avec plusieurs couches permet de confronter le SOC et les équipes Blue Team à un scénario plus représentatif. L'exercice mesure alors plus justement leurs capacités de détection et de réponse.
C'est cette approche réaliste de l'attaque qui permet d'aller plus loin qu'un test d'intrusion classique et de mettre réellement à l'épreuve les capacités de détection et de réponse du client.
Vous souhaitez organiser un exercice Red Team ?
Échangez avec nos experts pour définir un scénario adapté à votre environnement et à vos objectifs de sécurité.
Définitions
Infrastructure Red Team
Une infrastructure Red Team désigne l’ensemble des serveurs, domaines, services réseau et outils utilisés par une équipe offensive pour conduire une simulation d’attaque. Elle permet notamment d’héberger les outils nécessaires aux opérations, de gérer les communications et de reproduire une infrastructure proche de celle d’un attaquant réel.
Serveur Command and Control (C2)
Un serveur Command and Control, ou C2, permet à un opérateur Red Team de communiquer avec les systèmes compromis au cours d’une simulation d’attaque. Il sert notamment à transmettre des instructions et à recevoir les informations remontées par les agents déployés pendant l’opération. Parmi les solutions utilisées dans ce type d’environnement figurent notamment Cobalt Strike et Sliver.
Redirecteur
Un redirecteur est un serveur intermédiaire placé entre les systèmes ciblés et le serveur C2. Il permet notamment de ne pas exposer directement l’infrastructure de Command and Control et de filtrer ou rediriger les communications selon des règles définies.
Blue Team
La Blue Team désigne l’équipe chargée de la défense du système d’information. Elle intervient notamment dans la surveillance, la détection, l’analyse et la réponse aux activités malveillantes. Une opération Red Team permet notamment d’évaluer sa capacité à détecter et à répondre à une attaque simulée.
FAQ : Infrastructure Red Team
Quelle est la différence entre un pentest et une Red Team ?
Un pentest cherche principalement à identifier et exploiter des vulnérabilités sur un périmètre défini. Une opération Red Team adopte une approche plus globale en simulant le comportement d’un attaquant réel afin d’évaluer les vulnérabilités, mais également les capacités de détection et de réponse de l’organisation.
Pourquoi utiliser un redirecteur dans une infrastructure Red Team ?
Le redirecteur ajoute une couche intermédiaire entre les systèmes ciblés et le serveur C2. Il évite d’exposer directement l’infrastructure de Command and Control et permet de mieux contrôler les communications qui transitent vers le serveur C2.
Pourquoi utiliser AWS CloudFront dans une infrastructure Red Team ?
Dans l’architecture présentée dans cet article, AWS CloudFront est placé devant le redirecteur EC2 afin d’ajouter une couche intermédiaire. Les communications transitent ainsi par CloudFront avant d’atteindre le redirecteur puis le serveur C2. Cette approche s’apparente au domain fronting, où un CDN autorisé peut servir d’intermédiaire pour des communications dont la destination réelle est masquée. Dans un environnement d’entreprise, où les proxys bloquent certaines sorties mais autorisent des CDN comme CloudFront, cela peut faciliter le passage du trafic.
Quels frameworks C2 peuvent être utilisés ?
L’infrastructure présentée est conçue pour fonctionner avec plusieurs frameworks de Command and Control, notamment Cobalt Strike, Sliver et etc. Cette compatibilité permet d’adapter l’environnement aux outils et aux besoins spécifiques de chaque opération Red Team.
Pourquoi automatiser le déploiement d’une infrastructure Red Team ?
L’automatisation permet d’obtenir un déploiement plus rapide, reproductible et moins dépendant des configurations manuelles. Dans l’architecture présentée, Ansible et une CLI interne automatisent plusieurs étapes de création et de configuration de l’infrastructure.
Pourquoi journaliser les requêtes dans Amazon S3 ?
La centralisation des logs dans Amazon S3 permet de conserver les requêtes transitant par CloudFront et de disposer d’une source centralisée pour leur analyse. Cette journalisation facilite notamment le suivi du fonctionnement de l’infrastructure pendant les opérations.
