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
BlueTeam.Lab — Laboratoire de détection Blue Team créé avec Terraform et Ansible dans Azure. | Kitploit
Outils/GitHubGitHub/op7ic/blueteam.lab
Outils DéfensifsAudit de ConfigurationCriminalistique NumériqueTests d'IntrusionSécurité CloudDétection d'IntrusionApprentissage et ÉducationRéponse aux IncidentsAnalyse de JournauxLabs et Pratique
GitHubop7ic/blueteam.lab

BlueTeam.Lab

18723il y a 1 anVé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

Laboratoire de détection Blue Team créé avec Terraform et Ansible dans Azure.

Voir le dépôt

BlueTeam.Lab

BlueTeam.Lab

Objectif

Ce projet contient un ensemble de scripts Terraform et Ansible pour créer un laboratoire BlueTeam orchestré. L'objectif de ce projet est de fournir aux équipes rouge et bleue la possibilité de déployer un laboratoire de détection ad hoc pour tester diverses attaques et artefacts forensiques sur le dernier environnement Windows, puis d'obtenir une vue « type SOC » des données générées.

REMARQUE : Ce laboratoire est délibérément conçu pour être non sécurisé. Veuillez ne pas connecter ce système à un réseau auquel vous tenez.


Disposition du laboratoire


Prérequis

Un certain nombre de fonctionnalités doivent être installées sur votre système pour utiliser cette configuration.

root@kitploit:~
# Step 1 - Install Azure CLI. More details on https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-linux?pivots=apt
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

# Step 2 - Install Terraform. More details on https://learn.hashicorp.com/tutorials/terraform/install-cli
sudo apt-get update && sudo apt-get install -y gnupg software-properties-common curl
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -
sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"
sudo apt-get update && sudo apt-get install terraform

# Step 3 - Install Ansible. More details on https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html
sudo apt update
sudo apt install software-properties-common
sudo add-apt-repository --yes --update ppa:ansible/ansible
sudo apt update
sudo apt install ansible

# Step 4 - Finally install python and various packages needed for remote connections and other activities
sudo apt install python3 python3-pip
pip3 install pywinrm requests msrest msrestazure azure-cli
pip3 install -r https://raw.githubusercontent.com/ansible-collections/azure/refs/heads/dev/requirements.txt

Construction et déploiement de BlueTeam.Lab

Une fois tous les prérequis installés, effectuez les étapes suivantes :

root@kitploit:~
# Log in to Azure from command line to ensure that the access token is valid
az login

# Clone Repository and move to BlueTeam.Lab folder
git clone https://github.com/op7ic/BlueTeam.Lab.git && cd BlueTeam.Lab

# Initialize Terraform and begin planning
terraform init && terraform plan

# Create your lab using the following command. 
terraform apply -auto-approve

# Verify the layout of your environment using Ansible
cd ansible && ANSIBLE_CONFIG=./ansible.cfg ansible-inventory --graph -i inventory.azure_rm.yml -vvv && cd ../

# To see IPs of individual hosts and other setup details use the following command: 
cd ansible && ANSIBLE_CONFIG=./ansible.cfg ansible-inventory -i inventory.azure_rm.yml -vvv --list && cd ../

# Once done, destroy your lab using the following command:
terraform destroy -auto-approve

# If you would like to time the execution us following command:
start_time=`date +%s` && terraform apply -auto-approve && end_time=`date +%s` && echo execution time was `expr $end_time - $start_time` s

#NOTE: It will take about two hours to configure it all, depending on your selected hardware.

Déploiement de différentes versions de Windows

Les variables Terraform définissent le type de systèmes d'exploitation utilisés pour ce déploiement. Une simple modification des variables d'exécution permet de spécifier un autre système d'exploitation pour l'ensemble de l'Active Directory (AD). L'option par défaut est d'utiliser Windows 10 Entreprise pour les postes de travail et Windows Server 2019 Datacenter pour le contrôleur de domaine. Voici des exemples de quelques options de configuration courantes qui peuvent être utilisées pour modifier l'ensemble de l'environnement afin d'utiliser différentes versions de système d'exploitation :

root@kitploit:~
# Use Windows 10 Enterprise for Workstations and Server 2019 Datacenter for DC (default option)
terraform apply -auto-approve

# Use Windows 11 Enterprise for Workstations and Server 2019 Datacenter for DC
terraform apply -auto-approve  -var="workstation_os=Windows-11" -var="workstation_SKU=win11-21h2-ent" -var="workstations_vm_size=Standard_DC2s_v2" 

# Use Windows 11 Enterprise for Workstations and Server 2012 Datacenter for DC
terraform apply -auto-approve -var="workstation_os=Windows-11" -var="workstation_SKU=win11-21h2-ent" -var="workstations_vm_size=Standard_DC2s_v2" -var="dc_os=WindowsServer" -var="dc_SKU=2012-Datacenter"

# Use Windows 11 Enterprise for Workstations and Server 2016 Datacenter for DC
terraform apply -auto-approve -var="workstation_os=Windows-11" -var="workstation_SKU=win11-21h2-ent" -var="workstations_vm_size=Standard_DC2s_v2" -var="dc_os=WindowsServer" -var="dc_SKU=2016-Datacenter"

# Use Windows 10 Pro N for Workstations and Server 2012 Datacenter for DC
terraform apply -auto-approve -var="workstation_os=Windows-10" -var="workstation_SKU=21h1-pron" -var="dc_os=WindowsServer" -var="dc_SKU=2012-Datacenter"

La commande az vm image list peut être utilisée pour identifier différentes versions de système d'exploitation pour le déploiement.


Fonctionnalités

  • Active Directory Windows avec deux postes de travail connectés au domaine Windows dans la configuration par défaut.
  • Fichier de configuration du domaine flexible permettant des modifications faciles de la configuration sous-jacente.
  • Politiques d'audit configurées selon le Guide CIS pour augmenter la visibilité des événements sur l'infrastructure Windows. Auditpol utilisé pour configurer des paramètres supplémentaires et les journaux PowerShell Transcript activés.
  • Sysmon64 déployé sur l'infrastructure en utilisant la dernière configuration SwiftOnSecurity pour les périphériques Windows.
  • Serveur Wazuh configuré et opérationnel pour collecter les journaux des périphériques.
  • Agents Wazuh configurés sur l'infrastructure et alimentant le serveur Wazuh.
  • Pare-feu configuré pour autoriser uniquement votre propre IP à accéder aux systèmes déployés.
  • OSQuery et FleetDM installés sur l'infrastructure, utilisant des modèles de configuration de Palantir.
  • Serveur Velocidex Velociraptor configuré et opérationnel.
  • Agents Velocidex Velociraptor configurés sur l'infrastructure et alimentant le serveur Velociraptor.
  • WinLogBeat configuré pour journaliser les données dans l'instance Elastic.
  • LokiToWinEventLog Scanner Loki configuré pour journaliser les données dans le journal des événements Windows toutes les 3 heures et expédier les données vers l'instance Elastic installée avec .

Documentation

La section suivante décrit les différents composants de ce laboratoire ainsi que des détails sur la façon de modifier les fichiers de configuration pour modifier la configuration :

  • Serveur OSQuery et Fleetdm
  • Serveur Wazuh et Agent Wazuh
  • Sysmon
  • WinLogBeat
  • Serveur Velociraptor et Agent Velociraptor
  • Membres du domaine

Identifiants

Une fois le laboratoire construit, Terraform affichera l'emplacement réel des systèmes et les identifiants associés. Un exemple de sortie se trouve ci-dessous.

root@kitploit:~
Network Setup:

Domain Controller = xx.xx.xx.xx
Workstation DETECTION1: xx.xx.xx.xx
Workstation DETECTION2: xx.xx.xx.xx
Wazuh Server IP = xx.xx.xx.xx
Wazuh Web Interface = https://xx.xx.xx.xx:443/
Velociraptor Web Inteface: = https://xx.xx.xx.xx:10000/
FleetDM Web Interface: = https://xx.xx.xx.xx:9999/

Credentials:

Domain Admin:
    blueteam.lab\blueteam BlueTeamDetection0%%%
Local Admin on Workstations:
    blueteam BlueTeamDetection0%%%
Wazuh Server SSH Login:
    blueteam BlueTeamDetection0%%%
Wazuh Logins:
    wazuh  BlueTeamDetection0%%%
    admin  BlueTeamDetection0%%%
    kibanaserver  BlueTeamDetection0%%%
    kibanaro  BlueTeamDetection0%%%
    logstash  BlueTeamDetection0%%%
    readall  BlueTeamDetection0%%%
    snapshotrestore  BlueTeamDetection0%%%
    wazuh_admin  BlueTeamDetection0%%%
    wazuh_user  BlueTeamDetection0%%%
Velociraptor Web Inteface Login:
    blueteam BlueTeamDetection0%%%
FleetDM Web Inteface Login:
    [email protected] BlueTeamDetection0%%%

RDP to Domain Controller:
xfreerdp /v:xx.xx.xx.xx /u:blueteam.lab\\blueteam '/p:BlueTeamDetection0%%%' +clipboard /cert-ignore

RDP to Workstation DETECTION1: xx.xx.xx.xx
xfreerdp /v:xx.xx.xx.xx /u:blueteam '/p:BlueTeamDetection0%%%' +clipboard /cert-ignore

RDP to Workstation DETECTION2: xx.xx.xx.xx
xfreerdp /v:xx.xx.xx.xx /u:blueteam '/p:BlueTeamDetection0%%%' +clipboard /cert-ignore

Configuration du pare-feu

Le tableau suivant résume un ensemble de règles de pare-feu appliquées dans l'environnement BlueTeamLab en configuration par défaut. Veuillez modifier le fichier main.tf pour ajouter de nouvelles règles de pare-feu si nécessaire dans la section Firewall Rule Setup.

En interne, les adresses IP statiques et noms d'hôtes suivants sont utilisés dans la plage 10.0.0.0/16 pour cet environnement dans la configuration par défaut :


Configuration utilisateur

Les identifiants par défaut suivants sont créés lors de l'installation. L'affichage des identifiants réellement configurés sera présenté une fois le processus de déploiement terminé.

Pour modifier les identifiants par défaut, changez les noms d'utilisateur et mots de passe dans le fichier domain_setup.yml.

Captures d'écran

Contribution

Les contributions, correctifs et améliorations peuvent être soumis directement pour ce projet via un ticket GitHub ou une pull request.

Structure du répertoire

root@kitploit:~
| - ansible
|  | - ansible.cfg
|  | - domain-controller.yml
|  | - domain-member.yml
|  | - domain_setup.yml
|  | - group_vars
|  |  | - all
|  |  | - wazuh
|  | - inventory.azure_rm.yml
|  | - roles
|  |  | - domain-controller
|  |  |  | - tasks
|  |  |  |  | - main.yml
|  |  | - domain-member
|  |  |  | - tasks
|  |  |  |  | - main.yml
|  |  | - fleetserver
|  |  |  | - tasks
|  |  |  |  | - main.yml
|  |  |  | - templates
|  |  |  |  | - config.yml.j2
|  |  |  |  | - ssl.crt
|  |  |  |  | - ssl.key
|  |  |  |  | - systemd-fleetm.service.j2
|  |  | - monitor
|  |  |  | - tasks
|  |  |  |  | - main.yml
|  |  | - osqueryagent
|  |  |  | - tasks
|  |  |  |  | - main.yml
|  |  |  | - templates
|  |  |  |  | - osquery.conf
|  |  |  |  | - osquery.flags.j2
|  |  |  |  | - osquery.key.j2
|  |  |  |  | - ssl.crt
|  |  |  |  | - ssl.key
|  |  |  | - vars
|  |  |  |  | - main.yml
|  |  | - sysmon
|  |  |  | - handlers
|  |  |  |  | - main.yml
|  |  |  | - tasks
|  |  |  |  | - main.yml
|  |  |  | - vars
|  |  |  |  | - main.yml
|  |  | - velociraptorclient
|  |  |  | - tasks
|  |  |  |  | - main.yaml
|  |  |  | - templates
|  |  |  |  | - clientconfig.yml.j2
|  |  |  | - vars
|  |  |  |  | - main.yml
|  |  | - velociraptorserver
|  |  |  | - tasks
|  |  |  |  | - main.yaml
|  |  |  | - templates
|  |  |  |  | - serverconfig.yml.j2
|  |  |  |  | - systemd-velociraptor.service.j2
|  |  |  | - vars
|  |  |  |  | - main.yml
|  |  | - wazuhagent
|  |  |  | - tasks
|  |  |  |  | - main.yml
|  |  |  | - templates
|  |  |  |  | - ossec.conf.j2
|  |  |  | - vars
|  |  |  |  | - main.yml
|  |  | - wazuhserver
|  |  |  | - tasks
|  |  |  |  | - main.yaml
|  |  |  | - templates
|  |  |  |  | - sysmon_rules.xml
|  |  |  |  | - unattended-installation.sh
|  |  |  |  | - wazuh-passwords-tool.sh.j2
|  |  | - winlogbeat
|  |  |  | - tasks
|  |  |  |  | - main.yml
|  |  |  | - templates
|  |  |  |  | - config.yml.j2
|  |  |  | - vars
|  |  |  |  | - main.yml
|  | - wazuh-server.yml
| - documentation
|  | - osquery.md
|  | - pic
|  |  | - map.png
|  |  | - wazuh-logs.PNG
|  |  | - wazuh-pdc.PNG
|  |  | - winlogbeat.PNG
|  | - sysmon.md
|  | - velociraptor.md
|  | - wazuh.md
|  | - winlogbeat.md
|  | - winmember.md
| - main.tf
| - README.md
| - terraform.tfstate
| - terraform.tfstate.backup
| - variables.tf

