Pentest: como funciona o teste de intrusão e o que cobrar do fornecedor

Autor: Pedro Tebaldi PM do KeepGreen

Publicado ago/2021Atualizado ago/2026

Durante quase duas décadas, a credencial roubada foi a porta de entrada preferida de quem ataca uma empresa. Esse posto mudou de dono. Na edição de 2026 do relatório anual da Verizon, 31% das violações já começam pela exploração de uma falha de software.

Para quem responde pela infraestrutura, a pergunta deixou de ser se existem falhas no ambiente. Existem. A questão passou a ser quais delas alguém consegue encadear até chegar ao dado que importa. Um scanner automatizado responde à primeira. O teste de intrusão responde à segunda.

Este guia fala com quem contrata o serviço, define o escopo e depois recebe o relatório. Ele cobre a diferença para a varredura, os tipos de teste e as sete fases do trabalho. Em seguida, trata do intervalo defensável entre duas rodadas e do que fazer com cada achado.

O que é pentest e o que o relatório precisa provar

O pentest é um ataque simulado e autorizado contra sistemas, redes ou aplicações de uma empresa. Quem executa usa as mesmas técnicas de um invasor real. O objetivo não é listar falhas. É provar quais delas se encadeiam até um impacto concreto: acesso ao banco de dados, movimentação lateral, tomada de conta administrativa.

Essa distinção muda o que você deve exigir na entrega. Um relatório que devolve trinta itens com pontuação de severidade repete o que uma ferramenta já entregaria sozinha. O relatório útil mostra o caminho percorrido: por onde entrou, o que reutilizou, onde parou e o que teria acontecido se ninguém interrompesse.

Por isso a autorização escrita importa tanto quanto a competência técnica. Ela é o que separa o exercício controlado do crime. O documento nomeia alvos, janelas, técnicas permitidas e a pessoa responsável de cada lado. Sem ele, não existe teste: existe incidente.

Vale registrar o outro lado da moeda. O teste não prova que o ambiente está seguro. Ele prova que, naquele escopo e naquela janela, um profissional qualificado chegou até determinado ponto. Tudo que ficou fora continua sem resposta. Essa lacuna precisa aparecer no documento final.

Pentest ou análise de vulnerabilidade: o que muda na prática

Esta é a dúvida número um de quem vai contratar. A confusão custa caro: muita empresa paga por teste manual e recebe o relatório de um scanner com a capa trocada. As duas atividades têm propósitos diferentes, ritmos diferentes e entregas diferentes.

As duas não se substituem. A varredura roda de forma contínua sobre todo o parque e mantém o inventário de exposição atualizado. Se o seu programa ainda não tem essa camada rodando, comece por ela: o processo está descrito em como funciona a análise de vulnerabilidade, que trata da avaliação e do tratamento de risco.

Um sinal prático para reconhecer o serviço errado: peça ao fornecedor a cadeia de exploração de um achado crítico. Se a resposta for a saída bruta de uma ferramenta com o número do CVE, você contratou varredura. Se vier a sequência de comandos, as evidências e o ponto de parada acordado, é teste manual.

Os três tipos por nível de informação

White box, grey box e black box descrevem quanto a equipe de teste sabe antes de começar. A escolha não é sobre rigor técnico: é sobre qual cenário de ataque você quer simular e quanto orçamento vai para a fase de descoberta.

Na prática, o grey box costuma ser o padrão para trabalho contratado: entrega profundidade sem gastar metade da janela em descoberta. O black box faz sentido quando a pergunta é sobre superfície externa. Já o white box serve quando uma aplicação específica precisa passar por revisão antes do lançamento.

Onde o teste é aplicado: alvos que pedem abordagens diferentes

Definido o nível de informação, resta escolher o alvo. Cada superfície tem ferramental próprio. Misturar tudo em um único contrato dilui a profundidade.

Perímetro externo: tudo que responde da internet, incluindo VPN, portais de acesso remoto e serviços expostos por engano. É o escopo que mais se aproxima do vetor descrito no relatório da Verizon, porque concentra os dispositivos de borda.

Rede interna: simula quem já está dentro, por credencial vazada ou por máquina comprometida. Mede o que a segmentação da rede segura de fato. Costuma ser a superfície que mais surpreende quem contrata pela primeira vez.

Aplicação web e API: autenticação, autorização, tratamento de sessão e regra de negócio. É onde aparecem as falhas que nenhuma assinatura pega, como alterar o preço no carrinho ou acessar o pedido de outro cliente trocando um identificador.

Wireless: autenticação da rede sem fio, isolamento entre SSIDs e rede de visitantes com rota indevida para a rede corporativa.

