Voltar ao blog
SegurançaFraude AITVerify Call

Fraude AIT explicada: como os atacantes esgotam o seu orçamento de OTP

Novauth Team5 min de leitura

Algures no seu funil de registo existe um endpoint que envia uma mensagem de texto a qualquer pessoa que a solicite — sem necessidade de sessão iniciada, por conceção, porque o objetivo é precisamente verificar alguém antes de essa pessoa ter uma conta. É também exatamente isso que torna o ataque lucrativo. O esquema chama-se fraude de Artificially Inflated Traffic (AIT), por vezes designada SMS pumping, e as estimativas do setor apontam para danos na ordem dos 1,6 mil milhões de dólares por ano. A maioria das equipas nunca ouviu falar disto até a sua fatura de SMS disparar sem razão aparente.

Eis como funciona na realidade, porque é tão difícil de detetar, e o que realmente o trava.

O que é a fraude AIT

A fraude AIT não tem como alvo os seus utilizadores — tem como alvo diretamente o seu endpoint de OTP. Um fraudador controla, ou tem um acordo de partilha de receita com, uma rota de terminação de tarifa majorada: um intervalo de números de telefone onde a operadora local (ou um revendedor de "rota cinzenta" posicionado entre o seu fornecedor de SMS e a operadora) recebe uma taxa de terminação por cada mensagem entregue. O fraudador utiliza depois bots ou scripts para acionar o seu endpoint de "enviar código de verificação" milhares de vezes contra números dessa rota.

O seu fornecedor de SMS entrega as mensagens — ou reporta tê-lo feito — e fatura-o por mensagem. Uma parte do que pagou reverte para quem controla a rota de destino. Ninguém chega a introduzir o código. Ninguém precisou de o fazer. A fraude está concluída no momento em que a mensagem é enviada.

Porque é tão difícil de detetar

Um único pedido de OTP fraudulento é idêntico a um pedido real: um número de telefone, uma chamada à API, sem palavra-passe, sem conta para assinalar como comprometida. Multiplicado por milhares de números e distribuído por muitos IPs, mistura-se quase na perfeição com o tráfego normal de registo. As defesas básicas também não ajudam muito — o CAPTCHA abranda scripts ingénuos, mas não uma operação financiada a correr proxies residenciais, e a limitação de taxa apenas por IP é fácil de contornar.

O indício está normalmente nos números que só se nota depois do sucedido: o volume de envios de verificação a subir enquanto os registos reais se mantêm estáveis, os custos de entrega a concentrar-se num punhado de indicativos de país pouco familiares, e as taxas de conclusão (códigos efetivamente introduzidos) a colapsar num subconjunto do tráfego. Quando isso aparece numa fatura mensal, o prejuízo já está feito.

Padrões de ataque comuns

  • Abuso de registo por bots — scripts martelam um formulário público de registo ou de recuperação de palavra-passe apenas para acionar envios de OTP, sem nunca concluir o fluxo.
  • Direcionamento de rotas — o tráfego é desproporcionalmente dirigido a destinos de tarifa majorada ou pouco comuns, pois é aí que o pagamento de terminação é mais elevado.
  • Exploração de rotas cinzentas — a fraude é mais fácil onde uma mensagem SMS passa por vários revendedores antes de alcançar uma operadora; mais saltos significam mais oportunidades para alguém na cadeia lucrar com o volume inflacionado.
  • Campanhas lentas e discretas — algumas operações mantêm-se deliberadamente abaixo dos limiares óbvios de limitação de taxa, distribuindo pedidos ao longo do tempo e por vários intervalos de IP para evitar deteção por completo.

O que realmente o trava

Nada disto é exótico — são as mesmas boas práticas em que a maioria das equipas investe pouco até lhes custar caro:

  • Limitação de taxa por número de telefone e por dispositivo, não apenas por IP — um utilizador real não pede cinco códigos em dez segundos.
  • CAPTCHA ou prova de trabalho antes do envio do OTP, especificamente em endpoints não autenticados como o registo e a recuperação de palavra-passe.
  • Validação do número de telefone antes do envio — uma consulta a operadora/HLR deteta intervalos de números inválidos, inalcançáveis ou conhecidos por abuso antes de pagar para lhes enviar mensagens.
  • Monitorização de entregas e custos com alertas de anomalias — sinalizar picos súbitos de volume para países pouco familiares, e não apenas os totais mensais depois de a fatura chegar.
  • Menos revendedores no percurso de entrega — cada salto por rota cinzenta entre o seu fornecedor e a operadora de destino é um potencial participante na cadeia de pagamento da fraude.

Esse último ponto é a correção estrutural, não apenas uma mitigação. É também onde a escolha do canal importa mais do que a maioria das equipas percebe.

Porque o Verify Call contorna o problema por completo

A fraude AIT é, no fundo, uma exploração da taxa de terminação do SMS — depende de uma mensagem ser faturável e encaminhável através de uma cadeia onde alguém a jusante lucra com o volume. O Verify Call não tem essa economia. Não há texto SMS para encaminhar através de rotas cinzentas revendíveis, nem taxa de terminação por mensagem para um fraudador desviar; o "código" é um identificador de chamada numa chamada de voz direta através da infraestrutura da operadora, não uma carga faturável a viajar por intermediários. É por isso que não se limita a tornar a AIT mais difícil — elimina completamente a superfície de ataque.

Para o tráfego de SMS que continua a enviar — através de corredores de fallback de WhatsApp ou Telegram, por exemplo — encaminhar através de menos intermediários continua a importar. A Novauth liga-se diretamente a redes de operadoras de nível 1 através de SS7 e SIP protegidos, em vez de revender através de agregadores de rota cinzenta, e cada envio fica registado com operadora, duração e resultado, para que um volume anómalo seja visível no seu painel — e não escondido na fatura do mês seguinte.

Conclusão

A fraude AIT prospera com duas coisas: um endpoint não autenticado que envia algo faturável, e saltos suficientes no percurso de entrega para alguém lucrar com o volume inflacionado. Não é possível eliminar o primeiro sem quebrar o seu produto — a verificação tem de funcionar antes de existir sessão iniciada. Mas é possível eliminar o segundo, seja reforçando o percurso de SMS que já tem, seja movendo o seu canal de verificação principal para um onde a exploração simplesmente não se aplica.

Compare canais em preços, saiba mais em segurança, ou veja como o Verify Call funciona de ponta a ponta.