Quem busca entender o que é pentest normalmente chega com duas dúvidas misturadas: uma técnica e outra prática. A primeira é conceitual — afinal, o que separa um teste de penetração de um simples scanner rodando na rede? A segunda é decisória — vale contratar esse serviço, quanto custa, como escolher quem executa e o que fazer com o relatório depois que ele chega. Este texto foi escrito para responder às duas, sem prometer selo de "sistema seguro" e sem tratar pentest como caixinha de checklist.

Ao longo do artigo, você vai percorrer as fases de um teste de intrusão — do pré-engajamento ao reteste —, entender as diferenças entre abordagens black box, grey box e white box, e ver onde o pentest termina e onde começam a varredura de vulnerabilidades, a auditoria e o red team. Também entram na conversa os pontos que quase ninguém explica: como ler e priorizar um relatório na prática, critérios objetivos para escolher fornecedor sem conflito de interesse, o que fazer nas primeiras semanas após receber os achados e por que o modelo contínuo (PTaaS) muda a postura de segurança de quem publica código toda semana.

Por fim, o texto aborda a carreira de pentester no Brasil, as metodologias que organizam o trabalho e a relação entre testes de intrusão e conformidade regulatória. Se o seu objetivo é se capacitar para atuar nessa área, vale conhecer a trilha de Como trabalhar com segurança da informação e os cursos de cibersegurança da DEFTEC, que cobrem fundamentos de redes, Linux e infraestrutura — a base técnica que qualquer pentester precisa dominar antes de pensar em explorar falhas.

O que é pentest (teste de penetração) e o que ele realmente entrega

Pentest, abreviação de penetration test (teste de penetração), é um ataque simulado e autorizado contra sistemas, redes, aplicações ou infraestrutura física com o objetivo de identificar vulnerabilidades exploráveis antes que um criminoso real as encontre. Diferente de uma tentativa de invasão comum, o pentest opera sob contrato, com escopo definido, regras de engajamento documentadas e autorização formal do proprietário dos ativos. O profissional que executa esse trabalho — o pentester — usa as mesmas técnicas, ferramentas e mentalidade de um atacante, mas registra cada passo e entrega um relatório com evidências, impacto e recomendações de correção.

O que um pentest realmente entrega não é uma nota ou um selo de "sistema seguro". Ele entrega um mapa de falhas com prova técnica de exploração: quais brechas permitem acesso não autorizado, quais dados ficam expostos, qual o caminho que um invasor percorreria e quanto custa corrigir cada achado. Um bom teste responde à pergunta que nenhuma ferramenta automatizada consegue responder sozinha: "até onde um atacante motivado chegaria, com os controles atuais, antes de ser detectado?". Por isso, o valor do pentest está menos na lista de vulnerabilidades e mais na priorização do que corrigir primeiro com base em risco real, não teórico.

Na prática, empresas contratam pentest por três motivos principais: exigência contratual ou regulatória, mudança relevante na infraestrutura (novo sistema, migração para nuvem, lançamento de app) e suspeita ou confirmação de incidente. Em qualquer um dos casos, o resultado esperado é o mesmo: reduzir a superfície de ataque com evidências acionáveis. Um pentest bem executado também expõe falhas de processo — como um firewall mal configurado ou credenciais padrão que sobreviveram a três auditorias — que ferramentas de monitoramento contínuo frequentemente ignoram.

Pentest não é tudo igual: as 4 abordagens que mudam o resultado

A forma como o pentester recebe informação antes do teste altera profundamente o que ele encontra, quanto tempo leva e o custo do projeto. As abordagens se dividem pelo nível de conhecimento prévio sobre o alvo e pelo método de execução. Escolher a errada é uma das causas mais comuns de relatórios que não refletem o risco real da organização.

Caixa-preta, caixa-cinza e caixa-branca

No pentest caixa-preta (black box), o testador recebe apenas informações públicas — nome da empresa, domínio, talvez um IP. Ele precisa descobrir sozinho a infraestrutura, os subdomínios, os serviços expostos e os pontos de entrada. É o cenário que mais se aproxima de um atacante externo sem conhecimento interno, mas também o mais caro e demorado, porque boa parte do tempo é consumida em reconhecimento. Sua principal limitação: como o tempo é finito, falhas óbvias para quem conhece o sistema podem passar despercebidas.