FAQ

  • J'obtiens Disk wks-1-os-disk already exists in resource group BLUETEAM-LAB. Only CreateOption.Attach is supported. ou quelque chose de similaire à cette erreur.

    • Réexécutez les commandes Terraform terraform destroy -auto-approve && terraform apply -auto-approve pour détruire et recréer le laboratoire. Cette erreur semble apparaître lorsqu'Azure ne nettoie pas correctement tous les disques, laissant ainsi des ressources résiduelles avec le même nom.
  • J'obtiens Operation 'startTenantUpdate' is not allowed on VM 'domain-controller' since the VM is marked for deletion. You can only retry the Delete operation (or wait for an ongoing one to complete). ou quelque chose de similaire à cette erreur.

    • Réexécutez les commandes Terraform terraform destroy -auto-approve && terraform apply -auto-approve pour détruire et recréer le laboratoire. Cette erreur semble apparaître lorsqu'Azure ne nettoie pas correctement toutes les ressources, laissant des résidus qui doivent être détruits avant la création du laboratoire en raison de conflits de noms et/ou d'emplacements.
  • J'obtiens Network security group windows-nsg cannot be deleted because old references for the following Nics ou quelque chose de similaire à cette erreur.

    • Réexécutez les commandes Terraform terraform destroy -auto-approve && terraform apply -auto-approve pour détruire et recréer le laboratoire. Cette erreur semble apparaître lorsqu'Azure ne nettoie pas correctement toutes les ressources, laissant des résidus qui doivent être détruits avant la création du laboratoire en raison de conflits de noms et/ou d'emplacements.

Sources d'inspiration et remerciements

Une bonne partie de ce code a été empruntée et adaptée d'Adaz de Christophe Tafani-Dereeper. Un grand merci d'avoir construit la base qui m'a permis de concevoir cet environnement de laboratoire.

