Fraude de SMS pumping: como um formulario de verificacao de telefone pode esvaziar em silencio o orcamento de mensagens de um site de classificados

A fatura de SMS chega, e e' tres ou quatro vezes o normal. Mais nada mudou: o numero de novos anunciantes parece normal, o mural de anuncios parece normal, a conta de pagamentos nao mostra nenhuma atividade fora do comum. A primeira suspeita natural e' um erro de faturamento, entao o operador abre um chamado com o provedor de mensagens e espera. A resposta que volta e' pior que um erro de faturamento, porque significa que cada uma daquelas mensagens realmente saiu, e o provedor nao vai estornar uma cobranca por um texto genuinamente entregue.
O que aconteceu tem nome: SMS pumping, tambem chamado de fraude de pedagio por SMS ou trafego artificialmente inflado. Ele mira exatamente o tipo de formulario em que um diretorio de classificados se apoia para manter os anuncios honestos, aquele em que um anunciante digita um numero de telefone e aperta um botao que diz enviar codigo. Este blog ja explicou por que essa verificacao existe, ja que as checagens de telefone e identidade sao o que realmente impede um mural de anuncios de se encher de contas falsas. A fraude descrita aqui nao se importa nem um pouco com o anuncio. Ela so se importa com o botao.
Como a fraude realmente funciona
O SMS pumping e' uma variante de um esquema de telecomunicacoes bem mais antigo, chamado fraude internacional de particao de receita, e o mecanismo nao tem nada de sutil depois de explicado. Um fraudador estabelece um acordo, formal ou explorado, com uma operadora que ganha dinheiro com tarifas de terminacao de mensagens, muitas vezes num pais longe de onde o negocio opera. O fraudador entao usa bots para disparar repetidamente a acao de enviar codigo do site, mirando numeros de telefone reais que estao na rede dessa operadora. Cada um desses numeros e' um chip ativo capaz de receber um texto, entao as mensagens nao voltam nem falham. Elas chegam.
Como as mensagens sao realmente entregues, nao ha nenhum sinal de fraude do lado das telecomunicacoes que levaria uma operadora a recusar envia-las ou um provedor de mensagens a recusar fatura-las. A operadora recebe uma tarifa de terminacao por cada mensagem que entrega, e sob o acordo de particao de receita, uma parte dessa tarifa volta para quem opera o trafego de bots. O negocio que paga pelas mensagens e', do ponto de vista da rede, simplesmente um cliente que pediu o envio de um numero muito grande de textos. Ninguem rio acima tem motivo para parar isso por conta propria.
Nenhuma das partes rio acima do negocio esta motivada a parar isso por iniciativa propria, e esse e' um detalhe que vale a pena examinar com calma. A operadora e' paga por mensagens que realmente esta entregando, entao em seus registros nada parece errado. A API de mensagens fica entre o negocio e a operadora e fatura fielmente o que foi pedido para enviar. A responsabilidade de perceber que o trafego chegando no formulario de cadastro nao se parece com anunciantes acaba recaindo sobre a unica parte que tem tanto o motivo quanto a visibilidade para perceber: o negocio que paga a fatura.
O que torna isso atraente para fraudadores, e caro para um diretorio, e' que nada disso exige uma conta real. O bot nao precisa completar a verificacao, nao precisa publicar um anuncio, e o codigo nunca precisa ser digitado numa caixa. Basta que o formulario do site aceite um numero de telefone e despache uma mensagem. Um fluxo de cadastro que nunca termina uma unica verificacao bem-sucedida ainda assim pode gerar um mes inteiro de trafego faturavel.
Por que a fatura chega antes de qualquer outra coisa
A maioria das APIs de SMS e verificacao, incluindo a da Twilio, cobra por mensagem enviada ou tentada, nao por verificacao efetivamente concluida. Esse modelo de cobranca nao e' uma falha de projeto especifica de um fornecedor: e' assim que a rede telefonica subjacente ja cobra o negocio pela entrega de uma mensagem, e a API apenas repassa esse custo. O efeito pratico e' que uma campanha de fraude custa dinheiro ao operador desde a primeira mensagem, horas ou dias antes de alguem perceber que a taxa de conclusao no formulario de cadastro despencou em silencio.
A escala que isso pode atingir nao e' teorica. Em dezembro de 2022, Elon Musk declarou publicamente, durante uma sessao do Twitter Spaces, que o Twitter perdia cerca de sessenta milhoes de dolares por ano exatamente por causa desse esquema, e citou cerca de 390 operadoras de telecomunicacoes que, segundo ele, estavam envolvidas em inflar trafego fraudulento de autenticacao de dois fatores em direcao a plataforma. Esse numero foi uma afirmacao do proprio Musk, nao uma divulgacao corporativa auditada, mas a resposta foi real e noticiada bem alem do marketing de prevencao a fraude: o Twitter cortou lacos com operadoras cujo trafego parecia fraudulento, e meses depois restringiu a autenticacao de dois fatores gratuita por SMS a assinantes pagantes exatamente por causa do custo. Uma empresa com o volume e o time tecnico do Twitter ainda assim levou meses para perceber e reagir. Um diretorio rodando numa unica conta de mensagens independente, sem um time antifraude lendo os logs toda manha, tem muito menos aviso previo embutido.
O numero que realmente revela a fraude nao e' o volume de mensagens enviadas, ja que um impulso de marketing de verdade ou uma semana genuinamente movimentada tambem podem elevar esse numero. E' a proporcao entre codigos enviados e codigos inseridos com sucesso. Uma taxa de conclusao que cai em silencio em relacao ao seu valor normal, mesmo com o volume total subindo, e' o sinal de que o trafego chegando no formulario nao e' feito de pessoas com intencao de terminar o cadastro.
Por que um formulario de anuncios aberto e' exatamente o perfil visado
Um diretorio de classificados tem uma razao estrutural para deixar o botao enviar codigo facil de alcancar: qualquer atrito somado ao cadastro de um anunciante de primeira viagem custa conversoes, e este blog ja explicou por que esse atrito merece ser defendido com cuidado logo na porta mesmo antes de o pagamento entrar em cena. Uma etapa de verificacao de telefone rapida e acolhedora para um anunciante legitimo e', pelo mesmo desenho, rapida e acolhedora tambem para um bot sem nenhuma intencao de virar um.
A exposicao tambem e' mais aguda para um operador pequeno e independente do que parece de fora. Uma plataforma grande negocia precos por volume e geralmente tem um contrato que inclui algum monitoramento antifraude como parte da relacao. Um diretorio que roda seu fluxo de cadastro por uma API de mensagens padrao, paga por uso, nao tem esse amortecedor: cada mensagem fraudulenta e' faturada na mesma tarifa por mensagem que qualquer mensagem legitima, direto no cartao cadastrado, sem nada absorvendo o pico ate' que um humano note a fatura.
Nada disso significa que bloquear um prefixo de pais seja uma decisao para configurar uma vez e esquecer. Um diretorio que se expande para uma nova cidade, ou que atrai anunciantes que viajam, pode encontrar um grupo legitimo de cadastros atras de um prefixo que foi bloqueado por um bom motivo um ano antes. Tratar a lista de prefixos restritos como algo a rever a cada poucos meses, junto com tudo o mais que e' revisado nesse ritmo, evita que a defesa se transforme em silencio numa segunda fonte de cadastros perdidos.
Essa e' uma falha diferente daquela que este blog descreveu ao tratar de por que um e-mail de verificacao as vezes nunca chega a caixa de entrada de um anunciante. Aquele texto era sobre uma mensagem que falha em silencio, custando apenas um cadastro perdido. Este e' sobre uma mensagem que tem sucesso de forma barulhenta, chegando exatamente como previsto, e custando dinheiro de verdade cada vez que isso acontece.
O que realmente para isso
A primeira camada e' a limitacao de taxa na propria acao de enviar codigo, aplicada no servidor em vez de confiada ao navegador: um teto rigido para quantos codigos um unico endereco IP, sessao ou numero de telefone pode solicitar numa janela curta de tempo. Sozinha, isso nao vai parar uma rede de bots distribuida por muitos enderecos IP, mas remove a versao mais barata e preguicosa do ataque e forca qualquer coisa mais determinada a trabalhar mais.
A segunda camada e' uma checagem antibot colocada antes de a acao de envio disparar, nao depois: algo que confirme que um humano acionou a solicitacao sem pedir a esse humano que resolva algo irritante, como um desafio invisivel que pontua a solicitacao em segundo plano. Como toda a fraude depende de disparar envios de forma automatica e em volume, qualquer coisa que retarde de modo significativo o disparo automatizado reduz diretamente o custo do ataque, mesmo que deixe alguns bots passarem.
A terceira camada e' aplicar atrito, nao necessariamente um bloqueio total, a prefixos telefonicos que a base real de anunciantes de um diretorio praticamente nunca usa. Um site que atende cidades de um unico pais tem pouco motivo para aceitar, sem uma segunda checagem, uma onda de solicitacoes de verificacao direcionadas a um codigo de pais onde a base de anunciantes nunca teve presenca significativa.
A quarta camada e' ativar qualquer protecao antifraude que o provedor de mensagens ja ofereca, em vez de supor que as configuracoes padrao ja cobrem isso. A Twilio, para dar um exemplo concreto, oferece um recurso chamado Verify Fraud Guard que analisa padroes de trafego para detectar e bloquear automaticamente atividade suspeita de pumping, e vem ativado por padrao para clientes Verify, com niveis de protecao ajustaveis que trocam uma pequena taxa de falsos positivos por uma taxa maior de bloqueio. Confirmar que um recurso assim esta ligado, e ajustado a um nivel apropriado para o trafego real do site, nao custa nada e pega o que a propria logica do site vai deixar passar.
A quinta camada e' um alerta de gasto configurado diretamente com o provedor, nao descoberto um mes depois numa fatura. Um limite que dispara uma notificacao assim que o gasto diario em mensagens ultrapassa um nivel sem explicacao comum transforma uma campanha de fraude que de outra forma correria em silencio por semanas numa que e' notada em questao de horas.
O que fazer esta semana
Puxe os logs de mensagens do mes passado e calcule a proporcao real entre codigos enviados e codigos verificados com sucesso, nao apenas o volume total. Um numero que parece correto no agregado ainda pode esconder uma semana especifica ou um prefixo de pais especifico onde a proporcao despencou. Esse unico calculo dira a um operador mais sobre se essa fraude ja esta acontecendo do que qualquer outra coisa neste texto.
Depois verifique tres configuracoes diretamente com o provedor de mensagens: se uma protecao antifraude como o Fraud Guard esta ativa e em qual nivel, se existe um alerta de gasto e em qual limite, e se o endpoint de enviar codigo tem um limite de taxa no lado do servidor que nao depende de nada que o navegador possa ser instruido a ignorar. Nenhuma dessas tres checagens exige novo software ou uma nova relacao com fornecedor, apenas o tempo de perguntar diretamente ao provedor e ler a resposta que volta.


