Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
Ferramentas/GitHubGitHub/op7ic/blueteam.lab
Ferramentas DefensivasAuditoria de ConfiguraçãoForensia DigitalTestes de PenetraçãoSegurança na NuvemDetecção de IntrusãoAprendizado e EducaçãoResposta a IncidentesAnálise de LogsLabs e Prática
GitHubop7ic/blueteam.lab

BlueTeam.Lab

18723há 1 anoRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

Laboratório de detecção do Blue Team criado com Terraform e Ansible no Azure.

Ver Repositório

BlueTeam.Lab

BlueTeam.Lab

Propósito

Este projeto contém um conjunto de scripts Terraform e Ansible para criar um BlueTeam Lab orquestrado. O objetivo deste projeto é fornecer às equipes vermelha e azul a capacidade de implantar um laboratório de detecção ad-hoc para testar vários ataques e artefatos forenses no ambiente Windows mais recente e, em seguida, obter uma visão 'do tipo SOC' dos dados gerados.

NOTA: Este laboratório foi deliberadamente projetado para ser inseguro. Por favor, não conecte este sistema a nenhuma rede que você considere importante.


Layout do Laboratório


Pré-requisitos

Uma série de funcionalidades precisam ser instaladas no seu sistema para usar esta configuração.

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

Construindo e Implantando o BlueTeam.Lab

Depois que todos os pré-requisitos estiverem instalados, execute a seguinte série de etapas:

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.

Implantando Diferentes Versões do Windows

As variáveis do Terraform definem o tipo de sistemas operacionais usados nesta implantação. Uma simples modificação nas variáveis de tempo de execução permite especificar diferentes sistemas operacionais para executar todo o Active Directory (AD). A opção padrão é usar Windows 10 Enterprise para as Workstations e Windows Server 2019 Datacenter para o Controlador de Domínio. Aqui estão exemplos de algumas opções de configuração comuns que podem ser usadas para modificar todo o ambiente para usar diferentes versões de SO:

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"

O comando az vm image list pode ser usado para identificar várias versões de SO para a implantação.


Funcionalidades

  • AD do Windows com duas estações de trabalho conectadas ao domínio Windows na configuração padrão.
  • Arquivo de configuração de domínio flexível permitindo alterações fáceis na configuração subjacente.
  • Políticas de auditoria configuradas com base no CIS Guide para aumentar a visibilidade de eventos na infraestrutura Windows. Auditpol usado para configurar configurações adicionais e logs de Transcrição do PowerShell habilitados.
  • Sysmon64 implantado na infraestrutura usando a configuração mais recente do SwiftOnSecurity para dispositivos Windows.
  • Servidor Wazuh configurado e operacional para coletar logs dos dispositivos.
  • Agentes Wazuh configurados na infraestrutura e alimentando dados no servidor Wazuh.
  • Firewall configurado para permitir apenas o seu próprio IP acessar os sistemas implantados.
  • OSQuery e FleetDM instalados na infraestrutura, usando modelos de configuração do Palantir.
  • Servidor Velocidex Velociraptor configurado e operacional.
  • Agentes Velocidex Velociraptor configurados na infraestrutura e alimentando dados no servidor Velociraptor.
  • WinLogBeat configurado para registrar dados na instância Elastic.
  • LokiToWinEventLog Scanner Loki configurado para registrar dados no Log de Eventos do Windows a cada 3 horas e enviar dados para a instância Elastic instalada com o Servidor Wazuh.

Documentação

A seção a seguir descreve vários componentes que compõem este laboratório, juntamente com detalhes sobre como alterar os arquivos de configuração para modificar a configuração:

  • Servidor OSQuery e Fleetdm
  • Servidor Wazuh e Agente Wazuh
  • Sysmon
  • WinLogBeat
  • Servidor Velociraptor e Agente Velociraptor
  • Membros do Domínio

Credenciais

Uma vez que o laboratório é construído, o Terraform imprimirá a localização real dos sistemas e as credenciais associadas. Um exemplo de saída pode ser encontrado abaixo.

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

Configuração do Firewall

A tabela a seguir resume um conjunto de regras de firewall aplicadas em todo o ambiente BlueTeamLab na configuração padrão. Por favor, modifique o arquivo main.tf para adicionar novas regras de firewall conforme necessário na seção Firewall Rule Setup.

Internamente, os seguintes IPs estáticos e nomes de host são usados na faixa 10.0.0.0/16 para este ambiente na configuração padrão:


Configuração de Usuário

As seguintes credenciais padrão são criadas durante a instalação. A impressão das credenciais reais configuradas será exibida após a conclusão do processo completo de implantação.

Para modificar as credenciais padrão, altere os nomes de usuário e senhas no arquivo domain_setup.yml.

Capturas de Tela

Contribuição

Contribuições, correções e melhorias podem ser submetidas diretamente para este projeto como uma issue do GitHub ou um pull request.

Estrutura de Diretórios

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

Perguntas Frequentes (FAQ)

  • Eu recebo Disk wks-1-os-disk already exists in resource group BLUETEAM-LAB. Only CreateOption.Attach is supported. ou algo semelhante a este erro.

    • Execute novamente os comandos terraform terraform destroy -auto-approve && terraform apply -auto-approve para destruir e recriar o laboratório. Este erro parece aparecer quando o Azure não limpa todos os discos corretamente, deixando recursos residuais com o mesmo nome.
  • Eu recebo 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 algo semelhante a este erro.

    • Execute novamente os comandos terraform terraform destroy -auto-approve && terraform apply -auto-approve para destruir e recriar o laboratório. Este erro parece aparecer quando o Azure não limpa todos os recursos corretamente, deixando resíduos que precisam ser destruídos antes da criação do laboratório devido a conflitos de nomes e/ou localizações.
  • Eu recebo Network security group windows-nsg cannot be deleted because old references for the following Nics ou algo semelhante a este erro.

    • Execute novamente os comandos terraform terraform destroy -auto-approve && terraform apply -auto-approve para destruir e recriar o laboratório. Este erro parece aparecer quando o Azure não limpa todos os recursos corretamente, deixando resíduos que precisam ser destruídos antes da criação do laboratório devido a conflitos de nomes e/ou localizações.

