Ataques de enumeração de BIN

White Paper

À medida que os criminosos automatizam cada vez mais suas operações, alguns padrões tradicionais de fraude ressurgem em escala maior. Um deles é o chamado "ataque de enumeração de BIN", em que fraudadores partem de um BIN conhecido e geram sistematicamente números de cartão potencialmente válidos. Os números que se mostram válidos são então usados em tentativas de transações fraudulentas.

Para um emissor, o FraudAverse torna simples a detecção e a prevenção desses ataques. Antes de apresentar a solução, vale entender o que está por trás do ataque.

Números de cartão

A enumeração de BIN consiste, essencialmente, em identificar números de cartão que correspondem a contas válidas e ativas. Os criminosos exploram a estrutura bem definida do número do cartão:

• BIN (Bank Identification Number) — os primeiros 6 a 8 dígitos identificam o emissor e o produto. Listas públicas de BIN tornam esses números facilmente conhecidos, inclusive os seus.
• Identificador da conta — os 7 a 9 dígitos do meio. É esse o espaço de busca que os atacantes percorrem.
• Dígito verificador de Luhn — o último dígito é um simples checksum módulo 10. Como o algoritmo é público e fácil de aplicar, oferece pouca proteção contra fraudes; sua finalidade real é detectar erros de digitação em transações inseridas manualmente.

Para atingir a operação de um emissor, o atacante precisa usar um dos BINs dele. Em seguida, escolhe valores de identificador de conta aleatoriamente ou, se já conhece um cartão válido, varia o identificador de conta em torno dele.

Isso gera números de cartão candidatos — mas o número do cartão sozinho não basta para iniciar um pagamento fraudulento. O atacante também precisa da data de validade e do CVC. Nenhum dos dois pode ser derivado do número do cartão, então ambos precisam ser adivinhados.

É aqui que está a chave para detectar esse padrão. Para encontrar uma única combinação válida de número do cartão, data de validade e CVC, o atacante precisa testar um número muito grande de candidatos — e esse volume de testes é difícil de esconder.

Para não chamar atenção, os criminosos costumam adotar uma estratégia com vários BINs e vários emissores, distribuindo as tentativas entre muitos BINs e muitas instituições, de modo que nenhuma delas veja atividade suficiente para disparar um alarme evidente. É justamente essa distribuição que permite ao ataque escapar de limites por estabelecimento ou por endpoint — e, como mostraremos, é também por isso que a detecção precisa estar onde o quadro completo é visível.

Solicitações de autorização negadas

O primeiro passo para detectar esse ataque é monitorar as solicitações de autorização negadas. A melhor prática é integrar o FraudAverse de forma que a solicitação de autorização seja repassada a ele depois de concluídas todas as demais verificações de autorização — assim, o FraudAverse enxerga o resultado final de cada solicitação. Os códigos de resposta ISO 8583 a observar são:

• 14 — Número de cartão inválido (conta inexistente; o PAN não existe)
• 56 — Cartão sem registro
• 43 — Cartão roubado
• 41 — Cartão perdido

O código de resposta é numérico, e 0 indica que nenhuma regra de recusa foi aplicada e que as verificações de autorização liberaram a solicitação para aprovação. A rigor, os códigos 43 (cartão roubado) e 41 (cartão perdido) não fazem parte do ataque de enumeração em si. No entanto, os criminosos frequentemente usam um cartão perdido ou roubado como ponto de partida para adivinhar o primeiro identificador de conta — por isso vale monitorar esses códigos também.

FraudAverse

Nesse esquema de fraude há dois tipos de transação: as transações iniciais de enumeração — na prática, tentativas de adivinhar números de cartão — e as transações posteriores que de fato roubam dinheiro. Estas últimas são difíceis de detectar isoladamente; os criminosos as constroem para que se pareçam ao máximo com transações legítimas. Por isso, o essencial é detectar a atividade de enumeração que as antecede.

Comecemos pela solicitação de autorização do cash-out, ou seja, da retirada do dinheiro. Trata-se de uma solicitação de valor relevante — digamos US$ 100 como ponto de partida, a ser ajustado depois com dados reais por meio de análises. Com o tempo, podemos também perceber que os criminosos preferem certos tipos de transação para o cash-out — determinadas categorias de estabelecimento ou países — e adicionar essas condições de filtro mais tarde para reduzir ainda mais a taxa de falsos positivos.

