Teste de intrusão com finding validado na unha.
Teste de intrusão conduzido por gente, com exploração manual e cada achado reproduzido antes de virar relatório. O objetivo não é listar o que parece vulnerável: é demonstrar o que um atacante consegue fazer com o que está exposto hoje.
O que um pentest responde que um scanner não responde
Ferramenta automatizada aponta o que parece vulnerável. Um pentest demonstra o que é de fato explorável e até onde o acesso chega. A diferença aparece no encadeamento: uma falha de autorização que isolada seria tratada como baixa vira crítica quando permite alcançar um dado que deveria estar fora do alcance daquele usuário. É esse caminho completo que ferramenta nenhuma constrói sozinha — e é ele que muda a decisão de quem prioriza a correção.
- Cada achado é reproduzido manualmente antes de entrar no relatório: saída bruta de ferramenta não vira entrega.
- O risco é descrito pelo impacto no seu negócio, e não apenas pela nota genérica de uma base pública.
- Falso positivo não chega até você — o que não foi reproduzido fica de fora do documento.
- O caminho de exploração fica registrado passo a passo, para que o seu time consiga repetir e confirmar a correção.
O que está incluído
Escopo abaixo é o padrão para um engajamento típico. Tudo é ajustável durante a call de scoping, sem custo.
- Autenticação, sessão e recuperação de senha
- Autorização horizontal e vertical por objeto
- Injeção em consulta, comando e template
- Lógica de negócio e fluxos que podem ser burlados
- Upload, processamento e servir de arquivos
- Configuração de cabeçalhos, cookies e CORS
- Enumeração de recursos e identificadores previsíveis
- Controle de acesso entre contas e entre inquilinos
- Validação de esquema e tratamento de tipo inesperado
- Limites de taxa, custo e abuso automatizado
- Autenticação entre serviços e rotação de segredo
- Exposição de dado excessivo na resposta
- Superfície exposta na borda e serviços esquecidos
- Versões sem suporte e correção pendente
- Segmentação entre ambientes e entre redes
- Serviços internos alcançáveis a partir do perímetro
- Configuração de TLS e de terminação de tráfego
- Movimentação lateral a partir de um acesso inicial
- Provedor de identidade e fluxos de federação
- Segundo fator: cobertura, contorno e recuperação
- Privilégio herdado e acúmulo de permissão
- Contas de serviço e credencial em código
- Sessão em múltiplos dispositivos e revogação
- Cadastro e onboarding de novos usuários
- Aplicações Android e iOS, incluindo armazenamento local
- Comunicação do app com a API e fixação de certificado
- Proteções contra manipulação e execução em aparelho comprometido
- Wi-Fi corporativo, rede de visitantes e segregação entre elas
- Infraestrutura on-premises e o que ela alcança na nuvem
- Quiosques, terminais e dispositivos de uso compartilhado
- Injeção: SQL, NoSQL, LDAP, comando e template
- Autenticação, autorização, IDOR e escalada de privilégio
- SSRF, XXE e desserialização insegura
- Falhas de lógica de negócio e de fluxo de pagamento
- XSS, CSRF e clickjacking com impacto demonstrado
- Criptografia mal aplicada, token previsível e JWT frágil
Modalidades
ajustáveis ao escopoCaixa-preta
Começamos sem informação privilegiada, na mesma posição de quem ataca de fora. Mede o que a sua superfície entrega para um desconhecido e costuma revelar o que ninguém sabia que estava exposto.
Caixa-cinza
Recebemos credenciais e uma visão geral da arquitetura. É a modalidade que cobre mais superfície no mesmo tempo, porque o esforço vai para exploração em vez de reconhecimento — e é onde falha de autorização aparece.
Caixa-branca
Acesso a código, configuração e documentação. Permite alcançar caminhos que raramente aparecem de fora, como condição de corrida, tratamento de erro e lógica sensível escondida atrás de várias camadas.
Quando um pentest costuma fazer diferença
Não é um exercício anual por obrigação. Existem momentos em que o teste devolve mais do que custa, porque a superfície mudou ou porque alguém de fora vai perguntar.
Reescrita, troca de provedor de autenticação ou migração de ambiente mexem em pressupostos que ninguém revisita. Testar antes da virada é mais barato do que descobrir depois com tráfego real em cima.
Contrato corporativo, questionário de segurança e processo de compra costumam pedir um teste independente. O relatório serve como resposta objetiva, sem depender de declaração própria.
Time novo, serviço novo, integração nova. Crescimento acelerado cria superfície que ninguém mapeou por inteiro, e permissão que foi concedida em caráter temporário e nunca voltou atrás.
Sistema interno antigo, painel administrativo e integração legada costumam ficar fora de todo escopo por anos — exatamente por serem considerados internos demais para preocupar.
Como conduzimos
[pipeline]Definição e regras de engajamento
Antes de qualquer pacote sair, fica registrado por escrito o que entra no escopo, o que fica de fora, quais janelas são permitidas e quem é acionado se algo sair do previsto. Também combinamos o critério de parada para achado crítico, para que uma descoberta grave chegue a você no mesmo dia em vez de esperar o relatório.
Reconhecimento e mapeamento
Levantamos a superfície real: domínios, subdomínios, serviços expostos, tecnologias, pontos de entrada e o que já é público sobre o ambiente. É a etapa que costuma revelar ativos fora do inventário — ambiente de homologação acessível, painel esquecido, serviço que subiu para um teste e ficou.
Varredura e triagem
A automação entra aqui, e só aqui: ela cobre volume e aponta candidatos. Todo resultado passa por triagem manual, porque a maior parte do que uma ferramenta marca não se sustenta quando alguém tenta reproduzir. O que sobra vira hipótese de exploração.
Exploração manual
É onde o teste se separa de uma varredura. Encadeamos falhas, testamos lógica de negócio, tentamos escalar privilégio e alcançar dado que deveria estar protegido — sempre dentro das regras combinadas e sem tocar em disponibilidade de produção.
Pós-exploração e alcance
Achar a porta não basta: interessa até onde ela leva. Medimos o alcance de um acesso inicial, o que dá para ler, alterar ou persistir a partir dele, e se é possível chegar a outro sistema. É essa medida que transforma uma nota técnica em risco de negócio.
Relatório e reteste
O relatório traz o caminho reproduzível, o impacto e a correção recomendada, com uma leitura executiva separada da técnica. Depois da correção, retestamos os itens tratados e registramos o que fechou — porque achado corrigido só conta quando alguém confirma.
Referências públicas que guiam a execução
Trabalhamos sobre metodologias abertas e reconhecidas. Isso torna o escopo comparável entre fornecedores e permite que a sua auditoria confira o que foi coberto sem depender da nossa palavra.
- OWASP WSTG
- O guia de testes de aplicação web da OWASP organiza a cobertura por categoria — autenticação, sessão, autorização, validação, lógica de negócio — e serve de base para mostrar o que foi verificado.
- OWASP API Security
- A lista de riscos de API trata do que aplicação web tradicional não cobre bem: autorização em nível de objeto, exposição de dado além do necessário e consumo sem limite.
- PTES
- O Penetration Testing Execution Standard descreve as fases de um teste, do pré-engajamento ao relatório, e é a espinha do fluxo descrito acima.
- MITRE ATT&CK
- O catálogo de táticas e técnicas adversárias dá nome ao que foi executado, o que permite ao seu time de defesa cruzar cada passo com o que a detecção viu — ou deixou de ver.
- NIST SP 800-115
- O guia técnico de avaliação de segurança do NIST define planejamento, execução e pós-teste, e é a referência mais citada em requisitos contratuais.
- CVSS
- A pontuação padroniza a severidade técnica, mas ela entra como insumo: o que vale na priorização é o impacto no seu contexto, e ele é descrito em texto claro além da nota.
Entregáveis
dupla visão · NDASumário executivo
Uma leitura curta para quem decide orçamento e prioridade: o que foi testado, o que representa risco real e o que precisa de decisão. Escrito sem jargão, para sustentar conversa com diretoria e conselho.
Achados com reprodução completa
Cada item traz o caminho passo a passo, com requisição, resposta e evidência. Um desenvolvedor consegue reproduzir sem pedir esclarecimento, e sem depender de quem executou o teste.
Avaliação de impacto e prioridade
Severidade técnica e impacto de negócio aparecem separados, porque nem sempre andam juntos. A ordem sugerida considera esforço de correção, para o time não começar pelo mais caro e menos urgente.
Recomendação de correção específica
Orientação aplicada ao seu código e à sua arquitetura, não um parágrafo genérico copiado de documentação. Quando há mais de um caminho, o relatório descreve o compromisso de cada um.
Cruzamento com o seu monitoramento
Um resumo do que foi executado, mapeado por técnica, para o time de detecção comparar com o que os registros e alertas capturaram. Costuma revelar tanto quanto a lista de vulnerabilidades.
Reteste e carta de conclusão
Depois das correções, revisitamos os itens tratados e registramos o estado final. A carta serve para cliente, parceiro e auditor que precisam de evidência de que o ciclo foi fechado.
Perguntas frequentes
O padrão é não testar disponibilidade. Negação de serviço e qualquer ação de risco alto ficam fora do escopo salvo pedido explícito e janela combinada. Se um teste puder afetar produção, ele é levado a ambiente equivalente ou executado em janela acordada, com contato direto aberto do começo ao fim.
Escopo definido, credenciais de teste para cada perfil de usuário e um contato técnico disponível. Se houver proteção de borda que possa bloquear o teste, decidimos junto se ela entra no escopo ou se recebe uma exceção — testar o bloqueio e testar a aplicação são objetivos diferentes.
A varredura compara o que encontra com uma base conhecida e devolve uma lista. O pentest tenta explorar, encadeia falhas e mede até onde o acesso chega. A varredura é barata e serve para acompanhamento contínuo; o teste manual responde o que a lista não responde — se aquilo é explorável no seu contexto.
Sim. O sumário executivo é escrito para quem não é técnico e pode ser compartilhado com cliente, parceiro ou auditor. A parte técnica fica em seção separada, e a carta de conclusão após o reteste é o documento normalmente aceito como evidência em processo de compra.
Depende do risco. Homologação fiel à produção é preferível quando existe, porque libera testes mais agressivos. Quando só há produção — o caso mais comum — restringimos ações destrutivas, combinamos janela e mantemos canal aberto durante toda a execução.
O critério de parada combinado no início entra em ação: achado crítico é comunicado imediatamente, com o mínimo necessário para você agir, sem esperar o relatório final. Se o caso exigir, a execução é pausada até a contenção.
Depende da taxa de mudança. Aplicação com entrega contínua muda de superfície toda semana, e um teste anual olha para um sistema que não existe mais. Uma prática comum é combinar teste periódico do escopo principal com teste pontual a cada mudança estrutural — nova integração, novo provedor de identidade, novo ambiente.
Pronto para descobrir suas falhas?
Primeira call de scoping é gratuita e coberta por NDA. Em 48 horas você recebe proposta técnica, escopo e cronograma. Sem formulários burocráticos.