Accounting

#easy #TheHackersLabs #Windows #eJPT

Guia com dicas que podem te auxiliar na resolução do CTF antes de ler o write-up.

  1. Escaneie portas do alvo para identificar serviços.

  2. Explore e baixe arquivos interessantes do SMB.

  3. Use o MSSQL para explorar formas de execução remota de comandos.

  4. Obtenha uma shell reversa na máquina alvo.

  5. Verifique o fluxo de dados alternativos (ADS) no arquivo do root.

https://thehackerslabs.com/accounting/

Reconhecimento de Rede

Descoberta de Hosts Ativos

O primeiro passo foi identificar os hosts ativos na rede local. Para isso, utilizei a ferramenta arp-scan, que realiza uma varredura ARP passiva. Este método é eficaz para descobrir dispositivos que estão na mesma sub-rede, uma vez que a comunicação ARP é comum entre dispositivos conectados.

O scan revelou que a máquina alvo estava no IP 10.0.2.8. Esse foi o meu ponto de partida para os próximos passos.

Verificando a conectividade via Ping

A primeira ação para reconhecimento do alvo é testar a conectividade com ele, utilizando o comando ping. Ao enviar um pacote ICMP, podemos confirmar se a máquina alvo está acessível na rede.

No retorno, o TTL de 128 é uma indicação de que possivelmente estamos lidando com um sistema Windows. O TTL inicial para sistemas Windows costuma ser 128, e o valor observado no ping geralmente é reduzido conforme os pacotes atravessam roteadores na rede. Como o TTL está próximo de 128, é provável que o sistema alvo seja uma máquina Windows.

Varredura de Portas e Serviços

Em seguida, executei um escaneamento de porta no alvo para identificar quaisquer portas abertas que pudessem ser usadas para novos ataques. Usei a ferramenta nmap para verificar todas as portas (1-65535) no alvo. A varredura foi configurada para buscar por serviços, versões e scripts comumente usados para obter mais informações sobre os serviços rodando.

Na enumeração, é retornado várias portas, chamando a atenção:

  • Porta 445 (Microsoft SMB)

  • Porta 49992 (Microsoft SQL Server 2017)

Visualizando Resultados do Nmap

Para facilitar a análise dos resultados do Nmap, utilizamos o nmap-bootstrap-xsl, que converte os arquivos de saída XML para um formato HTML visualmente mais atraente.

Passos para utilizar o Nmap Bootstrap:

  1. Clonar o repositório do Nmap Bootstrap:

  2. Usar o xsltproc para converter o arquivo XML em HTML:

Isso gerou um relatório visual que ajudou a organizar melhor as informações da varredura.

image.png

Serviço SMB (porta 445): Esse serviço pode oferecer vulnerabilidades comuns em servidores Windows, especialmente em sistemas que não estão atualizados.

Microsoft SQL Server (porta 49992): Um banco de dados exposto dessa forma é um alvo potencial para enumeração de credenciais e exploração, especialmente se for possível acesso a usuários ou privilégios administrativos no SQL Server.

Explorando o SMB

Reconhecimento inicial de SMB

Ao iniciar a exploração, descobrimos que o alvo está rodando uma versão do Windows Server 2019 através de uma verificação com o crackmapexec. Esta etapa nos dá uma ideia da superfície de ataque e das versões dos sistemas envolvidos.

Listagem de compartilhamentos SMB sem credenciais

Na sequência, tentamos enumerar os compartilhamentos SMB usando uma sessão sem credenciais. Isso nos dá acesso às pastas compartilhadas que têm permissões de leitura e escrita, o que pode ser explorado posteriormente.

O compartilhamento Compac possui permissões de leitura e escrita, o que já representa um potencial vetor de ataque.

Acessando o compartilhamento Compac

Usamos o smbclient para acessar o conteúdo desse compartilhamento. A listagem de diretórios revela a presença de pastas que podem conter arquivos interessantes.

No diretório Empresas, identificamos um arquivo chamado SQL.txt, que baixamos para uma inspeção mais detalhada.

Conteúdo de SQL.txt Ao ler o conteúdo do arquivo, encontramos credenciais potencialmente úteis para o serviço MSSQL exposto:

Essa credencial chama atenção, já que podemos utilizá-la no serviço MSSQL.

Explorando o MSSQL

Verificação da credencial

Validamos que a credencial extraída é válida no host alvo usando o crackmapexec.

Conectando ao MSSQL

Agora, usamos o sqsh para nos conectar ao MSSQL e confirmar se a credencial extraída pode ser usada para obter acesso administrativo ao banco de dados.

Enumeração do ambiente MSSQL

Uma vez conectados, realizamos uma enumeração básica para obter informações como a versão do SQL Server, usuário em execução, e listar as bases de dados existentes.

Os resultados revelam que estamos em uma instância do SQL Server 2017 e que estamos executando com permissões de dbo, o que nos dá bastante controle sobre o banco de dados.

