A CVV attack indicator of compromise (IOC) is any observable signal that card verification value data is being tested or abused at scale. The strongest IOCs are bursts of low-value authorization attempts, a high ratio of CVV mismatch declines, sequential card numbers inside one BIN, and repeated requests from a small pool of IP addresses, devices, or email domains.
What are the most common CVV attack IOCs?
- Velocity spikes: dozens or hundreds of authorization attempts per minute from one account, IP, or device fingerprint.
- Small-ticket totals: repeated $0.00 to $2.00 charges used to validate a card before resale or cash-out.
- CVV mismatch clustering: a high share of "CVV invalid" responses against card numbers that otherwise validate.
- Sequential or grouped PANs: card numbers that increment or repeat within the same bank identification number (BIN).
- Recycled identity data: the same email, phone, billing address, or user agent tied to many different card numbers.
- Geographic mismatch: cardholder country, IP geolocation, and billing address landing in three different regions.
- Retained CVV data: any stored or logged verification value after authorization is itself a compliance failure signal.
How do infrastructure IOCs differ from transaction IOCs?
Transaction IOCs appear in payment gateway and order management logs. They describe what the attacker attempted against the checkout flow.
Infrastructure IOCs describe how the attack was delivered. Watch for proxy, VPN, and Tor exit nodes, datacenter ASNs on residential-only storefronts, headless browser fingerprints, scripted form-fill timing, and disposable email domains.
The two sets together give you confidence. A single velocity spike can be a marketing promotion, but a velocity spike plus datacenter ASNs plus sequential PANs is an active card-testing campaign.
Which metrics reveal an active CVV attack?
- Authorization approval rate dropping while attempt volume climbs.
- Average ticket size falling sharply against the store's normal baseline.
- Unique card numbers per IP address or per device rising well above one.
- CVV mismatch rate climbing independently of AVS failure rate.
- Refund and chargeback ratio rising two to eight weeks later, after stolen cards are reported.
How should you respond when IOCs match?
- Rate limit or block the offending IPs, ASNs, and device fingerprints at the edge.
- Turn on step-up authentication such as 3-D Secure so issuers can challenge risky attempts.
- Notify your acquirer and the affected card issuers with timestamps and request identifiers.
- Audit your own checkout and any third-party scripts for skimming code that could be feeding the attacker.
- Preserve raw logs for at least the chargeback window, and document the timeline.
Is a CVV attack the same as a BIN attack?
No. A BIN attack enumerates card numbers to find which ones are live. A CVV attack goes one step further and tests the verification value against those numbers.
The two overlap in practice. Most carding operations run enumeration first, then validate the successful hits with small CVV-bearing authorizations.
Are CVV attack IOCs visible in real time?
Yes, if your gateway and fraud stack stream authorization responses rather than batching them nightly. Real-time decline reason codes are the fastest IOC source you have.
Most merchants detect a campaign 24 to 72 hours late because they review dashboards instead of alerting on CVV mismatch rate. Set a threshold alert and route it to a human.
What does a card-testing pattern look like in gateway logs?
It looks like rhythm. Requests arrive at even intervals, from a narrow set of user agents, always hitting the smallest possible order total.
Card numbers often share a BIN prefix, and the billing zip or email changes while the device fingerprint stays fixed. Attackers rotate one identifier at a time, not all of them.