Cibersegurança e segurança da informação

Escrita de Relatório de Teste de Penetração que Leva à Correção

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre a escrita de um relatório de Teste de Penetração na área de Penetration Testing

Resposta rápida

A escrita de um relatório de Teste de Penetração deve ser realizada apenas no âmbito de um Scope e Rules of Engagement aprovados. O processo inclui recolha de informações, validação controlada, Evidências, avaliação de risco, correção e Retest.

Um teste de penetração profissional é um processo autorizado e definido, não uma coleção de comandos. Scope, Rules of Engagement, evidências, avaliação de risco, correção e Retest são partes integrantes do trabalho. Este artigo foca-se na escrita de um relatório de Teste de Penetração e destina-se a Junior Pentesters e gestores de segurança. O objetivo é fornecer uma metodologia de trabalho que pode ser aplicada na prática, numa entrevista profissional e num ambiente de trabalho, sem se contentar com uma definição de dicionário.

O principal desafio é que os dados estão quase sempre incompletos. O executive summary, scope e methodology podem indicar uma direção, mas o seu significado depende do tempo, do ativo, do utilizador e da atividade esperada. Por isso, construímos o teste em torno de uma questão de investigação, das evidências necessárias e de um critério claro para a conclusão.

O cenário prático no artigo é: reescrever um Finding fraco para um achado profissional. Todos os exemplos são dados de laboratório ou descrições de processos. Quando se trata de Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com autorização explícita, Scope definido e capacidade de interromper o teste.

Estrutura do Relatório

Os campos importantes não são necessariamente aqueles que são exibidos no topo do ecrã. Na escrita de um relatório de Teste de Penetração, é necessário identificar identificadores estáveis, tempo, origem, destino, resultado e contexto. Exemplos úteis são executive summary, scope, methodology, finding, evidence, risk. O objetivo é permitir a Correlação entre registos e não apenas a leitura de um único Event.

Recomenda-se a criação de um pequeno Data dictionary: nome do campo, significado, formato, origem, valores Null esperados e se é fiável para ligação. Assim, é possível distinguir entre um campo de visualização e um identificador investigativo, e identificar quando um Connector ou versão alterou o Schema.

Executive summary

O tópico 'Executive summary' é uma parte central do trabalho na escrita de um relatório de Teste de Penetração. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se pretende tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático de uma ferramenta sem a compreensão do objetivo.

Na prática, registe o executive summary, scope, methodology, finding, evidence, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Technical finding

O tópico 'Technical finding' é uma parte central do trabalho na escrita de um relatório de Teste de Penetração. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se pretende tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático de uma ferramenta sem a compreensão do objetivo.

Risk rating e Evidence

O tópico 'Risk rating e Evidence' é uma parte central do trabalho na escrita de um relatório de Teste de Penetração. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se pretende tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático de uma ferramenta sem a compreensão do objetivo.

Remediation, Retest e Appendices

Um teste profissional para a escrita de um relatório de Teste de Penetração começa com condições de sucesso e condições de falha. Define-se um Caso positivo, um Caso negativo, um Caso limite e uma atividade legítima semelhante. Assim, é possível identificar tanto False Negative quanto False Positive.

Num ambiente autorizado, utiliza-se uma ação mínima que comprove a alegação sem causar danos. Guardam-se Input, Output, tempo e versão, e após a correção, executa-se um Retest no mesmo cenário e verifica-se também a Regressão em funções adjacentes.

Pontos de Teste Únicos

Neste tópico, recomenda-se construir antecipadamente um mapa de evidências focado. Os principais pontos de teste são: executive summary, scope, methodology, finding, evidence, risk, remediation, retest. A lista não é uma Checklist automática; cada item é selecionado porque pode ligar uma entidade, ação e tempo ou explicar um comportamento legítimo.

executive summary: Defina qual é o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará o achado.
scope: Defina qual é o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará o achado.
methodology: Defina qual é o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará o achado.
finding: Defina qual é o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará o achado.
evidence: Defina qual é o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará o achado.
risk: Defina qual é o valor esperado, o que será considerado anómalo e qual a fonte adicional que verificará o achado.

