Teste de penetração black-box contra HackSudo Thor: CVE-2014-6271 Shellshock RCE através do Apache mod_cgi, encadeado com configuração incorreta do sudo e injeção de eval bash para escalação total de privilégios. Inclui ferramentas personalizadas de força bruta cientes de CSRF e automação Metasploit RPC.
heventafese/penetration-testing-walkthrough-hacksudo-thor
Alvo: HackSudo Thor do VulnHub
Objetivo: Obter acesso root e ler/root/proof.txt
Ambiente: Laboratório VirtualBox isolado segmentado por um firewall pfSense
Este repositório documenta um teste de penetração parcial em caixa preta realizado no HackSudo Thor, uma máquina virtual intencionalmente vulnerável publicada no VulnHub por Vishal Waghmare. O objetivo era simular um ataque do mundo real onde um atacante externo tenta comprometer um sistema interno isolado com o objetivo principal sendo obter acesso root e ler o conteúdo de /root/proof.txt.
A avaliação segue o ciclo completo de teste de penetração: reconhecimento passivo, descoberta de rede, enumeração, avaliação de vulnerabilidades, exploração, escalação de privilégio, pós-exploração e cobertura de rastros.
As ferramentas principais utilizadas foram Nmap para varredura de rede, Nessus para avaliação de vulnerabilidades e o Metasploit Framework como plataforma principal de exploração e pós-exploração. John the Ripper, Hashcat e Rainbow Tables online foram usados durante a fase de quebra de senhas, embora todas as tentativas tenham sido, em última análise, malsucedidas devido à força do algoritmo de hash em uso.
O laboratório virtual foi construído inteiramente no VirtualBox e projetado para simular uma rede empresarial realista com três zonas de segurança distintas, todas gerenciadas por um firewall pfSense 2.7.2. As três redes NAT foram configuradas da seguinte forma: uma zona WAN simulando a internet pública onde a máquina atacante Kali reside, uma zona DMZ hospedando a máquina alvo e uma zona LAN interna contendo máquinas fora do escopo.``` Internet Zone — NatNetwork (10.0.2.0/24) │ │ Kali Linux 2025.4 [attacker] — 10.0.2.9 │ pfSense WAN interface — 10.0.2.8 │ ├── pfSense Firewall (boundary device) │ ├── DMZ Zone — DMZnat (10.0.4.0/24) │ ├── HackSudo Thor [TARGET] — 10.0.4.3 │ └── DVWA — 10.0.4.4 (out of scope) │ └── LAN Zone — LANnat (10.0.3.0/24) ├── Metasploitable 2 — 10.0.3.5 (out of scope) └── Windows XP Cyberlab — 10.0.3.4 (out of scope)
*Zonas de segurança da topologia lógica de rede gerenciadas pelo pfSense*
A interface WAN recebeu o endereço `10.0.2.8/24` via DHCP, a interface LAN foi configurada como `10.0.3.1/24` e a interface OPT1 (DMZ) foi configurada como `10.0.4.1/24`. Para introduzir uma configuração incorreta deliberada no laboratório, a porta 80 foi intencionalmente deixada exposta na interface WAN do pfSense, simulando uma exposição comum de painel de administração no mundo real que serviu como ponto de entrada principal na rede interna.
---
## Resumo da Cadeia de Ataque```
[Kali Linux — 10.0.2.9]
│
│ CSRF-aware Python brute force → admin / pfsense
▼
[pfSense webConfigurator — 10.0.2.8:80]
│
│ Firewall rules disabled → DMZ and LAN now reachable
▼
[HackSudo Thor — 10.0.4.3]
│
│ Shellshock RCE (CVE-2014-6271)
│ Apache mod_cgi → /cgi-bin/shell.sh
▼
[Meterpreter shell — www-data]
│
│ sudo -u thor /home/thor/hammer.sh
│ Command injection via eval → bash -i payload
▼
[Interactive shell — thor]
│
│ GTFOBins: sudo service ../../bin/bash
▼
[Root shell]
│
├── /root/proof.txt captured ✅
├── /etc/shadow + /etc/passwd exfiltrated
└── SSH RSA backdoor planted
Antes de fazer qualquer contato com o ambiente alvo, as informações foram coletadas exclusivamente de fontes públicas. As duas fontes principais foram a página oficial de entrada do VulnHub para o HackSudo Thor e o perfil público do autor no GitHub.
A página do VulnHub confirmou que o alvo era um sistema baseado em Linux, classificado como fácil a médio, com o objetivo de encontrar a flag proof.txt. Revisar o perfil do autor no GitHub deu uma visão adicional. Vishal Waghmare projeta consistentemente máquinas Linux boot-to-root com escalação de privilégios como o desafio central em toda a série HackSudo. Isso moldou o modelo de ameaça ao entrar nas fases ativas: os serviços HTTP e SSH eram a superfície de ataque mais provável, e o caminho de escalação foi previsto para envolver configuração incorreta do sudo, abuso de binário SUID ou exploração de um serviço personalizado.
Esse tipo de análise de padrão do autor também é importante em um engajamento real. Entender como um sistema provavelmente foi projetado e quais categorias de fraqueza seu administrador provavelmente repetirá fornece direção antes que um único pacote seja enviado.
| Campo | Detalhe |
|---|---|
| Alvo | HackSudo Thor |
| Autor | Vishal Waghmare (@hacksudo) |
| Lançamento | 3 de agosto de 2021 |
| Dificuldade | Fácil a Médio |
| SO | Linux (Debian) |
| Formato | VirtualBox OVA |
| DHCP | Habilitado |
| Superfície de Ataque Prevista | HTTP, SSH, configuração incorreta do sudo provável |
Esta fase envolveu fazer contato ativo direto com o ambiente. O objetivo era identificar todos os hosts ativos, entender o limite da rede e construir uma imagem de toda a superfície de ataque antes de focar no alvo principal.
Uma varredura de ping leve do Nmap (-sn) foi executada primeiro na sub-rede WAN (10.0.2.0/24) para descobrir hosts ativos com o mínimo de ruído. Três hosts foram identificados: 10.0.2.1 e 10.0.2.2 eram endereços padrão da infraestrutura do VirtualBox, o que deixou 10.0.2.8 como o único host não pertencente à infraestrutura. Essa máquina tornou-se o foco imediato.
Uma varredura SYN stealth completa contra 10.0.2.8 não retornou nenhum resultado. Isso era um comportamento esperado, não um erro. Firewalls empresariais são projetados para não responder à varredura de portas, descartando pacotes silenciosamente em vez de responder. A ausência de resultados era, por si só, uma confirmação de que este era um dispositivo de borda de rede filtrando ativamente o tráfego.
Para confirmar quais serviços estavam realmente em execução sem depender de varredura de pacotes, uma solicitação HTTP direta foi emitida usando o curl. Essa abordagem foi adotada porque uma solicitação web padrão tem muito menos probabilidade de ser filtrada do que uma ferramenta de varredura. A resposta veio como HTTP/1.1 200 OK com Server: nginx e um título de página pfSense, confirmando que o webConfigurator estava acessível diretamente na porta 80 a partir da interface WAN.