Ataque BIN

Um ataque BIN (BIN attack) é uma técnica de fraude em pagamentos por força bruta: os fraudadores partem de um BIN conhecido, o número de identificação bancária formado pelos primeiros seis ou oito dígitos de um cartão, geram a partir dele possíveis números de cartão e os usam em pequenas tentativas de autorização para descobrir quais números, datas de validade e códigos de segurança correspondem a contas ativas.

O ataque não depende de nenhum vazamento de dados. Os números são gerados a partir da faixa de numeração do emissor, e não roubados, por isso muitas vezes os portadores são afetados sem ter exposto o cartão em lugar nenhum. A empresa cujo checkout ou formulário de pagamento é usado nos testes arca com boa parte do custo: tarifas de autorização, um aumento repentino de recusas e um monitoramento mais rigoroso por parte do adquirente.

Como funciona um ataque BIN

O BIN, cujo nome formal é número de identificação do emissor (IIN, na sigla em inglês), identifica a instituição que emitiu o cartão e, muitas vezes, a qual produto ele pertence. Desde a revisão de 2017, a norma ISO/IEC 7812-1 define o IIN com oito dígitos em vez de seis.

Os dígitos restantes seguem uma estrutura conhecida e terminam em um dígito verificador, o que permite gerar automaticamente longas listas de números estruturalmente válidos. Só uma autorização confirma se existe de fato uma conta por trás de um número. Por isso, os fraudadores testam os números gerados em qualquer formulário que dispare uma autorização (um checkout on-line, uma página de doações, um período de teste gratuito, a etapa de vinculação de um cartão), em geral por meio de scripts ou bots, muitas vezes com autorizações de baixo valor ou de valor zero, e alternam datas de validade e códigos CVV entre as tentativas. As mensagens de recusa podem revelar qual dado falhou, o que reduz as combinações a testar na rodada seguinte. Os dados validados são usados em compras fraudulentas com cartão não presente ou revendidos.

Ataque BIN, card testing e card cracking

Os três termos se sobrepõem e muitas vezes são usados como sinônimos. Em uma definição comum, o card testing verifica se dados de cartões obtidos por outros meios ainda funcionam; o card cracking descobre por força bruta os dados que faltam de um cartão do qual só se conhece uma parte; e o ataque BIN gera os próprios números de cartão a partir da faixa de um emissor. Emissores, adquirentes e fornecedores nem sempre traçam esses limites da mesma forma.

Como bandeiras e emissores monitoram ataques BIN

As bandeiras de cartão tratam a enumeração como uma categoria de risco à parte. O Visa Acquirer Monitoring Program (VAMP) a monitora mensalmente, junto com fraudes e disputas. Segundo os limites da ficha informativa do programa publicada pela Visa em 2025, um estabelecimento ultrapassa o limite de enumeração quando, em um mesmo mês, as transações identificadas como enumeração representam pelo menos 20% de todas as tentativas de autorização e somam no mínimo 300.000. Os emissores veem o outro lado da mesma atividade: uma enxurrada de tentativas contra uma mesma faixa de BIN, distribuída entre muitos estabelecimentos.

Como os ataques BIN são detectados

Controles no nível do cartão detectam pouco, porque cada número gerado aparece uma ou duas vezes e depois desaparece. A detecção se apoia em dados agregados. Entre os sinais comumente usados estão:

• picos de tentativas de autorização dentro de uma mesma faixa de BIN

• números de cartão sequenciais ou quase sequenciais

• uma proporção incomum de recusas por número de cartão inválido ou CVV incorreto

• concentrações de valores baixos idênticos

Ataques BIN costumam ser automatizados, e a automação deixa rastros fora dos dados de pagamento. Muitos cartões enviados a partir de um mesmo dispositivo, sessão ou faixa de IP, intervalos regulares entre tentativas típicos de script, navegadores headless, emuladores, máquinas virtuais e configurações de dispositivo que mudam de uma tentativa para outra apontam para ferramentas automatizadas, e não para clientes reais. Velocity checks baseados no dispositivo e na sessão, e não apenas no cartão, são uma forma comum de detectar esse padrão.

Respostas típicas

Entre as respostas típicas estão:

1. Limitar a taxa de requisições (rate limiting) nos endpoints de autorização e de vinculação de cartões.

2. Adicionar um desafio (challenge) quando houver suspeita de automação (veja mitigação de bots).

3. Aplicar 3-D Secure quando o mercado e o produto permitirem.

4. Exigir verificação de CVV e de endereço (AVS) quando disponível.

5. Notificar o adquirente ou o emissor.

Bloquear temporariamente uma faixa de BIN interrompe o ataque rapidamente, mas também barra clientes legítimos desse emissor; por isso, o custo em recusas indevidas precisa ser ponderado em relação ao volume do ataque.