Pentest Grey Box em 2026: por que é a escolha default e quando contratar (guia para SaaS e fintech)

Pentest Grey Box— ou “caixa-cinza” — é a modalidade em que o pesquisador de segurança recebe credenciais e documentação básica sobre o sistema antes de começar. Geralmente: duas contas de teste em tenants diferentes (essencial para testes cross-tenant), descrição de alto nível da arquitetura, documentação da API (Swagger/OpenAPI/GraphQL schema se existir), e lista de fluxos críticos do produto.

É o ponto de equilíbrio entre as três modalidades — nem o tempo perdido em recon que caracteriza Black Box, nem o overhead de revisão de código e setup de ambiente do White Box. Por isso ocupa ~60% do mercado em distribuição típica e é a escolha default da maioria dos pentests sérios em SaaS B2B e fintech.

Esse guia explica em profundidade o que é Grey Box em 2026, como funciona na prática, quando contratar, quando NÃO, e como ela se compara com Black Box (publicado ontem) e White Box (que vem amanhã).

O que é pentest Grey Box, em uma definição

Pentest Grey Box é a simulação controlada de um ataque por parte de alguém que tem algum nível legítimo de acesso ao sistema — cliente regular, ex-funcionário com credenciais ainda válidas, ou atacante externo que adquiriu credencial vazada ou comprada. O pesquisador recebe contas de teste, documentação de escopo, e a partir daí simula o que esse perfil de atacante consegue fazer com o privilégio que tem.

Como Grey Box parte de dentro do perímetro autenticado, ele cobre exatamente o que Black Box não enxerga: tudo o que está atrás do login. Em SaaS B2B típico, isso representa 80-90% da complexidade técnica e da superfície de risco real — porque a maior parte dos bugs caros (BOLA cross-tenant, BFLA, race conditions em transações, lógica de negócio quebrada) só aparece com múltiplas contas autenticadas testando em paralelo.

Diferenciador rápido: Grey Box vs Black Box vs White Box

Para ancorar onde Grey Box se encaixa no espectro das três modalidades:

Para o deep dive em Black Box, veja Pentest Black Box em 2026: o que é, quando contratar e quando NÃO. White Box vem amanhã. Para a visão comparativa completa, veja Black Box vs Grey Box vs White Box: qual pentest contratar em 2026.

Como funciona Grey Box na prática — metodologia

A grande diferença vs Black Box é estrutural: o pesquisador não gasta tempo descobrindo o que existe — recebe o mapa. Isso libera quase todo o orçamento de horas pra exploração ativa. As 4 fases:

Fase 1 — Setup credenciado e mapeamento (5–10% do projeto)

Pesquisador recebe credenciais (idealmente duas contas em tenants diferentes, mais uma conta admin do tenant principal pra teste de privilege escalation), documentação de escopo, OpenAPI/Swagger e diagrama de arquitetura. Configura o ambiente de teste, valida que as credenciais funcionam, mapeia o universo de endpoints autenticados que vai cobrir.

• Validação das contas: confirma escopo (papéis, permissões, tenants atribuídos)
• Mapeamento da API autenticada: enumeração via Swagger + descoberta de endpoints não documentados via crawl + análise de tráfego do app
• Configuração de gravação de tráfego HTTP: Burp Suite, Caido ou ZAP rodando como proxy para captura sistemática
• Setup de contas paralelas: o teste de cross-tenant exige que as duas identidades estejam logadas simultaneamente em sessões distintas

Em Black Box, essa fase consumiria 40–60% do projeto. Em Grey Box, 5–10%. A diferença não vai pra desperdício — vai pra exploração mais profunda.

Fase 2 — Validação de autorização e isolamento entre tenants (30–40%)

Essa é a fase onde Grey Box brilha. O pesquisador, com duas contas em tenants diferentes, testa sistematicamente a autorização de cada endpoint:

• BOLA cross-tenant — para cada endpoint que recebe ID/UUID, tentar acessar objeto do outro tenant trocando o ID. Aparece em ~85% dos SaaS B2B brasileiros que auditamos
• BFLA (Broken Function Level Authorization) — tentar chamar endpoints administrativos com token de usuário regular, endpoints de outro tenant com privilégio cruzado, fluxos de aprovação saltando passos
• BOPLA (Broken Object Property Level Authorization) — endpoint que aceita update parcial, tentar modificar propriedades sensíveis (role, plan, tenant_id, is_admin, billing_status)
• Mass assignment — em endpoints de criação/update, injetar campos extras no body que não deveriam ser editáveis pelo cliente
• Vertical privilege escalation — usuário regular tentando virar admin via manipulação de cookies, JWT, parâmetros de URL, ou abuso de fluxos de gestão de perfil
• Horizontal privilege escalation — usuário do tenant A conseguindo ler/editar dados específicos do tenant B (resources, files, contratos, configurações)

Esses padrões juntos representam os 5 itens do topo do OWASP API Security Top 10 em 2026 — e nenhum deles é detectável por scanner automatizado. Veja o detalhamento em BOLA, BOPLA e BFLA: as 3 falhas que dominam APIs em 2026.

Fase 3 — Exploração de lógica de negócio interna (35–45%)

Com autorização e isolation validados, o foco vira lógica de negócio — onde os bugs mais caros de fintech e SaaS B2B moram:

• Race conditions em endpoints financeiros (refund, saque, transferência, antecipação, resgate), cupom single-use, aprovação de transferência, mudança de plano, MFA bypass via OTP race
• Manipulação de fluxos multi-step — pular etapas de fluxo de compra/cadastro/aprovação, manipular estado para chegar em telas finais sem passar pelos checks intermediários
• Abuse de billing — manipular cupons, descontos, número de seats, downgrade após cobrança, double-upgrade race
• Webhooks e callbacks — SSRF em endpoints onde o cliente configura URL de webhook (atacante aponta para metadata interna, lateral movement)
• JWT em uso autenticado — algorithm confusion, kid path traversal, sessão eterna por exp ignorado, scope escalation, token reuse entre contextos
• Cache poisoning autenticado — fluxos onde cache compartilhado entre tenants ou usuários pode ser envenenado para servir dados de outro

Fase 4 — Encadeamento e demonstração de impacto (10–20%)

Com bugs individuais mapeados, o pesquisador encadeia o que faz sentido para demonstrar impacto máximo: BOLA + BFLA juntos viram tomada total de tenant, race em refund + BOPLA em endpoint de saldo vira drenagem de fundos, JWT algorithm confusion + reuse de scope vira admin master. Essa fase é o que diferencia “encontrou um BOLA” de “BOLA + BFLA + lógica de saldo = R$ X exposto” — contexto que vira priorização correta no time de engenharia.

O que Grey Box cobre bem

1. Autorização entre tenants (BOLA cross-tenant)

O caso de uso clássico de Grey Box. Com duas contas em tenants diferentes rodando em paralelo, o pesquisador testa cada endpoint da API sistematicamente trocando IDs entre as contas. Scanner não faz isso (precisa de múltiplas sessões coordenadas), Black Box não consegue (cobre só uma conta), e auditoria de checklist não pega (não simula o ataque). Grey Box é praticamente o único modo de validar isso adversarialmente.

2. Lógica de negócio interna autenticada

Todo o fluxo financeiro autenticado — refund, saque, antecipação, transferência, billing, cupom — cai em Grey Box. Mesmo o pesquisador externo testando como cliente real consegue encontrar race conditions, manipulação de parâmetros, downgrade attacks. White Box pega esses bugs lendo código, mas Grey Box pega rodando o sistema do jeito que o atacante real roda — incluindo bugs que aparecem em produção mas não estão visíveis no fonte (problemas de infraestrutura, configuração, timing).

3. APIs internas e endpoints não documentados

Em SaaS B2B típico, a documentação cobre 60–70% dos endpoints. O resto: endpoints internos para o frontend, endpoints administrativos esquecidos, endpoints v1/v2 paralelos, endpoints de jobs em background. Grey Box descobre esses endpoints por análise de tráfego (Burp como proxy do frontend autenticado) e testa cada um. Black Box não chega lá. White Box vê no código mas pode não avaliar comportamento em runtime.