Fontes de Inspiração e Agradecimentos

Uma boa parte deste código foi emprestada e adaptada do Adaz de Christophe Tafani-Dereeper. Um enorme agradecimento por construir a base que me permitiu projetar este ambiente de laboratório.

Baixar ferramenta
  • Pe-SieveToWinEventLog Scanner Pe-Sieve configurado para registrar dados no Log de Eventos do Windows a cada 3 horas e enviar dados para a instância Elastic instalada com o Servidor Wazuh.
  • Nome da RegraGrupo de Segurança de RedeHost de OrigemPorta de OrigemHost de DestinoPorta de Destino
    Allow-RDPwindows-nsgSeu IP Público*PDC-1, DETECTION1, DETECTION23389
    Allow-WinRMwindows-nsgSeu IP Público*PDC-1, DETECTION1, DETECTION25985
    Allow-WinRM-securewindows-nsgSeu IP Público*PDC-1, DETECTION1, DETECTION25986
    Allow-SMBwindows-nsgSeu IP Público*PDC-1, DETECTION1, DETECTION2445
    Allow-SSHwazuh-nsgSeu IP Público*Wazuh22
    Allow-Wazuh-Managerwazuh-nsgSeu IP Público*Wazuh1514-1516
    Allow-Wazuh-Elasticsearchwazuh-nsgSeu IP Público*Wazuh9200
    Allow-Wazuh-APIwazuh-nsgSeu IP Público*Wazuh55000
    Allow-Elasticsearch-Clusterwazuh-nsgSeu IP Público*Wazuh9300-9400
    Allow-Wazuh-GUIwazuh-nsgSeu IP Público*Wazuh443
    Allow-Velociraptor-Client-Connectionswazuh-nsgSeu IP Público*Wazuh8000
    Allow-Velociraptor-GUIwazuh-nsgSeu IP Público*Wazuh10000
    Allow-Fleet-GUIwazuh-nsgSeu IP Público*Wazuh9999
    HostFunçãoIP Interno
    PDC-1Controlador de Domínio Primário10.0.10.10
    WazuhServidor Wazuh, também hospedando Velocidex Velociraptor e FleetDM10.0.10.100
    DETECTION1Estação de Trabalho Windows 10 110.0.11.11
    DETECTION2Estação de Trabalho Windows 10 210.0.11.12
    HostLoginSenhaFunção
    PDC-1blueteam.lab\blueteamBlueTeamDetection0%%%Administrador de Domínio para o domínio blueteam.lab
    DETECTION1localadministratorBlueTeamDetection0%%%Administrador Local da estação de trabalho DETECTION1
    DETECTION2localadministratorBlueTeamDetection0%%%Administrador Local da estação de trabalho DETECTION2
    WazuhblueteamBlueTeamDetection0%%%Credenciais SSH para o servidor Wazuh
    WazuhwazuhBlueTeamDetection0%%%Administrador Wazuh
    WazuhadminBlueTeamDetection0%%%Administrador Wazuh
    WazuhkibanaserverBlueTeamDetection0%%%Conta de serviço Wazuh
    WazuhkibanaroBlueTeamDetection0%%%Conta de serviço Wazuh
    WazuhlogstashBlueTeamDetection0%%%Conta de serviço Wazuh
    WazuhreadallBlueTeamDetection0%%%Conta de serviço Wazuh
    WazuhsnapshotrestoreBlueTeamDetection0%%%Conta de serviço Wazuh
    Wazuhwazuh_adminBlueTeamDetection0%%%Conta de serviço Wazuh
    Wazuhwazuh_userBlueTeamDetection0%%%Conta de serviço Wazuh
    WazuhblueteamBlueTeamDetection0%%%Login do Portal Web Velociraptor
    Wazuh[email protected]BlueTeamDetection0%%%Login do Portal Web FleetDM
  • Por que Azure?

    • Créditos gratuitos estão disponíveis com conta de teste
  • Como modificar segmentos de rede, tamanho da implantação ou outras variáveis?

    • Modifique o arquivo de variáveis do Terraform para alterar sua configuração. Alternativamente, cada variável pode ser alterada durante a execução adicionando -var ao terraform apply. Por exemplo, terraform apply --auto-approve -var="region=East US 2" modificaria a região para uma diferente do padrão definido no arquivo variables. Toda a configuração, incluindo faixas de rede, sistemas operacionais e o tamanho da VM, pode ser alterada usando uma cadeia de parâmetros -var.
  • Como encontrar SKUs para uma implantação específica?

    • Use o comando Azure az vm list-skus --location westeurope --all --output table para encontrar SKUs disponíveis para sua implantação.
  • Eu recebo Max retries exceeded with url: /wsman e a conexão é recusada ao construir um sistema.

    • Infelizmente, as limitações do WinRM significam que, ocasionalmente, o WinRM simplesmente para de funcionar como esperado e as conexões congelam. Como resultado, a execução não se comporta corretamente. Execute novamente terraform apply -auto-approve para reparar o host danificado.