Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
cowcloud — Solution AWS serverless pour répartir les charges de travail de reconnaissance et d'analyse de vulnérabilités. Soumettez les tâches via l'interface web ; les workers EC2 exécutent des scripts Python personnalisés avec des outils comme Nmap. | Kitploit
Outils/GitHubGitHub/nccgroup/cowcloud
Sécurité de l'Infrastructure CloudFrameworks de Tests d'IntrusionScanners de VulnérabilitésScripting et AutomatisationCollecte d'InformationsSécurité CloudDevSecOpsUtilitaires et Frameworks
GitHubnccgroup/cowcloud

cowcloud

Solution AWS serverless pour répartir les charges de travail de reconnaissance et d'analyse de vulnérabilités. Soumettez les tâches via l'interface web ; les workers EC2 exécutent des scripts Python personnalisés avec des outils comme Nmap.

602il y a 3 ansVérifié par Kitploit

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager
Voir le dépôt

CowCloud

une solution serverless pour distribuer les charges de travail dans AWS

CowCloud a été créé à l'origine pour exécuter des outils de reconnaissance et des scans de vulnérabilités de manière distribuée ; par exemple, un cas d'usage pourrait être celui des chasseurs de bug bounty. Cette solution vise à abstraire les utilisateurs finaux du travail sous-jacent nécessaire pour distribuer des charges de travail dans AWS. CowCloud fournit aux utilisateurs une interface web conviviale pour visualiser et créer de nouvelles tâches qui sont ensuite consommées par le code Python s'exécutant sur les nœuds de travail (instances EC2). Il est prévu que le code Python ainsi que les AMI EC2 soient personnalisés.

À titre d'exemple, disons que vous souhaitez exécuter des scans Nmap. Dans ce cas, vous pouvez simplement choisir une AMI dans le catalogue d'AMI et mettre à jour le champ image_id dans Terraform/ec2_module/ec2_module.tf. Ensuite, le fichier ec2py/template.py devra être mis à jour pour personnaliser les arguments du scan Nmap (-Pn, -p 443, etc.). Enfin, le champ user_data dans le fichier de configuration Terraform/ec2_module/ec2_module.tf devra être mis à jour pour installer Nmap et ses dépendances.

Une autre option consiste à installer et exécuter plusieurs outils commerciaux ; dans ce cas, vous voudrez peut-être créer votre propre instance EC2 ou snapshot. Dans ce cas, vous installerez toutes les dépendances et activerez les licences afin de pouvoir utiliser cette AMI comme image de référence (gold image) pour vos nœuds de travail.

Screenshot

CowCloud peut être décomposé en trois composants principaux :

  • une configuration Terraform
  • un front-end React JS
  • une application Python qui s'exécute sur les nœuds de travail

Voici les fonctionnalités clés :

  • La solution utilise Amazon Cognito (avec un user pool) afin que les utilisateurs puissent s'inscrire et se connecter à l'application web
  • Une application React JS comme application front-end. Le front-end affiche les tâches et les nœuds de travail et vous permet d'ajouter de nouvelles tâches
  • API Gateway avec intégration Lambda pour gérer le CORS et interagir avec certaines fonctions Lambda afin de créer et d'obtenir des informations depuis DynamoDB
  • CloudFront pour gérer SSL et le cache
  • WAF avec règles et conditions d'adresses IP pour restreindre l'accès à l'application web (optionnel)
  • Des buckets S3 pour stocker les résultats d'exécution et l'application front-end ; un bucket S3 séparé est utilisé comme référentiel de code pour l'application Python.
  • Une application Python comme cœur pour exécuter les tâches sur les instances EC2 (nœuds de travail). Les actions de l'outil peuvent être décomposées en plusieurs étapes :
    • L'application Python consomme les messages
    • exécute les scans
    • compresse la sortie
    • et chiffre la sortie avec AES256-CBC et un mot de passe
    • puis téléverse le résultat dans un bucket S3
  • Chaque fois qu'un nouveau nœud de travail est créé, le référentiel Python est récupéré (pull) depuis un bucket S3, puis le fichier ec2py qu'il contient est exécuté.
  • Chaque fois qu'un nouveau nœud de travail est créé, une EIP peut être automatiquement assignée à l'instance (optionnel)
  • Des groupes de journaux CloudWatch pour stocker les journaux provenant de diverses sources telles que les erreurs Lambda, les exceptions survenant dans l'outil Python ec2app, l'API Gateway, les journaux Docker et bien plus encore
  • Des lifecycle hooks pour modifier le statut des nœuds de travail dans DynamoDB et empêcher que les nœuds de travail soient terminés pendant qu'une tâche est encore en cours d'exécution
  • Stratégie d'autoscaling basée sur le nombre de tâches en file d'attente et la configuration définie (plus d'informations sur le fonctionnement de l'algorithme dans autoscalingStrategy.py)
  • Mappage de source d'événements Lambda lié à la table des tâches dans DynamoDB, afin de gérer les actions d'autoscaling lorsque les éléments de la base de données augmentent ou diminuent
  • SNS pour envoyer de nouveaux messages (tâches) dans une file SQS ; ces messages sont ensuite lus par les nœuds de travail
  • Le service Step Functions est utilisé pour créer un compte à rebours et supprimer les groupes de journaux CloudWatch après l'expiration de retention_time

