Pentest: o que é e como funciona um teste de invasão

O que é pentest e por que difere de um scan de vulnerabilidades

Pentest, ou teste de invasão (penetration test), é um exercício ofensivo autorizado em que profissionais de segurança simulam o comportamento de um atacante real para identificar, explorar e demonstrar o impacto de vulnerabilidades em sistemas, redes, aplicações web, APIs, apps mobile e ambientes cloud. O objetivo não é apenas listar falhas, mas provar que elas são exploráveis e medir o dano concreto que causariam: acesso a dados de clientes, movimentação financeira indevida, escalada de privilégio ou comprometimento total do ambiente.

A diferença essencial em relação a um scan de vulnerabilidades é a presença de inteligência humana e exploração ativa. Um scanner (Nessus, Qualys, OpenVAS, Burp Scanner) compara versões e assinaturas conhecidas contra uma base de CVEs e devolve uma lista de possíveis problemas — rápido, barato e cheio de falsos positivos, sem confirmar se a falha é realmente explorável no contexto. O pentest valida cada achado manualmente, encadeia falhas de baixa severidade em um ataque de alto impacto (chaining) e descobre vulnerabilidades de lógica de negócio que nenhum scanner detecta, como burlar limites de transferência, manipular fluxo de checkout ou abusar de regras de autorização.

Na prática, scan e pentest são complementares: o scan automatizado serve para cobertura contínua e higiene básica entre testes; o pentest é a avaliação profunda, manual e contextual. Para fintechs, exchanges de cripto e e-commerces que processam transações reais, o que importa é o segundo — porque o atacante que tenta drenar uma carteira ou fraudar um pagamento também usa raciocínio humano, não apenas ferramentas automáticas.

Tipos de pentest: black, grey e white box, e os alvos testados

Os pentests classificam-se primeiro pelo nível de informação fornecido ao testador. No black box, a equipe recebe apenas o alvo (um domínio ou um IP) e atua como um atacante externo sem conhecimento interno — realista, porém mais demorado e com risco de não cobrir áreas profundas no tempo contratado. No grey box, o testador recebe credenciais de usuário comum e documentação parcial, simulando um cliente, parceiro ou insider de baixo privilégio; é o melhor custo-benefício para aplicações, pois maximiza cobertura por hora. No white box (ou crystal box), há acesso total a código-fonte, arquitetura e credenciais administrativas, permitindo a análise mais exaustiva possível, indicada para sistemas críticos e revisões de segurança aprofundadas.

Em paralelo, o pentest é classificado pelo tipo de alvo. Pentest de aplicação web foca em falhas como injeção, autenticação quebrada, controle de acesso e lógica de negócio. Pentest de API (REST, GraphQL, gRPC) testa autorização objeto a objeto (BOLA/IDOR), autenticação, rate limiting e exposição de dados — vetor crítico em fintechs e apps mobile. Pentest mobile (Android e iOS) analisa o app cliente, armazenamento local, comunicação, certificate pinning e a API de backend. Pentest de cloud avalia configurações de AWS, Azure e GCP: IAM, buckets, security groups, secrets e caminhos de escalada de privilégio. Pentest de rede externa simula o atacante na internet contra o perímetro; o de rede interna assume que o invasor já está dentro (phishing bem-sucedido, dispositivo comprometido) e testa movimentação lateral.

O Red Team é uma categoria à parte: em vez de cobrir o máximo de superfície, persegue um objetivo específico (por exemplo, acessar a base de clientes ou a carteira de custódia) simulando um adversário avançado e persistente, sem aviso prévio ao time de defesa (Blue Team), combinando exploração técnica, engenharia social e, às vezes, intrusão física. Mede não só a existência de falhas, mas a capacidade real de detecção e resposta da organização. A Decripte conduz tanto pentests manuais de web, API, mobile e cloud quanto exercícios de Red Team direcionados a fintechs, empresas de cripto e aplicativos.

Metodologias e frameworks de referência

