Fraude de SMS pumping: como un formulario de verificacion telefonica puede vaciar en silencio el presupuesto de mensajeria de un sitio de anuncios

Llega la factura de SMS, y es tres o cuatro veces lo normal. Nada mas se ha movido: el numero de nuevos anunciantes parece corriente, el tablon de anuncios parece corriente, la cuenta de pagos no muestra ninguna actividad inusual. La primera sospecha natural es un error de facturacion, asi que el operador abre un ticket con el proveedor de mensajeria y espera. La respuesta que llega es peor que un error de facturacion, porque significa que cada uno de esos mensajes salio de verdad, y el proveedor no va a revertir un cargo por un texto que se entrego genuinamente.

Lo que ha pasado tiene nombre: SMS pumping, tambien llamado fraude de peaje por SMS o trafico artificialmente inflado. Apunta exactamente al tipo de formulario en el que se apoya un directorio de anuncios para mantener honestos los anuncios, ese en el que un anunciante escribe un numero de telefono y pulsa un boton que dice enviar codigo. Este blog ya ha explicado por que existe ese control, ya que las comprobaciones de telefono e identidad son lo que realmente evita que un tablon se llene de cuentas falsas. El fraude descrito aqui no le importa el anuncio en absoluto. Solo le importa el boton.

Como funciona realmente el fraude

El SMS pumping es una variante de un esquema de telecomunicaciones mucho mas antiguo llamado fraude internacional de reparto de ingresos, y el mecanismo no tiene nada de sutil una vez explicado. Un estafador establece un acuerdo, formal o explotado, con un operador que gana dinero con las tarifas de terminacion de mensajes, a menudo en un pais lejos de donde opera el negocio. El estafador usa entonces bots para activar una y otra vez la accion de enviar codigo del sitio, apuntando a numeros de telefono reales que estan en la red de ese operador. Cada uno de esos numeros es una tarjeta SIM activa capaz de recibir un texto, asi que los mensajes no rebotan ni fallan. Llegan.

Como los mensajes se entregan de verdad, no hay ninguna senal de fraude en el lado de telecomunicaciones que lleve a un operador a negarse a enviarlos o a un proveedor de mensajeria a negarse a facturarlos. El operador cobra una tarifa de terminacion por cada mensaje que entrega, y bajo el acuerdo de reparto de ingresos, una parte de esa tarifa vuelve a quien gestiona el trafico de bots. El negocio que paga los mensajes es, desde el punto de vista de la red, simplemente un cliente que pidio el envio de un numero muy grande de textos. Nadie rio arriba tiene un motivo para detenerlo por su cuenta.

Ninguna de las partes que estan rio arriba del negocio esta motivada para detener esto por iniciativa propia, y es un detalle que merece la pena detenerse a pensar. Al operador se le paga por mensajes que realmente esta entregando, asi que en sus registros nada parece incorrecto. La API de mensajeria se sienta entre el negocio y el operador y factura fielmente lo que se le pidio enviar. La responsabilidad de notar que el trafico que llega al formulario de registro no se parece a anunciantes termina recayendo en la unica parte que tiene tanto el motivo como la visibilidad para notarlo: el negocio que paga la factura.

Lo que hace esto atractivo para los estafadores, y caro para un directorio, es que nada de esto requiere una cuenta real. El bot no necesita completar la verificacion, no necesita publicar un anuncio, y el codigo no necesita escribirse nunca en una casilla. Solo necesita que el formulario del sitio acepte un numero de telefono y despache un mensaje. Un flujo de registro que nunca termina una sola verificacion exitosa puede seguir generando un mes entero de trafico facturable.

Por que la factura llega antes que cualquier otra cosa

La mayoria de las API de SMS y verificacion, entre ellas la de Twilio, cobran por mensaje enviado o intentado, no por verificacion realmente completada. Ese modelo de facturacion no es un fallo de diseno especifico de un proveedor: es como la red telefonica subyacente ya le cobra al negocio por entregar un mensaje, y la API simplemente traslada ese coste. El efecto practico es que una campana de fraude le cuesta dinero al operador desde el primer mensaje, horas o dias antes de que alguien note que la tasa de finalizacion en el formulario de registro se ha derrumbado en silencio.

La escala que esto puede alcanzar no es teorica. En diciembre de 2022, Elon Musk declaro publicamente, durante una sesion de Twitter Spaces, que Twitter perdia unos sesenta millones de dolares al ano exactamente por este esquema, y nombro a unos 390 operadores de telecomunicaciones que segun el estaban implicados en inflar trafico fraudulento de autenticacion en dos pasos hacia la plataforma. Esa cifra fue una afirmacion propia de Musk, no una revelacion corporativa auditada, pero la respuesta fue real y se reporto mucho mas alla del marketing de prevencion de fraude: Twitter corto lazos con los operadores cuyo trafico parecia fraudulento, y meses despues restringio la autenticacion en dos pasos gratuita por SMS a los suscriptores de pago precisamente por el coste. Una empresa con el volumen y el personal tecnico de Twitter aun tardo meses en notarlo y reaccionar. Un directorio que funciona con una unica cuenta de mensajeria independiente, sin un equipo antifraude leyendo los registros cada manana, tiene mucho menos aviso incorporado.

El numero que realmente revela el fraude no es el volumen de mensajes enviados, ya que un impulso de marketing real o una semana genuinamente ocupada tambien pueden elevar ese numero. Es la proporcion entre codigos enviados y codigos introducidos con exito. Una tasa de finalizacion que baja en silencio respecto a su valor habitual, incluso mientras el volumen total sube, es la senal de que el trafico que llega al formulario no esta hecho de personas que pretenden terminar de registrarse.