No caixa-cinza (gray box), o pentester recebe credenciais de usuário comum, documentação de API ou acesso limitado a um ambiente de teste. É o equilíbrio mais usado no mercado porque simula tanto o atacante externo quanto o insider com privilégio mínimo, e direciona o esforço para onde há mais retorno: lógica de negócio, escalonamento de privilégio e falhas de autorização. Já o caixa-branca (white box) entrega acesso total ao código-fonte, diagramas de arquitetura, credenciais administrativas e configurações. O foco deixa de ser "achar a porta" e passa a ser "validar se a porta está bem trancada" — ideal para revisar controles internos, lógica de autenticação e segredos embutidos no código.

Pentest manual, automatizado e contínuo (PTaaS)

O pentest manual é conduzido por um profissional que combina ferramentas de varredura com raciocínio criativo, tentativa e erro, e exploração de falhas que nenhum scanner detecta — como quebra de lógica de negócio, cadeias complexas de vulnerabilidades e bypass de controles. Ele é mais lento e caro, mas é o único capaz de validar impacto real. O pentest automatizado usa plataformas que disparam scanners, validam assinaturas conhecidas e geram relatórios em horas. Serve como triagem contínua, não como substituto do teste manual: ferramentas como Nessus, OpenVAS e Burp Suite identificam CVEs conhecidos, mas não entendem contexto de negócio.

O modelo contínuo, conhecido como PTaaS (Penetration Testing as a Service), combina os dois: uma plataforma executa varreduras frequentes e um time de pentesters valida manualmente os achados mais relevantes, em ciclos curtos. Em vez de um evento anual, a empresa recebe um fluxo constante de validações. Para times que lançam código semanalmente, o PTaaS reduz a janela entre "introduzir a falha" e "descobrir a falha" de meses para dias — o que muda completamente a postura de segurança.

Pentest, varredura de vulnerabilidades, auditoria e red team: onde cada um termina

Os quatro termos aparecem juntos em propostas comerciais, mas entregam coisas diferentes. A varredura de vulnerabilidades (vulnerability scan) é automatizada, não explora falhas e gera uma lista de possíveis problemas com base em assinaturas e versões. Ela responde "o que pode estar errado". O pentest vai além: explora a falha, mede o impacto e responde "o que um atacante consegue fazer com isso". Um scanner aponta um servidor com SMBv1 habilitado; o pentester usa o EternalBlue, compromete o host e demonstra movimento lateral até o domínio.

A auditoria de segurança compara a configuração real com um padrão de referência — políticas internas, CIS Benchmarks, ISO 27001. Ela verifica conformidade, não resistência a ataque. Um sistema pode passar numa auditoria e cair em minutos num pentest, porque auditoria mede aderência a checklist e pentest mede capacidade de defesa sob pressão. Já o red team é um exercício mais amplo que o pentest: simula um adversário com objetivo específico (roubar dados do CFO, acessar o core bancário) sem escopo rígido, testando também detecção, resposta a incidentes e resiliência humana. O pentest tem alvo definido e prazo curto; o red team tem objetivo estratégico e pode durar semanas.

As 7 fases de um pentest, do escopo ao reteste

Metodologias como PTES (Penetration Testing Execution Standard), OWASP WSTG e NIST SP 800-115 organizam o trabalho em fases que vão da negociação inicial à validação das correções. Entender essas fases ajuda a contratar melhor e a interpretar o relatório final sem cair em promessas vagas.

Pré-engajamento, regras de engajamento e escopo

Antes de qualquer comando rodar, o pentest começa com o pré-engajamento: definição de quais ativos entram no teste (IPs, domínios, APIs, aplicações, faixas de rede), quais ficam fora, janela de execução, canais de comunicação e quem pode autorizar ações emergenciais. As regras de engajamento especificam o que o pentester pode ou não fazer — por exemplo, não usar ataques de negação de serviço em produção, não acessar dados pessoais além do necessário para provar a falha, não explorar vulnerabilidades em sistemas de terceiros. Um escopo mal redigido é a principal fonte de conflito jurídico: invadir um IP fora do contrato, mesmo por engano, pode configurar crime no Brasil, independentemente da boa intenção.

