pentest-dotfiles

Dotfiles + bootstrap de ferramentas pra deixar uma VM nova (Kali, Ubuntu ou Debian) pronta pra pentest rápido, num único comando.

Uso restrito a máquinas próprias, labs de estudo (OSCP, HTB, Solyd, Exploit Mind) e engajamentos com autorização formal. As ferramentas aqui são as mesmas usadas no dia a dia de qualquer pentester — o script só automatiza a instalação delas.

Uso rápido numa VM nova

git clone https://github.com/s3mPr1linux/PENTEST_DOTFILES.git 
cd ~/PENTEST_DOTFILES
chmod +x install.sh scripts/*.sh
./install.sh --all

Depois é só abrir um shell novo (ou source ~/.bashrc) pra tudo entrar no PATH.

Instalação seletiva

./install.sh --recon        # subfinder, amass, httpx, nuclei
./install.sh --webapp       # ffuf, gobuster, sqlmap
./install.sh --ad           # impacket, bloodhound-python, netexec
./install.sh --wordlists    # SecLists, rockyou.txt, hashcat, john
./install.sh --dotfiles     # .vimrc / .bashrc / .gitconfig + Vundle

# combina o que quiser:
./install.sh --recon --webapp --dotfiles

O que cada módulo instala

Módulo	Ferramentas	Como
--recon	subfinder, amass, httpx, nuclei (+ templates)	go install
--webapp	ffuf, gobuster, sqlmap	go install / git em /opt
--ad	impacket, bloodhound-python, netexec	pipx
--wordlists	SecLists, rockyou.txt, hashcat, john	git clone + apt
--dotfiles	.vimrc, .bashrc, .gitconfig, Vundle + plugins	symlink

Burp Suite não é instalado automaticamente — é GUI com licença própria. Baixe em https://portswigger.net/burp.

BloodHound GUI (manual)

O script instala só o ingestor (bloodhound-python), que já cobre 90% do uso em campo. Se quiser a interface gráfica pra visualizar o grafo, a forma mais simples é via Docker:

curl -L https://ghst.ly/getbhce -o docker-compose.yml
docker compose up

Isso sobe BloodHound CE + Neo4j já configurados. Acesse em http://localhost:8080.

Estrutura do repo

pentest-dotfiles/
├── install.sh              # entrypoint — parse de flags e orquestração
├── README.md
├── config/
│   ├── vimrc
│   ├── bashrc
│   └── gitconfig
└── scripts/
    ├── lib.sh               # cores, logging, detecção de distro, helpers
    ├── 10-recon-osint.sh
    ├── 20-webapp.sh
    ├── 30-ad-windows.sh
    ├── 40-wordlists-cracking.sh
    └── 90-dotfiles.sh

Adicionando uma ferramenta a um módulo existente

Cada módulo é só uma função bash. Pra adicionar algo no módulo de recon, por exemplo, edita scripts/10-recon-osint.sh e acrescenta:

go_install "github.com/owner/ferramenta@latest" "nome-amigavel"

Ou, pra ferramentas Python:

pipx_install "nome-do-pacote" "nome-amigavel"

Ou pra clonar um repo pra /opt e criar um wrapper em /usr/local/bin (mesmo padrão usado pro sqlmap em scripts/20-webapp.sh).

Adicionando uma categoria (módulo) nova

Isso é diferente do item acima: aqui é pra quando você quer uma flag nova inteira (ex: --mobile, --osint-social, --wireless), não só uma ferramenta a mais dentro de um módulo que já existe.

1. Crie o arquivo do módulo em scripts/. Escolha um prefixo numérico que reflita a ordem de execução — os módulos rodam na ordem dos números, e o 90-dotfiles.sh fica por último de propósito, então qualquer coisa nova costuma ficar entre 40- e 90- (ex: 50-):

#!/usr/bin/env bash
# ============================================================
# 50-nome-da-categoria.sh — descrição curta
# ============================================================
set -uo pipefail
DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# shellcheck disable=SC1091
source "${DIR}/lib.sh"

install_nome_da_categoria() {
    log_head "Nome da Categoria"

    ensure_go || true                                    # ferramentas Go
    go_install "github.com/owner/tool@latest" "tool"

    ensure_pipx                                           # ferramentas Python
    pipx_install "pacote-pypi" "nome-amigavel"

    apt_refresh_once; apt_install pacote1 pacote2          # pacotes apt

    git_clone_or_update "https://github.com/owner/repo.git" "/opt/repo"  # clonar do zero

    log_ok "Nome da Categoria concluído"
}

2. No install.sh, adicione o source junto dos outros módulos, logo abaixo da declaração de REPO_DIR:

source "${REPO_DIR}/scripts/50-nome-da-categoria.sh"

3. Adicione a flag em três pontos dentro do install.sh:

No usage(), na lista de opções:

  --categoria     Descrição curta do que instala

Na declaração de variáveis dentro de main():

RUN_CATEGORIA=0

No case do parsing de argumentos — e, se quiser que --all já inclua essa categoria, também na linha do --all:

--all)
    RUN_RECON=1; RUN_WEBAPP=1; RUN_AD=1; RUN_WORDLISTS=1; RUN_DOTFILES=1; RUN_CATEGORIA=1
    ;;
...
--categoria) RUN_CATEGORIA=1 ;;

4. Chame a função condicionalmente, junto dos outros [ "$RUN_..." -eq 1 ] && ... dentro de main():

[ "$RUN_CATEGORIA" -eq 1 ] && install_nome_da_categoria

5. (Opcional) Liste as ferramentas novas no summary(), no array tools, pra elas aparecerem no resumo final de "o que ficou disponível".

6. Teste antes de confiar:

chmod +x scripts/50-nome-da-categoria.sh
bash -n scripts/50-nome-da-categoria.sh   # checa sintaxe sem executar
./install.sh --categoria                  # testa isolado, sem rodar tudo de novo

Depois é só atualizar a tabela em "O que cada módulo instala" (mais acima neste README) com a linha da categoria nova.

Antes de usar

No config/gitconfig, troca:

[user]
    name = SEU NOME AQUI
    email = seu.email@exemplo.com

pelos seus dados de verdade — senão seus commits saem assinados errado.

Por que os módulos são idempotentes

Rodar ./install.sh --all de novo numa máquina que já tem tudo instalado não quebra nada: go install e pipx install apenas reinstalam/atualizam a versão mais recente, e git_clone_or_update (em lib.sh) faz git pull em vez de clonar de novo se o repo já existir. Dá pra rodar como rotina de manutenção pra manter as ferramentas atualizadas.