Short answer

A CVV attack indicator of compromise is any log artifact that shows someone validating stolen card data at scale. The reliable ones cluster: many card numbers tried from a few IPs, or one card number tried from many IPs, high CVV mismatch rates, tiny authorization amounts, and declines that spike inside a short window. Look for the pattern, not a single event. One failed CVV check is a typo. Four hundred in ten minutes from the same ASN is an attack.

What a CVV attack actually is

Attackers rarely guess CVVs. The three digit code has too little entropy for brute force to pay off, and issuers kill a card after a handful of wrong attempts. What happens instead is enumeration: someone buys a batch of card records and needs to know which ones still work. They run a small authorization, often under a dollar, and watch whether the issuer approves it and whether the CVV check passes. Cards that pass get resold or used for a bigger purchase. Cards that fail get discarded. From your side of the terminal it looks like a burst of checkout traffic that mostly declines.

Card testing vs enumeration vs BIN attacks

People use these terms loosely. BIN attacks generate numbers from a bank identification number prefix. Enumeration tests existing records. Card testing is the merchant-facing step where either one hits your payment form. Your IOCs are the same for all three because your logs only see the last step.

Network and transport IOCs

  • Request volume from a single IP or /24 that far exceeds your normal checkout rate.
  • One card number or PAN prefix showing up across dozens of IPs, which points to a distributed test.
  • Datacenter ASNs and hosting ranges hitting a consumer checkout page. Residential proxies show up too, but hosting ASNs are the cheap option and they leak.
  • Geo mismatch between IP country, billing country, and the card BIN country.
  • Identical TLS fingerprints or user agent strings across many sessions, especially old or uncommon browsers.
  • Requests that arrive without a referrer, without a prior page view, or faster than a human could read the form.

Application and order IOCs

  • Authorization amounts clustered at the minimum, like $0.00, $0.01, or $1.00.
  • CVV result codes skewed toward mismatch while AVS results stay mixed, which is what a stale data dump looks like.
  • Many distinct card numbers against a small set of email addresses, phone numbers, or shipping addresses.
  • Email domains that are disposable, or addresses that follow a pattern like a name plus digits.
  • Checkout sessions where the payment fields are filled in one burst with no mouse movement or field focus events.
  • Failures followed by instant retries with a different card on the same session token.
  • Decline rate per session above roughly 80 percent with several attempts.

Processor-side signals

Your acquirer sees things you do not. Watch the ratio of CVV mismatch declines to total authorizations by day. A sudden jump of a few points on stable volume is worth a look. So is a rise in do-not-honor responses across many BINs, and a widening gap between authorization count and settled transaction count. If your processor offers a fraud score or a velocity rule, put the threshold low for a week and read the false positive rate before you tune it.

Where to look in your logs

Pull authorization response codes, CVV and AVS result fields, IP, user agent, session ID, email, and cart total into one table with timestamps. Group by card BIN and by IP subnet, then count. Most real attacks fall out of a two minute query. If your payment provider only returns an approve or decline flag and no CVV result code, ask for the raw response. Without it you are guessing.

False positives worth knowing

Shared corporate NAT can look like one IP running hundreds of cards. Gift card resale and prepaid card buyers produce odd BIN mixes. Some legit customers fat-finger the CVV twice and retry. A test harness or a QA environment pointed at production will spike your volume too. Check account age, order history, and whether the suspect IP resolves to your own infrastructure before you block anything.

Response checklist

  1. Rate limit or challenge the offending IPs and subnets. Prefer a challenge over a permanent block so you do not lock out shared networks.
  2. Turn on or tighten CVV and AVS rules in your gateway, and require both to match for orders under your test amount threshold.
  3. Add a velocity rule per card, per email, and per IP that trips on counts, not amounts.
  4. Review settled orders from the same BIN range for the past 48 hours, since some tests succeed.
  5. Report confirmed card testing to your acquirer. They can see cross-merchant patterns you cannot.