Pentest Black Box: Como um Único Domínio Levou à Comprometimento Total da Infraestrutura - Parte 1
Este artigo detalha um pentest black box, onde o acesso inicial foi limitado a um único domínio. A exploração de vulnerabilidades em um subdomínio Joomla, combinada com técnicas de phishing e injeção SQL, resultou na comprometimento completo da infraestrutura, demonstrando a importância de uma segurança robusta.
MundiX News·10 de maio de 2026·10 min de leitura·👁 2 views
Pentest Black Box: Como um Único Domínio Levou à Comprometimento Total da Infraestrutura - Parte 1
Olá, pessoal do MundiX! Neste artigo, compartilho a experiência de conduzir um pentest externo black-box e detalho a metodologia que permitiu encontrar vulnerabilidades críticas, mesmo com um escopo inicial mínimo. O artigo será dividido em duas partes, a primeira sobre o pentest externo, que abordarei aqui, e a segunda sobre o pentest interno, que será tratada por um colega.
Um pentest black-box implica que o pentester não possui nenhuma informação interna: nem listas de IPs, nem credenciais, nem descrições da arquitetura. Apenas um nome de domínio - e vamos em frente. Isso pode parecer uma limitação, mas na prática é frequentemente uma vantagem: você observa a infraestrutura pelos olhos de um invasor real.
O objetivo deste pentest é verificar a possibilidade de comprometer a infraestrutura interna por meio de aplicações web.
1. Reconhecimento
A primeira etapa de qualquer pentest é a coleta de informações sobre o domínio alvo. A regra é simples: quanto mais subdomínios forem encontrados, melhor.
Para a coleta passiva de informações, foram utilizadas as seguintes ferramentas:
sublist3r
dnsrecon
VirusTotal
crt.sh
Como resultado, foram encontrados cerca de 40 subdomínios únicos, o que expandiu significativamente a superfície de ataque.
Um ponto interessante: é importante entender que diferentes ferramentas fornecem resultados diferentes. sublist3r e VirusTotal cobrem índices públicos, enquanto crt.sh analisa os logs de transparência de certificados (Certificate Transparency logs). Na prática, é o crt.sh que frequentemente fornece subdomínios que não são indexados por scanners clássicos - ambientes de teste, serviços internos, domínios temporários para integrações.
Análise da Lógica das Aplicações
Reconhecimento não se trata apenas de coletar subdomínios, mas também de analisar o comportamento das aplicações.
É importante entender:
Quem é o público-alvo
Qual é a ênfase na experiência do usuário (UX)
O que pode ter sido sacrificado em prol da facilidade de uso
Foi encontrado um domínio que era um sistema de ensino a distância com sinais claros de direcionamento a um público com baixo nível de conhecimento técnico:
Interface simplificada
Botões grandes
Modos para pessoas com deficiência visual
Muitas dicas pop-up
Tudo isso indicava que os desenvolvedores poderiam ter sacrificado a segurança em prol da acessibilidade. E, de fato, no site havia acesso de convidado, o que abriu uma vulnerabilidade IDOR, permitindo extrair credenciais, e também foi possível extrair dados do banco de dados.
2. O Domínio que Abriu Tudo
Entre os subdomínios encontrados, o domínio test-domínio.ru chamou a atenção. Era um domínio de placeholder, mas ao analisá-lo, foi descoberto que ele usava o CMS Joomla.
A forma de autorização não funcionava, os botões também não, mas ao ir para a página de autorização do painel de administração do Joomla, descobri que ela estava acessível. Uma tentativa de brute-force de autorização foi inesperadamente bem-sucedida - o acesso ao painel de administração foi obtido em questão de segundos.
A interface foi exibida incorretamente, mas o back-end funcionou. Isso permitiu obter acesso aos componentes e alterar o template do site.
No template do site, foi inserido código PHP, o que resultou em RCE (Remote Code Execution).
Execução de Comandos
Não é muito agradável trabalhar com um shell tão primitivo, então foi criado um reverse shell no servidor VDS.
Investigação do Servidor
Ao analisar o servidor, foi possível estabelecer:
O servidor é um host
Ele hospeda ~20 sites
Parte deles são empresas subsidiárias (elas estão fora do escopo)
O acesso foi limitado ao usuário www-data, então foi necessária a escalada de privilégios. Usando linpeas, foi encontrado e explorado com sucesso o pwnkit CVE-2021-4034, o que permitiu obter acesso root.
Depois disso, um usuário privilegiado foi criado e começamos a estudar os arquivos de configuração.
No entanto, o servidor estava hospedado em um VDS, e não havia acesso direto à rede interna. Isso significa que tudo precisava ser extraído desse servidor.
3. Phishing
Para avançar, foi acordada uma ataque de phishing. Neste ponto, o acesso a todos os bancos de dados dos sites foi obtido, o que significa que eu poderia criar contas administrativas nos sites.
Em uma das configurações, foram encontradas as credenciais do administrador de e-mail (Roundcube).
Isso deu acesso ao e-mail corporativo e a capacidade de redefinir senhas em sites que estavam em outros servidores, o que permitiu expandir a superfície de ataque.
Implementação do Ataque
Em um dos sites corporativos, foi colocada uma forma de autorização de phishing, que registrava os dados inseridos.
Para os usuários, tudo parecia legítimo. Um site legítimo, uma interface legítima, um remetente confiável com quem eles se comunicam todos os dias.
Após o envio, as credenciais dos funcionários foram obtidas.
4. Por que o Treinamento de Funcionários Não Funciona
O phishing continua sendo um dos vetores mais eficazes, não porque os funcionários sejam estúpidos, mas porque os ataques são bem preparados. Bem descrito neste artigo.
Muitas empresas se limitam ao treinamento formal, o que não produz resultados.
Princípios de treinamento anti-phishing eficaz:
Ataques simulados regulares - não envios únicos, mas trabalho sistemático
Cenários realistas - e-mails de RH, departamento de TI, gerência; links para portais internos
Feedback imediato - se o funcionário clicar, ele recebe imediatamente material de treinamento, e não uma bronca
Gamificação - classificações, certificados, competições entre departamentos
5. Injeção SQL que Mudou Tudo
Em um dos subdomínios, foi detectada uma SQLi time-based.
Eu a descobri no primeiro dia, mas ela não trazia nenhum benefício prático. No entanto, uma reanálise revelou que havia um segundo parâmetro que era vulnerável. A combinação de parâmetros permitiu aplicar a técnica de HTTP Parameter Fragmentation e alcançar a injeção UNION.
Estudar mais o banco de dados mostrou que enviamos as consultas sob um usuário privilegiado.
Microsoft SQL Server 2005, muito antigo, e isso sugere que há uma chance de xp_cmdshell funcionar.
Verifiquei a presença deste procedimento e sim, ele foi ativado. Imediatamente corri para verificar a possibilidade de executar comandos, whoami, dir, etc. Mas em resposta, nada. Criei shells e os executei, mas não encontrei nenhuma reação, constantemente NULL em qualquer comando.
A ideia veio de verificar o próprio fato da execução de comandos. No VDS, o tcpdump foi iniciado e, como resultado, os comandos foram realmente executados.
Exploração
xp_cmdshell - um procedimento armazenado estendido que permite executar comandos do sistema operacional. Em versões antigas (MSSQL 2005), ele é frequentemente ativado por padrão.
Problema do legado:
MSSQL 2005 x86 só funciona no Windows Server 2003 / 2003 R2
Sem PowerShell, cmd truncado, ausência de curl/wget/certutil
O único vetor confiável de entrega de payload - scripts VBS
Armazenamento de credenciais em arquivos de configuração
Software desatualizado (MSSQL 2005)
xp_cmdshell ativado
Segmentação de rede inadequada
Acesso ao e-mail via interface web
O artigo foi dividido em duas partes. Meu colega @CyberB falará sobre o pentest interno.
Este foi um pentest interessante. Muitas vulnerabilidades diferentes foram encontradas, mas contei a vocês sobre as mais interessantes. Todas as vulnerabilidades foram entregues ao cliente, assim como as recomendações, todos fecharam tudo e consertaram. Obrigado a todos.
Pentest Black Box: Como um Único Domínio Levou à Comprometimento Total da Infraestrutura - Parte 1
Olá, pessoal do MundiX! Neste artigo, compartilho a experiência de conduzir um pentest externo black-box e detalho a metodologia que permitiu encontrar vulnerabilidades críticas, mesmo com um escopo inicial mínimo. O artigo será dividido em duas partes, a primeira sobre o pentest externo, que abordarei aqui, e a segunda sobre o pentest interno, que será tratada por um colega.
Um pentest black-box implica que o pentester não possui nenhuma informação interna: nem listas de IPs, nem credenciais, nem descrições da arquitetura. Apenas um nome de domínio - e vamos em frente. Isso pode parecer uma limitação, mas na prática é frequentemente uma vantagem: você observa a infraestrutura pelos olhos de um invasor real.
O objetivo deste pentest é verificar a possibilidade de comprometer a infraestrutura interna por meio de aplicações web.
1. Reconhecimento
A primeira etapa de qualquer pentest é a coleta de informações sobre o domínio alvo. A regra é simples: quanto mais subdomínios forem encontrados, melhor.
Para a coleta passiva de informações, foram utilizadas as seguintes ferramentas:
sublist3r
dnsrecon
VirusTotal
crt.sh
Como resultado, foram encontrados cerca de 40 subdomínios únicos, o que expandiu significativamente a superfície de ataque.
Um ponto interessante: é importante entender que diferentes ferramentas fornecem resultados diferentes. sublist3r e VirusTotal cobrem índices públicos, enquanto crt.sh analisa os logs de transparência de certificados (Certificate Transparency logs). Na prática, é o crt.sh que frequentemente fornece subdomínios que não são indexados por scanners clássicos - ambientes de teste, serviços internos, domínios temporários para integrações.
Análise da Lógica das Aplicações
Reconhecimento não se trata apenas de coletar subdomínios, mas também de analisar o comportamento das aplicações.
É importante entender:
Quem é o público-alvo
Qual é a ênfase na experiência do usuário (UX)
O que pode ter sido sacrificado em prol da facilidade de uso
Foi encontrado um domínio que era um sistema de ensino a distância com sinais claros de direcionamento a um público com baixo nível de conhecimento técnico:
Interface simplificada
Botões grandes
Modos para pessoas com deficiência visual
Muitas dicas pop-up
Tudo isso indicava que os desenvolvedores poderiam ter sacrificado a segurança em prol da acessibilidade. E, de fato, no site havia acesso de convidado, o que abriu uma vulnerabilidade IDOR, permitindo extrair credenciais, e também foi possível extrair dados do banco de dados.
2. O Domínio que Abriu Tudo
Entre os subdomínios encontrados, o domínio test-domínio.ru chamou a atenção. Era um domínio de placeholder, mas ao analisá-lo, foi descoberto que ele usava o CMS Joomla.
A forma de autorização não funcionava, os botões também não, mas ao ir para a página de autorização do painel de administração do Joomla, descobri que ela estava acessível. Uma tentativa de brute-force de autorização foi inesperadamente bem-sucedida - o acesso ao painel de administração foi obtido em questão de segundos.
A interface foi exibida incorretamente, mas o back-end funcionou. Isso permitiu obter acesso aos componentes e alterar o template do site.
No template do site, foi inserido código PHP, o que resultou em RCE (Remote Code Execution).
Execução de Comandos
Não é muito agradável trabalhar com um shell tão primitivo, então foi criado um reverse shell no servidor VDS.
Investigação do Servidor
Ao analisar o servidor, foi possível estabelecer:
O servidor é um host
Ele hospeda ~20 sites
Parte deles são empresas subsidiárias (elas estão fora do escopo)
O acesso foi limitado ao usuário www-data, então foi necessária a escalada de privilégios. Usando linpeas, foi encontrado e explorado com sucesso o pwnkit CVE-2021-4034, o que permitiu obter acesso root.
Depois disso, um usuário privilegiado foi criado e começamos a estudar os arquivos de configuração.
No entanto, o servidor estava hospedado em um VDS, e não havia acesso direto à rede interna. Isso significa que tudo precisava ser extraído desse servidor.
3. Phishing
Para avançar, foi acordada uma ataque de phishing. Neste ponto, o acesso a todos os bancos de dados dos sites foi obtido, o que significa que eu poderia criar contas administrativas nos sites.
Em uma das configurações, foram encontradas as credenciais do administrador de e-mail (Roundcube).
Isso deu acesso ao e-mail corporativo e a capacidade de redefinir senhas em sites que estavam em outros servidores, o que permitiu expandir a superfície de ataque.
Implementação do Ataque
Em um dos sites corporativos, foi colocada uma forma de autorização de phishing, que registrava os dados inseridos.
Para os usuários, tudo parecia legítimo. Um site legítimo, uma interface legítima, um remetente confiável com quem eles se comunicam todos os dias.
Após o envio, as credenciais dos funcionários foram obtidas.
4. Por que o Treinamento de Funcionários Não Funciona
O phishing continua sendo um dos vetores mais eficazes, não porque os funcionários sejam estúpidos, mas porque os ataques são bem preparados. Bem descrito neste artigo.
Muitas empresas se limitam ao treinamento formal, o que não produz resultados.
Princípios de treinamento anti-phishing eficaz:
Ataques simulados regulares - não envios únicos, mas trabalho sistemático
Cenários realistas - e-mails de RH, departamento de TI, gerência; links para portais internos
Feedback imediato - se o funcionário clicar, ele recebe imediatamente material de treinamento, e não uma bronca
Gamificação - classificações, certificados, competições entre departamentos
5. Injeção SQL que Mudou Tudo
Em um dos subdomínios, foi detectada uma SQLi time-based.
Eu a descobri no primeiro dia, mas ela não trazia nenhum benefício prático. No entanto, uma reanálise revelou que havia um segundo parâmetro que era vulnerável. A combinação de parâmetros permitiu aplicar a técnica de HTTP Parameter Fragmentation e alcançar a injeção UNION.
Estudar mais o banco de dados mostrou que enviamos as consultas sob um usuário privilegiado.
Microsoft SQL Server 2005, muito antigo, e isso sugere que há uma chance de xp_cmdshell funcionar.
Verifiquei a presença deste procedimento e sim, ele foi ativado. Imediatamente corri para verificar a possibilidade de executar comandos, whoami, dir, etc. Mas em resposta, nada. Criei shells e os executei, mas não encontrei nenhuma reação, constantemente NULL em qualquer comando.
A ideia veio de verificar o próprio fato da execução de comandos. No VDS, o tcpdump foi iniciado e, como resultado, os comandos foram realmente executados.
Exploração
xp_cmdshell - um procedimento armazenado estendido que permite executar comandos do sistema operacional. Em versões antigas (MSSQL 2005), ele é frequentemente ativado por padrão.
Problema do legado:
MSSQL 2005 x86 só funciona no Windows Server 2003 / 2003 R2
Sem PowerShell, cmd truncado, ausência de curl/wget/certutil
O único vetor confiável de entrega de payload - scripts VBS
Armazenamento de credenciais em arquivos de configuração
Software desatualizado (MSSQL 2005)
xp_cmdshell ativado
Segmentação de rede inadequada
Acesso ao e-mail via interface web
O artigo foi dividido em duas partes. Meu colega @CyberB falará sobre o pentest interno.
Este foi um pentest interessante. Muitas vulnerabilidades diferentes foram encontradas, mas contei a vocês sobre as mais interessantes. Todas as vulnerabilidades foram entregues ao cliente, assim como as recomendações, todos fecharam tudo e consertaram. Obrigado a todos.