Um pentest profissional segue metodologias reconhecidas, o que garante reprodutibilidade, cobertura e comparabilidade entre testes. Para aplicações web, a referência é o OWASP Web Security Testing Guide (WSTG) — versão estável 4.2, com a 5.0 em desenvolvimento —, que detalha centenas de testes por categoria (autenticação, autorização, gestão de sessão, validação de entrada, lógica de negócio, incluindo injeção em GraphQL). Para mobile, o OWASP MASTG (Mobile Application Security Testing Guide), alinhado ao padrão de verificação MASVS, cobre testes técnicos para Android e iOS. A taxonomia OWASP Top 10 e a OWASP API Security Top 10 orientam priorização, mas não substituem o WSTG/MASTG como guia de execução.

Para o processo de engajamento de ponta a ponta, o PTES (Penetration Testing Execution Standard) define sete fases — pré-engajamento, coleta de informações, modelagem de ameaças, análise de vulnerabilidades, exploração, pós-exploração e relatório. O NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment) é o padrão formal, orientado a conformidade, com fases de planejamento, descoberta, ataque e relatório. O OSSTMM (Open Source Security Testing Methodology Manual) traz uma visão operacional mais ampla, incluindo segurança física, humana, wireless e de telecomunicações.

Para descrever táticas e técnicas de adversários — especialmente em Red Team e pós-exploração — usa-se o MITRE ATT&CK, uma matriz que cataloga o comportamento real de atacantes (reconhecimento, acesso inicial, execução, persistência, escalada, movimentação lateral, exfiltração). Mapear achados contra o ATT&CK permite que o cliente conecte cada vulnerabilidade às técnicas que ela habilita e avalie suas defesas de detecção. Um bom fornecedor combina essas referências: WSTG/MASTG para profundidade técnica por alvo, PTES ou NIST para estrutura do engajamento e ATT&CK para contextualizar o adversário.

As fases de um teste de invasão

Reconhecimento (recon): coleta de informações sobre o alvo. Inclui OSINT (subdomínios, e-mails vazados, repositórios públicos, metadados, infraestrutura exposta), footprinting de DNS e descoberta da superfície de ataque. Em black box, esta fase mapeia tudo que um atacante veria da internet sem credenciais.

Enumeração: a partir da superfície identificada, mapeiam-se serviços, portas, tecnologias, versões, endpoints de API, parâmetros, papéis de usuário e fluxos da aplicação. É aqui que o testador entende a lógica de negócio e levanta hipóteses de ataque — o passo que separa o pentest manual de um scan, que não constrói esse modelo mental.

Exploração: tentativa ativa e controlada de explorar as vulnerabilidades identificadas — injeção, falhas de autorização (IDOR/BOLA), bypass de autenticação, SSRF, desserialização, falhas de lógica de negócio. O objetivo é confirmar a falha com prova concreta, não apenas suspeitá-la, sempre dentro do escopo e das regras de engajamento acordadas para não causar dano nem indisponibilidade.

Pós-exploração: com um ponto de apoio inicial, o testador mede o impacto real — escalada de privilégio, acesso a dados sensíveis, movimentação lateral, persistência e alcance até ativos críticos (base de clientes, ambiente de pagamentos, carteira de custódia). Esta fase responde à pergunta que mais importa ao negócio: até onde um atacante chegaria.

Relatório: documentação de cada vulnerabilidade com evidências, classificação de risco (CVSS v4.0), prova de conceito (PoC) reproduzível e recomendações de correção priorizadas. Inclui sumário executivo para liderança e detalhamento técnico para os times de engenharia.

Reteste: após o cliente corrigir, valida-se que cada correção é efetiva e não introduziu regressões ou novas falhas. O reteste fecha o ciclo e costuma ser exigido por auditores e reguladores como evidência de remediação. A Decripte mantém SLA de contenção de incidente crítico em até 1 hora caso o teste revele uma exposição já em exploração ativa.

O entregável: o que esperar do relatório e como avaliar um fornecedor

O produto final de um pentest é o relatório, e sua qualidade define o valor do serviço. Um bom relatório tem duas camadas. O relatório executivo, destinado à liderança e a auditores, resume a postura de segurança, o risco de negócio, os principais achados e a recomendação geral em linguagem acessível, sem jargão. O relatório técnico, para os times de engenharia, descreve cada vulnerabilidade individualmente: descrição, localização exata (endpoint, parâmetro, requisição), severidade calculada por CVSS v4.0 (com o vetor explícito, não apenas a nota), prova de conceito reproduzível passo a passo, evidências (requisições, respostas, capturas) e recomendação de correção específica e acionável — não conselhos genéricos.

Para avaliar um fornecedor, observe sinais concretos. Predominância de teste manual sobre saída de scanner: peça um relatório de exemplo e verifique se há achados de lógica de negócio, encadeamento de falhas e PoCs reais, ou apenas itens que qualquer scanner geraria. Aderência a metodologias (WSTG, MASTG, PTES, NIST) declarada e demonstrável. Mapeamento contra MITRE ATT&CK em engajamentos de Red Team. Certificações da equipe (OSCP, OSWE, OSEP, CRTO, GPEN, GXPN) como indício de competência ofensiva real. Regras de engajamento, NDA e seguro claros. Oferta de reteste incluído. Comunicação imediata de falhas críticas durante o teste, em vez de só ao final.

Desconfie de fornecedores que entregam apenas o export de um scanner renomeado como pentest, que não conseguem mostrar um exemplo anonimizado de relatório, que não distinguem severidade técnica de risco de negócio, ou que não oferecem reteste. O preço mais baixo quase sempre corresponde a um teste automatizado com verniz de pentest — o que não protege contra um atacante humano motivado.

Quando e com que frequência fazer pentest

A regra prática consolidada é: pelo menos uma vez por ano e sempre após mudanças significativas — nova aplicação, refatoração relevante de arquitetura, migração de infraestrutura, nova integração crítica ou novo fluxo de pagamento. Mudança significativa, não calendário, é o gatilho mais importante, porque é exatamente quando novas falhas são introduzidas.

Drivers regulatórios e contratuais elevam essa frequência. No PCI-DSS 4.0, o requisito 11.4 exige pentest interno e externo do ambiente de dados de cartão (CDE) ao menos anualmente e após mudanças significativas; controles de segmentação devem ser testados anualmente — e a cada seis meses para prestadores de serviço. No Brasil, a política de segurança cibernética do Banco Central, atualizada pela Resolução BCB 538/2025 e pela Resolução CMN 5.274/2025 (com prazo de adequação até 1º de março de 2026 para instituições já em operação), reforça a exigência de testes de invasão periódicos, conduzidos com independência por equipe especializada, com documentação dos achados e do plano de ação mantida à disposição do regulador. A LGPD, embora não cite pentest nominalmente, exige medidas técnicas adequadas de segurança (art. 46), e o pentest é a evidência objetiva de que essas medidas foram verificadas.

Há ainda o gatilho de due diligence: rodadas de investimento, M&A e onboarding de grandes clientes corporativos frequentemente exigem um pentest recente como condição. Para produtos com mudança contínua, o pertinente é adotar um ciclo recorrente — pentest abrangente anual ou semestral, complementado por testes pontuais a cada release crítico e por scanning contínuo entre eles. A Decripte estrutura esse programa para fintechs, empresas de cripto e apps, alinhando a cadência aos requisitos de BACEN, PCI-DSS, LGPD e às demandas de investidores.

Passo a passo

1. Defina o escopo e os objetivos: liste os alvos (aplicações, APIs, apps, contas cloud, redes), o tipo de teste (black, grey ou white box) e o que se quer descobrir, considerando exigências de BACEN, PCI-DSS, LGPD ou due diligence.
2. Selecione o fornecedor com critério: peça um relatório de exemplo anonimizado, verifique predominância de teste manual, aderência a WSTG/MASTG/PTES/NIST, certificações da equipe (OSCP, OSWE, OSEP, CRTO) e se o reteste está incluído.
3. Formalize o engajamento: assine NDA, autorização formal e regras de engajamento (janelas de teste, ambientes permitidos, ações proibidas, contatos de emergência e canal de comunicação imediata para achados críticos).
4. Conduza o teste seguindo as fases: reconhecimento, enumeração, exploração, pós-exploração — sempre dentro do escopo e sem causar indisponibilidade não autorizada.
5. Receba e analise o relatório: confira sumário executivo, detalhamento técnico com CVSS v4.0, PoC reproduzível e recomendações; priorize a remediação por risco de negócio, não apenas por nota técnica.
6. Corrija as vulnerabilidades e documente o plano de ação, mantendo a evidência à disposição de auditores e do regulador quando aplicável.
7. Solicite o reteste para validar que cada correção foi efetiva e não introduziu regressões, fechando o ciclo, e agende a próxima rodada conforme a cadência definida.

Perguntas frequentes