CC Checkers: como funcionam, principais falhas de checkout e defesa

O que é um 'checker' de cartão

Um checker é um script — geralmente um bot em Python/Node — que recebe uma lista de cartões (PAN|MM|YY|CVV) e testa cada um contra um endpoint que devolve sinal claro de aprovação/negação. O objetivo do fraudador não é comprar nada de valor: é apenas separar cartões vivos (aprováveis) dos mortos (bloqueados, expirados, sem saldo). Cartões vivos são revendidos em fóruns e canais Telegram com preço proporcional ao BIN, país e tipo (débito, crédito, corporativo).

• Sinal binário claro — o checker precisa de uma resposta determinística: 200 vs 402, 'success:true' vs 'declined', ou até tempos de resposta diferentes.
• Baixo custo por tentativa — a operação favorável é aquela em que cada teste custa centavos (auth zero) ou nada (fluxo de tokenização sem cobrança).
• Escala — proxies residenciais rotativos, farms de headless browsers e resolvedores de CAPTCHA para diluir bloqueio por IP e device.
• Cash-out — cartões vivos alimentam BIN attacks, compras de gift cards, recargas e mule accounts.

Os principais métodos observados na natureza

1. Auth $0 / $1 abusiva

Merchants configuram uma pré-autorização de valor zero ou muito baixo para validar cartão em cadastros ('salvar cartão para próximas compras'). Sem rate limit e sem 3DS, esse endpoint vira um oráculo perfeito para o checker: cada request devolve approved/declined sem cobrar ninguém.

2. Endpoints de doação, assinatura ou tokenização

Formulários de doação (ONGs, igrejas), trials pagos de $1 e endpoints públicos de tokenização (Stripe Elements mal configurado, iframes de PSP sem domain restriction) são preferidos porque estão em domínios legítimos, com boa reputação, e frequentemente sem CAPTCHA nem 3DS.

3. Enumeração via mensagens de erro

Alguns gateways devolvem códigos ricos: 'invalid_cvc', 'insufficient_funds', 'card_declined_generic'. Cada resposta é um bit de informação. 'insufficient_funds' já confirma que PAN+expiração+CVV estão corretos — o cartão é vivo, só está sem limite naquele instante.

4. Timing / oráculo de latência

Mesmo quando a resposta HTTP é genérica ('erro no pagamento'), a diferença de tempo entre um cartão que chega ao emissor (300–1200 ms) e um que morre na validação local de BIN (20–80 ms) revela quais cartões estão pelo menos com formato válido e BIN ativo.

5. BIN attack

O fraudador escolhe um BIN conhecido de emissor com anti-fraude fraco, gera PANs válidos por Luhn e força bruta CVV+expiração em endpoints tolerantes. O prejuízo real cai sobre o emissor, mas o merchant carrega chargebacks, aumento de MDR e risco de entrar em programas de monitoramento das bandeiras (Visa VAMP, Mastercard ECM).

Vulnerabilidades de checkout que habilitam o abuso

• Ausência de rate limit por IP, por device fingerprint, por sessão e por BIN — o clássico. Um checkout que aceita 300 tentativas/minuto do mesmo device é um oráculo aberto.
• 3DS opcional ou desativado para valores baixos — cartões testados em auth $0 nunca acionam o ACS do emissor.
• Respostas verbosas do gateway repassadas ao front — devolver o código bruto ('cvc_check: fail') dá ao checker exatamente o sinal que ele precisa.
• Endpoint de tokenização sem allowlist de origem — chaves publicáveis (pk_live_...) usadas em iframes sem restrição de domínio permitem que qualquer site chame o gateway em nome do merchant.
• CAPTCHA ausente ou trivial — hCaptcha/reCAPTCHA v2 sem enforcement server-side ou v3 com threshold muito baixo são bypassados por serviços de resolução por US$ 1–3 por 1000.
• Fluxo de 'salvar cartão' sem cobrança real — permite validar cartão sem gerar transação financeira observável para o titular.
• Falta de velocity check cruzando e-mail, device, IP, país do BIN e hora — o mesmo device tentando 20 BINs diferentes em 5 minutos é sinal óbvio, mas raramente correlacionado.
• Retorno diferencial de HTTP status — 200 para aprovado, 402 para negado, 400 para erro de formato. Um proxy simples classifica tudo.
• Webhooks e callbacks públicos sem HMAC — permitem confirmar side-channel se a transação passou.
• SPA que expõe a chave secreta ou secret webhook em bundle JS — grep em bundles minificados por 'sk_live', 'MERCHANT_SECRET', 'API_KEY' ainda funciona em 2026 mais do que deveria.