4. Privilege escalation horizontal e vertical

Testar se usuário regular vira admin (vertical) e se usuário do tenant A acessa recursos do tenant B (horizontal) exige executar fluxos autenticados com múltiplas identidades — exatamente o que Grey Box configura. Esse vetor é onde muitos pentests de Black Box param na superfície e dão impressão de “limpo”, enquanto Grey Box revela os verdadeiros problemas.

5. Encadeamento credenciado

Chains internas — combinar BOLA + BFLA + race em fluxo financeiro pra demonstrar impacto encadeado — são natural em Grey Box porque o pesquisador tem o contexto necessário pra montar a sequência. Esse é o tipo de achado que gera priorização correta no time de engenharia: cada elo isoladamente é “médio”, mas a chain encadeada é crítica.

O que Grey Box NÃO cobre

Recon externo profundo

Subdomínios esquecidos, instâncias de staging expostas, painéis administrativos legados em endereços não-documentados, leakage em GitHub, S3 público — tudo isso é território do Black Box, não do Grey Box. O cliente entrega o escopo, e o pesquisador respeita esse escopo. Se algo importante está fora do escopo documentado, Grey Box não vai descobrir.

Bugs que exigem leitura de código

Padrões clássicos que só são detectáveis com acesso ao fonte: race condition fina em região não-óbvia do código, deserialização insegura em parsers internos, PHP Object Injection, gadgets de exploitation em libraries carregadas, padrões problemáticos de uso de ORM (queries sem tenant_id), TOCTOU em fluxos de aprovação. White Box pega tudo isso. Grey Box pega só o que manifesta em comportamento observável externamente.

Configurações de infraestrutura

Permissões IAM excessivas, buckets S3 mal configurados (que não estão expostos publicamente), segurança de containers, segmentação de rede interna, secrets em variáveis de ambiente — tudo isso requer acesso direto à infra. Grey Box vê apenas o que está atrás de API autenticada, não o substrato.

Cobertura completa para auditoria formal

Para SOC 2 Type II, ISO 27001, PCI-DSS Level 1, exigências do Bacen — auditorias formais costumam exigir combinação de Grey Box + White Box em áreas críticas. Grey Box sozinho não basta. Para essa categoria, programe ambas modalidades pelo menos uma vez por ano.

Quando contratar Grey Box

1. SaaS B2B estabelecido em produção

Esse é o caso de uso por excelência. SaaS B2B com base de clientes ativa, múltiplos tenants, fluxos autenticados ricos — Grey Box é a escolha que devolve mais cobertura efetiva por R$ gasto. Se você está rodando produção e ainda não passou por Grey Box, esse é o primeiro pentest a contratar.

2. Fintech com fluxos financeiros internos

Toda a complexidade financeira de fintech (cartão, conta digital, transferência, antecipação, resgate, billing, cupom, voucher) é autenticada e mora atrás do login. Grey Box é praticamente o único modo de validar adversarialmente esses fluxos. Para fintech, Grey Box é quase obrigatório antes de cada release importante.

3. Multi-tenant authorization auditing

Quando o objetivo específico é validar isolamento entre tenants — antes de fechar contrato enterprise grande, antes de auditoria de cliente, antes de anunciar feature de multi-organization — Grey Box focado em BOLA/BFLA é o modelo. Pode ser engagement de 40-60h específico, mais barato e direto que um Grey Box amplo.

4. Pré-due diligence e M&A

Em processos de venda de empresa ou captação Série A+, investidores exigem evidência de pentest sério. Grey Box gera relatório técnico denso o suficiente para satisfazer due diligence sem precisar abrir código (o que muitas empresas preferem evitar antes de assinar termsheet).

5. Após mudanças arquiteturais grandes

