Pentest

O que é um pentest?

O pentest manual é uma avaliação de segurança na qual um pentester ataca um alvo de avaliação sob regras acordadas, explora as fraquezas encontradas e documenta o impacto. Seu resultado não é uma lista de alertas, e sim evidência: um caminho reproduzível de um ponto de entrada até uma consequência de negócio.

Dois limites importam. Pentest não é varredura de vulnerabilidades, que automatiza a detecção mas para antes da exploração. E não é red teaming, que avalia a capacidade de detecção e resposta de uma organização, não a segurança de um sistema específico.

A técnica também é chamada de pentest manual, e esse qualificativo não é redundante. As ferramentas apoiam o trabalho em cada fase, mas as decisões que produzem um achado —qual hipótese testar, quais fraquezas encadear, quando um resultado prova impacto— são tomadas por uma pessoa. O "pentest automatizado" descreve varredura com um nome mais ambicioso.

Como o pentest é legal e autorizado, o profissional que o realiza é chamado de pentester, hacker ético ou analista de segurança. Certificações como OSCP ou OSEE sinalizam formação, mas a condição para o papel é demonstrar habilidade para contornar defesas dentro de um orçamento de tempo e um escopo definido.

Por que o pentest é importante?

O pentest importa porque continua sendo de onde vêm os achados de maior risco. A detecção automatizada melhorou e cobre uma amplitude que nenhum humano iguala, mas a profundidade e a prova de impacto seguem sendo trabalho manual.

Os pentesters reportam a maioria dos achados críticos

Em seu relatório State of Attacks 2026, a Fluid Attacks analisou dados de testes de segurança coletados em sistemas de clientes entre 1º de janeiro e 31 de dezembro de 2025. Os pentesters reportaram 87 % dos achados de severidade crítica nesses sistemas.

O mesmo relatório mostra por que contar achados induz ao erro. As ferramentas automatizadas identificaram 88,4 % da contagem total de vulnerabilidades, mas apenas 55,8 % da exposição ao risco total. Medido em unidades CVSSF, um achado de ferramenta teve média de 15,5 e um achado de pentest 93,2: seis vezes mais risco por ocorrência.

As ferramentas sozinhas deixam a maior parte do risco sem detectar

O benchmark citado acima mediu as duas abordagens contra a mesma aplicação. O recall do pentester foi de 89,6 % por contagem de vulnerabilidades e de 98,9 % por CVSSF, ou seja, encontrou quase toda a exposição ao risco da aplicação. Combinadas, todas as ferramentas automatizadas avaliadas ainda não alcançariam 60 % de recall por CVSSF.

Essa lacuna não é uma falha dos scanners: reconhecer padrões conhecidos em alta velocidade é para o que eles foram construídos. O que não conseguem fazer é raciocinar sobre as regras de uma aplicação, e é aí que o pentest justifica seu custo.

A conformidade fixa um piso, não uma meta

Vários padrões estabelecem uma cadência fixa para o teste de penetração. O PCI DSS v4.0.1 exige pentest interno e externo pelo menos a cada 12 meses, e testes sobre os controles de segmentação a cada 12 meses, ou a cada seis meses no caso dos prestadores de serviço. Esse ciclo de seis meses cobre os controles de segmentação, não o pentest completo, uma distinção que a maioria dos resumos erra. Sob a FTC Safeguards Rule que implementa a Gramm-Leach-Bliley Act, uma instituição financeira sem monitoramento contínuo efetivo realiza um teste anual e avaliações de vulnerabilidades a cada seis meses. Esses intervalos definem um mínimo, não uma postura de segurança. Um sistema que muda toda semana não é descrito por um teste feito uma vez por ano.

Pentest, avaliação de vulnerabilidades e varredura de vulnerabilidades não são alternativas

Esses três termos costumam ser comparados como se uma organização tivesse que escolher um. Eles respondem a perguntas diferentes: a avaliação de vulnerabilidades é o "o quê" —a avaliação sistemática da segurança de um sistema—, enquanto o pentest e a varredura são dois "como" que a alimentam.

