CVV Attack IOCs: How to Spot Card Testing Fraud

A CVV attack IOC is a measurable signal that someone is testing card numbers and CVV codes against a payment system. Common indicators include bursts of failed authorizations, many card numbers tied to one IP or device, and small test charges. These signals appear in gateway logs, fraud dashboards, and server records.

What Is a CVV Attack?

A CVV attack is a card testing method that submits card numbers with guessed or stolen CVV codes to find working cards. The CVV is the 3-digit code on the back of Visa, Mastercard, and Discover cards, or the 4-digit code on the front of American Express cards. Attackers use bots to send many authorization requests in a short window.

The goal is not a large purchase. The goal is to confirm which card numbers are live before reselling them or using them for fraud. A successful test often shows as a $0.00 or $1.00 authorization.

Top CVV Attack IOCs

Watch for these indicators in your payment and web logs. One signal alone can be noise. Two or more together raise the risk.

• Authorization velocity spike: Dozens of auth attempts from one IP, device, or email in minutes.
• Clustered CVV mismatch declines: A high share of declines with CVV failure codes from one source.
• Many PANs, one fingerprint: Different card numbers share a device ID, browser cookie, or shipping address.
• Low-value test charges: $0.00, $0.01, or $1.00 authorizations that repeat before a larger attempt.
• Sequential or patterned PANs: Card numbers that follow a visible pattern within a BIN range.
• Geo mismatch: IP country does not match the card's issuing country or billing address.
• AVS pass with CVV fail: The address matches but the CVV does not, repeated across cards.
• Headless browser signals: Missing headers, odd user agents, or automation flags at checkout.
• Account churn: New accounts created in bulk, each used for one checkout attempt.

Where CVV Attack IOCs Show Up in Logs

You do not need a new tool to find these signals. Start with fields your gateway already records.

• Authorization response code and decline reason.
• CVV result code and AVS result code.
• Timestamp with second-level precision.
• IP address, device ID, and user agent string.
• Card BIN, last four digits, and issuing country.
• Email address, account ID, and shipping address.

Group these fields by source. A single source with 40 CVV failures in 10 minutes stands out fast.

How to Confirm a CVV Attack

Use a short investigation flow. Pull data first, then act.

1. Export failed authorization logs for the last 24 hours.
2. Group records by IP address, device ID, email, and BIN.
3. Count declines by reason code. Look for CVV mismatch codes.
4. Compare the rate to your normal daily baseline.
5. Check if the same sources made successful low-value charges.

If one source shows 50 failed CVV checks in an hour and your baseline is 5, that is a strong IOC. If those attempts also share a device ID, treat the source as hostile.

Baseline Metrics to Track

Detection works better with a baseline. Track these numbers each day.

• Auth attempts per IP per hour.
• Overall decline rate and CVV mismatch rate.
• Unique PANs per device ID.
• Average ticket size by source.
• New account creation rate before checkout.

A sudden jump in any metric is a prompt to look closer. A jump across two or more metrics is a likely attack.

CVV Attack vs Card Testing vs BIN Attack

The terms overlap but are not the same. Use this guide to sort alerts.

• Card testing: A broad term for any attempt to validate stolen card data.
• CVV attack: A card testing attack that focuses on the CVV code.
• BIN attack: An attack that guesses full card numbers within a bank identification number range.

A CVV attack can be a BIN attack if the attacker also generates PANs. The shared trait is high-volume authorization attempts with a high failure rate.

False Positives to Rule Out

Not every spike is fraud. Check these cases before you block a source.

• Corporate NAT or VPN that sends many real buyers through one IP.
• Shared family devices with multiple saved cards.
• Travelers whose IP country differs from their card's issuing country.
• Retry loops from a broken checkout page.

Look for a mix of successful and failed attempts in these cases. A pure failure stream from one source is a red flag.

What to Do When You See These IOCs

Respond in layers. Start with controls that stop the bot without blocking real buyers.

• Add rate limits to the checkout and authorization endpoints.
• Turn on CAPTCHA or a challenge for suspicious sessions.
• Block the source IP and device ID at the edge.
• Require 3-D Secure for risky transactions.
• Alert your acquirer or payment processor with the log evidence.
• Review recent orders from the same source for fraud.

Do not rely on a single control. Attackers rotate IPs and device IDs. Rate limits, velocity checks, and CVV rules work best together.

Frequently Asked Questions

What is the most reliable CVV attack IOC?

A cluster of CVV mismatch declines from one source is the strongest single signal. It links the failed checks to the same actor.

Can a CVV attack succeed without the correct CVV?

No. A payment authorization fails if the CVV is wrong. Attackers need the correct code, which is why they test many combinations.

How fast does a CVV attack run?

Bots can send hundreds of attempts per minute. Small attacks can finish before a manual review starts.

Do CVV attacks always use stolen cards?

Not always. Some use generated card numbers. The IOC pattern is the same: many attempts, high decline rate, shared infrastructure.

Key Takeaways

• CVV attack IOCs are signals of card testing, not proof of a breach.
• Velocity, CVV decline clusters, and shared device IDs are the core indicators.
• Confirm with logs, then block, rate limit, and alert your processor.