Essa já foi minha dúvida e acredito que seja a dúvida de muitos iniciantes. Você aprendeu a parte técnica, mas e agora? Como fazer isso na vida real? Muita gente acaba aprendendo errado sobre isso, muito por se envolver com as pessoas erradas e elas ensinarem completamente errado.

O objetivo desse post é dar uma visão geral de como um pentest é feito na prática, só para quem está perdido ter uma noção de como funciona. O que eu vou dizer é baseado no Penetration Testing Execution Standard (PTES) e minhas próprias ideias de como fazer um pentest. Não reprenta uma regra universal, mas somente uma maneira de fazer pentest.

Pre-engagement Interactions

Antes de botar a mão na massa, é importante combinar com o cliente o escopo e os objetivos do pentest. Como dizem: "combinado não sai caro".

O escopo é definir o que está estritamente dentro do teste de segurança. Aplicações web, mobile, API, banco de dados, servidores etc.

Somente o que for determinado que está dentro do escopo, pode ser testado. Qualquer coisa fora do escopo, o pentester não pode tocar mesmo que ele acredite que possa haver uma vulnerabilidade ali. Se está fora do escopo, é intocável. Outra coisa: dados sensíveis são sempre intocáveis. Não leia arquivos com dados sensíveis, não exfiltre dados de bancos de dados. Se quiser validar uma vulnerabilidade, só obtenha dados de contas de teste que você mesmo criou ou solicitou a criação para o cliente.

Os objetivos do pentest também precisam ser claros. Por que o cliente quer fazer um pentest? Todo pentest é orientado com objetivos em mente e isso precisa ficar claro para ambas as partes.

Também é importante determinar uma data para início e finalização do pentest. Pentest não é processo contínuo, ele tem começo, meio e fim.

Também é bom combinar com o cliente uma faixa de horário em que você pode fazer o pentest. Não acontece sempre, mas durante o pentest você pode "quebrar" alguma coisa sem querer e o cliente pode precisar ter pessoal disponível para lidar com a situação. Então, na maioria dos casos, é melhor fazer pentest somente dentro de uma faixa de horário em que haja funcionários do cliente à disposição para lidarem com esse tipo de situação. E, naturalmente, importante você ter contato direto com esses funcionários. Só por garantia.

Tudo o que for combinado, naturalmente, deve ser estipulado em um contrato. Agora umas dicas antes de por a "mão na massa":

Sobe uma VPS e configura uma VPN para você usar ela para efetuar todo o pentest. Isso faz com que o seu tráfego de rede saia todo do mesmo IP (a VPS), isso facilita diferenciar pentest de uma tentativa real de ataque nos logs. Você pode seguir essa mesma ideia caso for testar uma rede interna do cliente: ele pode subir uma VPS e você conectar via VPN na rede interna.

Também é útil configurar um dashboard para o cliente poder acompanhar o pentest sem precisar ficar lhe perguntando "como estamos?" É bom ter informações como o progresso atual, fase atual, número de vulnerabilidades encontradas etc. Toda informação útil para o cliente entrar lá e ver o estado atual do pentest sem ter que perguntar para você, mas sem expor informações sensíveis ali. Não precisa fazer uma plataforma para isso, um simples Google Sheets resolve.

Também é importante deixar claro para o cliente que pentest é demorado e que é normal nos primeiros dias não encontrar vulnerabilidade nenhuma. Se não, vão se passar alguns dias, ele vai ver "0 vulnerabilidades" e vai estranhar.

Intelligence Gathering

Essa fase também é conhecida como reconhecimento (ou "recon"). Antes de tentar encontrar vulnerabilidades no sistema alvo para o pentest, é importante conhecê-lo. O objetivo do reconhecimento é obter o máximo de informações possíveis sobre como a aplicação funciona e quais tecnologias foram usadas no desenvolvimento dela.

Nessa fase você vai, por exemplo, estudar o código do frontend da aplicação, mapear rotas, identificar portas abertas em servidores etc. Quanto mais informações você conseguir, melhor.

E você não consegue obter informações sobre a aplicação somente interagindo com ela. Você pode usar o Google e redes sociais ao seu favor para obter informações. Exemplo: Provavelmente os desenvolvedores que trabalham ou trabalharam na empresa colocam com quais stacks e ferramentas eles trabalham naquela vaga no LinkedIn. Ou até comentam por aí sobre experiências que eles tiveram no trabalho desenvolvendo isso ou aquilo.

Usar ferramentas como nmap, ffuf, shodan, nuclei etc. é útil para reconhecimento, mas esperteza é mais. Usar Google Dorks e outras técnicas de OSINT (Open Source Intelligence) também é bastante útil para reconhecimento.

Pense nessa fase como afiar o machado antes de cortar a árvore. É importante dedicar bastante tempo nela e anotar (usando Obsidian ou o que preferir) tudo o que encontrar sobre a aplicação. É com as informações coletadas no reconhecimento que você saberá onde e o que procurar, ao invés de ficar atirando para todo lado igual um louco.

Dica: guarde a saída de ferramentas como nmap, ffuf etc. que posteriormente você poderá precisar usar elas na escrita do relatório.

Threat Modeling

Threat modeling é basicamente analisar o sistema com o intuito de fazer ponderações sobre segurança e privacidade no sistema. Nessa fase, você usará as informações coletadas na fase anterior para analisar a arquitetura e a implementação do sistema afim de encontrar potenciais riscos e falhas de segurança no sistema.

É nessa fase que você irá planejar os testes de segurança afim de confirmar a existência ou não de vulnerabilidades. Você modela o sistema, identifica onde e quais potenciais vulnerabilidades existem no sistema e planeja como validar a existência ou não das vulnerabilidades.

