heventafese/penetration-testing-walkthrough-hacksudo-thorBlack-box penetration test against HackSudo Thor : CVE-2014-6271 Shellshock RCE through Apache mod_cgi, chained with sudo misconfiguration and bash eval injection for full privilege escalation. Includes custom CSRF-aware brute force tooling and Metasploit RPC automation.
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.
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.
Com a página de login confirmada, o próximo passo foi tentar recuperar as credenciais. O Hydra foi inicialmente selecionado como a ferramenta de força bruta, mas esta tentativa falhou por dois motivos. O primeiro foi que um rockyou.txt prático contém mais de 14 milhões de entradas, tornando-o impraticável dentro do prazo desta avaliação. O segundo foi técnico e mais significativo: o pfSense 2.7.2 implementa proteção de token CSRF, gerando um token criptográfico único a cada carregamento de página que deve ser enviado junto com as credenciais. O módulo HTTP POST do Hydra envia um corpo de solicitação estático e não possui mecanismo para buscar dinamicamente um novo token por tentativa, então cada envio era rejeitado antes mesmo da senha ser verificada.
Para contornar isso, um script Python personalizado foi escrito para replicar o processo completo de login do navegador. Para cada tentativa de senha, o script abre uma nova sessão, carrega a página de login, extrai o token CSRF atual do formulário HTML e, em seguida, envia as credenciais junto com esse token exatamente como um navegador faria. Uma wordlist personalizada foi construída usando o CeWL para rastrear a página de login do pfSense e extrair termos relevantes, depois complementada com fasttrack.txt para cobrir credenciais padrão conhecidas.
O script recuperou as credenciais: admin / pfsense, o padrão inalterado.
Script Python personalizado recuperando credenciais do pfSense
Com o acesso ao painel estabelecido, a configuração da interface do pfSense foi revisada para entender toda a topologia interna. Isso revelou duas sub-redes que estavam invisíveis a partir da WAN: uma LAN em 10.0.3.0/24 e uma DMZ em 10.0.4.0/24. As regras do firewall WAN foram então desabilitadas através da interface web, e duas regras de permissão foram adicionadas para permitir o tráfego do IP do atacante para ambas as sub-redes.
Varreduras de ping do Nmap em ambas as sub-redes identificaram seis hosts ativos. Quatro deles foram enumerados mais a fundo, excluindo 10.0.4.1 e 10.0.3.1, que pertenciam às interfaces gateway do pfSense. Uma varredura combinada de enumeração de serviços com detecção de versão, scripts NSE padrão e identificação de SO foi executada contra todos os quatro simultaneamente. Ao cruzar os resultados com o reconhecimento passivo, todas as máquinas na topologia foram identificadas:
O alvo foi confirmado como 10.0.4.3. Todas as atividades subsequentes foram focadas exclusivamente nesta máquina.
Com o alvo identificado, uma análise mais profunda de seus serviços foi realizada para mapear a superfície de ataque e determinar caminhos de exploração viáveis. O Metasploit Framework foi usado como plataforma principal para esta fase, especificamente porque seu backend PostgreSQL persiste todos os resultados de varredura entre sessões – hosts, serviços e vulnerabilidades são todos armazenados no banco de dados e disponíveis para referência durante fases posteriores sem a necessidade de re-varredura.
Antes de começar, o Metasploit foi inicializado com msfdb init, a conexão com o banco de dados foi verificada com db_status, e todo o trabalho subsequente foi conduzido de dentro do msfconsole.
O comando db_nmap foi usado para executar uma varredura completa contra 10.0.4.3: varredura SYN stealth, detecção de versão de serviço, scripts NSE padrão, identificação de SO e todas as 65.535 portas TCP. Os resultados foram armazenados automaticamente no banco de dados e recuperados com hosts e services. Três serviços foram confirmados como abertos: FTP na porta 21 rodando Pure-FTPd, SSH na porta 22 rodando OpenSSH 7.9p1 e HTTP na porta 80 rodando Apache 2.4.38.
Cada serviço foi então enumerado usando módulos auxiliares direcionados do Metasploit. O serviço HTTP recebeu mais atenção. Os módulos dir_scanner e http_crawler foram usados para mapear todos os caminhos e endpoints acessíveis no servidor web. O achado mais significativo disso foi o diretório /cgi-bin/ e um script chamado shell.sh. Separadamente, uma revisão manual do código-fonte HTML de news.php revelou um comentário oculto do autor fazendo referência ao diretório /cgi-bin/, uma dica deliberada apontando para uma vulnerabilidade baseada em CGI. O serviço FTP foi verificado para acesso anônimo (desabilitado), e a string de versão foi anotada para referência cruzada de CVE. O banner SSH foi recuperado para o mesmo propósito.
Com a superfície de ataque totalmente mapeada, uma avaliação estruturada de vulnerabilidades foi realizada usando duas abordagens: uma varredura automatizada do Nessus e o raciocínio manual do atacante aplicado a cada serviço.
Uma política personalizada do Nessus foi criada com varredura de CGI e teste de aplicação web explicitamente habilitados, direcionando as portas 21, 22 e 80. Essas configurações não estão habilitadas por padrão e foram críticas aqui; sem elas, o endpoint CGI não teria sido testado. A varredura durou aproximadamente 11 minutos e retornou 41 achados no total. Os achados acionáveis foram:
Os dois achados de Shellshock em /cgi-bin/shell.sh foram imediatamente a prioridade. O CVE-2014-6271 possui pontuação CVSS de 9.8 e permite execução remota de código não autenticada, o achado de maior impacto na varredura. O CVE-2014-6278 representa um patch incompleto da mesma vulnerabilidade, o que significa que mesmo sistemas parcialmente corrigidos permanecem exploráveis. A fraqueza Terrapin SSH foi avaliada como não explorável sem uma posição de homem-no-meio. Os achados restantes não tinham valor de exploração significativo neste engajamento.
Antes de passar para a exploração, o achado de Shellshock foi verificado independentemente usando o script NSE http-shellshock do Nmap direcionado diretamente ao /cgi-bin/shell.sh. A verificação independente antes da exploração é um passo importante na metodologia, pois confirma que a vulnerabilidade é real e não um falso positivo do scanner, e evita perder tempo tentando um exploit que não funcionará. O script NSE confirmou que o endpoint era vulnerável, e o CVE-2014-6271 foi selecionado como vetor de ataque primário.
Com o Shellshock confirmado, a fase de exploração começou. A vulnerabilidade existe porque o Apache mod_cgi passa cabeçalhos de solicitação HTTP como variáveis de ambiente para o Bash quando um script CGI é invocado. Em uma versão não corrigida do Bash, uma definição de função especialmente criada em uma variável de ambiente faz com que quaisquer comandos anexados após a definição sejam executados imediatamente. Ao injetar esse payload no cabeçalho User-Agent de uma solicitação para /cgi-bin/shell.sh, comandos arbitrários poderiam ser executados no servidor sem qualquer autenticação.
O módulo do Metasploit exploit/multi/http/apache_mod_cgi_bash_env_exec automatiza isso completamente. O módulo foi configurado com RHOSTS definido como 10.0.4.3, TARGETURI definido como /cgi-bin/shell.sh, o payload definido como linux/x86/meterpreter/reverse_tcp, e o listener apontado de volta para a máquina Kali na porta 4444. Executar o módulo enviou a solicitação maliciosa, o servidor executou o payload, e o Metasploit recebeu a conexão de entrada, estabelecendo uma sessão Meterpreter como www-data.
Exploit Shellshock executado e shell reversa Meterpreter estabelecida como www-data
Começando como www-data, a extensão do acesso ao sistema era inicialmente desconhecida. A prioridade imediata era entender a posição atual – quem era o usuário ativo, quais outras contas existiam e quais caminhos estavam disponíveis para privilégios mais altos.
A sessão Meterpreter foi reduzida a um shell bruto do sistema, e um pseudo-terminal foi gerado usando o módulo pty do Python para criar um terminal interativo adequado. A leitura de /etc/passwd e a listagem de /home/ confirmaram a existência de um usuário chamado thor no sistema. Um ls -la /home/thor/ inicial retornou "permission denied", então o sistema de arquivos foi pesquisado por quaisquer arquivos pertencentes a thor, independentemente das permissões de diretório, usando find / -user thor 2>/dev/null. Isso localizou um binário anômalo em /usr/local/sbin/ls, um arquivo chamado ls que não era o binário padrão do sistema. Seu conteúdo revelou que era um script personalizado pertencente a Thor, que foi anotado para investigação posterior.
O passo padrão de pós-exploração de verificar as permissões sudo do usuário atual foi realizado com sudo -l. Isso revelou que www-data tinha permissão para executar /home/thor/hammer.sh como o usuário thor sem exigir senha – uma regra NOPASSWD sem justificativa operacional legítima.
sudo -l confirmando que www-data pode executar hammer.sh como thor sem senha
O acesso direto para ler hammer.sh foi bloqueado pelas permissões de diretório, então ele foi executado primeiro com sudo -u thor /home/thor/./hammer.sh para observar seu comportamento. O script apresentou dois prompts interativos: uma "Chave Secreta" e uma "Mensagem Secreta". O primeiro prompt ecoava a entrada de volta como uma saudação. O segundo processava a entrada e depois saía. A distinção entre esses dois comportamentos era significativa: se ambos os prompts simplesmente ecoassem a entrada, nenhum seria interessante. O fato de que o segundo prompt processava a entrada antes de responder sugeria que ele estava passando o valor para um comando shell, um padrão consistente com uma instrução eval, que é uma superfície de ataque bem documentada para injeção de comando.
Em uma segunda execução, uma entrada em branco foi passada para o primeiro prompt. O payload de injeção bash -i foi fornecido para o segundo. Isso gerou um shell interativo como thor.
Payload bash -i injetado no hammer.sh
sudo -l foi executado novamente como thor. Isso revelou acesso NOPASSWD irrestrito a ambos /usr/bin/cat e service como root. A regra service foi a mais significativa. A técnica GTFOBins sudo service permite que uma string de path traversal seja passada como argumento do nome do serviço. Fornecer ../../bin/bash faz com que o binário service resolva a traversal e invoque /bin/bash com privilégios de root.```bash
sudo service ../../bin/bash
Isso produziu um shell root completo.
*Shell root obtido via GTFOBins – path traversal do sudo service confirmada*
## Fase 7: Pós-Exploração
Com a identidade root confirmada, a fase de pós-exploração focou-se em três áreas: compreender o ambiente do sistema, extrair dados sensíveis e estabelecer acesso persistente.
### Informações do Sistema e Flag
Uma enumeração básica do sistema foi realizada primeiro para confirmar a identidade do alvo e construir contexto para as recomendações de remediação, incluindo a versão do kernel, a versão do SO e a configuração de rede. O sistema foi confirmado como Debian GNU/Linux 10 (Buster) executando o kernel 4.19.0-17-686-pae em `10.0.4.3`.
O diretório home do root foi listado, revelando `proof.txt` e `root.txt`. O arquivo `proof.txt` foi lido para capturar a flag principal, o objetivo declarado deste engajamento.
*Conteúdo do proof.txt – flag principal capturada*
### Extração de Credenciais e Quebra de Senhas
Os arquivos `/etc/shadow` e `/etc/passwd` foram copiados para `/tmp` e baixados para a máquina atacante via Meterpreter. Esses dois arquivos juntos fornecem as contas de usuários do sistema e os hashes de senha necessários para quebra offline.
Várias abordagens de quebra foram tentadas. John the Ripper identificou ambos os hashes como SHA-512crypt com um fator de custo de 5.000 iterações. Uma primeira tentativa utilizando `rockyou.txt` foi abortada após horas sem resultado. O custo computacional do SHA-512crypt torna ataques de dicionário exaustivos muito lentos sem aceleração de GPU. Uma segunda tentativa com uma wordlist personalizada alvo construída a partir de inteligência coletada durante o reconhecimento foi concluída rapidamente, mas não retornou correspondências.
CrackStation foi tentado a seguir como um serviço online de rainbow tables, mas retornou um formato de hash não reconhecido para ambas as entradas. Isso era esperado – o SHA-512crypt adiciona um salt aleatório único a cada hash antes de fazer o hash, o que significa que a mesma senha produz um hash diferente para cada conta. As rainbow tables funcionam pré-computando hashes para senhas conhecidas, mas seria necessária uma tabela separada para cada valor de salt possível, tornando a abordagem completamente impraticável contra hashes com salt.
Hashcat foi utilizado para as tentativas finais, com três wordlists em sucessão: `fasttrack.txt` (esgotado em 4 segundos), uma lista personalizada alvo (esgotada sem correspondência) e as 100.000 primeiras entradas de `rockyou.txt` (falhou após 3 minutos). Todas as tentativas de quebra de senha foram malsucedidas. O uso de SHA-512crypt com salt com um alto número de iterações é o motivo – o algoritmo foi projetado para ser computacionalmente caro, precisamente para resistir a esse tipo de ataque offline.
### Buscas por Chaves SSH
Uma busca no sistema de arquivos também foi realizada por arquivos de chave privada RSA e certificados PEM usando `find`. Qualquer chave privada encontrada poderia conceder acesso a outros sistemas que confiam na chave pública correspondente, uma valiosa oportunidade de movimento lateral. Nenhuma chave privada pertencente a outros sistemas foi encontrada.
### Implante de Backdoor
O acesso persistente foi implementado injetando uma chave pública RSA no arquivo `authorized_keys` da conta root. A autenticação por chave SSH foi escolhida porque não depende de senhas e é difícil de detectar a menos que o arquivo `authorized_keys` seja especificamente auditado. Um par de chaves RSA de 4096 bits foi gerado na máquina Kali, e a chave pública foi anexada a `/root/.ssh/authorized_keys` no alvo com as permissões corretas de diretório e arquivo definidas. Uma conexão de volta ao alvo usando a chave privada foi estabelecida para verificar se o backdoor estava funcional.
*Acesso root persistente confirmado via autenticação por chave privada*
### Automação
Um script Python RPC personalizado do Metasploit (`thor_full_chain.py`) também foi desenvolvido para automatizar toda a cadeia de pós-exploração. O script conecta-se a uma sessão RPC ativa do Metasploit e lida com a sequência completa – estabilização do shell `www-data`, injeção do `hammer.sh` para escalar para thor, escalonamento GTFOBins para root, captura de flag, extração de credenciais e implante de backdoor com registro de data e hora salvo em um arquivo local. Este foi um entregável adicional demonstrando a capacidade de automação da cadeia de ataque usando a API RPC do Metasploit. Veja `scripts/thor_full_chain.py` para a implementação completa.
## Fase 8: Cobertura de Rastros
A fase final envolveu remover evidências da intrusão tanto do sistema alvo quanto da máquina atacante Kali. No alvo, o log de acesso do Apache era o arquivo mais crítico a limpar, pois continha a requisição HTTP Shellshock bruta que desencadeou o exploit inicial. O log de autenticação foi limpo, pois armazenava cada comando sudo usado durante a fase de escalonamento. O syslog, os registros binários de login (`wtmp`, `btmp`, `lastlog`) e o histórico bash tanto do `root` quanto do `www-data` foram todos sobrescritos e verificados vazios.
No Kali, o workspace do Metasploit foi removido com `workspace -d default`, os arquivos de credenciais baixados foram removidos, o par de chaves SSH foi deletado e o histórico bash foi limpo. Cada passo foi verificado antes de prosseguir para o próximo.
Uma exceção deliberada foi feita para o backdoor SSH, e seus arquivos de chave associados foram mantidos no alvo e não removidos neste estágio, pois eram necessários para fins de demonstração na apresentação da avaliação.
## Vulnerabilidades Exploradas
| Vulnerabilidade | CVE | CVSS | Componente | Método |
|--------------|-----|------|-----------|--------|
| Shellshock RCE | CVE-2014-6271 | 9.8 | Apache mod\_cgi + Bash sem patch | Metasploit com cabeçalho User-Agent malicioso |
| Credenciais padrão | — | — | pfSense webConfigurator | `admin / pfsense` inalterado pós-instalação |
| Configuração incorreta do sudo (www-data) | — | — | `/etc/sudoers` | NOPASSWD executável `hammer.sh` como thor |
| Injeção de comando no hammer.sh | — | — | Script bash personalizado | Injeção `eval` via payload `bash -i` |
| Configuração incorreta do sudo (thor) | — | — | `/etc/sudoers` | NOPASSWD `service` sem restrições como root |
---
## Ferramentas Utilizadas
| Ferramenta | Propósito |
|------|---------|
| Nmap | Descoberta de host, varredura de portas, fingerprinting de SO, verificação de Shellshock via NSE |
| Metasploit Framework | Enumeração baseada em banco de dados, exploração, Meterpreter, pós-exploração |
| Nessus Essentials | Avaliação estruturada de vulnerabilidades com varredura CGI e aplicações web |
| Hydra | Tentativa inicial de brute force no pfSense sem sucesso devido à proteção CSRF |
| CeWL | Geração de wordlist personalizada através de crawler na página de login do pfSense |
| Python 3 + BeautifulSoup | Script de brute force pfSense com conhecimento de CSRF |
| pymetasploit3 | Cliente da API RPC do Metasploit para automação completa da cadeia de ataque |
| John the Ripper | Quebra offline de hashes SHA-512crypt |
| Hashcat | Tentativas de quebra SHA-512crypt aceleradas por GPU |
| CrackStation | Consulta online de rainbow tables |
| GTFOBins | Referência para a técnica de escalonamento de privilégios via sudo service |
| curl | Verificação de serviço HTTP contra a WAN do pfSense |
---
## Recomendações
**Atualize o Bash imediatamente.** A vulnerabilidade Shellshock existe porque o Bash nunca foi atualizado neste sistema Debian 10. Executar `apt-get update && apt-get upgrade bash` remove a vulnerabilidade. Além da atualização, se scripts CGI não forem operacionalmente necessários, o diretório `/cgi-bin/` deve ser desabilitado completamente na configuração do Apache, removendo a superfície de ataque independentemente da versão do Bash.
**Audite e endureça as regras do sudo.** Duas regras sudo NOPASSWD formaram toda a cadeia de escalonamento de privilégios. Nenhuma das regras tem uma justificativa legítima. O arquivo `/etc/sudoers` deve ser revisado e ambas as entradas removidas. O princípio do menor privilégio deve governar qualquer configuração futura do sudo; as contas devem ter apenas o acesso específico de que realmente precisam, nada mais.
**Remova eval de scripts shell.** O script `hammer.sh` passava a entrada do usuário diretamente para uma instrução `eval` sem qualquer validação ou sanitização. Isso é o que tornou a injeção de comando possível. O uso de `eval` deve ser evitado completamente em scripts shell que aceitam entrada do usuário, pois é quase sempre uma superfície de ataque. A entrada deve ser validada contra uma lista de permissões estrita antes de qualquer processamento ocorrer.
**Altere as credenciais padrão do pfSense e restrinja o acesso.** O webConfigurator foi exposto na interface WAN usando as credenciais padrão inalteradas `admin / pfsense`. As credenciais padrão devem ser alteradas imediatamente após a instalação. O webConfigurator nunca deve ser acessível a partir da WAN; o acesso deve ser restrito apenas à LAN ou a uma interface de gerenciamento dedicada.
**Implemente registro centralizado de logs.** Na Fase 8, todos os logs locais foram limpos em minutos, não deixando vestígios da intrusão no sistema alvo. Isso demonstrou que o alvo não tinha gerenciamento centralizado de logs. Em um ambiente de produção, os logs devem ser encaminhados em tempo real para um SIEM remoto. Isso garante que, mesmo que um atacante limpe os logs localmente, a evidência já foi preservada fora do sistema e não pode ser adulterada.
---
## Estrutura do Repositório```
hacksudo-thor-pentest/
│
├── README.md
├── report.pdf ← Full penetration testing report
│
├── scripts/
│ ├── pfsense_brute.py ← CSRF-aware pfSense brute force script
│ └── thor_full_chain.py ← Metasploit RPC attack chain automation
│
└── screenshots/
├── network.PNG
│
├── Discovery/
│ └── pfsenselogin.png
│
└── exploit/
├── sheellockexploit.PNG
├── sudol.PNG
├── hammer.bash-i.PNG
├── privilage escaltiontoroot.PNG
├── proof.PNG
└── backdoor.PNG
Este teste de penetração foi conduzido exclusivamente em um ambiente de laboratório virtual autocontido e isolado, construído no Oracle VirtualBox. HackSudo Thor é uma máquina CTF intencionalmente vulnerável publicada no VulnHub com o propósito explícito de educação e prática em segurança.
| 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 |
| Endereço IP | Serviços Chave | SO | Identificado Como |
|---|
| 10.0.4.3 | SSH 7.9p1, Apache 2.4.38, FTP | Linux (Debian) | HackSudo Thor |
| 10.0.4.4 | Apache 2.4.29, DVWA v1.10 | Linux (Ubuntu) | DVWA |
| 10.0.3.4 | Microsoft IIS 5.1 | Windows XP/2003 | WinXP Cyberlab |
| 10.0.3.5 | vsftpd 2.3.4, SSH, Apache 2.2.8 | Linux (Ubuntu) | Metasploitable 2 |
| Gravidade | Achado | CVE | CVSS v3 |
|---|
| CRÍTICO | Shellshock RCE | CVE-2014-6271 | 9.8 |
| CRÍTICO | Correção Incompleta do Shellshock | CVE-2014-6278 | 8.8 |
| MÉDIO | Fraqueza Terrapin SSH | CVE-2023-48795 | 5.9 |
| MÉDIO | Diretórios Web Navegáveis | — | 5.3 |
| MÉDIO | Clickjacking / Sem X-Frame-Options | CWE-693 | 4.3 |
| BAIXO | Divulgação de Timestamp ICMP | CVE-1999-0524 | 2.1 |