Os dois métodos alimentam a mesma avaliação de vulnerabilidades; a comparação é entre técnicas, não entre uma técnica e um objetivo.

Tratá-los como rivais leva à compra errada. Uma organização que só roda varreduras automatizadas obtém amplitude sem prova, e uma que contrata pentest uma vez por ano obtém prova sem cobertura. A combinação é o que produz uma avaliação de vulnerabilidades útil.

Pentest na Fluid Attacks

A Fluid Attacks executa Pentesting as a Service (PTaaS) de forma contínua, não como um projeto pontual, junto com Secure Code Review e Reverse Engineering, e os combina com IA e scanners próprios em uma única plataforma. A empresa é CVE Numbering Authority desde 2021 —CVE-2026-6093, uma injeção de SQL no Corteza, é um dos registros que nossa equipe atribuiu— e prestadora de serviços de pentest credenciada pela CREST desde 2025.

O que avaliamos e sob quais regras

O escopo é definido por alvo de avaliação. Os clientes registram repositórios, aplicações e infraestrutura em nuvem como alvos, e o pentest segue o que está registrado, não uma lista de ativos fixada meses antes. Os ambientes de pré-produção e de produção podem estar ambos no escopo.

As regras de engajamento fixam os limites. Nossos pentesters operam em safe mode por padrão, de modo que os ataques demonstram impacto sem interromper as operações do cliente, e isso muda apenas se o cliente pedir. Essas regras também definem o que conta como prova: um achado é reportado com os passos para reproduzi-lo, não com um rótulo de severidade isolado.

Como isso se parece na prática

Cada técnica manual reporta na mesma plataforma dos achados automatizados, então a remediação é rastreada em um só lugar.

▶️ Vídeo: explicamos como a Fluid Attacks combina IA, scanners e pentesters para testar software de forma contínua.

Resultados manuais e automatizados, medidos sobre o mesmo alvo

Nosso benchmark é a comparação mais clara que podemos publicar, porque as duas abordagens rodaram contra uma aplicação idêntica.

Números do benchmark da Fluid Attacks sobre 36 ferramentas AppSec de terceiros contra uma aplicação com 1.201 vulnerabilidades.

Sobre a mesma aplicação com 1.201 vulnerabilidades, o pentester alcançou 89,6 % de recall sem falsos positivos.

O limite desse número: 89,6 % não é 100 %

O resultado do pentester nesse alvo foi 1.076 de 1.201. O benchmark conta 73 do restante como falsos negativos, porque o pentester pulou deliberadamente seções que o scanner já havia coberto; a lacuna completa de 125 é o que separa o resultado da cobertura total. Qualquer um dos dois números é o argumento contra vender o pentest como cobertura completa.

Também é o argumento contra a afirmação oposta. Em 2025, as ferramentas automatizadas encontraram 88,4 % de todas as vulnerabilidades por contagem e carregaram 55,8 % da exposição ao risco total; os pentesters encontraram os 11,6 % restantes das vulnerabilidades e carregaram 44,2 % do risco. Nenhum método basta sozinho, e qualquer fornecedor que apresente um como substituto do outro está descrevendo um produto, não um resultado.

Toda correção é testada de novo

Encontrar uma vulnerabilidade é metade do trabalho. A documentação da Fluid Attacks é explícita: "you should reassess the code after a fix attempt", porque uma mudança pode não fechar o problema original ou introduzir um novo. Os clientes solicitam reattacks pela plataforma, automatizados ou manuais, e quando o achado foi reportado pela equipe de pentest, é um pentester quem confirma se ele foi realmente fechado. Sem esse passo, um programa de pentest mede quantos achados foram marcados como resolvidos, não quantos de fato estão.

Quanto acesso e conhecimento os pentesters recebem?

Antes de o pentest começar, duas variáveis independentes são acordadas: quanta informação quem testa recebe sobre o alvo, e quanto a própria equipe da organização sabe sobre o exercício. Nenhuma delas é um tipo de pentest, embora ambas sejam frequentemente descritas assim.

• Os testes opacos ou de black box não entregam ao pentester código-fonte nem documentação interna, então a abordagem imita a de um atacante externo. O black box testing leva mais tempo e costuma revelar menos problemas, porque o tempo vai para descobrir o que o sistema é antes de sondar como ele falha.