Migração de monolito para microserviços, troca de stack de auth (sair de sessão pra JWT, ou vice-versa), implementação de RBAC novo, mudança de modelo de tenancy — qualquer mudança que altere fronteiras de autorização exige Grey Box focado. Bugs novos aparecem nessas transições.

Quando NÃO contratar Grey Box

1. Quando o objetivo é validar superfície externa pura

Recon profundo, descoberta de subdomínios esquecidos, validação de exposição externa — Black Box é estruturalmente melhor para isso. Grey Box começa do escopo documentado e não procura fora dele.

2. Quando você tem orçamento para máxima profundidade técnica

Se o orçamento permite, White Box devolve cobertura 85–95% por preço apenas ~40% acima de Grey Box. Para áreas críticas — módulo de transações financeiras, auth core, API de billing — White Box é matematicamente mais eficiente em bugs-por-real-gasto, desde que você esteja confortável compartilhando código.

3. Quando você precisa de certificação formal pesada

SOC 2 Type II, ISO 27001, PCI-DSS Level 1, exigências do Bacen para instituições de pagamento — Grey Box sozinho costuma ficar abaixo do limiar de evidência exigido pelo auditor. Combine com White Box em áreas críticas para gerar o pacote completo de evidência.

Quanto custa Grey Box em 2026

Para o mercado brasileiro de SaaS B2B e fintech PME:

• Grey Box focado (40-60h): R$ 14.000 – R$ 22.000 — escopo específico (ex: só BOLA cross-tenant, só fluxo de billing, só uma API crítica). Adequado para validações pontuais ou retest pós-correção.
• Grey Box padrão (60-80h): R$ 20.000 – R$ 34.000 — escopo amplo de SaaS B2B típico, cobertura de autorização + lógica de negócio + fluxos financeiros + APIs autenticadas, relatório técnico + executivo. Esse é o engagement padrão da maioria dos pentests sérios.
• Grey Box estendido (120h+): R$ 36.000 – R$ 58.000+ — fintech com fluxos complexos, SaaS multi-produto, plataformas com múltiplos papéis e tenants em camadas, ou Grey Box anual amplo cobrindo toda a aplicação.

Para faixas de preço por porte/setor, veja Quanto custa pentest no Brasil em 2026 e Pentest por porte de SaaS B2B em 2026.

Combinando Grey Box com Black Box e White Box

A combinação típica que vemos em SaaS B2B brasileiro maduro:

• Anual: White Box completo cobrindo módulos críticos (auth core, financeiro, billing)
• Trimestral: Grey Box amplo focado em autorização + lógica de negócio (esse aqui é o ritmo padrão da maioria)
• Mensal/bimestral: Black Box leve em superfície externa (capturar deriva da superfície ao longo do tempo)

Essa cadência atinge ~85% de cobertura efetiva ao longo do ano por preço composto significativamente menor que 4 White Box trimestrais. O ponto chave: Grey Box é o backbone do programa de pentest contínuo, não evento único. White Box é o aprofundamento periódico. Black Box é a captura de mudanças entre ciclos.

O que fazer agora

1. Mapeie qual % da sua aplicação está atrás de auth. Se for > 60% (típico de SaaS B2B/fintech), Grey Box devolve mais ROI que Black Box.
2. Liste os papéis e tenants que você quer cobrir. Quanto mais variados, mais valor um Grey Box bem feito gera (multi-tenant + múltiplos roles = mais chains a testar).
3. Confirme se você tem ambiente de staging dedicado para o pentest. Grey Box em produção é viável mas mais arriscado; idealmente, ambiente equivalente isolado.
4. Considere a cadência: Grey Box recorrente é significativamente mais valioso que Grey Box único anual. Trimestral é o ritmo mais comum em empresas maduras.

Para entender o roadmap completo de segurança em SaaS, veja /seguranca-saas. Para o escopo técnico específico de pentest, veja /pentest-saas. Para fintech, veja /pentest-fintech.

Para os outros guias da série: Pentest Black Box (publicado ontem) e White Box (amanhã, fechando a trilogia).

Se já quer pular pra ação: solicitar pentest. NDA bilateral em 24h.