Testes de penetração
Testar as defesas com os métodos de quem ataca.
Atacamos as suas aplicações, APIs e infraestruturas como um atacante faria, mas com autorização, dentro de um âmbito e de janelas acordados, e com o objetivo de fechar cada falha que encontrarmos.
- Autorização escrita
- Janelas acordadas
- Reteste incluído
Para decisores
O que é um teste de penetração, em linguagem simples.
É um ataque controlado e autorizado, feito para descobrir o que um atacante real conseguiria fazer, antes de ele tentar.
- Mostra o risco real. Não basta saber que uma falha existe: o teste mostra até onde se chega com ela.
- Testa o conjunto. Aplicação, servidor, configuração e integrações, tal como estão em funcionamento.
- É feito com regras. Âmbito, janelas, contactos e condições de paragem acordados por escrito.
- Termina com as falhas fechadas. O reteste confirma que as correções resultaram.
Aplicações e APIs
Portais, backoffices e APIs REST ou GraphQL.
Infraestruturas
Perímetro externo, rede interna e diretório.
Aplicações móveis
Apps Android e iOS e as APIs de que dependem.
Com reteste
Confirmação de que cada falha ficou fechada.
O que testamos
Três tipos de teste, uma só metodologia.
-
Aplicações web e APIs
Seguimos o guia de testes OWASP (WSTG) para aplicações web e o OWASP API Security Top 10 para APIs.
- Autenticação, sessões e recuperação de conta
- Permissões entre utilizadores e perfis
- Injeção, validação e envio de ficheiros
- Lógica de negócio e limites de utilização
-
Infraestruturas
Avaliamos o que está exposto à Internet e, com acesso à rede, o que um atacante conseguiria fazer a partir de dentro.
- Serviços expostos e versões vulneráveis
- Acessos remotos e VPN
- Active Directory e Microsoft Entra ID
- Configurações, palavras-passe e segmentação
-
Aplicações móveis
Seguimos o guia de testes OWASP para aplicações móveis (MASTG), em Android e iOS.
- Dados guardados no dispositivo
- Comunicações e certificados
- Proteção do código da app
- APIs de suporte
Abordagens
Quanto sabemos antes de começar.
A abordagem define a informação que nos dá à partida. A caixa cinzenta é a que recomendamos na maioria dos casos.
| Abordagem | O que sabemos | Quando usar |
|---|---|---|
| Caixa preta | Apenas o endereço do sistema, como um atacante externo. | Para medir a exposição a quem não tem qualquer acesso. |
| Caixa cinzenta | Contas de teste com os perfis habituais e documentação básica. | Recomendada: cobre mais em menos tempo e testa as permissões entre utilizadores. |
| Caixa branca | Acesso ao código e à arquitetura, em conjunto com uma auditoria de código. | Para sistemas críticos, onde se quer a cobertura mais completa. |
Como decorre um teste
Do âmbito ao reteste, sempre em contacto.
-
Âmbito e autorização
Sistemas, endereços, contas de teste, janelas e contactos acordados e autorizados por escrito.
-
Reconhecimento
Levantamento do que está exposto: serviços, versões, tecnologias e pontos de entrada.
-
Testes
Testes automáticos e manuais, guiados pelas metodologias OWASP e pelo que o reconhecimento revelou.
-
Confirmação
Cada falha é confirmada sem causar dano; uma falha crítica é comunicada no próprio dia.
-
Relatório
Achados por gravidade, com provas, a narrativa do ataque e as correções propostas.
-
Reteste
Depois das correções, confirmamos que cada falha ficou fechada.
Regras de execução
Atacar com cuidado também é uma competência.
As regras ficam escritas antes do primeiro teste e protegem o seu serviço, os seus dados e as pessoas que os usam.
- Autorização escrita do responsável pelo sistema e, quando os termos o exigem, do fornecedor de alojamento.
- Âmbito fechado: só os endereços, as aplicações e as contas acordados.
- Janelas combinadas para os testes mais intrusivos, de preferência em ambientes de teste.
- Contacto de emergência de ambos os lados durante toda a execução.
- Condições de paragem: paramos de imediato se nos for pedido ou se o serviço for afetado.
- Sem dados reais em risco: não copiamos dados pessoais além do mínimo necessário para provar a falha.
- Limpeza no fim: contas, ficheiros e alterações de teste são removidos e confirmados.
Autorização
Nada é testado sem autorização escrita.
Janelas
Os testes intrusivos têm hora marcada.
Contacto direto
Uma pessoa disponível durante a execução.
Confidencialidade
Achados e provas tratados na UE.
Ferramentas
Ferramentas abertas, análise feita por pessoas.
Usamos ferramentas de código aberto reconhecidas para cobrir o essencial depressa. O que distingue um teste é o trabalho manual que vem a seguir.
- As ferramentas encontram candidatos; as pessoas confirmam, encadeiam falhas e avaliam o impacto real.
- A lógica de negócio e as permissões entre utilizadores só se testam à mão.
- Cada achado é reproduzido antes de entrar no relatório, sem listas de falsos positivos.
ZAP
Testes a aplicações web e APIs.
Nmap
Descoberta de sistemas e serviços.
Nuclei
Falhas conhecidas e configurações inseguras.
sqlmap
Confirmação de injeção de SQL.
MobSF
Análise de aplicações móveis.
IA com revisão humana
Apoio na análise, sempre confirmado por uma pessoa.
O que recebe
Um relatório que conta como o ataque aconteceria.
Para cada falha importante, mostramos o caminho de um atacante, passo a passo, e como o fechar. Veja como é um relatório completo.
- Resumo executivo para a direção, com o nível de risco e as prioridades.
- Narrativa do ataque para as falhas críticas: do primeiro acesso ao impacto.
- Relatório técnico com provas, gravidade medida com CVSS 4.0 e correções propostas.
- Correções feitas por nós ou pela sua equipa ou fornecedor, à sua escolha.
- Reteste e relatório final com o estado de cada achado.
Perguntas frequentes
Sobre os testes de penetração.
Os testes podem parar o serviço?
Planeamos tudo para que não aconteça. Os testes mais intrusivos são feitos em ambientes de teste ou em janelas combinadas, há sempre um contacto direto e paramos de imediato se o serviço for afetado.
Testam em produção?
Quando é necessário, sim, com cuidados adicionais: testes menos intrusivos, janelas fora das horas de maior utilização e contas criadas para o efeito. Sempre que existe um ambiente de teste igual ao de produção, preferimos usá-lo.
Temos de avisar o fornecedor de alojamento?
Depende dos termos do seu fornecedor. Alguns exigem aviso ou autorização prévia para testes de segurança. Verificamos isso consigo durante a definição do âmbito.
O que acontece se encontrarem uma falha crítica?
Comunicamos de imediato, no próprio dia, sem esperar pelo relatório. Combinamos consigo as medidas urgentes e, se quiser, ajudamos a aplicá-las.
Com que frequência devemos fazer testes de penetração?
Pelo menos uma vez por ano e depois de cada alteração importante, como uma nova versão, uma nova integração ou uma mudança de alojamento. A subscrição anual cobre este calendário.
Quer saber até onde chegaria um atacante?
Conte-nos que sistemas quer testar e propomos um âmbito, uma abordagem e um preço fechados.