PENTEST
Um especialista tenta invadir, e o relatório prova até onde deu para chegar
Pentest, ou teste de intrusão, é um ataque autorizado e combinado contra os seus sistemas, conduzido por quem faz isso profissionalmente. Ele não devolve uma lista de falhas possíveis: devolve a demonstração do que um invasor conseguiria fazer de fato, com o caminho percorrido, a evidência de cada passo e o que resistiu. É a diferença entre saber que a porta pode estar destrancada e ver alguém entrar por ela.
Nenhum teste começa sem autorização formal, escopo escrito e regras de engajamento assinadas. Isso não é formalidade: é o que separa um teste de intrusão de um acesso não autorizado, e é o que protege os dois lados quando algo sai do previsto. A DM11 conduz o trabalho com as fases do PTES declaradas em contrato, cobertura de aplicação pelo OWASP e o caminho descrito na linguagem do MITRE ATT&CK.
Quem conduz o teste
CEH, hacker ético certificado pelo EC-Council
CPTE, engenharia de teste de intrusão pela AcadiTI
SYCP e SYWP, pentest e pentest de aplicação web pela Solyd
17 anos de governança, riscos e conformidades
O QUE É
Ataque autorizado, com método declarado e prova no fim
Um pentest é conduzido por uma pessoa, com ferramentas ajudando, e não por uma ferramenta com uma pessoa olhando. Essa ordem explica quase tudo o que vem depois: o preço, o prazo, o que o relatório consegue afirmar e por que duas propostas com o mesmo nome entregam trabalhos incomparáveis. O que se compra é a perícia de quem encadeia falhas pequenas até chegar a algo que importa, e não a quantidade de itens encontrados.
Não é varredura, e a diferença aparece no relatório
Uma varredura de vulnerabilidades encontra e lista falhas conhecidas, de forma ampla e automática, e é trabalho de rotina que deve acontecer o ano inteiro. Um pentest confirma o que dá para explorar de verdade e mede até onde daria para chegar depois da primeira porta. Se o relatório que você recebeu tem dezenas de páginas de achados classificados por cor e nenhuma frase sobre o que alguém conseguiu fazer com eles, você comprou pentest e recebeu varredura com outro nome. As duas coisas se completam, e a comparação inteira está na página de pentest e análise de vulnerabilidade.
A autorização é requisito, e não burocracia
Sem autorização formal do responsável pelo ativo, o mesmo conjunto de ações é acesso não autorizado. Por isso o trabalho começa por um documento que define o que está dentro do escopo, o que está fora, quem autoriza, em qual janela, com qual critério de parada e quem é acionado se algo sair do previsto. Quando há terceiros no caminho, provedor de nuvem, provedor de acesso ou empresa que opera a sua segurança, o tratamento de cada um fica escrito antes do primeiro pacote.
O método é declarado antes, e é o que torna propostas comparáveis
A DM11 usa o PTES para a estrutura de execução, das interações prévias ao relatório, o OWASP para a cobertura de aplicação, com o Top 10 e o ASVS, e o MITRE ATT&CK para nomear o caminho percorrido. Os três resolvem coisas diferentes e nenhum substitui o outro. Um efeito prático disso é que o seu time de infraestrutura consegue conferir depois se a detecção enxergaria aquele caminho, o que transforma o relatório em insumo de melhoria e não apenas em documento de auditoria.
O que você recebe é um relatório auditável, não um selo
Não existe certificado de pentest, aqui ou em lugar nenhum, e desconfie de quem oferecer um. O que existe é um relatório em duas camadas, sumário executivo para a diretoria e relatório técnico com evidência, reprodução e correção por achado, mais o registro do reteste do que foi corrigido. É esse conjunto que vai para a auditoria, para o cliente que pediu e para o regulador. Quando alguém precisa de documento emitido por terceiro credenciado, quem responde é a ISO 27001 ou o SOC 2, e este relatório entra inteiro nelas como evidência.
Sem teste de intrusão
- A empresa sabe quais falhas existem e não sabe o que dá para fazer com elas
- A fila de correção é atacada de cima para baixo, por gravidade técnica
- A defesa nunca foi testada contra alguém tentando de verdade
- O cliente pergunta se vocês testam, e a resposta é sobre ferramenta
Com teste de intrusão
- O alcance real está demonstrado, com o caminho encadeado e a evidência
- A fila de correção segue o que foi explorado, e não só a cor da gravidade
- O time de detecção confere se enxergaria aquele caminho, técnica por técnica
- Existe relatório com método declarado para mandar a quem perguntar
QUANDO FAZ SENTIDO
Três momentos em que o teste deixa de ser opcional
Em dois deles a exigência vem de fora e tem prazo. No terceiro ela vem de dentro, e costuma ser o que produz o resultado mais útil.
Uma exigência externa cobra o teste, com periodicidade
O PCI DSS exige metodologia documentada e teste anual de quem processa cartão. As resoluções de segurança cibernética do Banco Central exigem teste de intrusão com periodicidade mínima anual, conduzido com independência e imparcialidade por especialista contratado para essa finalidade. Cliente grande em due diligence e auditoria de certificação pedem a mesma coisa em outro formato. Nesses casos o relatório sai da sua empresa e vai ser lido por quem não participou do teste.
Alguma coisa importante mudou e nunca foi testada assim
Aplicação nova que expõe dado de cliente, migração para nuvem, integração com um parceiro que passou a acessar o seu ambiente, fusão que juntou duas redes que ninguém conhece inteiras. Aqui o valor não está em achar muitas falhas, está em descobrir cedo qual caminho novo foi aberto por uma mudança que todo mundo aprovou olhando outra coisa.
A empresa investiu em defesa e quer saber se funciona
É o motivo menos comum e o que costuma render mais. Depois de comprar proteção de estação, filtro de e-mail e monitoramento, a única forma de saber o que aquilo barra é alguém tentar passar. A conversa muda quando o relatório mostra o que a defesa bloqueou, o que ela apenas registrou e o que ela ignorou, porque aí a próxima decisão de investimento é tomada com dado em vez de folheto de fabricante.
TRADUZINDO O PEDIDO
O que costuma chegar escrito, e o que aquilo quer dizer em escopo
Contar endereços não descreve esforço. Estas são as quatro formas em que o pedido costuma chegar, com o que cada uma significa e o que realmente mexe no tamanho do trabalho.
| O que pediram | O que isso quer dizer | O que muda o tamanho |
|---|---|---|
| Precisamos de um pentest da nossa infraestrutura | Teste do que está exposto e do que existe atrás, com exploração e pós-exploração. É o formato que responde a exigência regulatória e a due diligence. | Quantos serviços diferentes existem de fato, e não quantos endereços. Faixa grande com serviços repetidos anda rápido; ambiente heterogêneo, não. |
| Queremos testar a nossa aplicação | Teste de aplicação com cobertura pelo OWASP, incluindo regra de negócio e controle de acesso entre perfis, que é onde as falhas caras costumam estar. | Quantidade de perfis de usuário, complexidade da regra de negócio, integrações com terceiros e se há acesso a documentação ou ao código. |
| O cliente pediu evidência de teste anual | O que vai ser lido por terceiro é o relatório. Ele precisa trazer escopo, método, datas, qualificação de quem executou, achados com evidência e comprovação do reteste. | O escopo que o exigente aceita, que raramente é o ambiente inteiro, e se o reteste precisa estar concluído dentro do mesmo ciclo. |
| Queremos saber se a nossa defesa funciona | O foco sai da lista de falhas e vai para a cobertura de detecção: o que a defesa barrou, o que apenas registrou e o que passou sem deixar rastro. | Se haverá janela com o bloqueio ativo, janela com o testador liberado de forma controlada, ou as duas, que é o que separa notícia boa de notícia útil. |
A conversa de escopo acontece antes da proposta, e a DM11 ajuda a escrever esse requisito mesmo quando a demanda ainda vai ao mercado. Serve para comparar fornecedores por trabalho em vez de por preço.
HISTÓRIAS
Três situações em que o escopo decidiu o resultado
Trocamos os nomes dos clientes com o mesmo sigilo que vai proteger a sua empresa depois. Os nomes mudam, o padrão dos problemas se repete. Quando o cliente autoriza, mostramos referências com nome numa conversa.
Plataforma digital
Pediram teste da aplicação, e o que importava era a fronteira entre perfis
- Situação
O pedido chegou como teste de uma aplicação web, com o número de telas na proposta. A aplicação tinha vários perfis de usuário, incluindo um perfil administrativo usado por parceiros externos, e nenhum teste anterior tinha olhado o que um perfil conseguia fazer com o identificador de outro. O escopo, do jeito que estava escrito, não obrigava ninguém a olhar isso.
- O que fizemos
Reescrevemos o requisito de escopo antes da proposta, trocando contagem de telas por combinação de perfis: o que cada um deveria poder ver, e o que deveria ser recusado. A cobertura seguiu o OWASP, com o requisito verificado item a item, e a exploração seguiu para a pós-exploração para medir o alcance a partir de cada perfil.
- Resultado
As falhas mais graves não estavam nas telas que o pedido listava, e sim na fronteira entre dois perfis, que nenhuma contagem de telas alcançaria. O escopo escrito daquela forma virou o modelo das contratações seguintes da empresa.
Varejo
A migração para nuvem tinha aberto um caminho que ninguém olhou
- Situação
Depois de mover parte do ambiente para nuvem, a empresa manteve a rotina de varredura e considerou o assunto resolvido. A migração tinha sido aprovada por arquitetura, por custo e por disponibilidade. Ninguém tinha perguntado o que ficou alcançável de fora que antes não era, porque essa pergunta não pertencia a nenhuma das três aprovações.
- O que fizemos
Combinamos nas regras de engajamento o tratamento do provedor de nuvem e a janela, que é a parte que mais atrasa esse tipo de teste. O reconhecimento partiu do que estava exposto depois da migração, e as hipóteses de ataque foram ligadas ao que o negócio não podia perder, e não ao que era mais fácil de testar.
- Resultado
O caminho encontrado começava num serviço que existia desde antes e que a migração passou a expor. A correção foi de configuração e saiu rápido; o que ficou foi a mudança de processo, com o teste passando a ser gatilho de migração e não item anual solto no calendário.
Serviços B2B
O cliente exigia teste anual, e o escopo negociado era outro
- Situação
A exigência veio no contrato: teste de intrusão anual, com evidência. A empresa orçou o ambiente inteiro, o valor assustou, e a discussão virou desconto. Ninguém tinha perguntado ao cliente qual escopo ele aceitava, e a suposição era que ele queria tudo.
- O que fizemos
Ajudamos a escrever a pergunta que faltava e a levá-la ao cliente por escrito, junto do que o relatório traria: escopo, método, datas, qualificação de quem executa, achados com evidência e comprovação do reteste. Com a resposta, o escopo foi desenhado sobre o que o exigente de fato lia, e o reteste entrou no mesmo ciclo em vez de ficar para depois.
- Resultado
O trabalho ficou do tamanho da exigência real, e não do tamanho do medo. E a empresa passou a ter, no primeiro ciclo, o documento que o cliente pedia, com o reteste concluído dentro do prazo do contrato.
COMO CONDUZIMOS
As fases escritas antes, executadas na ordem, provadas no relatório
Cada fase termina com alguma coisa que você consegue conferir sem depender da nossa palavra. É esse o ponto do método declarado: um relatório que outro profissional consegue auditar vale mais do que um que só quem escreveu entende.
- 01
Escopo, autorização e regras de engajamento
A fase que o comprador mais ignora e a que mais protege os dois lados. Fica escrito o que está dentro e o que está fora, a abordagem, as janelas, o critério de parada imediata, o tratamento de terceiros como provedor de nuvem e provedor de acesso, e se qualquer teste que possa afetar disponibilidade está autorizado. Autorização formal e contatos de emergência são registrados antes do primeiro pacote.
Escopo escrito, com o que está dentro e o que está fora
Regras de engajamento, janelas e critério de parada
Autorização formal para testar e contatos de emergência
Tratamento acordado para nuvem, provedor de acesso e demais terceiros
Marco de entregaEscopo e autorização assinados, sem nenhum ponto de escopo em aberto.
- 02
Reconhecimento e hipóteses de ataque
Levantamos o que existe e o que o mundo já sabe sobre a sua empresa, e transformamos isso em hipóteses de ataque ligadas ao que o seu negócio não pode perder. Sem esta fase o teste vira busca por falha solta, e o resultado é uma lista sem prioridade que ninguém sabe usar. As hipóteses são validadas com o seu time antes de qualquer exploração.
Superfície levantada, com o que é exposto e o que é interno
Informação pública sobre a empresa, quando está no escopo
Hipóteses de ataque ligadas ao que o negócio não pode perder
Alvos priorizados e acordados com você antes da exploração
Marco de entregaHipóteses validadas com o seu time, com prioridade acordada por escrito.
- 03
Exploração e pós-exploração
Confirmamos na prática o que dá para explorar, que é a diferença entre suspeita e fato, e seguimos para medir até onde daria para chegar depois da primeira porta. A pós-exploração é a fase que mais falta nas propostas baratas e a que mais muda decisão de investimento. Em aplicação, a cobertura segue o OWASP, com o Top 10 e o ASVS. Achado crítico é comunicado no mesmo dia, sem esperar o relatório.
Confirmação por exploração, com evidência do que foi obtido
Alcance real demonstrado, com o caminho encadeado
Cobertura de aplicação pelo OWASP, com o requisito verificado por item
Comunicação imediata do achado crítico, com recomendação inicial
Marco de entregaFalha crítica comunicada no mesmo dia em que é confirmada.
- 04
Relatório em duas camadas e reteste
O relatório sai nas duas camadas que o próprio PTES define, sumário executivo e relatório técnico, com o caminho percorrido descrito na linguagem do MITRE ATT&CK para o seu time conferir a detecção e não só a correção. Depois que a correção acontece, refazemos o teste do que foi corrigido e registramos o resultado, que é o documento que a auditoria costuma pedir junto do relatório.
Sumário executivo para a diretoria, sem jargão
Relatório técnico com evidência, reprodução e correção por achado
Caminho percorrido nomeado por tática e técnica do MITRE ATT&CK
Reteste do que foi corrigido, com o resultado registrado
Marco de entregaCada achado fechado ou aceito por escrito, com o reteste registrado.
QUANTO TEMPO LEVA
Três coisas mexem no relógio, e a contagem de endereços não é uma delas
Não publicamos prazo padrão porque prazo publicado vira promessa e escopo de teste de intrusão varia muito. A primeira conversa já mostra em qual destes fatores a sua empresa está, e é ela que produz o requisito de escopo.
Quantos alvos, e o que é alvo de verdade
Uma faixa grande com serviços repetidos anda rápido. Uma única aplicação com muitos perfis de usuário, regra de negócio complexa e integração com terceiros consome muito mais. É a conversa de escopo que separa os dois casos, e ela acontece antes da proposta.
Com quanta informação o teste começa
Sem informação nenhuma, boa parte do tempo vai para o reconhecimento, e o resultado se parece com o que um atacante externo enfrentaria. Com acesso a documentação ou ao código, o mesmo tempo é gasto procurando falha em vez de procurando porta. As duas escolhas são legítimas, entregam coisas diferentes, e a decisão fica registrada no escopo.
Quando a janela pode acontecer
Ambiente que só pode ser testado fora do horário comercial, sistema com pico sazonal, autorização pendente de provedor de nuvem e aviso prévio ao provedor de segurança gerenciada mexem no calendário mais do que a parte técnica. Essa conversa começa cedo, porque costuma ser a mais demorada do projeto inteiro.
PERGUNTAS FREQUENTES
O que perguntam antes de contratar
As dúvidas que aparecem em quase toda primeira reunião, respondidas sem rodeio.
A análise de vulnerabilidade é ampla e sobretudo automática: encontra e lista falhas conhecidas, em ordem de gravidade, e serve como rotina ao longo do ano. O pentest é fundo e sobretudo manual: um especialista tenta explorar as falhas para provar o que um atacante conseguiria fazer, e mede até onde daria para chegar depois da primeira porta. Uma responde o que pode estar errado; a outra responde o que dá para fazer de fato. As duas se completam, e várias exigências pedem as duas: o PCI DSS, por exemplo, exige varredura trimestral e teste anual.
Precisa, e sem isso não começamos. Sem autorização formal do responsável pelo ativo, o mesmo conjunto de ações deixa de ser teste e passa a ser acesso não autorizado. O documento define o que está dentro e o que está fora do escopo, quem autoriza, a janela de execução, o critério de parada imediata, se qualquer teste que afete disponibilidade está permitido, e quem é acionado se algo sair do previsto. Quando há terceiros no caminho, como provedor de nuvem, provedor de acesso ou empresa que opera a sua segurança, o tratamento de cada um também fica escrito antes.
Pode, se ninguém combinar isso antes, e é exatamente por isso que a primeira fase existe. Nas regras de engajamento fica escrito se qualquer teste que afete disponibilidade está autorizado, quais sistemas ficam fora, em que janela o trabalho acontece, quem é acionado se algo sair do previsto e qual é o critério de parada imediata. Com isso registrado, o risco de indisponibilidade deixa de ser sorte e passa a ser decisão sua, tomada com informação e antes do começo.
Não existe, nem para a sua empresa nem para o relatório, e vale desconfiar de quem oferecer um. O que existe é o relatório com método declarado, e são as pessoas que conduzem o teste que têm certificação, como CEH, CPTE e as trilhas de pentest da Solyd. Quando o seu cliente ou o seu auditor precisa de um documento emitido por terceiro credenciado, quem responde a isso é a ISO 27001 ou o SOC 2, e o relatório do teste entra inteiro nessas auditorias como evidência.
Está, e ele é entregável declarado em contrato, não cortesia. Depois que a sua equipe corrige, refazemos o teste do que foi corrigido e registramos o resultado por achado, fechado ou aceito por escrito. Esse registro costuma ser tão pedido pela auditoria quanto o relatório em si, porque é ele que mostra que a lista não ficou parada. Se o prazo de correção do seu lado for longo, isso entra no escopo desde o começo em vez de virar discussão depois.
Peça a cada fornecedor que declare, fase a fase, o que será feito. Cinco perguntas separam quase tudo: quais fases estão incluídas, se a pós-exploração faz parte ou se o trabalho termina na confirmação da falha, se há reteste e em qual prazo, quem executa e com qual qualificação, e o que exatamente o relatório vai conter. Onde a proposta diz apenas pentest de um número de endereços, não há o que comparar, e a diferença de preço vai continuar sem explicação. A DM11 ajuda a escrever esse requisito mesmo quando a sua empresa ainda vai levar a demanda ao mercado.
Depende de quem está cobrando e do que muda no seu ambiente. O PCI DSS exige teste anual de quem processa cartão, e as resoluções de segurança cibernética do Banco Central exigem periodicidade mínima anual com independência de quem executa. Fora de exigência formal, a regra prática é anual, mais um teste sempre que algo relevante mudar: aplicação nova exposta, migração de ambiente, integração que abriu acesso a um parceiro. Entre um teste e outro, quem cobre o ano é a gestão de vulnerabilidades, que é trabalho de rotina e não substitui o teste.
Sim, e é um trabalho com outro escopo, não uma extensão do teste tradicional. Um sistema de IA é atacado por caminhos que uma aplicação comum não tem: manipulação da entrada para mudar o comportamento do modelo, extração do que ele aprendeu, envenenamento do dado que o alimenta. A referência que cataloga essas técnicas é o MITRE ATLAS, e não o ATT&CK. Se o seu caso envolve modelo em produção na frente do cliente, a conversa começa por ali e costuma vir junto da governança de IA.
Escreva o escopo antes de pedir o preço
Uma conversa curta já produz o requisito fase a fase que a sua empresa pode levar ao mercado. Serve para comparar fornecedores com critério, e serve para contratar com a gente sabendo exatamente o que recebe em cada etapa.
Comparativos sobre este assunto
Ver os 13 comparativosFontes e referências
- Penetration Testing Execution Standard
PTES · versão 1.0; a edição mais recente do wiki é de dezembro de 2015 · consultado em
- OWASP Top 10
OWASP Foundation · edição 2025, primeira revisão desde 2021 · consultado em
- Application Security Verification Standard
OWASP Foundation · ASVS 5.0 · consultado em
- MITRE ATT&CK
The MITRE Corporation · v19.1, publicada em 28/04/2026 · consultado em
- Publicado em
- Revisado em
- Revisão editorial
- DM11 Consultoria em Segurança da Informação Ltda
Esta página é informativa e descreve como a DM11 lê e aplica as fontes acima. Ela não reproduz o texto das normas, não substitui a leitura do documento oficial e não substitui auditoria, certificação, avaliação independente ou aconselhamento jurídico. Onde a norma exige avaliação formal, quem conduz é um organismo, auditoria ou avaliador credenciado, sempre separado de quem preparou.