• Os testes semiopacos ou de gray box compartilham algum detalhe interno com a equipe de pentest —notas de arquitetura, credenciais de teste, uma especificação de API— e retêm o código-fonte. É o meio-termo prático para uma superfície autenticada.

• Os testes transparentes ou de white box compartilham o código-fonte e o contexto de apoio. O white box testing produz os melhores resultados, porque o analista pode revisar o código e atacar o sistema em execução ao mesmo tempo, e pode confirmar na fonte se uma fraqueza é realmente alcançável.

Do lado do conhecimento, nos testes direcionados as duas partes compartilham cada movimento, então as defesas podem ser ajustadas e reverificadas durante o exercício.

• Os testes às cegas entregam a quem testa apenas o nome da empresa.

• Os testes às cegas duplas mantêm parte da equipe de segurança sem saber que um exercício foi contratado: é a configuração que recomendamos para operações de red teaming, porque mede tanto a detecção quanto a exposição.

Fases do pentest

Não existe uma sequência universal única, mas as metodologias reconhecidas convergem. O NIST SP 800-115 (2008) agrupa o pentest em quatro fases: planejamento, descoberta, ataque e relatório, com um ciclo de retroalimentação que vai do ataque de volta à descoberta, porque uma exploração bem-sucedida revela nova superfície a examinar. O Penetration Testing Execution Standard expande o mesmo trabalho para sete fases e acrescenta a modelagem de ameaças e a pós-exploração como passos explícitos. Escolher uma delas não é opcional sob o PCI DSS: o requisito 11.4.1 obriga a entidade a documentar uma metodologia de pentest construída sobre abordagens aceitas pelo setor.

O NIST SP 800-115 modela o teste de penetração como quatro fases, com a fase de ataque retroalimentando a descoberta. Fonte: NIST SP 800-115 (2008).

Planejamento e reconhecimento

A organização e quem testa acordam o escopo, os padrões aplicáveis e qual informação será compartilhada. Esses termos formam as regras de engajamento. A modelagem de ameaças entra aqui: decidir quais ativos um atacante iria querer e quais caminhos valem o tempo disponível.

Segue o reconhecimento. O reconhecimento passivo reúne inteligência de fontes públicas sem tocar no alvo; o reconhecimento ativo interage com ele para identificar tecnologias e pontos de entrada.

Descoberta: varredura e avaliação de vulnerabilidades

O pentester mapeia a superfície de ataque com ferramentas —scanners de portas para serviços expostos, Static Application Security Testing quando o código-fonte está no escopo, Dynamic Application Security Testing (DAST) contra o sistema em execução— e depois trabalha o que a automação não consegue interpretar: lógica de negócio, limites de autorização e combinações de fraquezas inofensivas isoladamente.

Esta é a fase em que o pentest e a varredura automatizada mais se sobrepõem, e em que seus resultados divergem. A varredura produz candidatos; o analista decide quais valem o ataque.

Obtenção de acesso por exploração

É aqui que o pentest se separa da varredura. Quem testa constrói ou adapta um exploit, confirma que a vulnerabilidade é alcançável e mede o que ela entrega: exposição de dados, escalada de privilégios, movimento lateral para sistemas adjacentes.

A injeção de SQL cega ilustra por que isso exige critério. O catálogo da Fluid Attacks a descreve como um ataque no qual "an attacker sends queries to the server that ask the database true or false questions": a aplicação não devolve nada útil, então o achado é confirmado por comportamento, não por saída.

Jonathan Armas, analista de segurança na Fluid Attacks, descreve essa decisão quando um filtro bloqueia o caminho habitual:

"A partir de uma palavra-chave ORDER BY, precisamos usar uma SQLi baseada em erro ou uma baseada em tempo".

Um scanner reporta um parâmetro suspeito; escolher qual variante prova a explorabilidade é decisão de quem testa.

Cada fraqueza liga o achado ao seu impacto, à sua remediação e aos requisitos de segurança que ele descumpre.