Como defender — camadas obrigatórias

Camada 1 — Higienizar a API de pagamento

• Rate limit em múltiplas dimensões: IP, ASN, device fingerprint, e-mail, sessão, BIN, país. Bloqueio progressivo (soft → captcha → hard).
• Uniformizar respostas: nunca vaze 'cvc_check_failed' vs 'insufficient_funds' vs 'do_not_honor' para o front. Devolva sempre 'pagamento não autorizado' com HTTP 402 padrão e delay artificial pequeno para nivelar latência.
• Idempotência com token único por tentativa — impede replay simples.
• Bloquear auth $0 pública sem sessão autenticada; se precisar validar cartão, use Setup Intents / Zero-Auth com 3DS obrigatório.

Camada 2 — Autenticação forte no lugar certo

• 3DS 2.x com challenge obrigatório em cadastro de novo cartão e em compras acima do TRA exemption threshold (ver estudo dedicado ao 3DS).
• Enriquecer o AReq com merchantRiskIndicator, acctInfo e histórico — mais contexto = mais frictionless para o cliente legítimo, mais challenge para o fraudador.
• CAPTCHA server-side com pontuação (reCAPTCHA Enterprise, Turnstile), não apenas widget visual.

Camada 3 — Device fingerprint e sinais comportamentais

• Fingerprint com canvas, WebGL, fontes, timezone × geoIP, plugins e áudio (ver a rota /scan deste site como demonstração das dimensões coletáveis).
• Comportamento: velocidade de digitação do PAN, movimento de mouse, tempo entre foco e submit. Bots preenchem tudo em < 200 ms.
• Consistência entre linguagem do browser, timezone, país do IP e país do BIN. Divergências combinadas são o sinal mais forte de proxy/farm.

Camada 4 — Configuração correta do gateway

• Chaves publicáveis com restrição de domínio (Stripe: allowed_origins; Adyen: origin key vinculada ao HMAC).
• Webhooks com assinatura HMAC obrigatória e verificação de timestamp contra replay.
• Radar / Sift / Signifyd / Cybersource Decision Manager ativos, com regras de blocklist por BIN e por device.
• Monitorar em dashboard: approval rate por BIN, por país, por hora, por device — anomalia dispara rate limit dinâmico.

Checklist rápido de auditoria do seu próprio checkout

Como o portador se protege

• Cartão virtual descartável para compras online (Nubank, Itaú, Inter, C6 oferecem) — CVV rotativo neutraliza reuso.
• Notificação por push para toda transação, inclusive de $0, e revisão semanal da fatura.
• Bloqueio de compras internacionais por padrão, liberando pontualmente.
• Nunca digitar o cartão em site sem HTTPS, sem cadeado válido, ou fora do domínio esperado (verificar barra de endereço, não apenas o visual).
• Preferir carteiras (Apple Pay, Google Pay, Pix) — o PAN real nunca chega ao merchant.
• Ativar 3DS/senha de compras online no app do banco quando o emissor permite escolher.

Modelo de ameaças (STRIDE + PASTA aplicado ao checkout)

Modelo focado em duas ameaças correlatas: (A) enumeração/validação de PANs (CC checker) e (B) BIN attack / brute force de expiração+CVV. O escopo é o par formulário-de-pagamento ↔ API-de-pagamento ↔ gateway/PSP, incluindo endpoints auxiliares (tokenização, salvar cartão, doação, trial).

Ativos protegidos

• Reputação do merchant junto a bandeiras (Visa VAMP, Mastercard ECM) e ao adquirente.
• Chargeback ratio e MDR (taxa por transação).
• Dados de cartão em trânsito (PCI-DSS scope) e tokens do PSP.
• Chaves publicáveis, secretas e webhook secrets.
• Confiança do portador legítimo (UX sem falsos positivos).

Atores de ameaça