Schéma :

Deprecated

Les options suivantes sont disponibles dans la configuration Terraform :

À la suite de l'exécution de Terraform, un nouveau fichier est créé (config.js) ; celui-ci contient la configuration requise pour que l'application React JS s'authentifie auprès du répertoire du user pool Cognito. Une fois l'infrastructure déployée, vous devez compiler l'application React et téléverser le dossier build. De plus, vous devez téléverser le code Python dans un bucket S3 qui agit comme référentiel de code. Ce processus est automatisé dans deux scripts setup.bat et setup.sh afin que vous n'ayez pas à vous en soucier ; ceci est uniquement pour résumer cette étape.


Étapes d'installation :

L'infrastructure est déployée dans la région us-east-1 par défaut, bien que cela puisse être modifié dans le fichier locals.tf au sein du dossier Terraform.

Étapes :

  • Vous devez créer un utilisateur avec des privilèges d'administrateur dans votre compte AWS
  • (Optionnel) Créez une AMI « dorée » (golden) avec les outils que vous souhaitez
  • Allez dans le dossier Terraform et mettez à jour le fichier variables.tf ; la variable ami doit pointer vers une AMI EC2 existante, qui peut être votre AMI dorée ou une AMI du catalogue EC2
  • Téléchargez et installez aws-cli, NPM, Yarn et Terraform sur votre ordinateur
  • Configurez aws-cli pour utiliser votre compte AWS avec aws configure. Vérifiez que la configuration est correcte en exécutant cette commande : aws sts get-caller-identity ; lorsqu'elle est correctement configurée, cette commande ne doit pas renvoyer d'erreur
  • (Optionnel) Générez une paire de clés SSH pour les instances EC2. Si vous ne prévoyez pas d'utiliser SSH sur les nœuds de travail, mettez à jour le module ec2_module en conséquence aws ec2 create-key-pair –key-name cowCloud –query “cowCloud” –output text > ec2_module/cowCloud.pem
root@kitploit:~
git clone [email protected]:nccgroup/cowcloud.git
# Deploy the infra
cd cowcloud
cd Terraform
terraform init
terraform plan
terraform apply --auto-approve
  • Notez la valeur (website) affichée dans la sortie de Terraform ; il s'agit de l'URL pour accéder au front-end
  • Une fois l'infrastructure déployée, il vous suffit d'exécuter setup.sh ou setup.bat pour compiler et téléverser le code du front-end et d'ec2py

Vous êtes maintenant prêt ! Inscrivez-vous, connectez-vous et créez une nouvelle tâche !

Flux utilisateur final