Engenharia social: phishing dirigido, ligação com pretexto e acesso físico. Mede pessoas e processo, não tecnologia. Antes de contratar, vale alinhar com o jurídico e o RH como o resultado será comunicado. Os vetores usados aparecem em principais tipos de ataques virtuais.

Nuvem: permissões de identidade, papéis com privilégio excessivo, buckets e chaves em repositório. Aqui o contrato precisa observar as regras do provedor sobre teste em ambiente compartilhado.

As sete fases de um teste de intrusão

Os artigos sobre o tema costumam falar em cinco fases. O padrão de execução mais citado descreve sete. A diferença não é cosmética: as duas fases extras separam trabalho de consultoria de execução de ferramenta.

A sequência abaixo segue a documentação pública do padrão de execução, mantida desde 2009 por profissionais da área. Cada fase tem um entregável verificável. É por ele que o contratante acompanha o andamento.

Fase 1: pré-engajamento

Antes de qualquer comando, as duas partes escrevem o acordo. Alvos por IP, domínio e aplicação. Janela de execução. Técnicas proibidas, como negação de serviço ou força bruta em conta de produção. Canal de emergência para interromper o trabalho. Assinatura de quem autoriza dos dois lados.

Entregável: documento de escopo e regras de engajamento. É o item que mais influencia o prazo total. Escopo aberto, com centenas de hosts internos, consome semanas. Uma aplicação web com poucas rotas termina em dias.

Fase 2: coleta de informação

A equipe monta o mapa do alvo com fontes abertas e varredura ativa: domínios, subdomínios, faixas de IP, tecnologias em uso, funcionários expostos em redes profissionais, credenciais vazadas em incidentes anteriores. Em black box, esta fase consome a maior parte do orçamento.

Entregável: superfície de ataque documentada. Muitas empresas descobrem aqui, antes de qualquer exploração, serviços que ninguém sabia que estavam publicados.

Fase 3: modelagem de ameaça

Com o mapa na mão, a equipe define o que vale a pena atacar. Quais ativos sustentam receita ou processo crítico? Quais perfis de atacante fazem sentido para o seu setor? Quais caminhos parecem mais curtos até o dado sensível?

Entregável: priorização de alvos. Esta fase é a que evita o relatório genérico. Sem ela, o teste ataca o que é fácil, não o que dói.

Fase 4: análise de vulnerabilidade

Aqui entra a varredura, agora dirigida pela fase anterior. Ferramentas automatizadas levantam candidatos, o especialista descarta ruído e valida manualmente o que sobra. É o ponto de encontro entre as duas disciplinas comparadas mais acima.

Entregável: lista de candidatos validados, com hipótese de exploração para cada um. Ainda não existe prova: existe alvo confirmado.

Fase 5: exploração

A execução propriamente dita. A equipe tenta explorar cada candidato dentro das técnicas permitidas, registrando comando, resposta e evidência. O critério de sucesso não é derrubar o serviço: é obter acesso, dado ou privilégio que não deveria estar disponível.

Entregável: achados confirmados com evidência reproduzível. Cada item precisa vir com o passo a passo que permite ao seu time reproduzir e depois validar a correção.

Fase 6: pós-exploração

Obtido o primeiro acesso, a pergunta muda: até onde dá para ir a partir daqui? Escalada de privilégio, movimentação lateral, persistência, acesso a dados. É a fase que transforma um achado técnico em número que a diretoria entende.

Entregável: cadeia completa, do ponto de entrada ao impacto final. Também sai daqui o inventário do que precisa ser limpo: contas criadas, agentes instalados, artefatos deixados no ambiente.

Fase 7: relatório

O documento final tem duas audiências. O sumário executivo traduz risco em linguagem de negócio, com o que aconteceria se o caminho encontrado fosse percorrido por alguém mal-intencionado. A parte técnica traz cada achado com severidade, evidência, passo de reprodução e recomendação de correção.

Entregável: relatório com plano de correção e, no contrato bem escrito, direito a reteste dentro de um prazo. Sem reteste, ninguém prova que a correção funcionou.

De quanto em quanto tempo refazer o teste

O intervalo de referência é de 12 meses, com uma rodada adicional a cada mudança significativa no ambiente. Esse critério vem do PCI DSS, que exige teste interno no requisito 11.4.2 e teste externo no 11.4.3.

O texto completo está na biblioteca de documentos do PCI Security Standards Council. Vale ler o requisito inteiro antes de fechar contrato: ele também exige metodologia documentada.

Fora do setor de cartões, esse intervalo virou padrão de fato porque resolve um problema prático: doze meses é o horizonte de um orçamento e de um ciclo de auditoria. O que não pode acontecer é o teste virar evento de calendário enquanto o ambiente muda toda semana.