• Carder oportunista — script kiddie com checker público, proxies gratuitos, baixa persistência.
• Operador organizado — usa proxies residenciais rotativos, farms headless, resolvedores de CAPTCHA pagos, alterna BINs e horários.
• Insider / integrador comprometido — chave secreta vazada em repositório público ou bundle JS.
• Botnet contratada — tráfego distribuído em milhares de IPs residenciais legítimos, difícil de bloquear por IP puro.

Ameaças mapeadas em STRIDE

S — Spoofing
   • Chave publicável usada em domínio de terceiro (sem allowlist de origem)
   • Sessão / device forjado por bot com fingerprint reciclado
T — Tampering
   • Manipulação de amount no request client-side ($100 → $0.50)
   • Alteração de currency ou BIN country no payload
R — Repudiation
   • Ausência de logs correlacionáveis (sem request_id, sem device_id)
   • Webhooks sem HMAC / sem timestamp → replay indistinguível
I — Information Disclosure
   • Resposta verbosa do gateway repassada ao front (cvc_check, avs_check)
   • Diferença de latência entre PAN válido e inválido (timing oracle)
   • Bundle JS expõe sk_live_ / MERCHANT_SECRET / endpoint interno
D — Denial of Service
   • Flood de tentativas esgota quota do PSP e derruba checkout legítimo
   • Custo de auth $0 × milhões de tentativas = prejuízo operacional
E — Elevation of Privilege
   • Endpoint 'salvar cartão' sem sessão autenticada → qualquer visitante valida cartão
   • Endpoint interno de refund/void exposto sem auth server-to-server

Cenários de ataque (abuse cases)

1. AC-01 Auth-Zero Oracle — bot envia 10k PANs contra /save-card sem sessão; resposta binária revela vivos.
2. AC-02 BIN Attack — PAN gerado por Luhn a partir de BIN alvo; brute force de MM/YY (60 combinações) e CVV (10k) em endpoint tolerante.
3. AC-03 Timing Oracle — respostas HTTP idênticas, mas latência de 40 ms vs 800 ms separa PANs inválidos de válidos.
4. AC-04 Doação como oráculo — formulário público de doação de R$ 1 usado como checker; merchant vira alvo indireto.
5. AC-05 Chave publicável hijack — pk_live_ sem restrição de domínio usada em site do fraudador para chamar o PSP em nome do merchant.
6. AC-06 Replay de webhook — ausência de HMAC/timestamp permite reenvio de evento 'payment.succeeded' forjado.
7. AC-07 CAPTCHA bypass — token de reCAPTCHA v3 aceito sem verificação server-side ou com threshold ≤ 0.1.
8. AC-08 Slow burn distribuído — 1 tentativa por IP residencial, 20k IPs distintos, ritmo humano, dilui rate limit por IP.

Controles recomendados por camada

AC-01  Auth-Zero Oracle
   → C-01 Sessão autenticada obrigatória em /save-card
   → C-02 3DS challenge em cadastro de novo cartão (Setup Intent)
   → C-03 Rate limit por device_fp + email + IP + BIN

AC-02  BIN Attack
   → C-04 Bloqueio progressivo por BIN após N declines/janela
   → C-05 Velocity check cross-dimensão (device × BIN × país)
   → C-06 3DS obrigatório acima do TRA exemption threshold

AC-03  Timing Oracle
   → C-07 Resposta com delay artificial nivelado (jitter constante)
   → C-08 Uniformização de HTTP status (sempre 402 para qualquer decline)

AC-04  Doação como oráculo
   → C-09 CAPTCHA Enterprise/Turnstile com score server-side
   → C-10 Valor mínimo + limite de tentativas por sessão

AC-05  Chave hijack
   → C-11 allowed_origins / origin key vinculada ao domínio no painel PSP
   → C-12 CSP com frame-src restrito ao PSP

AC-06  Webhook replay
   → C-13 HMAC obrigatório + timestamp ± 5 min + nonce em cache

AC-07  CAPTCHA bypass
   → C-14 Validação server-side com threshold ≥ 0.7 e ação por score

AC-08  Slow burn distribuído
   → C-15 Device fingerprint estável + comportamental (tempo de digitação)
   → C-16 Correlação timezone × geoIP × BIN country
   → C-17 Reputação de ASN (bloquear datacenter/VPN em /pay)

Critérios de aceitação (Definition of Done)