CVV attack log analysis is the work of reading authorization, gateway, and web server logs to find card-testing traffic before it turns into chargebacks. A CVV attack, often called card enumeration or a BIN attack, appears as many small authorization attempts spread across many card numbers but coming from a small set of IPs and devices. The point of the analysis is to confirm the pattern, measure its size, and cut it off.

Prerequisites

  • Gateway and processor authorization logs with timestamps normalized to UTC
  • Web server or WAF logs covering the same time window
  • Order and account records for the same period
  • A query tool or spreadsheet that can group by IP, BIN, and email domain
  • Authority to pause payment endpoints and contact your acquirer

How to Analyze the Logs

  1. Pull the window. Export authorization logs for the last 30 days plus the 7 days before the earliest suspected attempt so you have a baseline for comparison.
  2. Normalize the fields. Keep timestamp, IP, card BIN, response code, order value, email, and user agent. Remove full card data from the working copy.
  3. Group by response code. Count declines by code. A spike in CVV mismatch or do-not-honor responses inside a short window is the first sign.
  4. Rank IPs by attempt count. Sort by the number of distinct card numbers per IP. Automated attacks push many cards through few addresses.
  5. Rank BINs. Count attempts per BIN. One BIN or a narrow BIN range holding most of the traffic points to an enumeration run.
  6. Check timing. Plot requests per minute. Scripted traffic holds a steady rate while real shoppers arrive in irregular bursts.
  7. Compare order values. Card testing leans on small or minimum amounts. Flag clusters of identical low values.
  8. Cross-check account data. Look for disposable email domains, sequential addresses, and accounts created within the same hour.
  9. Match against web logs. Confirm the source IPs hit the checkout or payment endpoint directly without browsing product pages first.
  10. Size the exposure. Count approved attempts as well as declines. Approved attempts are the ones that become chargebacks.

Signals That Separate an Attack From Normal Traffic

  • Many card numbers, few IPs or devices
  • High decline rate inside a narrow window
  • Uniform intervals between requests
  • Low and repeated order values
  • No session history before the checkout step
  • Traffic that ignores site navigation entirely

What to Do After Triage

  1. Block or rate-limit the source IPs and ASNs at the edge.
  2. Add a CAPTCHA or device check to the payment step.
  3. Tighten velocity rules on attempts per IP, per email, and per device.
  4. Require CVV and AVS checks on every attempt.
  5. Notify your acquirer and processor with the timestamps and counts.
  6. Void or refund approved test orders before shipment.
  7. Preserve the raw logs and hash them as evidence.
  8. File a complaint with the FBI Internet Crime Complaint Center.
  9. Review PCI DSS log retention requirements and confirm 12 months of history is available.
  10. Re-run the analysis weekly for a month to confirm the traffic has stopped.