An enumeration attack is automated guessing of card details, the number, expiry, and security code, to find combinations that actually work. Starting from a known card range, it lets criminals manufacture usable cards out of partial data, one valid guess at a time.
What is an enumeration attack, in plain English?
An enumeration attack is brute force applied to card data. A card number is not random: the first digits identify the issuer and card range, known as the BIN, and the rest follows patterns with a check digit at the end. An attacker who knows a valid BIN can generate candidate numbers and then test them against a payment endpoint to see which ones are live.
The missing pieces, the expiry date and the security code, have small enough ranges that automation can grind through them. Software fires thousands of authorization or verification attempts, most of which fail, until valid combinations fall out. The result is a fresh supply of working card credentials assembled from almost nothing.
This sits at the front of card-not-present fraud. Enumeration produces the raw, verified card data that later gets spent, resold, or fed into larger schemes. It is closely tied to BIN attacks and card testing, which describe overlapping parts of the same behavior.
How an enumeration attack unfolds
- Seed — Pick a BIN. The attacker starts from a known card range, giving a valid prefix to build numbers on.
- Generate — Build candidate numbers. Software fills in the remaining digits, respecting the check digit, to produce many plausible card numbers.
- Test — Fire attempts at an endpoint. Small authorizations or verifications probe expiry and security-code combinations at high volume.
- Harvest — Keep the approvals. The rare successes are collected as validated cards, ready to spend or sell.
What it looks like in practice
In practice
A merchant's checkout suddenly processes a flood of tiny authorization attempts overnight. The card numbers move almost in sequence, share the same handful of BINs, and come from a small set of IP addresses and devices. Nearly all of them decline.
The traffic is an enumeration attack using the merchant's payment API as a free oracle: every approval tells the attacker they have found a valid expiry and code. Left alone, the merchant would rack up network fines for excessive testing traffic, so the team adds rate limits, a CAPTCHA, and velocity rules that choke the sequential attempts before valid cards leak out.
Why it matters to operators
Enumeration is dangerous even when almost every attempt fails, because the successes become working cards and the failures still cost you. Card networks now monitor for excessive testing traffic and fine merchants whose endpoints get abused this way, so an unprotected checkout is both a fraud hole and a compliance liability. The processing fees on thousands of declined attempts add up on their own.
It is also a leading indicator. A burst of enumeration against your BINs or your endpoint often precedes a wave of card-not-present spending, either on your platform or someone else's. Catching the sequential, high-decline pattern early lets you slow the attacker before the validated cards ever get used.
What to watch in the data
- Sequential numbers. Card numbers that increment in order, rather than arriving randomly, are a hallmark of enumeration.
- High decline rates. A flood of attempts where the vast majority fail signals guessing, not real shoppers.
- BIN concentration. Traffic clustered on a few card ranges suggests an attacker working from a known BIN.
- Tiny or zero-value probes. Small authorizations or verification-only calls are cheap ways to test validity.
- Narrow origin. Many attempts from a small set of IPs, devices, or fingerprints point to automation.
Quick questions
How is enumeration different from card testing?
They overlap heavily. Enumeration is the guessing of unknown digits to find valid cards, while card testing is checking whether cards, however obtained, are still live. An enumeration attack usually ends in card testing.
What is a BIN attack?
It is enumeration focused on one bank identification number. The attacker fixes a valid BIN and brute-forces the remaining digits, expiry, and code to mint working cards from that issuer's range.
Why do networks fine merchants for this?
Because an unprotected endpoint becomes a testing ground that harms cardholders and floods the network with junk authorizations. Networks track excessive testing traffic and penalize merchants that allow it.
How do teams slow enumeration down?
Rate limits, CAPTCHA, device fingerprinting, and velocity rules that catch sequential numbers and high decline rates. The goal is to make each attempt costly enough that mass guessing stops paying off.
Can enumeration work without any stolen data?
Largely yes. Given a valid BIN, the attacker generates candidate numbers and brute-forces the rest. It manufactures usable card details from a known range rather than needing a full breach.
Is a spike in declines always an attack?
Not always, but a spike combined with sequential numbers, BIN clustering, and narrow device origins strongly suggests enumeration rather than genuine failed purchases.
Go deeper
- EMVCo ↗ — Maintains the EMV chip and 3-D Secure specifications for card payments.
- PCI Security Standards Council ↗ — Security standards for handling cardholder data, including PCI DSS.