What Your WAF Misses: Card Cracking

OWASP Automated Threat OAT-010 | Part 4 of 10

Most payment teams treat a spike in declined transactions as a processor problem. Most security teams treat it as noise. By the time either team recognizes the coordinated card cracking campaign running against their checkout, the attacker has already moved on, having extracted everything they came for.

That's the nature of OWASP OAT-010 Card Cracking. It's quiet by design. And the tools most organizations rely on to stop it are watching the wrong thing.

What is OAT-010 card cracking?

Card cracking is a brute force attack against payment card validation processes. The goal is to identify missing values for stolen card data, specifically the card security code (CVV/CVV2/CVC), expiration date, or both, by systematically testing combinations through your application's payment flows until one succeeds.

Here's the starting condition: the attacker already has partial card data. Primary Account Numbers (PANs) are widely available on dark web marketplaces, acquired through breaches, skimming operations, phishing campaigns, or purchased wholesale from fraud ecosystems. PCI DSS prohibits merchants from storing CVV codes post-authorization, which means breach data frequently includes the PAN but not the security code. Expiration dates, while stored, are sometimes absent or stale. The attacker's problem is a math problem: only 1,000 possible CVV combinations exist for any given card. A small enumeration space is trivially solvable with automation.

So the attacker builds a bot, or rents one from a crimeware-as-a-service platform, and starts guessing. They submit payment attempts against checkout pages or payment APIs, cycling through possible CVV values and date combinations using the stolen PAN as the anchor. Each declined transaction returns a signal: a CVV mismatch tells them to try again; an AVS failure tells them something different; an approval tells them they're done. The payment processor's response codes become a feedback mechanism for the attack.

When the missing values are found, the attacker moves up the kill chain. A completed card record (PAN, expiration date, CVV) feeds directly into OAT-001 Carding (validating full card details with small test purchases) and then OAT-012 Cashing Out (converting validated cards into goods, gift cards, or cash). Card cracking isn't the end of the fraud. It's the beginning.

The business impact lands in multiple places simultaneously. Every brute-force attempt hitting your checkout triggers processor fees. Even failed transactions cost money. Successful cracks lead to chargebacks you're liable for, often weeks after the attack. Excessive decline rates can flag your merchant account as high-risk, triggering higher processing fees or processor review. And beyond the direct financial exposure, there's regulatory surface too. Depending on your jurisdiction, facilitating card enumeration can create GDPR and PCI DSS compliance complications, even as the victim.

Card cracking affects roughly one in three global e-commerce merchants. Also called card testing or credit card cracking, it peaks during high-traffic events like Black Friday and major sale cycles, precisely because the noise floor of legitimate transaction volume makes anomalous activity harder to detect. The attacker knows this. They time their campaigns accordingly.

How card cracking moves through the stack

Understanding why this attack is so difficult to stop requires following it through the actual request path.

The attacker's bot makes a POST request to your checkout or payment API endpoint, the same endpoint your legitimate customers use. The request looks structurally correct. It contains a valid PAN, a plausible expiration date, and a guessed CVV. The HTTP headers may be spoofed to mimic a browser session. The User-Agent is generic. The IP address routes through a residential proxy pool, making it appear to originate from a real consumer device in a real location. From a network perspective, this is indistinguishable from a customer entering their card details.

The request reaches your WAF. The WAF inspects it. There's no SQL injection. No XSS payload. No malformed header. No signature match. The request body is well-formed JSON or URL-encoded form data. The WAF passes it through.

The request reaches your application layer. Your application receives the payment data, validates it against any client-side checks, and forwards it to your payment processor or payment gateway via API. The processor runs the transaction. The CVV doesn't match. The processor returns a decline with a specific response code. Your application returns a failure response to the bot.

The bot logs the response, increments the CVV counter by one, and sends the next request. This happens thousands of times per minute, distributed across rotating IP addresses and session identifiers to stay below per-IP thresholds.

The meaningful information exists only in the combination of application behavior and payment processor responses: whether a CVV guess was correct, whether the card is valid, which BIN ranges are being targeted. A WAF sitting at the network perimeter sees the request. It doesn't see the processor response. It can't correlate the pattern of attempts across sessions. It can't see that 847 requests this hour share the same BIN prefix, spread across 23 different IP addresses, each hitting the same endpoint with incrementing CVV values. That correlation only exists at the application layer, across multiple requests, over time.

Low-and-slow campaigns make this worse. Sophisticated attackers deliberately throttle their request rate to stay below velocity thresholds, dropping to a few attempts per minute per IP, distributed across many IPs, producing an aggregate attack volume that no single threshold-based rule will catch. The payment processor sees repeated declines. The security team sees nothing actionable.

What happens when a card cracking alert fires