Por que un formulario de anuncios abierto es exactamente el perfil objetivo

Un directorio de anuncios tiene una razon estructural para hacer facil de alcanzar el boton de enviar codigo: cualquier friccion anadida al registro de un anunciante primerizo cuesta conversiones, y este blog ya ha explicado por que esa friccion merece protegerse con cuidado justo en la puerta incluso antes de que el pago entre en escena. Un paso de verificacion telefonica rapido y acogedor para un anunciante legitimo es, por el mismo diseno, rapido y acogedor tambien para un bot que no tiene ninguna intencion de convertirse en uno.

La exposicion tambien es mas aguda para un operador pequeno e independiente de lo que parece desde fuera. Una gran plataforma negocia precios por volumen y suele tener un contrato que incluye cierto monitoreo antifraude como parte de la relacion. Un directorio que hace pasar su flujo de registro por una API de mensajeria estandar de pago por uso no tiene ese colchon: cada mensaje fraudulento se factura a la misma tarifa por mensaje que cualquier mensaje legitimo, directo a la tarjeta registrada, sin nada que absorba el pico hasta que un humano nota la factura.

Nada de esto significa que bloquear un prefijo de pais sea una decision para fijar una vez y olvidar. Un directorio que se expande a una nueva ciudad, o que capta anunciantes que viajan, puede encontrarse con un grupo legitimo de registros detras de un prefijo que se bloqueo por buenas razones un ano antes. Tratar la lista de prefijos restringidos como algo para revisar cada pocos meses, junto con todo lo demas que se revisa con ese ritmo, evita que la defensa se convierta en silencio en una segunda fuente de registros perdidos.

Este es un fallo distinto del que este blog describio cuando trato por que un correo de verificacion a veces nunca llega a la bandeja de entrada de un anunciante. Aquella pieza trataba de un mensaje que falla en silencio, sin costar mas que un registro perdido. Esta trata de un mensaje que tiene exito ruidosamente, llegando exactamente como estaba previsto, y costando dinero real cada una de las veces que lo hace.

Que lo detiene realmente

La primera capa es limitar la tasa en la propia accion de enviar codigo, aplicada en el servidor y no confiada al navegador: un tope estricto de cuantos codigos puede pedir una sola direccion IP, sesion o numero de telefono en una ventana corta. Por si sola no detendra una red de bots distribuida en muchas direcciones IP, pero elimina la version mas barata y perezosa del ataque y obliga a lo que sea mas persistente a trabajar mas.

La segunda capa es una comprobacion antibot colocada antes de que se dispare la accion de envio, no despues: algo que confirme que fue un humano quien activo la solicitud sin pedirle que resuelva nada molesto, como un desafio invisible que puntua la solicitud en segundo plano. Como todo el fraude depende de activar envios de forma automatica y a gran volumen, cualquier cosa que ralentice de forma significativa la activacion automatica reduce directamente el coste del ataque, aunque deje pasar algunos bots.

La tercera capa es aplicar friccion, no necesariamente un bloqueo total, a los prefijos telefonicos que la base real de anunciantes de un directorio practicamente nunca usa. Un sitio que atiende ciudades de un solo pais tiene pocos motivos para aceptar, sin una segunda comprobacion, una ola de solicitudes de verificacion dirigidas a un prefijo de pais donde la base de anunciantes nunca ha tenido presencia significativa.

La cuarta capa es activar cualquier proteccion antifraude que el proveedor de mensajeria ya ofrezca, en lugar de asumir que la configuracion predeterminada ya lo cubre. Twilio, por poner un ejemplo concreto, ofrece una funcion llamada Verify Fraud Guard que analiza los patrones de trafico para detectar y bloquear automaticamente la actividad sospechosa de pumping, y viene activada por defecto para los clientes de Verify, con niveles de proteccion ajustables que cambian una pequena tasa de falsos positivos por una tasa mas alta de bloqueo. Confirmar que una funcion asi esta encendida, y ajustada a un nivel apropiado para el trafico real del sitio, no cuesta nada y detecta lo que la propia logica del sitio pasara por alto.

La quinta capa es una alerta de gasto configurada directamente con el proveedor, no descubierta un mes despues en una factura. Un umbral que dispara una notificacion en cuanto el gasto diario en mensajeria supera un nivel sin una explicacion ordinaria convierte una campana de fraude que de otro modo correria en silencio durante semanas en una que se nota en cuestion de horas.

Que hacer esta semana

Saca los registros de mensajeria del mes pasado y calcula la proporcion real entre codigos enviados y codigos verificados con exito, no solo el volumen total. Un numero que parece correcto en conjunto puede seguir escondiendo una semana concreta o un prefijo de pais concreto donde la proporcion se derrumbo. Ese unico calculo le dira a un operador mas sobre si este fraude ya esta ocurriendo que cualquier otra cosa en esta pieza.

Despues comprueba tres ajustes directamente con el proveedor de mensajeria: si una proteccion antifraude como Fraud Guard esta activa y en que nivel, si existe una alerta de gasto y en que umbral, y si el endpoint de enviar codigo tiene un limite de frecuencia en el servidor que no dependa de nada que se le pueda decir al navegador que ignore. Ninguna de estas tres comprobaciones requiere software nuevo ni una nueva relacion con un proveedor, solo el tiempo de preguntarle directamente al proveedor y leer la respuesta que llega.