Wiki pour collecter des ressources de durcissement d'infrastructure Red Team
Cette page wiki est destinée à fournir une ressource pour la mise en place d'une infrastructure Red Team résiliente. Elle a été créée pour compléter la présentation de Steve Borosh (@424f424f) et Jeff Dimmock (@bluscreenofjeff) lors du BSides NoVa 2017, intitulée "Doomsday Preppers: Fortifying Your Red Team Infrastructure" (slides)
Si vous souhaitez apporter une contribution, veuillez soumettre une Pull Request ou signaler un problème sur le dépôt.
MERCI à tous les auteurs du contenu référencé dans ce wiki et à tous ceux qui ont contribué !
Lors de la conception d'une infrastructure Red Team qui doit résister à une réponse active ou durer pour un engagement à long terme (semaines, mois, années), il est important de ségréguer chaque actif en fonction de sa fonction. Cela offre résilience et agilité face à la Blue Team lorsque les actifs de la campagne commencent à être détectés. Par exemple, si l'e-mail de phishing d'une évaluation est identifié, la Red Team n'aurait besoin de créer qu'un nouveau serveur SMTP et un serveur d'hébergement de payloads, plutôt qu'une configuration complète de serveur d'équipe.
Envisagez de ségréguer ces fonctions sur différents actifs :
Chacune de ces fonctions sera probablement requise pour chaque campagne d'ingénierie sociale. Étant donné que la réponse active aux incidents est typique dans une évaluation Red Team, un nouvel ensemble d'infrastructure doit être mis en œuvre pour chaque campagne.
Pour renforcer la résilience et la dissimulation, chaque actif back-end (c'est-à-dire le serveur d'équipe) doit avoir un redirecteur placé devant lui. L'objectif est de toujours avoir un hôte entre notre cible et nos serveurs back-end. La mise en place de l'infrastructure de cette manière rend le déploiement de nouvelle infrastructure beaucoup plus rapide et facile - pas besoin de monter un nouveau serveur d'équipe, de migrer les sessions et de reconnecter les actifs non brûlés sur le back-end.
Types de redirecteurs courants :
Chaque type de redirecteur dispose de multiples options d'implémentation qui conviennent le mieux à différents scénarios. Ces options sont discutées plus en détail dans la section Redirecteurs du wiki. Les redirecteurs peuvent être des hôtes VPS, des serveurs dédiés, ou même des applications exécutées sur une instance Platform-as-a-Service.
Voici un exemple de conception, en gardant à l'esprit la ségrégation fonctionnelle et l'utilisation de redirecteurs :
A Vision for Distributed Red Team Operations - Raphael Mudge (@armitagehacker)
Infrastructure for Ongoing Red Team Operations - Raphael Mudge
Advanced Threat Tactics (2 of 9): Infrastructure - Raphael Mudge
Cloud-based Redirectors for Distributed Hacking - Raphael Mudge
How to Build a C2 Infrastructure with Digital Ocean – Part 1 - Lee Kagan (@invokethreatguy)
Automated Red Team Infrastructure Deployment with Terraform - Part 1 - Rasta Mouse (@_RastaMouse)
La réputation perçue d'un domaine variera considérablement en fonction des produits utilisés par votre cible, ainsi que de leur configuration. Par conséquent, choisir un domaine qui fonctionnera sur votre cible n'est pas une science exacte. La collecte de renseignements en sources ouvertes (OSINT) sera essentielle pour aider à faire une estimation éclairée de l'état des contrôles et des ressources à vérifier pour les domaines. Heureusement, les annonceurs en ligne sont confrontés aux mêmes problèmes et ont créé des solutions que nous pouvons exploiter.
expireddomains.net est un moteur de recherche pour les domaines récemment expirés ou abandonnés. Il fournit une recherche et un filtrage avancé, tels que l'âge de l'expiration, le nombre de backlinks, le nombre de captures Archive.org, le score SimilarWeb. En utilisant le site, nous pouvons enregistrer des domaines pré-utilisés, qui viendront avec un âge de domaine, qui ressemblent à notre cible, ressemblent à notre usurpation, ou simplement sont susceptibles de se fondre dans le réseau de notre cible.