Assume your monitoring eventually catches something. Maybe your payment processor sends an alert about elevated CVV failure rates. Maybe someone notices an anomalous decline spike in your operations dashboard. Maybe a fraud analyst manually reviews the logs and spots the pattern. An alert fires.

Now the real problem begins.

Your WAF doesn't have the context to act. The WAF's visibility ends at the request level. It doesn't have access to payment processor response codes. It doesn't know which requests resulted in CVV mismatches versus legitimate declines. It can't reconstruct the behavioral pattern because it wasn't tracking session continuity across distributed IPs. To write a WAF rule that blocks this attack, you'd need to know what to block, a specific IP range, a specific User-Agent, a specific PAN format, but by the time you've identified those attributes, the attacker has already rotated their infrastructure.

So the response becomes manual. Someone pulls logs from your payment processor. Someone else queries your application logs. A third person tries to correlate the two datasets to identify which IP addresses, device fingerprints, or session tokens were involved in the attack. This investigation takes hours. In most organizations, it takes days. During that investigation, the attack continues.

When you finally have a candidate IP list or a behavioral signature, you take it to whoever owns the WAF policy. You file a change request. The change goes through whatever approval process your organization requires, because pushing an unreviewed rule to production infrastructure is how you cause outages. The rule eventually gets deployed. The attacker, who has been running automated tooling since day one, has long since rotated their source addresses. The rule blocks nothing.

Meanwhile, the chargebacks start arriving. Payment processors typically surface fraud disputes 30 to 60 days after the underlying transactions. By the time your finance team is processing chargebacks and tracing them back to this attack, the incident is ancient history from an operational standpoint. The enforcement gap isn't just technical. It's temporal. The attack happens in real time. The response happens in retrospect.

There's also a risk asymmetry that makes enforcement harder even when you have good signal. Your checkout is a revenue-critical path. A rule that's too aggressive will catch legitimate customers with genuine payment difficulties and block them from completing purchases. A false positive at checkout isn't just an inconvenience. It's measurable lost revenue, and it will get pushed back by the business. So security teams make their rules conservative. And conservative rules miss the attack.

What we see when detection and enforcement share a request path

The fundamental problem with WAF-based approaches to card cracking isn't rule quality or detection sophistication. It's position. A WAF sits outside the application, watching requests before they hit your code. Card cracking is an attack that only becomes legible through application behavior: how your payment flow responds, what your processor returns, how those responses correlate across sessions and time. That signal doesn't exist at the network perimeter. It exists inside the request path.

Impart operates inside the application's request path. This matters for card cracking in specific, concrete ways.

First, Impart can observe both the inbound request and the application's response, including payment processor outcomes. When a CVV failure response comes back from your payment gateway, Impart sees it. When the same BIN prefix appears across 200 requests in the past 90 minutes with a failure rate of 98%, Impart sees that pattern forming in real time, not in a log review 48 hours later. The behavioral signal that makes card cracking detectable is exactly what Impart is built to observe: high-velocity failures against a constrained enumeration space, distributed across IPs but correlated by PAN, BIN, or session behavior.

Second, Impart enforces in the same place it detects. There's no gap between "we know this is an attack" and "we can do something about it." When Impart identifies card cracking behavior, it can act on the next request: challenge it, block it, or return a response that degrades the attacker's signal quality without impacting legitimate users. That enforcement happens automatically, inline, without requiring a ticket to a WAF admin, a change control process, or a rule deployment that takes three days.

Shadow mode changes the economics of getting this right. Impart deploys first in an observational posture, watching live traffic, identifying what card cracking attempts look like against your specific payment flows, and building decision evidence before enforcement goes live. Security teams can review exactly what Impart would have blocked, validate that the signal is real and the false positive rate is acceptable, and then enable enforcement with confidence. This is how you solve the risk asymmetry at checkout: you don't guess at what a rule will do. You watch it against real traffic first.

The enforcement surface also extends beyond IP addresses and User-Agent strings. Because Impart operates at the application layer with full request context, it can target attacker behavior by any attribute in the request path: session tokens, payment card BIN ranges, behavioral timing patterns, response correlation patterns. When attackers rotate IPs, those other attributes often persist. The enforcement can follow them.

Card cracking is fundamentally an abuse-of-functionality attack. It doesn't exploit a vulnerability in your code. It exploits the intended behavior of your payment validation flow, using it as an oracle to enumerate card data. Traditional security tooling is designed to find code-level vulnerabilities and block known-bad signatures. It has no model for "this is legitimate functionality being used at machine speed to extract information." Impart does. That's the difference between a security tool that watches your application and one that understands it.

See what you would block before you block it

Impart closes the enforcement gap for card cracking and all 21 OWASP automated threats. Shadow mode against live traffic. Full decision evidence. Enforcement when you're ready.

OWASP Deep Dive Series
This post is part of a 10-part series examining how OWASP automated threats expose the gap between detection and enforcement, and what changes when both move into the application's request path.