Cases · 6 findings reais · ~14 min
Cases Reais de Pentest: o Que Encontramos em Bancos, Governo e e-Commerce
Os cases abaixo ilustram o tipo de finding que pentest manual encontra e scanner automatizado não vê. Cada case anonimizado quando o cliente está sob NDA estrito; clientes que autorizaram divulgação genérica (Caixa Econômica, BMG, iFood, ArcelorMittal, Multibanco, Polícia Federal) são nomeados.
Para cada case: o que o cliente contratou, o tempo de engagement, o finding crítico, o impacto evitado, e o callout do que scanner não pegaria — o eixo central da nossa tese.
Time fixo
O mesmo time que executou esses 6 cases vai executar o seu. Sem rodízio.
90% manual
Cada finding aqui foi descoberto manualmente. Scanner não pega lógica de negócio, não pega encadeamento.
Relatório PoC
Cada finding entrega: descrição, PoC reproduzível, business impact, CVSS justificado, rota de correção.
Race condition em saque PIX → R$ 4M expostos
Cliente: Fintech regulada com volume de R$ 200M/mês em PIX, atuando em ambiente OpenBanking.
Escopo: Web app + API REST/GraphQL + multi-tenancy + autenticação OAuth2 (FAPI 1.0 Advanced).
Finding crítico: Race condition no endpoint de saque permitia, em janela de 80ms, criar duas requisições simultâneas que ambas eram aprovadas com o mesmo saldo. Resultado: saque dobrado da quantia.
Impacto evitado: R$ 4M expostos por dia em janela vulnerável. Atacante com automação básica conseguiria milhões em horas.
Scanner não pegaria isso porque: race condition de lógica de negócio depende de mapear o fluxo de débito + envio de mensagem + check-then-act. Burp Active Scan testa string match, não temporalidade. Identificamos no Threat Modeling e validamos manualmente em ambiente espelho.
IDOR em prontuário eletrônico → ~200k pacientes expostos
Cliente: Hospital de grande porte com PEP integrado a portal do paciente.
Escopo: Portal do paciente + APIs de prontuário + integração com sistemas hospitalares (HIS).
Finding crítico: Endpoint /api/exame/{id} não validava ownership — qualquer paciente autenticado podia incrementar/decrementar o ID e ver exames de outros. ~200.000 prontuários acessíveis sequencialmente.
Impacto evitado: Multa LGPD potencial de R$ 50M (categoria de dado sensível, art. 11 LGPD), processo coletivo, suspensão de credenciamento ANS, dano reputacional irrecuperável.
Scanner não pegaria isso porque: ferramenta vê o endpoint retornando 200 OK com payload válido — não tem como saber que o ID 12347 deveria ser inacessível ao paciente 12346. IDOR cross-tenant exige análise manual de autorização.
ArcelorMittal — Default credentials em PLC e segmentação rede
Cliente: ArcelorMittal — siderurgia/mineração de grande porte.
Escopo: Pentest interno corporativo + auditoria de segmentação OT/IT + análise de PLCs Siemens e Rockwell em linha de produção.
Finding crítico: 60% dos PLCs com credenciais default (admin/admin), expostos na rede corporativa por VLAN mal configurada. Engenheiro com acesso VPN poderia, deliberadamente ou via phishing, modificar parâmetros de produção.
Impacto evitado: Adulteração de torque em montagem → recall regulatório. Em farma: adulteração de receita → crise de saúde pública. O custo direto de uma intervenção em PLC mal-intencionada chega a USD 300k/hora de linha parada em siderurgia.
Scanner não pegaria isso porque: scanners corporativos não falam Modbus, DNP3, IEC 60870-5 ou OPC-UA. Mapeamento Purdue Level 2/3 e segmentação OT exigem conhecimento de IEC 62443 — não é produto de mercado, é especialidade.
IDOR cross-tenant em GraphQL → dados de cliente A vazando para B
Cliente: SaaS B2B com 10k clientes enterprise, dependendo de SOC 2 Type II para vendas.
Escopo: Web app + API GraphQL + multi-tenancy isolation + cloud configuration AWS.
Finding crítico: GraphQL query getDocument(id) não validava tenant_id. Qualquer cliente autenticado podia, com ID válido, ler documentos de qualquer outro cliente.
Impacto evitado: Vazamento de dado contratual entre concorrentes. Auditoria SOC 2 Type II reprovada se não corrigido. Risco de churn de cliente enterprise (10x ARR perdido por incidente).
Scanner não pegaria isso porque: ferramentas de scan GraphQL como InQL ou GraphQL-Voyager mapeiam schema, não testam isolamento entre tenants. Análise manual de 6 horas em schema + 2 horas de exploração reproduziu o finding.
Caixa Econômica Federal — Phishing → AD admin em 36h, 0 detecções
Cliente: Caixa Econômica Federal. Reconhecidos como melhor pentest técnico em avaliação competitiva.
Escopo: Red Team multi-vetor com objetivo "transferir R$ X de uma conta para outra sem ser detectado".
Cadeia de ataque:
- OSINT identificou padrão de email da empresa via LinkedIn e cert transparency;
- Phishing direcionado a 12 colaboradores de áreas de TI/Segurança;
- 1 clique → execução de payload customizado, bypass de EDR;
- Movimentação lateral via Kerberos roasting → Domain Admin em 36h;
- Acesso ao core bancário simulado em ambiente espelho;
- Detecção: 0 alertas no SOC durante toda a operação.
Entregue ao cliente: Plano de melhoria SOC com 14 detecções de TTPs MITRE ATT&CK não cobertas + treinamento de blue team com cenário do próprio relatório.
Por que MSSP grande não entrega esse engajamento: Red Team realista exige time fixo com OPSEC consolidada. Engajamento operado por analistas júniors em rotação não constrói a cadeia de TTPs nem mantém persistência adequada.
Multibanco (PT) e Santa Casa de Misericórdia — pentest regulatório PT
Clientes: Multibanco (rede de pagamento portuguesa) e Santa Casa de Misericórdia (instituição hospitalar histórica de Portugal).
Escopo: Pentest combinado de aplicação + infraestrutura + adequação a GDPR, NIS2 (UE 2022/2555) e legislação setorial portuguesa.
Findings de ordem: Falhas em cadeia de autenticação multi-fator, tratamento de dados especiais (saúde), cookies sem flag adequada, exposição de tokens em telemetria de terceiros.
Impacto evitado: Adequação a GDPR art. 32 (segurança do tratamento) e a inspeção da CNPD (autoridade portuguesa de proteção de dados). Para hospital, evitar violação dos termos de processamento conforme padrão UE.
O que diferenciou: presença física em Portugal (Leiria) permitiu pentest interno on-site sem custo de deslocamento internacional. Multinacionais que terceirizam pentest PT a partir do Brasil pagam dia + hotel — modelo nosso já tem o time presente.
O que cada case ilustra do nosso modelo
FAQ
Esses cases são reais?
Sim. Os clientes nominados (Caixa, BMG, iFood, ArcelorMittal, Multibanco, Polícia Federal) constam com autorização de divulgação genérica. Os findings descritos são reais — anonimizados em pormenor técnico onde NDA exige.
Vocês entregam cases sob NDA?
Sob proposta avançada e mediante NDA específico, compartilhamos relatórios sanitizados como referência técnica. Nunca compartilhamos dados de cliente atual sem autorização explícita.
Que tipo de cliente vocês recusam?
Pedidos sem Authorization to Test válido. Solicitação para atacar sistema de terceiro sem autorização. Operações em jurisdições sob sanção (Cuba, Irã, Coreia do Norte, Síria, regiões ocupadas Ucrânia). Cliente que não passa em sanctions screening (OFAC, UN, EU).
Quanto tempo até o primeiro pentest?
Cotação em até 48h após receber o contexto. Início típico do engagement: 1-3 semanas após assinatura, dependendo de complexidade do escopo e disponibilidade do cliente para pre-engagement.
Vocês fazem retest?
Sim, 1x retest incluso no preço base, validando correção de findings críticos/altos dentro de 30-90 dias da entrega do relatório. Retests adicionais cobrados separadamente, com desconto sobre engajamento original.
Posso indicar cliente com case parecido ao meu?
Quando há overlap setorial, apresentamos resumo técnico do tipo de finding encontrado em case análogo. Detalhe completo permanece sob NDA do cliente original.