Execução de comandos via xp_cmdshell

Testamos o comando xp_cmdshell, que nos permite executar comandos diretamente no sistema operacional alvo. Ao executar um simples whoami, descobrimos que o processo MSSQL está sendo executado como nt authority\system, o que nos dá controle total sobre o sistema.

Esse acesso abre a possibilidade de realizar movimentos laterais no sistema ou até mesmo escalada de privilégios para obter o controle completo do host.

Por meio da execução de comandos via xp_cmdshell, uma das primeiras coisas que quis fazer foi identificar o IP interno do alvo. Isso é crucial para confirmar a conectividade entre a máquina do atacante e o host comprometido, além de ajudar a mapear a rede local em um ambiente mais amplo.

Utilizei o comando ipconfig para exibir a configuração de rede do sistema comprometido:

O output do comando ipconfig nos dá várias informações valiosas:

  • Endereço IPv4: O alvo está utilizando o IP interno 10.0.2.8 com a máscara de sub-rede 255.255.255.0.

  • Gateway padrão: A máquina se comunica com o gateway 10.0.2.1.

Esses detalhes são importantes para entender o contexto de rede do alvo. Sabendo que o IP da minha máquina atacante é 10.0.2.15, já temos indícios de que estamos na mesma sub-rede.

Testando Conectividade

Para garantir que as máquinas estavam realmente se comunicando, fiz um teste simples de ping do host comprometido para minha máquina atacante. Primeiro, preparei a captura de pacotes ICMP (protocolo utilizado pelo ping) com o tcpdump no meu lado:

Com o tcpdump rodando, executei o comando ping no alvo para verificar se a máquina comprometida era capaz de se comunicar com a minha máquina atacante:

No lado do atacante, o tcpdump capturou os pacotes ICMP conforme esperado:

A captura confirma que os pacotes ICMP foram trocados entre a máquina do alvo e a minha, validando a comunicação entre os hosts.

Ganhando Acesso ao Alvo

Agora que confirmei a comunicação, a ideia é estabelecer uma reverse shell a partir do alvo. O método que utilizei evita a necessidade de baixar ferramentas diretamente no alvo, o que poderia gerar alertas. Em vez disso, usei um compartilhamento de rede SMB para fornecer o Netcat ao alvo, permitindo que ele se conecte de volta à minha máquina e execute uma reverse shell.

Passos seguidos:

  1. Download do Netcat para Windows:

    Para enviar a reverse shell, optamos por usar o netcat. Baixamos uma versão de 64 bits para Windows diretamente do site eternallybored.org e extraímos o executável nc64.exe usando o comando 7z.

  2. Compartilhando o Netcat via SMB:

    Em vez de enviar o binário diretamente ao alvo, configuramos um servidor SMB com o impacket-smbserver, compartilhando o diretório contendo o nc64.exe para que o alvo pudesse acessá-lo remotamente.

  3. Configurando o listener no atacante:

    Enquanto preparávamos o alvo, configuramos o pwncat ****para escutar na porta 443, onde receberíamos a shell reversa.

  4. Executando o Netcat no Alvo via SMB:

    Utilizando a xp_cmdshell do alvo, o Netcat foi executado diretamente a partir do compartilhamento SMB. Com isso, enviamos a shell reversa para o listener configurado na máquina atacante, garantindo que não precisássemos baixar ou instalar nada no sistema alvo.

A conexão foi bem-sucedida, como mostrado pelos logs do servidor SMB, que confirmaram o acesso ao compartilhamento, e pelo listener pwncat que recebeu a shell com privilégios de NT AUTHORITY\SYSTEM, o nível mais alto de privilégio em sistemas Windows.

A tarefa final foi localizar as flags indicadoras da conclusão da máquina.

User Flag

Primeiro, busquei a user flag, geralmente armazenada no diretório do usuário. No caso, ela estava localizada no diretório de contpaqi:

Root Flag

A próxima etapa foi localizar a root flag, tradicionalmente armazenada no diretório do administrador. No diretório C:\Users\admin\Desktop, encontrei um arquivo chamado root.txt:

Curiosamente, o conteúdo do arquivo root.txt não continha a flag tradicional. Em vez disso, exibiu um desenho ASCII, o que me levou a suspeitar que a flag estivesse escondida em algum outro lugar.

Descobrindo um Alternate Data Stream (ADS)

Ao enumerar o diretório com o comando dir /r, que exibe fluxos de dados alternativos (ADS), descobri que o arquivo root.txt continha um fluxo adicional chamado HI:

O arquivo root.txt tinha um fluxo de dados alternativo de 35 bytes chamado HI. Para acessar esse conteúdo, utilizei o comando more:

Este fluxo alternativo continha a verdadeira root.

Com a escalada de privilégios bem-sucedida e acesso root obtido, todas as flags foram coletadas e a máquina foi totalmente comprometida.

AnteriorTheHackersLabsPróximoSherlocks

Atualizado