Veja como fica a primeira etapa da criação da regra, com apenas a condição e a conclusão definidas:

Análise do histórico

O primeiro critério é que tenha havido pelo menos um teste bem-sucedido das credenciais do cartão. Como os criminosos raramente demoram a explorar o acesso ilícito a um cartão, esse teste normalmente terá ocorrido pouco antes do cash-out. Como ponto de partida, adotamos uma janela máxima de uma hora e um valor abaixo de US$ 20, já que as autorizações de teste costumam ficar abaixo de US$ 10.

Veja como essa feature é definida:

Observe que a condição de filtro "ResponseCode == 0" garante que apenas solicitações autorizadas/bem-sucedidas sejam contadas.

Para verificar se as credenciais do cartão da solicitação de autorização atual foram obtidas por enumeração, precisamos determinar se o cartão fez parte de um lote de testes. Como os fraudadores costumam concentrar os testes em poucos estabelecimentos e terminais, traçamos o perfil do histórico do estabelecimento e do terminal do último teste bem-sucedido.

Se esse estabelecimento ou terminal também aparece em um conjunto de tentativas de autorização recentes malsucedidas — a rajada de enumeração identificada pelos códigos de recusa vistos acima —, isso é um forte indício de que o cartão foi validado como parte de uma campanha de enumeração. Usando o estabelecimento e o terminal da última solicitação de autorização bem-sucedida, contamos — separadamente para o estabelecimento e para o terminal — o número de solicitações de autorização negadas em todos os cartões. Uma contagem alta concentrada em um único estabelecimento ou terminal é um forte indício de testes de enumeração, já que um estabelecimento legítimo normalmente não acumula uma rajada de recusas ligadas a números de cartão inválidos ou inexistentes.

Veja essa configuração para o estabelecimento:

Como referência, contamos também o total de solicitações de autorização do estabelecimento e do terminal e usamos a proporção entre recusas e total de solicitações como condições adicionais na regra de enumeração de BIN. Essa normalização é importante: um número absoluto alto de recusas em um estabelecimento grande, de alto volume, pode ser totalmente normal, enquanto a mesma contagem em um terminal de baixo volume é uma anomalia evidente. Expressar as recusas como proporção da atividade total permite que a regra diferencie rajadas reais de enumeração do ruído comum de recusas, mantendo baixa a taxa de falsos positivos. Esta é a regra completa contra a exploração por enumeração de BIN:

O pipeline completo

Na prática, a regra de enumeração de BIN faria parte de um conjunto maior de regras de fraude, e o perfil dos históricos de cartão, estabelecimento e terminal seria combinado com features adicionais ou diferentes. Para fins de ilustração, porém, reunimos todas as definições apresentadas até aqui em um único pipeline. Esse pipeline recebe os campos padrão da solicitação de autorização, traça o perfil dos históricos relevantes e contém a regra que detecta o ataque de enumeração de BIN — e o impede ao interceptar e negar a solicitação de autorização.

Este é o pipeline:

Próximos passos: simulação e refinamento adaptativo. A regra apresentada aqui se baseia, em grande parte, em princípios gerais e na experiência de diversas implementações em clientes. Se você já tem dados sobre ataques de enumeração de BIN da sua própria operação, o próximo passo é usar os recursos de simulação e análise do FraudAverse para modelar a eficácia dessas contramedidas no seu ambiente. Você também pode recorrer à Adaptive AI do FraudAverse para sugerir ajustes na regra ou propor regras adicionais.

O atalho: IA generativa

Seguindo os passos acima, você monta uma contramedida completa contra enumeração de BIN em muito pouco tempo, mas existe um caminho ainda mais rápido: o AI Assistant do FraudAverse. Com um prompt simples — "Crie contramedidas contra ataques de enumeração de BIN" —, o LLM do FraudAverse entra em ação, analisa os dados históricos de transações disponíveis e gera propostas de contramedidas.

Veja como fica:

Agora você pode aceitar todas as propostas de uma vez ou selecionar apenas algumas: