Metodologia PentestAI

Última atualização: 23 de abril de 2026

O PentestAI é um teste de intrusão ofensivo entregue em até dez dias corridos. Mecanismos de IA generativa executam o trabalho exaustivo (reconhecimento, varredura, fuzzing e correlação de vulnerabilidades), enquanto os analistas da WiserSecurity validam cada achado crítico, testam lógica de negócio sensível, redigem o relatório final e assinam o atestado. Essa arquitetura híbrida, IA combinada com analista humano, é o que permite entregar um pentest completo por R$5.000 sem abrir mão da qualidade nos pontos que importam.

Esta página documenta os frameworks e processos que sustentam essa metodologia. O OWASP Top 10 e o OWASP API Security Top 10 servem como mapas de superfície de ataque. O PTES dá o esqueleto de fases. A NIST SP 800-115 é o guia fundacional. No fim, descrevemos o workflow específico do PentestAI, incluindo as limitações do formato. O objetivo é que qualquer engenheiro de segurança, CTO ou responsável por compliance avalie com clareza o que está sendo contratado, o que está incluído e o que fica de fora.

O que é pentest (e o que não é)

Um penetration test (pentest, ou teste de intrusão) é uma avaliação de segurança em que profissionais autorizados simulam ataques reais contra um sistema, aplicação ou infraestrutura — com o objetivo de descobrir, explorar e demonstrar o impacto de vulnerabilidades antes que um atacante real o faça. Um pentest envolve obrigatoriamente exploração: não basta identificar uma falha, é preciso validar que ela é explorável no contexto daquele alvo, e medir até onde o acesso pode ser escalado.

Por essa razão, pentest não é a mesma coisa que vulnerability scan. Uma varredura automatizada lista potenciais falhas detectadas por assinaturas, heurísticas ou checagens de versão; um pentest confirma quais dessas falhas são de fato exploráveis, descarta falsos positivos e descobre vulnerabilidades que nenhuma ferramenta automatizada encontraria sozinha — como falhas de lógica de negócio, abusos de fluxos legítimos ou cadeias de exploração (exploit chains) que combinam múltiplas fraquezas de baixa severidade em um impacto crítico.

Pentest também não é auditoria de código-fonte (SAST/revisão manual), não é análise de configuração (benchmark CIS, revisão de IAM) e não é bug bounty. Cada um desses formatos tem um propósito diferente: auditoria de código examina o fonte linha a linha em busca de padrões inseguros; revisão de configuração valida hardening contra baseline; bug bounty é um programa contínuo em que pesquisadores independentes reportam falhas por recompensa. O pentest, por sua vez, é uma janela temporal de ataque controlado, com escopo definido, equipe identificada, cronograma fechado e entregável formal (relatório + atestado).

Pentest vs Vulnerability Scan vs Pentest tradicional

A confusão entre esses três formatos é uma das principais fontes de frustração de compradores de segurança. Vale distinguir com cuidado.

Um vulnerability scan é uma varredura automatizada executada por ferramentas como Nessus, Qualys, OpenVAS, Nuclei ou similares. Ele é barato (algumas centenas de reais por execução), rápido (horas), repetível e útil para manter higiene contínua — detectar serviços desatualizados, portas abertas inesperadas, certificados vencidos, versões com CVEs conhecidos. Porém, uma varredura não valida exploitabilidade: ela reporta "CVE-2023-XXXXX detectado na porta 443" sem saber se o patch já foi aplicado em um fork interno, se o caminho vulnerável é alcançável ou se há WAF no meio. O resultado típico de um scan são centenas de itens, dos quais apenas uma fração pequena é real.

Um pentest tradicional (o formato clássico, que a própria WiserSecurity também oferece para escopos maiores) é conduzido de ponta a ponta por analistas seniores ao longo de três a seis semanas. Ele inclui profundidade manual — análise detalhada de lógica de negócio, engenharia reversa de protocolos proprietários, construção de exploits sob medida, cenários de ataque multi-etapa — e entrega um relatório extenso com contexto estratégico. É o formato indicado para aplicações críticas, compliance exigente (PCI-DSS nível 1, auditorias SOC 2 Type II) ou ambientes com alta complexidade. O custo correspondente fica tipicamente entre R$30.000 e R$150.000.

O PentestAI fica no meio, como um formato próprio. É um pentest genuíno — com exploração, validação por nossos analistas e atestado assinado — executado em dez dias corridos por R$5.000. A receita que viabiliza esse preço e prazo é o uso intensivo de IA generativa para as tarefas mecânicas (enumeração, fuzzing, correlação, triagem, redação de seções descritivas do relatório) combinado com a atenção dos nossos analistas concentrada nos pontos que de fato exigem julgamento: validação de exploitabilidade, teste de lógica de negócio sensível, revisão final e assinatura do atestado. Não é substituto do pentest tradicional — é um formato diferente, otimizado para aplicações web/API de porte médio, ciclos ágeis de produto e empresas que precisam de um insumo de segurança formal sem esperar seis semanas.

OWASP Top 10 (aplicações Web)

O OWASP Top 10 é o documento de referência global sobre as categorias mais críticas de vulnerabilidades em aplicações web. Mantido pela Open Worldwide Application Security Project, é atualizado periodicamente com base em dados reais da indústria. A versão atual utilizada como baseline do PentestAI contempla:

A01 — Broken Access Control: falhas de controle de acesso em que usuários conseguem acessar recursos, funções ou dados fora de sua autorização legítima. Inclui IDOR, bypass de verificação de função, forced browsing e elevação de privilégio horizontal/vertical.
A02 — Cryptographic Failures: uso incorreto ou ausente de criptografia — transporte sem TLS, armazenamento em texto claro, algoritmos obsoletos, chaves fracas, geração de números pseudo-aleatórios insegura. Frequentemente resulta em exposição de dados sensíveis.
A03 — Injection: injeção de comandos quando entradas não confiáveis são interpretadas como código ou consultas. Abrange SQL Injection, NoSQL, OS Command, LDAP, XPath e template injection em frameworks server-side.
A04 — Insecure Design: falhas estruturais de design e arquitetura que não podem ser corrigidas por implementação cuidadosa — ausência de threat modeling, padrões de segurança insuficientes, fluxos que permitem abuso por construção.
A05 — Security Misconfiguration: configurações padrão perigosas, cabeçalhos de segurança ausentes, mensagens de erro verbosas, serviços desnecessários expostos, permissões frouxas em cloud storage, headers de CORS permissivos.
A06 — Vulnerable and Outdated Components: uso de bibliotecas, frameworks ou componentes com vulnerabilidades conhecidas e não corrigidas. Inclui dependências transitivas, base images desatualizadas e plugins de terceiros abandonados.
A07 — Identification and Authentication Failures: falhas em autenticação e gestão de sessão — credenciais padrão, brute force não mitigado, recuperação de senha insegura, tokens com entropia baixa, sessão sem invalidação após logout.
A08 — Software and Data Integrity Failures: ausência de verificação de integridade em atualizações, CI/CD comprometido, desserialização insegura e dependência de fontes não confiáveis sem validação de assinatura.
A09 — Security Logging and Monitoring Failures: logs insuficientes, ausência de alertas em eventos suspeitos, retenção inadequada. Impede detecção e resposta efetiva a incidentes em andamento.
A10 — Server-Side Request Forgery (SSRF): o servidor é induzido a fazer requisições HTTP a destinos escolhidos pelo atacante, permitindo acesso a serviços internos, metadata de cloud provider e pivoting para infraestrutura privada.

OWASP API Security Top 10

APIs têm superfície de ataque distinta de aplicações web tradicionais: clientes frequentemente confiáveis (mobile, SPA), autenticação via tokens, controles espalhados entre endpoints, ausência de UI que visualize o que está exposto. Por isso existe o OWASP API Security Top 10, complementar ao Top 10 web:

API1 — Broken Object Level Authorization (BOLA): endpoints que aceitam identificadores de objeto sem validar se o usuário autenticado pode acessar aquele objeto específico. A vulnerabilidade mais comum e mais crítica em APIs.
API2 — Broken Authentication: falhas no fluxo de autenticação — JWTs com algoritmo none, refresh tokens eternos, endpoints de login sem rate limit, ausência de MFA em contas administrativas.
API3 — Broken Object Property Level Authorization (BOPLA): autorização é verificada no objeto, mas não nas propriedades — permitindo mass assignment (atribuir campos não autorizados no update) ou excessive data exposure (a resposta retorna mais campos do que o cliente deveria ver).
API4 — Unrestricted Resource Consumption: endpoints sem throttling, paginação opcional, limites de tamanho de payload ausentes. Permite DoS com baixo custo e abuso financeiro em APIs cobradas por uso.
API5 — Broken Function Level Authorization: controles de acesso por função são inconsistentes entre endpoints. Atacante descobre endpoints administrativos escondidos e consegue acessá-los com conta comum.
API6 — Unrestricted Access to Sensitive Business Flows: fluxos de negócio expostos sem proteção contra automação abusiva — compra em massa, criação de contas, envio de convites, scraping de inventário.
API7 — Server-Side Request Forgery: mesma classe do A10 web, mas particularmente frequente em APIs que consomem URLs fornecidas pelo cliente (webhooks, importadores, validadores de link).
API8 — Security Misconfiguration: cabeçalhos de segurança ausentes, CORS excessivamente permissivo, versões antigas do gateway de API, erros verbosos expondo stack trace e detalhes internos.
API9 — Improper Inventory Management: APIs em staging, versões antigas (v1 ainda rodando quando v3 é a atual), endpoints não documentados, integrações legadas esquecidas — todas representam superfície invisível para o defensor e visível para o atacante.
API10 — Unsafe Consumption of APIs: a aplicação consome APIs de terceiros e confia cegamente nas respostas, permitindo que uma API externa comprometida induza vulnerabilidade na aplicação consumidora.

PTES — Penetration Testing Execution Standard

O PTES define o esqueleto de execução de um pentest em sete fases sequenciais. O PentestAI respeita essa estrutura, ajustando a profundidade e a distribuição de esforço entre IA e analista em cada fase:

1. Pre-engagement Interactions

Definição formal de escopo, janela de execução, regras de engajamento, autorizações legais, canais de comunicação e critérios de sucesso. É a fase em que se documenta por escrito o que está dentro e fora do alvo, que tipos de teste estão autorizados (ex.: pode executar fuzzing em endpoint de pagamento?) e quem é notificado em caso de achado crítico em tempo real.

2. Intelligence Gathering

Reconhecimento passivo e ativo do alvo — enumeração de subdomínios, descoberta de endpoints, identificação de tecnologias, mapeamento de usuários, coleta de metadados públicos. O objetivo é montar uma visão completa da superfície de ataque antes de qualquer tentativa de exploração. Essa é uma das fases em que a IA mais acelera o trabalho, correlacionando fontes abertas em minutos.

3. Threat Modeling

Com a superfície mapeada, modelam-se os cenários de ataque mais prováveis e mais impactantes para aquele alvo específico — quem são os adversários relevantes, quais ativos são de maior valor, que fluxos de abuso fazem sentido. Essa fase orienta a priorização das fases seguintes: não se testa tudo com a mesma profundidade, testa-se com profundidade aquilo que importa.

4. Vulnerability Analysis

Identificação sistemática de vulnerabilidades potenciais no escopo — varreduras automatizadas, análise manual de respostas, fuzzing de parâmetros, inspeção de código cliente (JS, binários mobile quando aplicável), análise de headers, checagem de configurações. Ao fim dessa fase existe uma lista bruta de hipóteses de vulnerabilidade a serem validadas.

5. Exploitation

Validação ativa das hipóteses — tentativa real de explorar cada vulnerabilidade candidata para confirmar exploitabilidade, descartar falsos positivos e medir impacto. É aqui que se constroem provas de conceito, se executam injections reais (em ambiente autorizado), se bypassa controles. No PentestAI, toda exploração de alto impacto passa por validação dos nossos analistas antes de ser marcada como confirmada.

6. Post Exploitation

Uma vez obtido acesso inicial, avalia-se até onde esse acesso pode ser escalado — movimentação lateral, elevação de privilégio, acesso a dados sensíveis, persistência. O objetivo não é permanecer no alvo, mas demonstrar o impacto real de cada cadeia de exploração (exploit chain) para o relatório final.

7. Reporting

Consolidação dos achados em entregáveis — relatório técnico com descrição detalhada, evidências, passos de reprodução e remediação recomendada; sumário executivo para gestão; atestado formal de pentest. É a fase em que o trabalho ganha forma comunicável. No PentestAI, a IA auxilia na redação de seções descritivas (descrições de CWE, explicações de classe de vulnerabilidade, texto de contexto) e o analista WiserSecurity escreve, revisa e assina as conclusões.

NIST SP 800-115 — posicionamento e complementaridade

A NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment é uma publicação do National Institute of Standards and Technology dos Estados Unidos, amplamente reconhecida como guia fundacional para avaliações técnicas de segurança. Ela não é um checklist de vulnerabilidades como o OWASP Top 10, nem uma sequência de execução como o PTES — é um documento de princípios e técnicas que descreve como planejar, conduzir e documentar avaliações de segurança de forma rigorosa e repetível.

A SP 800-115 organiza as técnicas em três grandes categorias: review techniques (revisão de documentação, código, logs e configurações), target identification and analysis (descoberta de rede, identificação de serviços, análise de vulnerabilidades) e target vulnerability validation (validação via exploração, incluindo pentest, password cracking e social engineering). Esse vocabulário é o que aparece em requisitos formais de compliance — quando um contrato ou norma pede "avaliação conforme NIST SP 800-115", está pedindo que a metodologia empregada respeite esses princípios de planejamento, execução controlada e documentação.

No PentestAI, a SP 800-115 funciona como camada fundacional: as fases do PTES e as categorias do OWASP operam dentro dos princípios que a SP 800-115 estabelece — escopo formalmente documentado, coleta e preservação de evidências, comunicação estruturada com o stakeholder, análise de impacto e plano de remediação. Dessa forma, o entregável final do PentestAI pode ser referenciado em contextos de compliance que exigem aderência a SP 800-115, sem prejuízo da especificidade técnica trazida pelo OWASP e pela disciplina de execução do PTES.

Workflow interno PentestAI — IA + humano na prática

Abaixo, o fluxo de dez dias corridos com a distribuição explícita de esforço entre os mecanismos de IA generativa e os analistas da WiserSecurity:

Dia 1–2 — Validação de escopo (analista)

O analista WiserSecurity revisa o escopo submetido, valida as informações fornecidas (domínios, ranges, credenciais de teste, documentação de API), confirma janelas autorizadas e regras de engajamento, e assina o documento de autorização. Sem essa validação prévia, o teste não começa. É também nessa fase que se definem os critérios de notificação imediata para achados críticos descobertos durante a execução.

Dia 3–8 — Execução híbrida (IA + analistas em paralelo)

Os mecanismos de IA executam o grosso do trabalho mecânico: reconnaissance ativo e passivo, varreduras de porta e serviço, fuzzing de parâmetros, correlação de CVEs contra o inventário identificado, teste sistemático das categorias OWASP Top 10 e OWASP API, geração de hipóteses de exploit chain a partir dos achados individuais. Em paralelo, nossos analistas acompanham em tempo real um painel de achados triados por severidade e, para cada item crítico ou de alto impacto, executam validação manual: reproduzem o ataque, ajustam parâmetros, confirmam exploitabilidade real no contexto do alvo. Descobertas de lógica de negócio sensível (fluxos de pagamento, autorização entre tenants, manipulação de saldo, escalonamento de permissão) são testadas exclusivamente pelo analista responsável.