É importante entender que o objetivo não é apenas encontrar falhas de implementação, mas também falhas de design. Falhas de segurança na arquitetura do sistema também devem ser analisadas e identificadas em um pentest.

Já publiquei um post aqui no TabNews explicando o que é e como fazer threat modeling em mais detalhes: https://www.tabnews.com.br/Silva97/threat-modeling

Vulnerability Analysis

Após fazer o reconhecimento e o threat modeling, só então você estará realmente preparado para fazer análise de vulnerabilidades. É nessa fase que você verifica manualmente ou de forma automatizada pela existência de vulnerabilidades. Mas não aleatoriamente igual um louco, pois você já fez threat modeling e já sabe onde e o que procurar.

O principal erro dos iniciantes é achar que essa fase é onde se inicia um pentest ou até mesmo achar que o pentest inteiro se trata apenas de análise de vulnerabilidades. Mas como aquela frase famosa diz:

Se eu tivesse 6 horas para derrubar uma árvore, passaria as primeiras 4 afiando o machado.
~ Supostamente Abraham Lincoln

Análise de vulnerabilidades em um pentest é pontual porque você não vai atirar para todo lado uma vez que você já tenha se preparado e planejado nas fases anteriores.

Pesquise no Google ou pergunte para o ChatGPT sobre os seguintes termos:

• Static Application Security Testing (SAST)
• Dynamic Application Security Testing (DAST)

Basicamente são as duas formas existentes de se fazer análise de vulnerabilidades: analisando/lendo o código (SAST) ou interagindo com a aplicação enquanto ela executa (DAST). As duas podem ser manual ou automática.

Em um pentest, normalmente, você faz tanto testes manuais como automáticos. Nunca totalmente automatizado, pois automações não são muito efetivas.

E algo importante: ferramentas automáticas com frequência acusam falso positivo. É necessário verificar manualmente cada suposta vulnerabilidade que a ferramenta acusar para garantir que a vulnerabilidade é real e não um falso positivo.

Dica: enquanto você faz análise de vulnerabilidades, já vai guardando evidências (prints, vídeos, logs) e escrevendo provas de conceito (PoC) que provem a existência da vulnerabilidade. No relatório, você tem que provar que a vulnerabilidade existe, não basta apenas dizer "tem uma vulnerabilidade aqui".

Exploitation

Essa fase é crítica e deve ser muito bem planejada. É a fase do pentest onde você vai realmente invadir o sistema. Com base na fase anterior, você vai identificar alguma vulnerabilidade que sirva como "porta de entrada" para explorar e obter acesso ao sistema. Não precisa explorar todas as vulnerabilidades encontradas, apenas uma ou uma sequência específica de vulnerabilidades. O objetivo é entrar no sistema e não validar todas as vulnerabilidades (isso já é feito com provas de conceito).

O planejamento é muito importante, pois sistemas na vida real têm soluções de segurança que podem detectar ou até barrar a invasão. E você terá que bypassar tudo isso.

É a partir daqui que o pentest irá simular um ataque e invasão ao sistema, com o objetivo de avaliar o impacto real que um atacante conseguiria causar ao sistema.

Post Exploitation

Se você conseguir uma exploração com sucesso e invadir o sistema, nessa fase você terá o papel de avaliar o impacto que um atacante teria. Você terá que avaliar formas de fazer escalação de privilégios, persistência de acesso e também analisar serviços e a rede interna. Também é importante tentar fazer movimentação lateral, que é obter acesso a outras máquinas na mesma rede.

Essa é a fase onde você irá avaliar a segurança interna do sistema, afim de responder a pergunta: "se um atacante invadir meu sistema, o que ele conseguiria fazer?"

Com essa análise, você gera informações úteis para o cliente saber como fazer defesa em profundidade e você prova na prática que isso é realmente importante.

Reporting

Finalmente, após fazer toda a análise, você escreve o relatório para o cliente. No relatório é importante ter um relatório executivo que explique em termos simples os resultados do pentest. Nessa parte do relatório, escreva supondo que um leigo irá ler.

Logo depois escreva o relatório técnico explicando de forma técnica os resultados do pentest. Descreva quais foram os resultados, o impacto que você conseguiu causar e liste todas as vulnerabilidades encontradas com evidências e provas de conceito.

Daí é só mandar o PDF para o cliente e fim! Missão cumprida! Só não esqueça: entregue o PDF de forma segura. Use GPG para encriptar o PDF usando criptografia assimétrica (usando a chave pública do cliente), se possível. Se não, pensa em outro jeito seguro. O relatório não pode ser lido por qualquer pessoa. Ele contém informações extremamente sensíveis que comprometem a segurança do sistema analisado.

Dicas

Eu desenvolvi uma ferramenta própria de shell que faz log de todo comando executado, salvando o comando e a saída do comando (veja aqui). Sugiro usar essa ferramenta, fazer uma semelhante ou pelo menos usar a ferramenta script que é uma versão simples disso. É útil para ter a saída de ferramentas como nmap, ffuf etc. gravadas para uso posterior no relatório. Essa ferramenta já vem no Debian e creio que em outras distros também (rode script --help aí no seu terminal).

Crie um template de relatório de pentest. Coloque uma descrição breve da metodologia usada (exemplo: PTES) e separe relatório executivo de relatório técnico. E coloca um gráfico no relatório executivo. As pessoas adoram gráficos. :D

Escreva bem... Sério, escreva bem! Não é opcional. Pratique sua escrita diariamente ou até pague aulas de Português se for necessário, mas escreva igual um adulto funcional. Nada de Português de rede social no relatório. Sim, o cliente se importa com isso.