54:45Cet enregistrement n'est pas encore disponible.
Cacher son traffic réseau à la Blue Team en opération Red Team
Télécharger les ressourcesCatégories
Menaces et renseignementMaliciels et techniques d'attaqueSécurité réseau et confiance zéroSécurité offensive et expositionTests d'intrusion et red teaming
Fournisseurs et outils abordés
À propos de cette session
Joel Hien (pentester devenu responsable adjoint d'un centre d'opérations de vulnérabilités) et Hocine Mahtout, Offensive Security Manager à la Caisse des dépôts, expliquent comment les red teams dissimulent leur trafic de commande et contrôle aux équipes blue team. Ils commencent par le domain fronting classique : abuser de la réputation d'un CDN en indiquant un domaine de confiance dans le SNI TLS pendant que l'en-tête HTTP host contient un domaine contrôlé par l'attaquant, ce qui fait relayer le trafic sous couvert d'un certificat et d'une IP fiables. Ils passent en revue les contre-mesures qui ont largement fermé cette porte : SNI chiffré, CDN qui vérifient la correspondance SNI/host, et le récent blocage par Azure du domain fronting inter-abonnement. Ils enchaînent sur les équivalents modernes : des redirecteurs PaaS bâtis sur AWS Lambda et API Gateway, Azure Functions, Cloudflare Workers et Google Cloud Functions, chacun accessible via une URL propre au fournisseur adossée à un certificat de confiance que la plupart des proxys d'entreprise ne bloqueront jamais, combinables avec des reverse proxys comme YARP ou NGINX pour une redirection conditionnelle vers un site légitime ou le serveur des attaquants. Une démonstration avec Terraform déployant une fonction Azure montre un beacon qui communique à travers un tel redirecteur. Ils terminent en nommant d'autres canaux peu surveillés, comme Teams et Slack, qui contournent le proxy d'entreprise.
Dans le domaine de la cybersécurité, les opérations de Red Team sont des exercices cruciaux visant à évaluer la robustesse des infrastructures et des défenses d'un système face à des attaques simulées. Pour mener à bien ces missions, les équipes Red Team doivent constamment innover et adopter des stratégies d'attaque élaborées pour dissumuler leurs traffics une fois l'accès inital obtenu.
Deux approches utilisées dans ce contexte sont le “domain fronting“ et l'utilisation de redirecteurs Cloud PaaS (Platform as a Service). Cette présentation explorera les avantages offerts par les redirecteurs Cloud PaaS (CloudFront AWS Lambda, Azure Function, etc.) par rapport au “domain fronting“ dans le cadre des opérations de Red Team. Nous étudierons les différences fondamentales entre ces deux techniques, en mettant en évidence celle qui offre une solution plus évolutive, flexible et adaptable pour dissimuler le trafic réseau, fournissant ainsi à l'équipe Red Team : résilience, efficacité opérationnelle et capacité d'adaptation.
À retenir
- Ne pas présumer qu'un certificat et une IP de CDN légitimes signifient un trafic sûr; comparer le SNI TLS à l'en-tête HTTP host dans les journaux pour repérer le domain fronting classique.
- Se familiariser avec le SNI chiffré et les fonctionnalités de proxy d'entreprise (comme le blocage des écarts SNI/host de Zscaler), car l'inspection standard du SNI seule ne suffit plus à détecter le domain fronting moderne.
- S'attendre à ce que les attaquants fassent transiter leur trafic C2 par AWS Lambda, Azure Functions, Cloudflare Workers ou Google Cloud Functions, précisément parce que bloquer les domaines des grands fournisseurs cloud casserait le trafic d'affaires légitime.
- Considérer les canaux SaaS peu surveillés comme Teams et Slack comme des voies potentielles d'exfiltration ou de C2, car ils contournent souvent complètement le proxy d'entreprise.
- Pour qui exploite un service derrière un CDN ou un PaaS, vérifier par politique que le SNI et l'en-tête host correspondent, sur le modèle adopté par Azure Front Door pour fermer le domain fronting inter-abonnement.