Dia 9–10 — Relatório, sumário executivo e atestado (analista)

O analista consolida todos os achados, escreve o relatório técnico (descrição, evidências, impacto, remediação por item), redige o sumário executivo — calibrado para gestão e conselho — e emite o atestado formal de pentest assinado pelo analista responsável. A IA pode auxiliar na redação de trechos descritivos padronizados (explicação de uma classe de CWE, contexto histórico de uma vulnerabilidade), mas a narrativa, as conclusões e o julgamento de criticidade ficam com nossos analistas. O atestado é assinado pelo analista WiserSecurity responsável e carrega a identidade da empresa emissora.

Pós-entrega — Reteste em até 30 dias

Após a entrega, o cliente tem uma janela de 30 dias corridos para solicitar um reteste, já incluído no preço. O reteste valida a remediação dos achados reportados, gera um relatório de diferenças e, se todos os achados críticos e altos foram devidamente tratados, um atestado de reteste pode ser emitido. O reteste é executado pelo mesmo analista responsável pela execução original, preservando continuidade de contexto.

Limitações honestas do formato

Clareza sobre o que o PentestAI não cobre é parte integrante da metodologia — contratar um formato de dez dias por R$5.000 na expectativa de um engajamento de red team é receita para frustração bilateral. As limitações abaixo são intrínsecas à proposta de valor, não deficiências a serem corrigidas:

Análise manual profunda de lógica de negócio complexa: aplicações com centenas de fluxos, regras de precificação intrincadas, workflows multi-etapa com estados ocultos — exigem semanas de imersão de analistas seniores. O PentestAI cobre os fluxos principais identificados no escopo, não a totalidade exaustiva.
Red team de múltiplas semanas: operações adversariais de longa duração com objetivos específicos (exfiltrar base X, obter acesso a sistema Y via cadeia social + técnica), incluindo evasão de blue team, não são compatíveis com a janela de dez dias.
Pesquisa de zero-days novos: o PentestAI explora vulnerabilidades conhecidas e combinações exploráveis dessas; pesquisa original que resulta em CVE novo é atividade de semanas-meses, tipicamente em laboratório dedicado.
Engenharia social aprofundada: phishing direcionado, pretexting por telefone, vishing, tailgating físico e campanhas extensas de awareness-testing exigem escopo e autorizações próprias, além de janela mais longa.
Campanhas estendidas de phishing: a operação típica de phishing simulado envolve planejamento de pretexto, infraestrutura dedicada, envio escalonado, coleta de métricas e relatório comportamental — trabalho separado do pentest técnico.
Engenharia reversa completa de binários mobile em iOS: análise profunda de binários iOS (desofuscação, reversão de esquemas criptográficos proprietários, bypass de jailbreak detection avançado) demanda ferramental e tempo superiores à janela do formato. O PentestAI cobre a superfície exposta pela aplicação e o backend de API, não a reversão completa do app.
Auditorias de compliance enterprise complexas: PCI-DSS nível 1 de ponta a ponta, ISO 27001 com levantamento de controles, SOC 2 Type II com período de evidência — compromissos de compliance que exigem auditoria formal independente continuam sendo responsabilidade de engajamentos dedicados da WiserSecurity ou do auditor de certificação.

Para os cenários acima, o caminho recomendado é o pentest tradicional da WiserSecurity, dimensionado sob medida. O PentestAI é a escolha correta quando o objetivo é obter um pentest genuíno, com atestado formal, em escopo bem definido (aplicação web, API REST/GraphQL, infraestrutura pública de porte médio), dentro de ciclos curtos de entrega de produto e com orçamento previsível.