Une fois que tout est déployé et que le front-end est accessible, vous devez suivre ces étapes :

  • Visitez le site web et cliquez sur le bouton de connexion (pour vous inscrire, vous devrez fournir un email valide, un nom d'utilisateur et un mot de passe)
  • Validez l'email en cliquant sur le lien que vous recevez dans votre boîte de réception
  • Connectez-vous avec l'email/nom d'utilisateur et le mot de passe
  • Cliquez sur l'onglet « add a new task » et mettez à jour le document JSON pour spécifier le domaine cible, puis soumettez le formulaire ; vous recevrez alors un ID de tâche, un lien et un mot de passe qui seront affichés ci-dessous.
  • Revenez au tableau de bord et attendez de voir une nouvelle instance EC2 être créée et la tâche exécutée par le nœud de travail
  • Si la tâche est exécutée dans un conteneur Docker, la sortie standard (stdout) peut être consultée via l'interface web
  • Une fois la tâche terminée, la tâche est déplacée vers la table d'archive ; vous pouvez maintenant visiter le lien fourni, télécharger le résultat, le déchiffrer avec le mot de passe fourni et décompresser la sortie ou le résultat de l'outil CowCloud\ec2py> python .\decypt_file.py 2e8cf87c-5389-11ec-abec-d6d1f378b18d
  • Le nœud de travail est automatiquement terminé une fois la tâche terminée

Screenshot

Administrateur/mainteneur

  • La personne chargée de déployer l'infrastructure et de la maintenir doit correctement assainir et valider les entrées des utilisateurs finaux fournies via l'application web. En d'autres termes, il faut s'assurer que le code dans ec2py/template.py n'est pas vulnérable à l'injection de commandes OS. Ce point est souligné car c'est l'aspect le plus critique du système. Un soin particulier a été apporté pour limiter le périmètre des permissions et l'exposition des nœuds de travail, réduisant ainsi les risques associés. Néanmoins, il incombe à l'administrateur de prendre en charge cet aspect de la sécurité du système. Les politiques de rôle attachées au profil des instances EC2 sont répertoriées dans le fichier readme.md à l'intérieur du dossier Terraform

    • De plus, il existe une fonction Lambda appelée workers_manager.py qui est appelée par l'outil ec2py pour effectuer des actions plus privilégiées. Ces actions ont été déplacées vers une fonction Lambda afin de limiter le risque en cas de compromission de la clé d'accès du rôle attaché au profil EC2. Elle fonctionne néanmoins avec IMDSv2. Les politiques de rôle attachées à la fonction Lambda workers_manager.py sont répertoriées dans le fichier readme.md à l'intérieur du dossier Terraform
  • Si vous souhaitez capturer la sortie standard (stdout) et l'afficher via l'interface web pendant l'exécution de la tâche, allez dans ec2py/template.py et suivez ces étapes :

    • La variable extra_docker_params contient les informations requises pour que vos conteneurs Docker envoient la sortie standard aux groupes de journaux CloudWatch. Vous devrez inclure cette variable dans la ligne de commande lorsque vous voulez voir la sortie standard via le front-end.
    root@kitploit:~
    cmd = f"docker run {extra_docker_params} --rm -v {tmp_folder}target.txt:/root/Tools/reconftw/target.txt -v {tmp_folder}reconftw.cfg:/root/Tools/reconftw/reconftw.cfg -v {tmp_folder}Recon/:/root/Tools/reconftw/Recon/ six2dez/reconftw:main -l target.txt -w".split(' ')
    

Désinstallation

Vous pouvez détruire l'infrastructure en exécutant cette simple commande : terraform destroy --auto-approve. Cela supprimera toutes les ressources existantes. Remarque : n'interrompez pas ce processus, car cela pourrait laisser certains éléments dans le cloud que vous devriez ensuite identifier et supprimer manuellement.


Flux utilisateur final

Screenshot

Flux principal

Screenshot


Notes de développement

  • Si vous apportez une modification à l'application ec2py, pensez à synchroniser les changements avec le dépôt S3 ; vous devez ensuite terminer les instances actuelles et en relancer une nouvelle pour récupérer les derniers changements
  • Lorsqu'un composant du module gateway est modifié, vous devrez peut-être redéployer l'API REST. Pour ce faire :
    • terraform destroy --auto-approve -target module.gateway_module.aws_api_gateway_deployment.lambda
    • terraform apply --auto-approve -target module.gateway_module

Remerciements à :

  • Sabrina MM https://www.linkedin.com/in/sabrina-marisol-martinez-a4bb54181/
  • Ricardo Martinez Martin (NCC Group)
  • Conor McErlane (NCC Group)
  • Simon Harraghy (NCC Group)
Télécharger l’outil
  • Si ec2py exécute des outils (par exemple Nmap) dans des conteneurs Docker, la sortie standard (stdout) peut être enregistrée dans CloudWatch et consultée via le front-end ; consultez la variable extra_docker_params dans le fichier template.py (ceci est expliqué dans la section Administrateur/mainteneur ci-dessous)
  • Le front-end fournit un bouton pour interrompre les tâches pendant leur exécution et un autre bouton pour afficher les journaux des conteneurs Docker
  • Si vous souhaitez modifier quoi que ce soit dans le code du front-end ou dans les dossiers ec2py, vous devrez propager ces modifications vers les buckets S3 et invalider le cache du front-end ; vous pouvez faire tout cela en exécutant simplement setup.bat/sh
  • variablevaleur par défautdescription
    eipenablefalseSi la valeur est true, la solution alloue un pool d'adresses IP élastiques associées aux nœuds de travail lors de leur création. Le nombre d'EIP à réserver est calculé à l'aide de la formule sum([var.max_workers, var.maximum_number_of_terminating_machines])
    cidr_whitelist[]La liste blanche CIDR pour autoriser uniquement certaines plages d'adresses IP dans le pare-feu. Par ex. ["195.95.131.0/24"]
    max_workers et max_queued_tasks_per_workermax_workers: 3, max_queued_tasks_per_worker: 10Ces deux paramètres déterminent quand réduire (scale in) ou étendre (scale out) la capacité, par ex. max_workers 3, max_queued_tasks_per_worker 10. Cela signifie que si le nombre de tâches dépasse dix, une nouvelle instance EC2 sera créée. S'il y a plus de vingt tâches, un maximum de trois instances EC2 sera disponible pour distribuer les charges de travail (consultez l'algorithme dans le script Terraform/dynamodb_module/autoscalingTool/autoscalingStrategy.py).
    maximum_number_of_terminating_machines2Ceci définit le nombre d'instances qui sont marquées pour être terminées mais qui sont en attente jusqu'à ce que le processus/scan termine la tâche.
    heartbeat_timeout900Ceci définit le temps pendant lequel ces nœuds de travail sont en attente. Une fois ce temps écoulé, le nœud de travail sera terminé de force.
    instance_typet2.microhttps://aws.amazon.com/ec2/instance-types/
    aminullhttps://aws.amazon.com/es/amazon-linux-ami/
    retention_time7Définit la durée de conservation (en jours) des journaux et l'expiration des éléments de la table d'archive (tâches terminées).