Francisco Pérez
Actualizado: 2026-10-04
Si aumentan los SMS de verificación y el gasto, pero no los registros o accesos completados, conviene investigar el tráfico. El SMS pumping consiste en provocar envíos artificiales que generan costes para la empresa. Ese patrón puede confundirse con una campaña comercial, un problema de entrega o un bucle de reintentos.
Esta guía explica cómo relacionar los datos, prevenir el abuso y comprobar los controles de envío. Si el gasto ya está creciendo de forma anómala, consulte primero qué hacer durante un ataque .
Qué es el SMS pumping y cómo genera costes
El SMS pumping, también llamado bombeo de SMS , abusa de formularios o API que activan mensajes, como el registro, el inicio de sesión o la recuperación de contraseñas. Las solicitudes no responden a una necesidad real de verificación: buscan generar tráfico de pago.
En este fraude, los atacantes pueden obtener una parte de los ingresos asociados al tráfico. Twilio describe este mecanismo y distingue situaciones en las que el operador participa y otras en las que es explotado sin saberlo. No implica que todos los operadores estén involucrados ni que el destino deba ser un número de tarificación especial.
La expresión tráfico inflado artificialmente , o AIT por sus siglas en inglés, describe el volumen creado sin demanda legítima. Un número puede existir y recibir el SMS correctamente: eso no demuestra que la solicitud sea auténtica.
El objetivo también difiere del smishing , que intenta engañar al destinatario, y del bombardeo de mensajes dirigido a molestar a una persona. Aquí el problema central es la generación de tráfico facturable.
Cómo detectar anomalías en el tráfico de SMS OTP
Compare envíos, verificaciones y gasto por mercado y por flujo: registro, acceso o recuperación. Las siguientes señales sirven para orientar la investigación; ninguna confirma por sí sola un fraude.
| Señal | Qué revisar | Otra explicación posible | Acción inicial |
|---|---|---|---|
| Más envíos sin más verificaciones | Flujos iniciados y completados | Retrasos de entrega o fallos del registro | Relacionar estados y resultados del negocio |
| Concentración en destinos nuevos | Países y rangos con más solicitudes | Lanzamiento en otro mercado | Contrastar con la actividad prevista |
| Más reenvíos por flujo | Intentos e intervalos | Bucle de reintentos o mala entrega | Revisar la lógica de reenvío |
| Patrones repetidos | Cuenta, sesión, dispositivo e IP | Usuarios de una red compartida | Correlacionar señales antes de bloquear |
| El coste crece más que el volumen | Destinos, tarifas y unidades facturadas | Cambio en la mezcla de destinos | Desglosar el gasto |
De dónde obtener los datos: el backend registra la petición; la plataforma informa del envío; el sistema de negocio confirma si se completó el registro o el acceso. Conviene conservar estas etapas por separado.
| Dato | Fuente recomendada | Relación que guardar | Precaución |
|---|---|---|---|
| Solicitudes, bloqueos previos y reenvíos | Registros del backend | ID del flujo e ID de cada intento | Una solicitud no equivale a un envío |
| Aceptación, envío y entrega | Respuesta de API, mensajes y callbacks | ID del flujo, ID del mensaje y canal | Son estados distintos |
| Verificación y resultado del negocio | Resultado de verificación y eventos de registro o acceso | ID del flujo y evento de negocio | Validar el código no implica completar el registro |
| Gasto | Facturación; campos de coste cuando estén disponibles | Mensaje o unidad facturada y periodo | La ausencia de coste no significa coste cero |
Como diseño de registro, genere un ID propio para cada flujo y asocie sus intentos de envío. Cuando la plataforma devuelva un ID de mensaje, guarde la correspondencia: un flujo puede tener varios mensajes . Si un intento se rechaza sin devolver ese ID, conserve igualmente el registro de la petición y su error.
La documentación de callbacks de OTP distingue sent ,
delivered y verified , e incluye message_id . Los campos de facturación solo aparecen
cuando hay facturación. Al procesar eventos, contemple duplicados y cambios de orden; no cuente cada callback como un SMS ni sume dos veces una misma unidad facturada.
Para un grupo de flujos con al menos una solicitud de envío SMS aceptada, puede calcular:
(Flujos de ese grupo que completan la verificación ÷ total de flujos del grupo) × 100
Esta es una propuesta de análisis, no una métrica predeterminada del proveedor. Use una ventana que permita completar el flujo y cuente aparte los bloqueos previos. Si un canal alternativo completa la verificación, identifíquelo: el indicador mide el resultado del flujo, no la entrega del SMS. La respuesta inicial indica el canal actual, no acredita el de entrega final; compruebe los eventos. Sin una relación fiable entre flujos y mensajes, primero hay que corregir la recogida de datos.
Por ejemplo, ante más envíos y menos verificaciones en un mercado, revise primero los fallos de entrega y los reintentos del mismo flujo. Después contraste destinos y patrones con la demanda prevista. Un problema técnico también puede aumentar el gasto.
Cómo prevenir el abuso antes de enviar un SMS OTP
La prevención empieza antes de la llamada que activa el mensaje. El equipo de la aplicación controla el contexto de negocio; los controles del proveedor añaden otra capa, según las capacidades disponibles.
Validar la solicitud y limitar los reintentos en el backend
Compruebe que la petición pertenece a un flujo válido. Un registro puede empezar sin una cuenta autenticada, pero debe tener una sesión o contexto válido. Valide en el servidor el resultado de los controles contra bots y aplique límites por cuenta, sesión o dispositivo. El contador del frontend no sustituye al control del backend.
Un CAPTCHA puede reducir solicitudes automatizadas, pero no determina por sí solo el riesgo del destino. La defensa por SMS de reCAPTCHA , por ejemplo, utiliza una evaluación específica antes del envío. Si se añade una herramienta especializada, hay que comprobar sus requisitos de integración, coste y efecto sobre usuarios legítimos.
Restringir los destinos al alcance real del negocio
Permita los mercados atendidos y defina cómo evaluar excepciones, como usuarios internacionales. La validación del formato evita errores básicos, pero no acredita que un número sea seguro. Evite abrir todos los destinos para resolver una incidencia aislada.
Vigilar el volumen, el coste y la estrategia de canales
Para ajustar los umbrales, use el comportamiento normal del servicio como referencia:
- Separar escenarios. Revisar solicitudes y reenvíos habituales en registro, acceso y recuperación.
- Analizar cada mercado. Incluir picos previstos, campañas y reintentos legítimos; no adoptar una cifra universal.
- Distinguir alerta y límite. Dejar margen entre ambos según el ritmo de crecimiento y el tiempo de respuesta del equipo.
- Revisar el gasto aparte. Una cuota diaria o mensual limita el volumen acumulado; los picos breves requieren límites de frecuencia. El mismo volumen puede tener costes distintos según el destino.
- Evaluar cada ajuste. Comparar gasto anómalo, finalización de usuarios legítimos, reenvíos y consultas a soporte por escenario y mercado.
OWASP recomienda adaptar la limitación a las necesidades del negocio y establecer límites de gasto para servicios externos o alertas de facturación cuando no sea posible. Una cuota de mensajes no debe presentarse como un presupuesto monetario.
La siguiente distribución ayuda a asignar responsabilidades:
| Control | Responsable | Dónde se aplica | Comprobación |
|---|---|---|---|
| Contexto y señales de bots | Equipo de la aplicación | Backend, antes de enviar | Las peticiones sin contexto válido se detienen |
| Cuenta, sesión y dispositivo | Equipo de la aplicación | Entrada de cada flujo | Se limitan los intentos relacionados |
| Frecuencia por número e IP | Integración y proveedor | Controles de envío y datos transmitidos | El límite recibe los datos necesarios y actúa |
| Destinos permitidos | Negocio e integración | Backend y controles del proveedor | El alcance coincide con los mercados atendidos |
| Alertas y cuotas de volumen | Operaciones e integración | Envío y recepción de notificaciones | La alerta llega y la cuota se aplica |
| Costes y usuarios afectados | Operaciones y producto | Facturación y eventos relacionados | Se detectan gasto anómalo y posibles bloqueos incorrectos |
Un bloqueo no confirma automáticamente un fraude. Si aumentan las incidencias de usuarios legítimos, revise la regla y sus señales antes de ampliar las restricciones. Los canales alternativos también necesitan controles de riesgo y coste; no deben servir para eludir una decisión de bloqueo.
Qué hacer si el ataque ya está en curso
Durante una anomalía activa, la prioridad es contener los envíos y conservar información para decidir qué puede recuperarse.
-
Acotar el tráfico
Identificar aplicación, entrada, destinos y periodo afectados. Contrastar solicitudes, estados y gasto.
-
Contener los envíos
Aplicar restricciones disponibles o pausar SMS si el gasto sigue creciendo. Confirmar el alcance y el impacto sobre verificaciones legítimas.
-
Conservar los registros
Guardar intentos, mensajes, errores, facturación y cambios de configuración. Evitar reintentos o canales alternativos que prolonguen el abuso.
-
Corregir el origen
Revisar la entrada y la lógica de reenvío. Deshabilitar o rotar credenciales si hay indicios de filtración; la rotación no corrige por sí sola un formulario vulnerable.
-
Reanudar con supervisión
Tras corregir la causa y comprobar un flujo legítimo, recuperar un alcance controlado y observar solicitudes, gasto y finalización.
Antes de retirar restricciones, compruebe que la causa y la configuración están revisadas y que los reintentos no reabren el problema. Defina quién autoriza la recuperación y quién vigila sus resultados.
Cómo configurar y comprobar los controles en EngageLab OTP
En EngageLab OTP , la implementación combina controles de la aplicación y configuración de envío. La guía para evitar el abuso de la API exige realizar las llamadas desde el servidor y mantener allí las credenciales.
Preparar la integración y los límites de frecuencia
Distinga los dos tipos de IP: la lista de IP permitidas de la API Key contiene las IP de salida del servidor ; el parámetro
end_user_ip corresponde a la IP del usuario final . Obtenga ese dato mediante la infraestructura de confianza de su aplicación; sustituirlo por
la IP del servidor agruparía peticiones de usuarios distintos.
Active los límites por número y, si se usa el control por IP, incluya end_user_ip en la solicitud. El
Centro de seguridad documenta estos controles por ventanas de tiempo. Las comprobaciones de
sesión, cuenta y dispositivo siguen correspondiendo al backend.
Configurar los destinos, las alertas y las cuotas
Configure la lista de países o regiones permitidos o bloqueados. Después defina los valores diarios o mensuales de alerta y límite: la alerta avisa sin pausar; el límite detiene el envío SMS al alcanzarse. Son umbrales de volumen .
Para recibir las notificaciones, configure los eventos correspondientes en Webhook callbacks . Compruebe la recepción por el equipo responsable, además de la conectividad del endpoint. El gasto se supervisa por separado mediante los datos de facturación.
Preparar la parada de emergencia y validar los cambios
La parada descrita en el Centro de seguridad pausa el SMS de toda la aplicación . Prepare su uso y recuperación considerando ese alcance. En esa guía, las secciones de seguridad de WhatsApp, Voice y Email figuran como «Próximamente»; confirme sus controles por separado antes de utilizarlos.
La aplicación también debe interpretar las respuestas. La referencia de envío de OTP distingue estos errores:
| Código | HTTP | Motivo | Acción del backend |
|---|---|---|---|
| 6001 | 429 | Frecuencia del mismo número | Detener el reintento inmediato y respetar la ventana aplicable |
| 6002 | 429 | Frecuencia de la IP del usuario | Detener el reintento inmediato y comprobar el límite y end_user_ip |
| 6003 | 429 | Cuota global diaria o mensual | Detener reintentos y revisar cuota y periodo |
| 6007 | 403 | Envío SMS suspendido | Detener reintentos y comprobar la suspensión y su causa |
Decida según el campo code , no según el texto de message . Un HTTP 429 no tiene siempre la misma causa. Tras alcanzar una
cuota, las peticiones posteriores pueden devolver 6007. No reintente inmediatamente en bucle ni active otro canal de pago para esquivar el rechazo. Muestre un plazo de espera solo cuando se conozca;
para una suspensión, informe de la indisponibilidad temporal sin prometer una recuperación automática.
Revise tanto los reintentos de la aplicación como la estrategia de canales de las plantillas. Un rechazo de riesgo y un fallo asíncrono de entrega requieren decisiones distintas. Esta propuesta de pruebas de aceptación debe ejecutarse con números propios, tráfico controlado y umbrales de prueba:
| Prueba | Condición | Resultado esperado | Evidencia |
|---|---|---|---|
| Flujo normal y reenvío permitido | Destino y frecuencia válidos | Verificación completada | Resultado del flujo y estados |
| Límite por número | Límite activo | 6001, sin bucle de reintentos | Respuesta e intentos relacionados |
| Límite por IP | end_user_ip enviado | 6002, sin reintento inmediato | Petición y respuesta |
| Destino no permitido | Lista configurada | Rechazo del envío | Respuesta y registros |
| Alerta de volumen | Callback y receptor definidos | Notificación recibida | Evento y recepción |
| Cuota global | Cuota y periodo definidos | 6003 y cese de reintentos; posible 6007 posterior | Respuestas e intentos |
| Pausa y recuperación | Causa y alcance revisados | 6007 durante la pausa; flujo legítimo tras recuperar | Respuesta y resultado |
| Rechazo con canales alternativos | Estrategias revisadas | No se elude el rechazo con otro canal de pago | Intentos y eventos de todos los canales |
| Ajuste de umbrales | Escenarios y mercados comparables | Impacto sobre usuarios legítimos evaluado | Resultados y reenvíos antes y después |
Preguntas frecuentes
¿Puede haber SMS pumping si los mensajes se entregan correctamente?
Sí. La entrega demuestra que el mensaje llegó, no que la solicitud fuera legítima. Hay que relacionarla con la verificación, el contexto y el resultado del negocio.
¿Un CAPTCHA basta para prevenir el SMS pumping?
No. Puede frenar automatizaciones, pero debe combinarse con límites, controles de destino y supervisión del gasto. No equivale por sí solo a evaluar el riesgo del número.
¿Por qué no basta con limitar las solicitudes por IP?
Porque varios usuarios legítimos pueden compartir IP y un atacante puede distribuir las solicitudes. Conviene contrastar número, sesión, dispositivo y comportamiento.
¿Es necesario que se filtre una API Key para sufrir este fraude?
No. Un atacante puede abusar de un formulario que llama correctamente al proveedor desde el backend. Proteger la clave y proteger la entrada son tareas complementarias.
¿Cambiar de canal elimina el riesgo de abuso?
No. Puede cambiar el coste y la forma del abuso. El canal alternativo necesita sus propias comprobaciones y no debe eludir un rechazo de riesgo.
Para avanzar, relacione un flujo real con sus mensajes, compruebe un límite y verifique cómo responde la aplicación. Esa prueba permite revisar a la vez el gasto y la experiencia de los usuarios legítimos.
Definir límites, restringir destinos y preparar alertas para revisar el tráfico de verificación.
