Answer first

A CVV attack shows up as a burst of authorization requests that fail the CVV check across many card numbers. The signature sits in three places: the request stream (many PANs, few devices), the response stream (CVV mismatch codes at a rate far above baseline), and the timing (flat intervals, small ticket sizes). You cannot see any of it without per-request logging of PAN hash, BIN, response code, IP, device ID, and timestamp.

detecting cvv attack signatures

Signatures in the request stream

  • Many distinct PANs from a small set of IP addresses or device IDs.
  • BIN concentration: 80 percent or more of attempts on one issuer range.
  • Sequential or near-sequential PANs, or PANs that fail the Luhn check before the gateway rejects them.
  • Ticket amounts from $0.00 to $1.00, or repeated identical amounts.
  • Missing or mismatched AVS data while the CVV field is always populated.
  • Uniform user agents, or a user agent that does not match the device fingerprint.

Signatures in the response stream

Track the ratio of CVV mismatch responses to total authorizations per source. A merchant baseline sits near 1 to 3 percent. A card testing run pushes that to 30 percent or higher in minutes. Watch for these response patterns:

CVV Signature Identification: Where the Code Sits on a Card

  • A high count of "invalid CVV" or "CVV failure" codes with a low count of approvals.
  • Approvals clustered on a small subset of BINs while other BINs fail at 90 percent.
  • "Do not honor" bursts that follow a wave of CVV failures. This points to issuer-side blocking.
  • Retry loops: the same PAN submitted three to five times inside 60 seconds.

Timing and velocity signals

Human buyers do not submit 40 authorizations per minute from one session. Measure requests per IP, per device, per session, and per card BIN over 1 minute, 10 minute, and 60 minute windows. Attacks show flat gaps between requests, often 200 to 900 ms, with low variance. Legitimate traffic has high variance.

read more

What to log

  1. Timestamp with millisecond precision.
  2. Hashed PAN (SHA-256 with a salt), plus first six and last four digits.
  3. Issuer BIN and card brand.
  4. Authorization response code and CVV result code as separate fields.
  5. IP address, ASN, and country-level geolocation.
  6. Device fingerprint, user agent, and session ID.
  7. Ticket amount and currency.

Keep raw PANs and CVV values out of logs. PCI DSS Requirement 3 covers storage limits on sensitive authentication data.

more on this topic

Response steps

Block on the source first, then on the pattern. Rate limit per IP and per device ID. Add a CVV failure counter per BIN and per session. Send sessions that hit the threshold to a step-up check. Report confirmed card testing to your acquirer and to the card brand fraud desk. In the US, file a complaint with the FBI IC3 when volume crosses your incident threshold.