Pós-exploração e manutenção do acesso

Já dentro, o analista estabelece por quanto tempo um atacante real poderia permanecer e até onde poderia se mover. Isso pode envolver um backdoor, extração lenta de dados ou adulteração de registros, tudo simulado dentro do escopo acordado, para documentar a persistência e não para alcançá-la. A pós-exploração transforma uma vulnerabilidade confirmada em uma afirmação sobre o raio de impacto.

Análise e relatório

O relatório é a entrega do pentest. O Web Security Testing Guide da OWASP diz isso sem rodeios: "a good report helps your client understand your findings". Ele recomenda uma introdução que cubra escopo, limitações e cronograma; um resumo executivo não técnico; achados detalhados com classificações de risco, e artefatos de teste reproduzíveis.

Um relatório de pentest deve dizer ao proprietário o que foi avaliado, o que foi encontrado e como, o que cada achado expõe e o que fazer a respeito. As provas de conceito em vídeo tornam o impacto difícil de contestar, e um documento claro permite que a equipe de desenvolvimento comece a corrigir no mesmo dia em que ele chega.

Quais são os tipos de pentest?

Os tipos de pentest costumam ser classificados pelo que está sendo atacado. As categorias abaixo seguem o alvo de avaliação, que é a classificação que usamos porque corresponde a como as organizações definem o escopo de um projeto na prática.

Pentest em aplicações

As aplicações web e móveis são os alvos mais comuns. Além do OWASP Top 10, o teste de intrusão verifica requisitos de segurança que os scanners não conseguem avaliar; por exemplo, restringir o acesso aos processos críticos, que exige que as funções que executam processos críticos de negócio estejam disponíveis apenas para usuários autenticados com os privilégios correspondentes.

Isso é uma verificação de lógica, não uma correspondência de padrões. Quem testa, com uma conta de baixo privilégio, tenta invocar diretamente uma função administrativa, e o resultado é ou uma falha de autorização verificada ou um controle que resiste.

Pentest em redes

O pentest de rede externo —o teste de invasão clássico— sonda se o perímetro pode ser rompido, com técnicas como o password spraying e o credential stuffing. Os testes internos estabelecem qual dano é possível por dentro —ataques man-in-the-middle, falhas de segmentação, controles de acesso fracos— e costuma ser o mais revelador dos dois.

Pentest em IoT e hardware

Os dispositivos inteligentes são avaliados por suas restrições de acesso lógico, a proteção dos dados armazenados e transmitidos, a configuração padrão, o tratamento de credenciais e os mecanismos de atualização. Um dispositivo que sai de fábrica com uma senha padrão compartilhada e sem caminho de atualização assinada falha antes de qualquer análise de protocolos começar.

Pentest em pessoas

A engenharia social mira as pessoas, não os sistemas. O phishing é o vetor mais comum: quem testa se passa por uma parte confiável para que um funcionário divulgue informação ou execute algo que não deveria. Os resultados são reportados como lacunas de processo, nunca como falhas individuais.

Tipos de ferramentas de pentest

As ferramentas não substituem o analista, mas nenhum pentest roda sem elas. A documentação da Fluid Attacks coloca a relação de forma direta: "Expert security analysts leverage automation enabled by tools to maximize their security testing speed".

• Sniffers de rede: monitoram o tráfego para mapear quais dispositivos se comunicam, sobre quais protocolos e portas. Exemplo: Wireshark.

• Scanners de portas: identificam portas abertas e inferem os serviços e sistemas operacionais por trás delas. Exemplo: Nmap.

• Quebradores de senhas: recuperam credenciais por força bruta, decifração ou material em cache. O pentest os usa para medir a política de senhas na prática.

• Scanners de vulnerabilidades: rodam SAST, SCA, DAST e verificações de postura em nuvem para apontar problemas conhecidos com rapidez.

• Proxies web: interceptam e modificam o tráfego entre o navegador e o servidor para sondar o tratamento de requisições.

• Frameworks de ataque: montam e entregam payloads depois que uma fraqueza é confirmada.

A lista é um inventário de recursos, não uma metodologia. O escopo, a análise e a validação continuam com quem executa o pentest.