O contrato precisa prever também cláusulas de confidencialidade, tratamento de dados coletados durante o teste, propriedade do relatório e limitação de responsabilidade. Empresas que pulam essa fase para "economizar tempo" costumam pagar caro depois — com incidente real, processo ou relatório inutilizável porque o alvo testado não era o que interessava.

Reconhecimento, modelagem de ameaças e exploração controlada

O reconhecimento divide-se em passivo (sem tocar no alvo: WHOIS, DNS, Shodan, redes sociais, repositórios públicos) e ativo (interação direta: varredura de portas, enumeração de serviços, fingerprint de versões). É aqui que o pentester monta o mapa de superfície de ataque e escolhe os vetores mais promissores. A modelagem de ameaças prioriza esses vetores: o que é mais valioso para a empresa, quem teria interesse em atacar, qual o caminho de menor resistência. Um e-commerce prioriza falhas em checkout e API de pagamento; uma clínica prioriza exposição de prontuários.

A exploração controlada é a fase em que as vulnerabilidades confirmadas são aproveitadas para demonstrar impacto — escalar privilégio, extrair um registro do banco, assumir uma conta administrativa. O controle é essencial: o pentester documenta cada comando, limita o dano ao necessário para a prova e preserva evidências (screenshots, logs, payloads). A fase seguinte, pós-exploração, busca manter acesso, pivotar para outros sistemas e identificar o que mais poderia ser comprometido a partir daquele ponto — mas sempre dentro do escopo autorizado.

Relatório executivo, relatório técnico e reteste

O resultado do pentest se materializa em dois documentos com públicos diferentes. O relatório executivo resume riscos em linguagem de negócio: quantas falhas críticas, qual o impacto financeiro ou reputacional potencial, o que precisa de ação imediata e qual o prazo recomendado. Ele não lista payloads; ele responde "estamos quanto expostos e o que fazer primeiro". O relatório técnico traz a evidência completa: vulnerabilidade, CVE quando houver, CVSS, passo a passo de reprodução, prova de conceito, trecho de código afetado e recomendação específica de correção.

O reteste fecha o ciclo: depois que a equipe interna corrige as falhas, o pentester valida se a correção funciona e se não introduziu nova vulnerabilidade. Reteste sem custo adicional é prática comum para falhas críticas, mas precisa estar previsto em contrato — muitas propostas cobram o reteste como serviço separado. Sem reteste, a empresa não tem confirmação de que o problema saiu do papel e foi resolvido de fato.

Tipos de pentest por alvo: web, API, mobile, rede, nuvem, OT e engenharia social

O alvo define as ferramentas, a metodologia e o perfil do pentester. Um especialista em aplicação web não é automaticamente qualificado para testar uma rede industrial, e contratar o perfil errado produz relatórios superficiais.

  • Pentest web: foca em aplicações e sites; segue OWASP Top 10 — injeção, autenticação quebrada, XSS, CSRF, SSRF, controle de acesso falho.
  • Pentest de API: testa REST, GraphQL e SOAP; valida autenticação, autorização por objeto (IDOR/BOLA), rate limiting e vazamento de dados em respostas.
  • Pentest mobile: analisa apps Android e iOS; verifica armazenamento inseguro, comunicação com backend, certificados, root/jailbreak detection e engenharia reversa.
  • Pentest de rede: cobre infraestrutura interna e externa; explora serviços expostos, segmentação, protocolos legados, Active Directory e movimento lateral.
  • Pentest de nuvem: revisa configuração de IAM, buckets, permissões entre serviços, segredos em repositórios e identidade federada em AWS, Azure ou GCP.
  • Pentest de OT/ICS: mira ambientes industriais — SCADA, PLC, redes Modbus; exige cuidados redobrados para não interromper processos físicos.
  • Engenharia social: testa o fator humano via phishing, pretexting, USB drop ou tentativa de acesso físico; mede a eficácia de treinamentos e políticas.

A escolha do tipo depende do que a empresa quer proteger e do que mudou recentemente. Um banco que lançou um app novo prioriza pentest mobile e de API; uma indústria que conectou o chão de fábrica à rede corporativa prioriza OT e segmentação. O erro mais comum é contratar "um pentest" genérico sem definir o alvo — o fornecedor testa o que for mais fácil, não o que é mais crítico.

