When we talk about PCI DSS compliance, the conversation tends to stay clinical. Scoping exercises. Network diagrams. Encryption at rest. But compliance doesn’t exist in a vacuum. It exists because there’s a thriving, industrialized criminal economy on the other end waiting to monetize every gap you leave open.
Rapid7 published a detailed piece of research this month that every QSA, security engineer, and compliance leader should read: their analysis of the carding-as-a-service (CaaS) ecosystem and the underground dump shops that power it. Having spent years on the assessor side of PCI, I want to connect what Rapid7 found directly back to what it means for your cardholder data environment and your scoping decisions.
The Underground Runs Like a Business, and It Shows#
Let’s start with the uncomfortable part.
The dump shops Rapid7 profiled (Findsome, UltimateShop, Brian’s Club) aren’t scrappy hacker forums. They’re polished marketplaces with search filters, refund policies, deposit bonuses, and reseller networks. Findsome had 51 active resellers in the second half of 2025. UltimateShop offers zero-dollar minimum deposits to reduce barriers to entry. Brian’s Club has been operating since 2014 and sells dumps, CVVs, fullz, and Track 1 cloning data at prices up to $49 per record.
These platforms let buyers filter stolen card data by BIN, country, issuing bank, and card brand. They offer validity checkers so buyers can test cards before use, and refund windows if the data turns out to be dead. Findsome even accepts Litecoin and Zcash alongside Bitcoin.
The point isn’t to sensationalize. It’s to understand what you’re defending against. This isn’t opportunistic crime. It’s a supply chain with suppliers, aggregators, quality assurance, and customer service. And the data they’re selling came from somewhere.
Where the Cards Come From (And Why It Matters for Scope)#
Rapid7 identified four primary acquisition channels feeding these marketplaces:
Phishing-as-a-Service (PhaaS): Turnkey phishing platforms that handle infrastructure, page design, and credential collection. That’s why PCI DSS 4.0.1 Requirement 5.4.1 now mandates phishing-awareness training and mechanisms for staff to verify sender identity. If your organization handles card data and your people can’t spot a phishing page, you’re a potential supplier to these dump shops.
Physical skimmers and shimmers: Devices attached to ATMs, gas pumps, and POS terminals that capture magnetic stripe or EMV chip data. The Rapid7 report notes that specialized stores sell and ship these devices openly, lowering the bar for entry. That’s the threat model behind Requirement 9’s physical access controls and Requirement 11.2.1’s rogue wireless detection, even if you don’t use wireless in your CDE.
POS malware: Variants like BlackPOS and MajikPOS that scrape card data from retail systems in memory. This has been a known vector since the Target breach in 2013, and it’s why Requirements 5 and 6 around malware protection and secure software development exist. If you’re running payment applications, your patching cadence and runtime protections aren’t just compliance checkboxes. They’re the difference between your customers’ card data staying in your environment or ending up on Findsome.
Payment page script injection (XSS/e-skimming): Malicious JavaScript injected into payment pages to capture card data in the browser. That’s the exact threat that drove one of PCI DSS 4.0’s most debated new requirements, Requirement 6.4.3, which mandates controls for all payment page scripts executed in consumers’ browsers and requires monitoring for unauthorized modifications at least every seven days.
Each of these vectors maps directly to specific PCI DSS requirements. That’s not a coincidence. The standard exists because these attack paths exist.
What This Means for Your Scoping Exercise#
Here’s where my QSA instincts kick in. If you’re doing a PCI DSS scoping exercise (and under Requirement 12.5.2, you must validate scope at least annually, or every six months if you’re a TPSP), this research should change how you think about a few things.
Your scope is defined by the attacker, not your architecture diagram#
Most organizations scope their CDE based on where they intend card data to flow. But the underground economy tells us that card data often ends up in places it was never supposed to be, scraped from memory by POS malware, captured by a compromised JavaScript library on a payment page, or intercepted by a shimmer on a terminal you assumed was physically secure.
Requirement 12.10.7 now requires you to initiate your incident response plan if you find unencrypted PAN where it shouldn’t be. The implication’s clear: the PCI Council expects that this will happen, and they want you actively looking for it. Your scoping exercise should include not just “where does card data flow by design?” but “where could card data end up if a control fails?”
E-skimming makes your website part of the CDE whether you like it or not#
The explosive growth in payment page script attacks is directly reflected in the Rapid7 findings. Underground forums openly share sniffer code and instructions for injecting it into payment pages. Requirement 6.4.3’s mandate to inventory and monitor all scripts on payment pages isn’t theoretical. It’s a response to an active, documented attack vector that feeds the dump shops profiled in this research.
If you’re an e-commerce merchant and you haven’t implemented script monitoring on your payment pages yet, you’re operating on borrowed time. The March 31, 2025 deadline for this requirement has passed, and assessors are now validating it.
Third-party risk is supply chain risk (in both directions)#
The CaaS model runs on resellers. Findsome doesn’t steal card data directly. It aggregates stolen data from dozens of third-party suppliers. Sound familiar? Your own payment ecosystem likely involves multiple third parties: payment processors, gateway providers, hosting companies, JavaScript libraries, analytics platforms.
PCI DSS 4.0.1 significantly expanded the requirements around third-party service provider (TPSP) management. If a third party is compromised and your customers’ card data ends up in a dump shop, “we outsourced that” isn’t a defense. Requirement 12.8 and its sub-requirements exist precisely because of this reality. You need to know who your third parties are, what they have access to, and how they’re protecting it.
Tokenization and de-scoping aren’t optional strategies anymore#
When individual card records sell for $4 to $49 on these marketplaces, and the volume is measured in hundreds of thousands of records per reseller, the economics of card theft make every stored PAN a liability. The most effective defense isn’t just locking down your CDE more tightly. It’s reducing the CDE itself.
Tokenization, point-to-point encryption (P2PE), and architectural decisions that keep raw card data out of your environment entirely are no longer “nice to have” optimizations. They’re the most practical way to make your organization a less attractive target. If there’s no card data to steal, there’s nothing to sell on Findsome.
The Numbers That Should Keep You Up at Night#
A few data points from the Rapid7 research worth sitting with:
Visa cards make up 60.4% of leaked card data across these marketplaces, followed by Mastercard at 32.3%. This distribution skews heavily toward the US market, where the majority of victims originate. If you’re a US-based merchant or processor, your customers’ cards are disproportionately represented in these shops.
The highest volume of stolen card data appeared in November and December, right in the middle of shopping season. Black Friday and Cyber Monday aren’t just high-traffic events for legitimate commerce. They’re high-traffic events for the criminal supply chain too. Your security posture during peak transaction periods matters more than you might think.
Most stolen card records are bundled with additional PII, including email addresses, phone numbers, and sometimes SSNs. UltimateShop listings included supplemental personal data 99.4% of the time. This means a card breach isn’t just a card breach. It’s an identity theft event, and it expands the regulatory and reputational impact well beyond PCI DSS.
So What Do You Actually Do?#
If you’re a security or compliance professional reading this, here’s where I’d focus:
Treat threat intelligence as a scoping input. Your annual scope validation under Requirement 12.5.2 should incorporate current threat intelligence about how card data is stolen and monetized. If your scoping exercise doesn’t account for e-skimming, POS malware, and phishing-as-a-service, it’s incomplete.
Get serious about Requirement 6.4.3. Payment page script monitoring is the control that most directly addresses the e-skimming pipeline feeding these dump shops. If you haven’t implemented it, make it your top priority.
Pressure-test your third-party oversight. Map your third-party relationships against the acquisition vectors in this research. Which of your vendors could be a path for card data exfiltration? Are you actually reviewing their AOCs, or just collecting them?
Minimize your footprint. Every system that touches raw card data is a potential source for the underground market. Reduce your CDE surface area through tokenization, P2PE, and architectural choices that eliminate unnecessary card data storage.
Run tabletop exercises against this specific scenario. What happens if you discover your customers’ card data listed on a dump shop? Do you know how to respond? Does your incident response plan under Requirement 12.10 cover it?
The Compliance-Threat Intelligence Gap#
The broader takeaway here is that there’s a persistent gap between how we do compliance and how the underground does crime. The criminals are running an optimized, service-oriented operation. Too many compliance programs are still running annual checkbox exercises.
PCI DSS 4.0.1 is pushing hard toward continuous security: targeted risk analyses, ongoing script monitoring, regular scope validation. That shift in the standard is a direct acknowledgment that the threat environment is continuous, not annual.
The Rapid7 research makes the threat tangible. These aren’t abstract risks in a risk register. They’re active marketplaces with inventory, pricing, and customer support, processing stolen card data at scale every single day. Your PCI compliance program should be built with that reality in mind.
The Rapid7 research referenced in this article, “Carding-as-a-Service: The Underground Market of Stolen Cards,” was published on February 12, 2026. I’d recommend reading the full report if you’re involved in PCI compliance, incident response, or threat intelligence.
