Answer first
A CVV attack log is the record of a burst of card verification attempts fired at your checkout, usually with stolen or generated numbers. The analysis job is narrow: tell that burst apart from ordinary declines, count how many attempts got approved, and shut the door before the next wave. You are not profiling cards. You are profiling request patterns.
CVV Attack Log Study Buying Guide
Most merchants find out after a chargeback notice. By then the log already had the answer in it, sitting in the response codes and the timing.
Fields you need in the log
If your gateway payload is thin, analysis turns into guessing. I want these columns before I start:
- Timestamp with an explicit timezone, plus a request ID that ties to the gateway's own record
- Masked card reference, BIN, BIN country, and last four digits
- Source IP, ASN, and whether that ASN is a hosting or VPN provider
- User agent, TLS or JA3 fingerprint, and any device ID your fraud vendor returns
- Email address and email domain
- Billing country, IP country, and shipping country if collected
- Amount and currency
- Gateway response code, plus the separate CVV and AVS result codes
- Session ID and a retry counter per session
- Round-trip latency to the authorization call
The response body matters as much as the code. A decline of "CVV mismatch" repeated across two hundred different cards in ten minutes is a very different story from two hundred "insufficient funds" declines.
Signals that separate an attack from normal declines
Normal decline traffic is boring and scattered. Attack traffic is clustered. I look for:
- Velocity per IP and per device. A residential IP hitting the card field twenty times in a minute is not shopping.
- Sequential or Luhn-valid card numbers. Generated PANs often run in order within a BIN range.
- BIN spread. One source cycling through dozens of BINs is enumeration, not a customer with a wallet full of cards.
- Amount clustering. Attempts pinned at a low fixed value, often under a dollar, to test whether the card is live.
- Missing funnel steps. No product page, no cart, no address step. The session lands on the payment form and nothing else.
- Response code skew. A sudden run of CVV mismatches or "invalid card" codes that does not match your baseline distribution.
- Datacenter ASNs and headless user agents. Not proof on their own, but they raise the score when combined with velocity.
- Approvals mixed in. The dangerous part of the log is the small number of successes hiding inside the failures.
A parsing workflow that holds up
- Pull raw web logs and gateway responses side by side, joined on request ID. Do not work from the dashboard summary alone.
- Normalize into one table with consistent field names, then filter to authorization attempts on the card verification endpoint.
- Group by IP and by /24 block, by device fingerprint, by email domain, and by BIN. Grouping by one dimension hides the pattern.
- Rank each group by attempt count and, separately, by approval count. The approval ranking is the one that gets escalated.
- Compare the burst against your own baseline decline rate for the prior two weeks. A spike only means something relative to normal.
- Export the approved attempts with order IDs and hand them to fulfillment and risk before anything ships.
The whole pass takes an hour on a mid-size store. Doing it weekly is cheaper than doing it after a fraud report.
Containment after the read
Log analysis without a follow-through is paperwork. Once a cluster is confirmed, I rate limit the card verification endpoint per IP and per device, block the hosting ASNs involved, and require 3D Secure on any session that shows the attack fingerprint. Then I re-check the approval list and refund or hold what slipped through.
Rule tuning comes after that, not before. Tightening velocity limits during an active attack just teaches the attacker to slow down below the threshold.
Metrics worth tracking
- Authorization attempts per hour, split by endpoint
- Approval rate during the burst versus the trailing average
- Unique BINs per source, and mean attempts per card reference
- Time from first suspicious request to block
- False positive rate on the blocklist, reviewed monthly
Mistakes I see often
Blocking on IP alone is the classic one, because the attacker rotates addresses and the rule catches shared mobile carriers instead. Ignoring the gateway response body is another; the code alone rarely tells you what happened. And quiet log retention is a compliance problem as well as an investigative one. PCI DSS expects audit trails kept for at least a year, with the recent three months ready to query. If your retention window is fourteen days, you will lose the evidence you need for the chargeback rebuttal.