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/gregdurys/specterops-k8s-red-teamers-libvirt-patch
Segurança na NuvemAprendizado e EducaçãoRed TeamingLabs e Prática
GitHubgregdurys/specterops-k8s-red-teamers-libvirt-patch

specterops-k8s-red-teamers-libvirt-patch

Patch não oficial do libvirt para o laboratório gratuito Kubernetes para Red Teamers da SpecterOps

Ver Repositório
10há 5 diasAinda não revisado

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

Patch Libvirt do SpecterOps Kubernetes para Red Teamers

Um patch não oficial de libvirt e QEMU/KVM para o curso gratuito SpecterOps Kubernetes for Red Teamers. Os endereços de rede originais, a topologia Kubernetes, os callbacks do Mythic e o comportamento do laboratório permanecem inalterados.

Porquê?

Porque executar VirtualBox no Linux é como levar um gerador portátil para uma casa que já está ligada à rede elétrica; você paga duas vezes por algo que o kernel já lhe dá, enquanto adiciona outro hipervisor e superfície de ataque de módulos de kernel. O KVM faz parte do Linux, enquanto o QEMU e o libvirt fornecem as camadas de máquina virtual e gestão em torno dele. Isso evita adicionar uma pilha separada de módulos de hipervisor de terceiros a um host Linux.

O VirtualBox resolve o problema de distribuição multiplataforma do curso; o libvirt resolve o problema do host Linux. O provider VirtualBox original permanece intocado para utilizadores de Windows e macOS, enquanto este patch permite que utilizadores Linux executem o mesmo laboratório no KVM.

Este repositório intencionalmente não contém o arquivo do laboratório SpecterOps nem uma cópia da sua árvore de código-fonte. Obtenha o material original através do curso oficial:

  1. Registe-se ou inicie sessão em Kubernetes for Red Teamers.
  2. Abra Lab Infrastructure and Configuration.
  3. Transfira Lab Environment Files.

Conteúdo do repositório

root@kitploit:~
README.md
ARCHITECTURE.md
LICENSE
NOTICE.md
UPSTREAM_SHA256SUMS
docs/
  libvirt-lab-provisioned.png
patches/
  libvirt.patch
  SHA256SUMS

patches/libvirt.patch contém apenas as alterações necessárias para adicionar suporte a libvirt. Não contém o arquivo original, planos de conversão internos, relatórios de revisão, harness de teste local, credenciais geradas ou estado da VM.

Requisitos

  • Um host Linux com QEMU/KVM e libvirt;
  • Vagrant 2.4 ou mais recente;
  • O plugin vagrant-libvirt;
  • Recursos suficientes para executar quatro VMs de laboratório, que utilizam 8 vCPUs e 16 GiB de RAM no total
  • Um backend de pasta sincronizada bidirecional selecionado automaticamente ou explicitamente.

Instalação

Transfira k8s-attack-path-part-1-lab-assets.tar.gz da secção Lab Infrastructure and Configuration do curso gratuito SpecterOps.

Extraia os ficheiros originais do laboratório:

root@kitploit:~
mkdir -p ~/kubernetes-for-red-teamers
cd ~/Downloads
tar xzvf k8s-attack-path-part-1-lab-assets.tar.gz -C ~/kubernetes-for-red-teamers

Clone o repositório do patch:

root@kitploit:~
cd ~
git clone https://github.com/GregDurys/specterops-k8s-red-teamers-libvirt-patch.git

Verifique o patch:

root@kitploit:~
cd ~/specterops-k8s-red-teamers-libvirt-patch
sha256sum -c patches/SHA256SUMS

O resultado deve ser:

root@kitploit:~
patches/libvirt.patch: OK

Opcionalmente, verifique o arquivo transferido em relação à versão utilizada para testar este patch:

root@kitploit:~
cd ~/Downloads
sha256sum -c ~/specterops-k8s-red-teamers-libvirt-patch/UPSTREAM_SHA256SUMS

Se o checksum diferir, a SpecterOps pode ter atualizado os ficheiros do laboratório.

Aplique o patch:

root@kitploit:~
cd ~/kubernetes-for-red-teamers
git apply --check ~/specterops-k8s-red-teamers-libvirt-patch/patches/libvirt.patch
git apply ~/specterops-k8s-red-teamers-libvirt-patch/patches/libvirt.patch

Valide a configuração:

root@kitploit:~
vagrant validate

O resultado deve ser:

root@kitploit:~
Vagrantfile validated successfully.

O patch adiciona o seu próprio README de utilização do laboratório e documento de arquitetura ao diretório extraído.

Inicie o laboratório a partir do diretório do curso com patch:

root@kitploit:~
vagrant up --provider=libvirt

O Vagrantfile desativa automaticamente o arranque paralelo porque as máquinas posteriores consomem ficheiros gerados pelo control plane.

Callbacks do Mythic developer e noaccess juntamente com o aprovisionamento libvirt concluído e quatro VMs em execução

Topologia do laboratório

A topologia funcional mostrada no diagrama do curso é preservada:

Elemento do diagramaConversão Libvirt
Teamserver192.168.56.10, DNS teamserver
Control plane192.168.56.20, servidor API em TCP 6443
Worker 1192.168.56.30
Worker 2192.168.56.31
UI MythicTCP 7443
Porta de callbackTCP 8081
Registry TLSTCP 5000, confiável pelos nós do cluster
Callbacks MythicCallbacks developer e noaccess mantidos
Acesso do hostO Vagrant encaminha as portas 7443 e 8081 para o teamserver
Tráfego privado do laboratórioPermanece na rede isolada 192.168.56.0/24
Acesso à InternetMantido através do adaptador 1
Resolução de nomes de hostMantida em todas as quatro VMs
Code-server e manifests do laboratórioInalterados em relação ao upstream

A implementação de rede tem uma diferença deliberada:

  • O VirtualBox dá a cada VM um motor NAT independente no adaptador 1.
  • O Libvirt liga as quatro VMs à rede NAT dedicada k8s-workshop-mgmt, normalmente 192.168.157.0/24.

As VMs libvirt podem, portanto, comunicar através do adaptador 1, enquanto os adaptadores NAT separados do VirtualBox não fornecem esse caminho. Kubernetes, Calico, callbacks Mythic, o registry e a resolução de nomes de host do laboratório estão explicitamente fixados ao adaptador 2, pelo que a topologia do laboratório permanece inalterada.

Leia ARCHITECTURE.md para detalhes da topologia, tratamento de colisões e justificação da pasta sincronizada.

Verificações pós-aprovisionamento

Após a conclusão do aprovisionamento:

root@kitploit:~
vagrant status
vagrant ssh control-plane-1 -c 'kubectl get nodes -o wide'
vagrant port --guest 7443 teamserver
curl --insecure --head https://192.168.56.10:7443

Os três nós Kubernetes devem estar Ready com endereços internos .20, .30 e .31. A página de início de sessão do Mythic deve estar acessível através da porta do host encaminhada e diretamente em https://192.168.56.10:7443. Os dois callbacks do curso devem aparecer no Mythic conforme descrito pelo material oficial do curso.

Para desmontar o ambiente de teste:

root@kitploit:~
vagrant destroy -f

Licença

O trabalho original neste repositório está licenciado sob a Apache License 2.0.

Esta licença aplica-se apenas ao código e documentação originais contribuídos por este repositório. Não concede quaisquer direitos sobre o curso SpecterOps, arquivo transferido ou outro material upstream.

Baixar ferramenta