Os gatilhos que antecipam a próxima rodada, independentemente da data:

Mudança de segmentação ou de perímetro. Novo link, novo datacenter, migração de carga para nuvem, troca de firewall de borda. O desenho testado no ano passado deixou de existir.

Aplicação nova ou release que mexe em autenticação e autorização. Um controle de acesso reescrito é superfície nova, mesmo que a interface pareça igual.

Fusão, aquisição ou incorporação de parque. Você herdou uma rede que ninguém do seu time desenhou, com dívida de segurança desconhecida.

Incidente confirmado. Depois de conter, é preciso validar se o vetor foi realmente fechado e se o atacante não deixou caminho alternativo.

Sobre obrigação legal, cuidado com o atalho: nenhuma norma geral brasileira cita o teste pelo nome. A lei geral de proteção de dados exige medidas de segurança aptas a proteger dados pessoais, sem determinar a técnica. A exigência explícita aparece em normas setoriais e em contratos com grandes clientes.

O que fazer com o relatório depois que ele chega

Esta é a parte que a maioria dos textos sobre o assunto pula. É também onde o investimento se perde. Um relatório entregue vira PDF em pasta compartilhada quando não existe dono, prazo nem reteste combinados desde o início.

O primeiro ajuste é mental: severidade técnica não é risco de negócio. Uma falha classificada como alta em um sistema sem dado sensível e sem exposição externa pode esperar. Uma falha média em um sistema que processa pagamento não pode. Quem faz essa tradução é o time de TI junto com o dono do sistema, não a ferramenta que calculou a pontuação.

O segundo ajuste é contratual. Combine o prazo de correção por faixa de severidade antes do teste começar, com quem pode aprovar exceção. O modelo abaixo funciona como ponto de partida e deve ser calibrado ao seu apetite de risco.

O terceiro ajuste é operacional. Ele é o que fecha o ciclo. Cada achado que não será corrigido no prazo precisa virar regra de detecção: se a falha continua aberta, o mínimo é enxergar quando alguém tentar explorá-la. O caminho encontrado vira caso de uso de correlação de eventos de segurança, com alerta e responsável definido.

Por fim, registre o resultado onde a decisão acontece. Achado aceito sem correção é risco assumido. Risco assumido pertence ao processo formal de risco em TI, com prazo de reavaliação e nome de quem aceitou. Sem esse registro, a mesma falha reaparece no relatório do ano seguinte como novidade.

Cinco erros que anulam o resultado do teste

1. Escrever o escopo pelo orçamento, não pelo risco. Cortar a rede interna porque o valor ficou alto entrega um relatório sobre a parte do ambiente que você já monitorava. O ajuste correto é reduzir profundidade ou dividir em duas rodadas, mantendo o alvo que importa.

2. Comprar varredura vendida como teste manual. O sinal está na entrega: saída bruta de ferramenta, achados sem passo de reprodução, nenhuma cadeia de exploração. Peça uma amostra de relatório anonimizado antes de assinar.

3. Começar sem dono nem prazo de correção. Sem isso, o relatório chega e a discussão sobre quem corrige o quê consome mais tempo do que o próprio teste consumiu.

4. Testar só o perímetro. O perímetro é a primeira porta. O que decide o tamanho do estrago é o que acontece depois dela. Isso só aparece em teste interno ou em fase de pós-exploração bem contratada.

5. Tratar o relatório como documento de auditoria. Ele é backlog. Cada achado vira item com responsável, prazo e critério de aceite, dentro da mesma ferramenta onde o time já trabalha. Programa de segurança que vive em PDF não sobrevive ao segundo trimestre, como discutimos no guia de segurança cibernética para empresas.

O teste é uma foto. A operação é o filme.

Um teste de intrusão bem contratado responde a uma pergunta específica: naquele escopo, naquela janela, até onde alguém qualificado consegue chegar. A resposta tem prazo de validade curto, porque o ambiente muda com cada release, cada regra de firewall e cada conta criada.

Por isso o resultado só se sustenta quando alimenta a rotina. Os caminhos encontrados viram regra de detecção. Os achados viram backlog com dono e prazo. O que não foi corrigido vira risco registrado com data de reavaliação.

Entre uma rodada e outra, quem cobre o intervalo é a vigilância contínua. Uma operação de detecção 24×7 enxerga a tentativa de exploração no dia em que ela acontece, não no relatório do ano seguinte.

É esse encaixe que a OpServices monta com o time de TI dos clientes: correlação de eventos, alerta com dono definido e visibilidade contínua da infraestrutura, para que o resultado do teste vire operação em vez de arquivo. Converse com nossos especialistas e avalie como fechar esse ciclo no seu ambiente.