Vale lembrar que engenharia social frequentemente entrega mais resultado com menos esforço técnico. Um e-mail de phishing bem elaborado ou um SMS fraudulento pode render credenciais em minutos, sem tocar em nenhum firewall. Por isso, qualquer programa sério de pentest inclui o fator humano como vetor de teste, não apenas a infraestrutura.

O que um relatório de pentest precisa conter para ser útil

Um relatório que só lista vulnerabilidades não serve para decidir nada. O documento útil conecta cada achado a risco de negócio, priorização e ação concreta. Os elementos mínimos de um relatório acionável são:

  • Sumário executivo: visão geral do risco, achados críticos e recomendação de prioridade em uma página.
  • Escopo e limitações: o que foi testado, o que ficou de fora, janela de execução e restrições impostas.
  • Metodologia: padrão seguido (PTES, OWASP, NIST), fases executadas e ferramentas utilizadas.
  • Achados detalhados: cada vulnerabilidade com descrição, evidência, impacto, probabilidade, CVSS e referência (CVE, CWE).
  • Prova de conceito: reprodução passo a passo que permita à equipe interna validar e corrigir.
  • Recomendação por achado: correção específica, não genérica — "atualize a biblioteca X para a versão Y" em vez de "mantenha sistemas atualizados".
  • Matriz de risco: classificação por criticidade que oriente a ordem de correção.
  • Anexos técnicos: logs, payloads, capturas de tela e saídas de ferramentas.

Além do conteúdo, o relatório precisa ser legível por dois públicos: o diretor que aprova orçamento e o analista que vai corrigir a falha. Relatórios com 300 páginas de saída de scanner sem priorização são tão inúteis quanto relatórios executivos sem evidência técnica. O equilíbrio está em hierarquizar: as 5 falhas que importam primeiro, com profundidade, e o restante em anexo.

A priorização deve considerar não só o CVSS, mas o contexto. Uma falha crítica em sistema interno sem exposição à internet pode ser menos urgente que uma falha média em API pública com dados de clientes. O relatório bom já entrega essa leitura; o relatório fraco deixa o trabalho de interpretar para a equipe interna, que muitas vezes não tem repertório para isso.

Quanto custa, quanto tempo leva e com que frequência fazer

No mercado brasileiro, os valores variam conforme escopo, abordagem e senioridade do fornecedor. PTaaS costuma ser cobrado por assinatura mensal.

O prazo segue a mesma lógica. Prazos muito abaixo do esperado para escopo equivalente são sinal de alerta: ou o teste é superficial, ou é automatizado disfarçado de manual.

Quanto à frequência, a regra prática é: pentest completo pelo menos uma vez por ano para sistemas críticos, e sempre que houver mudança relevante — novo módulo, migração de infraestrutura, integração com terceiro, incidente de segurança. Aplicações que recebem deploy semanal se beneficiam mais de PTaaS contínuo do que de um evento anual. Para conformidade, PCI DSS exige pentest anual e após mudanças significativas no ambiente de dados de cartão; ISO 27001 pede avaliação de riscos periódica, com pentest como evidência comum de controle A.12.6.1.

Pentest e conformidade: LGPD, ISO 27001, PCI DSS, NIST e CIS Controls

Nenhuma dessas normas exige pentest com esse nome exato, mas todas criam obrigações que o pentest ajuda a cumprir e a evidenciar. A LGPD (Lei nº 13.709/2018) exige medidas técnicas e administrativas para proteger dados pessoais, e o art. 46 determina que os agentes adotem medidas de segurança compatíveis com o risco. Um pentest documentado comprova que a empresa testa seus controles — evidência valiosa em caso de incidente ou questionamento da ANPD.

A ISO 27001 trata de pentest nos controles A.8.8 (gestão de vulnerabilidades técnicas) e A.8.29 (testes de segurança em desenvolvimento). O pentest não é obrigatório para certificação, mas auditores frequentemente pedem evidência de testes em ativos críticos. O PCI DSS é mais direto: o requisito 11.4 exige teste de penetração anual na rede e em aplicações, com metodologia reconhecida, cobertura do ambiente de dados de cartão e correção de achados com reteste. É a norma que mais objetivamente obriga pentest no mercado.

O NIST SP 800-115 é o guia técnico de referência para planejar e executar testes de segurança, e o CIS Controls trata do tema no Controle 18 (testes de penetração) e no Controle 7 (gestão contínua de vulnerabilidades). Empresas que seguem CIS Controls usam pentest como validação periódica de que os controles preventivos funcionam sob ataque real. Em todos os casos, o valor não está no relatório em si, mas na demonstração de um ciclo: testar, corrigir, retestar e documentar.