Quando um dos focos não está disponível, é necessário documentar a lacuna e escolher uma alternativa. Por exemplo, se o Process identifier não for estável, pode-se usar tempo, Host, User e Parent; se o Payload estiver encriptado, usam-se Metadata, volume, frequência e TLS/DNS context.

Processo de Trabalho Recomendado

Defina o Scope e uma pergunta de trabalho sobre a escrita de um relatório de Teste de Penetração.
Registe as fontes de dados e evidências necessárias: executive summary, scope, methodology, finding.
Crie uma Baseline curta de comportamento normal ou resultado esperado.
Execute o teste mínimo em ambiente de laboratório e guarde o tempo, entrada e saída.
Construa um Timeline ou tabela de comparação e separe facto de interpretação.
Execute um Pivot para uma fonte adicional para verificar ou refutar a explicação inicial.
Resuma a decisão, limitações, ação recomendada e critério de Retest.

Cenário Prático

O cenário escolhido é reescrever um Finding fraco para um achado profissional. O objetivo do exercício não é provar a capacidade de ataque, mas sim praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, definem-se dados simulados, uma janela de tempo e um resultado esperado.

No final do exercício, deve ser entregue um produto que outro analista ou testador possa rever: uma captura de ecrã ou Export da evidência, um Timeline curto, uma hipótese inicial, uma evidência de verificação, uma limitação e uma recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

Fase	O que fazer	Produto
Preparação	Defina Scope, tempo e objetivo. Registe quais campos ou evidências do executive summary, scope, methodology devem aparecer.	Plano de teste curto
Criação de dados	Execute uma ação segura e simulada relacionada com a escrita de um relatório de Teste de Penetração, sem informações reais ou impacto num sistema de produção.	Evento/Pedido/Fluxo controlado
Recolha	Recolha a evidência bruta e o contexto de uma fonte adicional. Verifique o Time zone, identificadores e integridade.	Duas evidências ligadas
Análise	Escreva o que cada evidência prova, o que não prova e qual é a explicação legítima possível.	Conclusão intermédia
Conclusão	Escolha fechar, escalar, Finding ou Tuning; adicione uma recomendação e Retest.	Produto documentado

Checklist Prática

Verifique e documente: Scope e ROE.
Verifique e documente: Hora do teste e origem.
Verifique e documente: Request/Response ou saída da ferramenta.
Verifique e documente: Impacto comprovado em laboratório.
Verifique e documente: Risk rating.
Verifique e documente: Remediation e Retest.
Indique o Time zone, versão da ferramenta e hora de recolha.
Guarde os dados brutos antes de filtrar ou alterar.
Escreva o que o achado prova e o que ainda é desconhecido.
Defina o proprietário e a ação de acompanhamento com data.

Erros Comuns

Iniciar o teste sem um Scope assinado.
Usar um Exploit agressivo por padrão.
Não guardar Evidence.
Reportar apenas o CVSS sem contexto.
Não propor uma correção aplicável.
Não realizar um Retest.

Resumo e CTA

A escrita de um relatório de Teste de Penetração que leva à correção é um tópico que conecta o conhecimento técnico à disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, mantenha o contexto e o tempo, e escolha uma ação que possa ser justificada e retestada.

No curso Cybersecurity & AI da HPI, estes princípios são praticados usando sistemas, logs e laboratórios. O próximo passo natural é passar para os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portfólio profissional.

Perguntas frequentes

É permitido testar a escrita de um relatório de Teste de Penetração num site público?

Não, sem autorização explícita do proprietário do sistema. Mesmo um teste que pareça simples pode alterar dados, ativar mecanismos de defesa ou ser considerado acesso não autorizado.

O que fazer quando faltam alguns dados?

Documente o que falta, verifique uma fonte alternativa e reduza o nível de confiança. Não preencha campos por suposição ou apresente 'Unknown' como correto.

Quanto tempo as evidências devem ser guardadas?

O tempo depende da política, regulamentação, custo e tipo de incidente. É importante definir antecipadamente a Retenção, Legal hold e a capacidade de exportar evidências num formato verificável.

Como praticar sem colocar em risco um sistema real?

Utilize máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, defina o Scope, Stop conditions e backup antes de iniciar o trabalho.