Télécharger l’outil
Wazuh Server
  • Pe-SieveToWinEventLog Scanner Pe-Sieve configuré pour journaliser les données dans le journal des événements Windows toutes les 3 heures et expédier les données vers l'instance Elastic installée avec Wazuh Server.
  • Nom de la règleGroupe de sécurité réseauHôte sourcePort sourceHôte de destinationPort de destination
    Allow-RDPwindows-nsgVotre IP publique*PDC-1, DETECTION1, DETECTION23389
    Allow-WinRMwindows-nsgVotre IP publique*PDC-1, DETECTION1, DETECTION25985
    Allow-WinRM-securewindows-nsgVotre IP publique*PDC-1, DETECTION1, DETECTION25986
    Allow-SMBwindows-nsgVotre IP publique*PDC-1, DETECTION1, DETECTION2445
    Allow-SSHwazuh-nsgVotre IP publique*Wazuh22
    Allow-Wazuh-Managerwazuh-nsgVotre IP publique*Wazuh1514-1516
    Allow-Wazuh-Elasticsearchwazuh-nsgVotre IP publique*Wazuh9200
    Allow-Wazuh-APIwazuh-nsgVotre IP publique*Wazuh55000
    Allow-Elasticsearch-Clusterwazuh-nsgVotre IP publique*Wazuh9300-9400
    Allow-Wazuh-GUIwazuh-nsgVotre IP publique*Wazuh443
    Allow-Velociraptor-Client-Connectionswazuh-nsgVotre IP publique*Wazuh8000
    Allow-Velociraptor-GUIwazuh-nsgVotre IP publique*Wazuh10000
    Allow-Fleet-GUIwazuh-nsgVotre IP publique*Wazuh9999
    HôteRôleIP interne
    PDC-1Contrôleur de domaine principal10.0.10.10
    WazuhServeur Wazuh, héberge également Velocidex Velociraptor et FleetDM10.0.10.100
    DETECTION1Poste de travail Windows 1010.0.11.11
    DETECTION2Poste de travail Windows 1010.0.11.12
    HôteIdentifiantMot de passeRôle
    PDC-1blueteam.lab\blueteamBlueTeamDetection0%%%Administrateur de domaine pour le domaine blueteam.lab
    DETECTION1localadministratorBlueTeamDetection0%%%Administrateur local du poste de travail DETECTION1
    DETECTION2localadministratorBlueTeamDetection0%%%Administrateur local du poste de travail DETECTION2
    WazuhblueteamBlueTeamDetection0%%%Identifiant SSH pour le serveur Wazuh
    WazuhwazuhBlueTeamDetection0%%%Administrateur Wazuh
    WazuhadminBlueTeamDetection0%%%Administrateur Wazuh
    WazuhkibanaserverBlueTeamDetection0%%%Compte de service Wazuh
    WazuhkibanaroBlueTeamDetection0%%%Compte de service Wazuh
    WazuhlogstashBlueTeamDetection0%%%Compte de service Wazuh
    WazuhreadallBlueTeamDetection0%%%Compte de service Wazuh
    WazuhsnapshotrestoreBlueTeamDetection0%%%Compte de service Wazuh
    Wazuhwazuh_adminBlueTeamDetection0%%%Compte de service Wazuh
    Wazuhwazuh_userBlueTeamDetection0%%%Compte de service Wazuh
    WazuhblueteamBlueTeamDetection0%%%Identifiant portail web Velociraptor
    Wazuh[email protected]BlueTeamDetection0%%%Identifiant portail web FleetDM
  • Pourquoi Azure ?

    • Des crédits gratuits sont disponibles avec un compte d'essai
  • Comment modifier les segments réseau, la taille de déploiement ou d'autres variables ?

    • Modifiez le fichier de variables Terraform pour changer votre configuration. Alternativement, chaque variable peut être modifiée lors de l'exécution en ajoutant -var à terraform apply. Par exemple, terraform apply --auto-approve -var="region=East US 2" modifierait une région pour qu'elle soit différente de celle définie par défaut dans le fichier variables. L'ensemble de la configuration, y compris les plages réseau, les systèmes d'exploitation et la taille des machines virtuelles, peut être modifié en utilisant une chaîne de paramètres -var.
  • Comment trouver les SKU pour un déploiement spécifique ?

    • Utilisez la commande Azure az vm list-skus --location westeurope --all --output table pour trouver les SKU disponibles pour votre déploiement.
  • J'obtiens Max retries exceeded with url: /wsman puis la connexion est refusée lors de la construction d'un système.

    • Malheureusement, les limitations de WinRM font que, parfois, WinRM cesse simplement de fonctionner comme prévu et les connexions se bloquent. Par conséquent, l'exécution ne se comportera pas correctement. Réexécutez terraform apply -auto-approve pour réparer l'hôte endommagé.