Pentest Black Box: Como um único domínio levou à completa comprometimento da infraestrutura. Parte 2

Pentest Black Box: Como um único domínio levou à completa comprometimento da infraestrutura. Parte 2

Ponto de Entrada: Acesso Concedido, Mas Sem Apoio.

Às vezes, o acesso à rede interna não é o início de um ataque bem-sucedido, mas sim um beco sem saída. Foi exatamente nessa situação que me encontrei no início desta jornada. Olá a todos! Continuamos a análise de um caso interessante de teste de penetração em que tive a oportunidade de participar. A primeira parte, focada no comprometimento do perímetro externo, já foi publicada por um colega. Portanto, aqui me concentrarei no que aconteceu a seguir – dentro da rede local. Para recapitular brevemente o ponto de partida: durante o teste da infraestrutura externa do cliente, conseguimos obter acesso à rede interna através de tunelamento. Para evitar a duplicação de material, mencionarei apenas que o esquema foi implementado seguindo a abordagem descrita por meus amigos da empresa "Deiteriy Lab" em seu artigo. É um método excelente e totalmente funcional, que recomendo adotar. Para uma compreensão geral, apresento o esquema de conexão que utilizamos (também retirado do artigo).

No momento do início, já tínhamos um túnel configurado para a infraestrutura interna do cliente e acesso RDP a um dos servidores. Este foi um "ponto de entrada" bastante típico, do qual se espera ou um sucesso rápido, ou a compreensão de que seria necessário cavar mais fundo. A máquina possuía o antivírus Kaspersky instalado, mas, para minha surpresa, seus processos foram encerrados sem problemas através do Gerenciador de Tarefas. Em seguida, decidi testar o cenário mais óbvio – coletar rapidamente credenciais. O Mimikatz foi carregado no host, e os dumps SAM e LSASS foram extraídos. No entanto, o resultado foi bastante modesto: o hash do administrador local e uma conta de domínio sem quaisquer privilégios. A situação foi ainda mais complicada pelo fato de que a própria máquina não pertencia ao domínio, o que a tornava um ponto de apoio fraco para um avanço posterior.

Reconhecimento: Quando o Caminho Rápido Falha.

Se o "ataque direto" não funcionou, é preciso entender como a infraestrutura está organizada – e onde estão seus pontos fracos. Quando o "caminho rápido" não funciona, quase sempre é necessário voltar à base – o reconhecimento. Durante a investigação da infraestrutura, ficou claro que a rede estava dividida em dois segmentos, cada um servindo seu próprio domínio: Corp.local.ru e Sub.corplocal.ru. Ao mesmo tempo, não havia relações de confiança configuradas entre os domínios, embora pelos nomes fosse óbvio que um deles desempenhava o papel principal e o outro, mais aplicado. Tendo uma conta de usuário do domínio principal, comecei a construir cuidadosamente um mapa da rede. Para evitar fazer barulho desnecessário, primeiro coletei uma lista de hosts acessíveis usando fping e, em seguida, com a ajuda de nmap e netexec, examinei-os com mais detalhes, formando uma compreensão dos sistemas operacionais e serviços. Separei meu pipeline padrão para encontrar serviços web na rede interna – uma combinação de masscan, nmap e EyeWitness. Este é um método bastante simples, mas eficaz, para entender rapidamente quais interfaces web internas existem e merecem atenção.

bash
masscan -p 80,443,8080,8443,8000 -i eth0 | tee web_ports.txt
cat web_ports.txt | awk {'print $6'} | sort | uniq > web_hosts.txt
nmap -p 80,443,8080,8443,8000 -iL web_hosts.txt -oX nmap_scan_web.xml
eyewitness -x nmap_scan_web.xml -d eyew --web

Em resumo, o script implementa um pipeline típico de pesquisa web (recon) inicial na rede: masscan escaneia rapidamente a rede através da interface eth0 em busca de portas web abertas (80, 443, 8080, 8443, 8000) e salva o resultado em web_ports.txt. O processamento dos resultados (awk + sort + uniq) extrai os endereços IP dos hosts com portas abertas da saída do masscan → uma lista única web_hosts.txt é formada. O nmap escaneia os hosts encontrados de forma mais detalhada nas mesmas portas, coleta informações de serviço e salva o resultado em XML (nmap_scan_web.xml). O EyeWitness, com base nos resultados do nmap, tira screenshots dos serviços web e coleta artefatos web no diretório eyew. Paralelamente, como a infraestrutura era predominantemente baseada em Windows, coletei dados para o BloodHound, usuários, grupos, compartilhamentos SMB acessíveis e parâmetros de política de senha. E foi nesta etapa que surgiu a primeira pista realmente interessante.

Primeira Pista: Aquilo Que Não Deveria Ter Sido Encontrado.

Na maioria das vezes, a primeira vulnerabilidade séria não é encontrada em tecnologia complexa, mas em um erro operacional banal. Aqui, tudo aconteceu exatamente assim. Entre os recursos de rede disponíveis, descobrimos um compartilhamento com o nome sugestivo FREENAS. A conta atual tinha acesso total de leitura e gravação a ele, o que por si só já parecia suspeito.

Dentro, encontramos um diretório com backups de configuração do servidor Zabbix.

Após descompactar o arquivo, extraí o arquivo etc/shadow, contendo os hashes de senha dos usuários do sistema. Os hashes obtidos foram imediatamente enviados para brute-force usando a utilidade "JohnTheRipper". Para minha surpresa, após alguns minutos, obtive a senha do root. Ah, essa observância nominal das políticas de senha nas organizações!)))

A senha obtida foi inicialmente testada em seu propósito – o acesso SSH ao servidor Zabbix foi bem-sucedido. Após isso, como é comum, surgiu a suposição óbvia: e se a senha for usada em outro lugar? Uma tentativa de password spraying nas contas de domínio não deu resultado, mas ao verificar usuários locais em diferentes máquinas, tudo se mostrou muito mais interessante – conseguimos obter vários administradores locais em ambos os domínios imediatamente.

Fixação no Domínio: Acesso Concedido, Mas Sem Desenvolvimento.

Obter um administrador local é gratificante. Perceber que isso não permite o avanço é menos gratificante. Em seguida, eu e meus colegas dividimos as áreas de responsabilidade, e eu me concentrei no domínio Sub.corplocal.ru, onde já tinha acesso a um dos servidores com privilégios de administrador local. Conectando-me via RDP e desativando o antivírus, repeti a tentativa de extrair credenciais usando Mimikatz, mas desta vez novamente sem muito sucesso: além das entidades já conhecidas e do hash NTLM da conta da máquina, nada útil foi obtido.

Autenticação Forçada e NTLM Relay.

Quando os métodos diretos falham, é preciso forçar o sistema a "atacar a si mesmo". Neste momento, decidi mudar a abordagem e procurar vulnerabilidades relacionadas à autenticação forçada e ataques de relay. Rapidamente encontrei a combinação: uma máquina vulnerável ao PetitPotam e um alvo para o qual a autenticação poderia ser retransmitida. Em seguida, tudo se desenvolveu de acordo com o cenário clássico. Em um terminal, iniciei o Impacket-ntlmrelayx. E em outro, iniciei a exploração da vulnerabilidade PetitPotam com um script obtido aqui.

O ataque funcionou, e obtive acesso ao sistema através de um SMB shell. Não pude executar comandos no host atacado. No entanto, tive a capacidade de ler e gravar arquivos. Mas isso foi suficiente.

Da Gravação de Arquivos à Execução de Código.

Às vezes, entre "tenho acesso a arquivos" e "tenho controle total" – há apenas um passo. É importante vê-lo a tempo. No sistema de arquivos, descobri o diretório C:\inetpub\wwwroot – a raiz do servidor web IIS. Isso imediatamente abriu um vetor claro: o upload de um shell ASPX. Para este fim, usei o ASPX Shell de xl7dev. Após a implantação do web shell, obtive a execução remota de comandos completa.

Escalação de Privilégios: Quase o Máximo Ainda Não é o Máximo.

Mesmo obtendo a execução de comandos, você ainda pode estar longe do objetivo. A questão é apenas quais privilégios você já possui. A partir deste momento, o trabalho progrediu visivelmente mais rápido. Primeiro, verifiquei os privilégios disponíveis e descobri o SeImpersonatePrivilege – uma das bandeiras que quase sempre significa uma escalada potencial para SYSTEM. E novamente o antivírus não foi um obstáculo. Tentativas de usar várias variantes de exploits "Potato" não deram resultado, então fui por um caminho mais confiável e carreguei o Meterpreter (como parte do Metasploit Framework). Como resultado do estabelecimento de uma conexão TCP reversa, obtive um shell interativo com os privilégios do usuário atual. Dentro da sessão Meterpreter, o módulo getsystem foi executado, que usou esse privilégio para criar um token NT AUTHORITY\SYSTEM e substituir o contexto de execução. Como resultado, obtive um shell com privilégios máximos. A operação foi concluída com sucesso: a sessão shell foi escalada para o nível máximo de privilégios no sistema.

Ponto Crítico: O Domínio Começa a "Desmoronar".

Há um momento após o qual a infraestrutura para de resistir. Aqui, ele ocorreu exatamente nesta etapa. Tendo obtido os direitos mais altos no sistema, executei o Mimikatz novamente e a sorte sorriu para mim. Do processo LSASS, consegui extrair o hash NTLM da senha do administrador do domínio. Usando-o, consegui descarregar o NTDS.DIT, ou seja, obter efetivamente o banco de dados de todos os hashes NTLM do domínio. Neste ponto, o domínio Sub.corplocal.ru poderia ser considerado completamente comprometido.

Frutos Baixos: Quando o Ataque se Escala Sozinho.

Depois disso, conectei-me aos colegas que, nesse momento, continuavam trabalhando com o domínio principal. A solução que tentei a seguir não pode ser chamada de elegante, mas muitas vezes funciona. Peguei os hashes do NTDS e os executei em uma lista de usuários do segundo domínio no contexto de password spraying. O resultado foi inesperadamente generoso: duas contas com direitos de administrador de domínio imediatamente. Em seguida, tudo foi uma questão de técnica – pass-the-hash e um novo dump do NTDS, mas agora no segundo domínio. Neste ponto, o trabalho foi concluído, pois atingimos o objetivo que o cliente nos estabeleceu, a saber, o comprometimento completo da infraestrutura.

Conclusões: Comprometimento é Sempre uma Cadeia, Não um Único Erro.

Se olharmos para todo o caso em conjunto, torna-se óbvio: nenhuma das etapas por si só foi algo único ou particularmente complexo. Não houve vulnerabilidades zero-day ou técnicas sofisticadas que exigissem desenvolvimento personalizado profundo. Todo o ataque é uma utilização sequencial de abordagens bem conhecidas que funcionaram devido à combinação de deficiências organizacionais e técnicas. O problema principal reside no efeito cumulativo. Cada fraqueza individual parecia não crítica:

• Backups com dados sensíveis estavam acessíveis da rede,
• A senha do root era fraca e rapidamente quebrada,
• Essa mesma senha foi reutilizada em outros sistemas,
• Administradores locais tinham privilégios excessivos,
• Vulnerabilidades de nível PetitPotam permaneceram na infraestrutura,
• Privilégios como SeImpersonatePrivilege estavam presentes, permitindo a escalada.

Individualmente, estes são problemas típicos de "médio porte". Mas em conjunto, eles formaram uma cadeia de ataque contínua – de uma máquina comprometida fora do domínio ao controle total sobre dois domínios. Vale ressaltar que a ausência de relações de confiança entre os domínios não se tornou um fator de contenção. Na prática, a segurança da infraestrutura é determinada não apenas por decisões arquitetônicas, mas também pela disciplina operacional. A reutilização de senhas e o controle fraco de credenciais anularam a segmentação no nível dos domínios.