Com que frequência o pentest deve ser feito?

Com a frequência com que o sistema muda. O pentest pontual descreve um sistema no dia em que foi executado, e cada implantação posterior é superfície não testada.

O pentest contínuo trata dessa lacuna de três formas: o escopo se ajusta conforme novos ativos aparecem, em vez de ficar congelado nas regras de engajamento; o trabalho de definir escopo e alocar pessoas que um projeto pontual repete toda vez se reduz a ajustes ocasionais; e o suporte à remediação segue disponível além da janela curta que um projeto isolado oferece. A análise da Fluid Attacks sobre testes contínuos frente a pontuais desenvolve os prós e contras em detalhe.

Uma ressalva: o pentest contínuo não é uma obrigação universal. A cadência correta depende de quão rápido o sistema muda, quais dados ele trata e quais padrões se aplicam. Uma ferramenta interna estática e uma plataforma de pagamentos que implanta diariamente não precisam da mesma resposta, e um teste anual que satisfaz um auditor ainda pode deixar onze meses de mudanças sem exame.

Conclusões

O pentest merece seu lugar porque produz evidência em vez de alertas. Os dados sustentam isso: 87 % dos achados de severidade crítica nos sistemas de clientes da Fluid Attacks em 2025 vieram de pentesters, e sobre um alvo controlado um único analista encontrou 98,9 % da exposição ao risco contra 8,8 % do melhor scanner. Esse é o argumento a favor do pentest, enunciado com sua base.

O contrário também é verdade. Esse mesmo pentester deixou 125 de 1.201 vulnerabilidades sem reportar naquele alvo, e as ferramentas automatizadas cobriram uma amplitude que nenhum humano cobriria. O pentest é um instrumento de profundidade, e tratá-lo como cobertura total é ler mal o que os números dizem.

A pergunta útil não é qual método vence, e sim como um programa de pentest combina os dois, e se ele dá um achado por fechado apenas depois que alguém verificou a correção.

Perguntas frequentes

Qual é a diferença entre pentest e varredura de vulnerabilidades?

Um scanner detecta; um pentester explora. A varredura reporta padrões potencialmente vulneráveis sem confirmar que são alcançáveis, enquanto o pentest prova a explorabilidade dentro de um escopo acordado e mede o impacto. A varredura cobre mais superfície, mais rápido, com falsos positivos a triar.

O pentest pode ser automatizado?

Não. As ferramentas automatizam o reconhecimento, a varredura e parte da fase de ataque, mas o critério que define um pentest —escolher qual hipótese testar, encadear fraquezas, decidir quando o impacto está provado— é humano. Os produtos comercializados como teste automatizado estão fazendo varredura automatizada.

Com que frequência os padrões de segurança exigem pentest?

O piso comum é uma vez a cada 12 meses, mais um novo teste após qualquer mudança significativa. É isso que o PCI DSS v4.0.1 exige para os testes internos e externos; sua regra de seis meses se aplica aos controles de segmentação em prestadores de serviço, não ao teste completo. A FTC Safeguards Rule sob a GLBA exige um teste anual das instituições que não têm monitoramento contínuo efetivo.

O que deve conter um relatório de pentest?

Escopo e limitações, um resumo executivo não técnico, achados detalhados com classificações de risco e artefatos reproduzíveis. O Web Security Testing Guide da OWASP estabelece essa estrutura e acrescenta que o relatório deve servir tanto à direção quanto aos engenheiros que vão corrigir os problemas.

A Fluid Attacks faz pentest?

Sim. A Fluid Attacks o entrega de forma contínua por meio de PTaaS, combinado com IA, scanners próprios, revisão segura de código e engenharia reversa. Em seu benchmark contra 36 ferramentas AppSec de terceiros, um pentester da Fluid Attacks reportou 1.076 de 1.201 vulnerabilidades semeadas, sem falsos positivos.

Teste seus sistemas como um atacante faria

Nossos pentesters atacam suas aplicações, redes e infraestrutura em nuvem de forma contínua, e verificam cada correção antes de dar um achado por fechado. Teste gratuito · Fale conosco.