Erros que fazem o pentest virar só um PDF na gaveta

O padrão é conhecido: a empresa contrata o teste, recebe o relatório, arquiva e segue operando com as mesmas falhas. Isso acontece por erros previsíveis, quase sempre de processo, não de tecnologia.

  • Escopo genérico: contratar "um pentest" sem definir alvos, abordagem e profundidade gera relatório que não responde às perguntas do negócio.
  • Sem dono para as correções: ninguém é designado responsável por tratar os achados; o relatório circula e morre no e-mail.
  • Corrigir só o sintoma: aplicar patch na falha apontada sem investigar a causa raiz — a próxima versão reintroduz o mesmo problema.
  • Pular o reteste: assumir que a correção funcionou sem validar; muitas "correções" não fecham a falha de verdade.
  • Priorizar por CVSS em vez de contexto: gastar semanas numa falha crítica sem exposição enquanto uma falha média em produção segue aberta.
  • Tratar pentest como evento anual: entre um teste e outro, meses de código novo entram em produção sem validação.
  • Contratar o mesmo fornecedor para corrigir e retestar: conflito de interesse clássico — quem corrige não deve validar a própria correção.

O antídoto para o "PDF na gaveta" é um plano de remediação com dono, prazo e critério de aceite para cada achado. Nas primeiras 30 dias após receber o relatório, o mínimo esperado é: corrigir as falhas críticas, agendar reteste, comunicar risco residual à diretoria e inserir os achados no backlog de segurança. Empresas maduras transformam cada achado em item de um processo contínuo — muitas vezes usando um CMDB para mapear ativos afetados e garantir que nenhuma correção se perca.

Outro erro recorrente é não medir evolução. Se o segundo pentest encontra as mesmas classes de falha do primeiro, o programa não está funcionando — independentemente do número de patches aplicados. A métrica certa não é "quantas vulnerabilidades corrigimos", mas "quantas classes de falha deixaram de existir entre um ciclo e outro". Essa leitura de maturidade é o que separa empresa que usa pentest como ferramenta de gestão da que o usa como obrigação burocrática.

Perguntas frequentes sobre pentest

Pentest é ilegal no Brasil? Não, desde que haja autorização formal do proprietário dos ativos, escopo documentado e regras de engajamento assinadas. Sem autorização, a conduta pode se enquadrar no art. 154-A do Código Penal (invasão de dispositivo informático), com pena de 1 a 4 anos de reclusão, aumentada se houver prejuízo econômico.

Qual a diferença entre pentest e bug bounty? O pentest é um serviço contratado, com escopo fechado, prazo definido e relatório formal. Bug bounty é um programa aberto e contínuo, em que qualquer pesquisador pode reportar falhas e receber recompensa por achado validado. São complementares: o pentest cobre profundidade em janela curta; o bounty cobre amplitude em tempo contínuo.

Preciso de pentest se já tenho varredura de vulnerabilidades? Sim. A varredura encontra problemas conhecidos; o pentest valida se eles são exploráveis, em cadeia, e se geram impacto real. São camadas diferentes do mesmo programa de segurança, não substitutos.

Quem deve executar o pentest: equipe interna ou fornecedor externo? O ideal é combinar: equipe interna para testes contínuos e conhecimento profundo do ambiente; fornecedor externo para visão independente, sem vícios de quem construiu o sistema. Para conformidade e auditoria, o olhar externo costuma ter mais peso como evidência.

Pentest pode derrubar meu sistema? Existe risco, especialmente em testes de disponibilidade ou exploração agressiva. Por isso as regras de engajamento definem o que é proibido e o que exige autorização prévia. Um pentester experiente trabalha com margem de segurança e comunicação constante com o time responsável.

O que estudar para trabalhar com pentest? A base passa por redes, sistemas operacionais — com forte presença de Linux como base da infraestrutura —, programação para automação e leitura de código, e domínio de metodologias como OWASP e PTES. Certificações como OSCP, eWPT e PNPT são referências de mercado. A carreira exige prática constante em laboratório, porque a única forma de aprender a explorar é explorando em ambiente controlado.