Un cliente detectó una cantidad anormal de registros en sus formularios. Los nombres eran falsos, los mensajes eran promocionales, y los datos no correspondían a ningún lead real. Estaban contaminando las métricas y ensuciando la base de datos.
La hipótesis inicial era la típica: bots entrando en los formularios.
Lo primero que hizo el equipo: asumir que eran bots
Con esa hipótesis encima de la mesa, tomaron tres acciones en orden: una automatización en ActiveCampaign para filtrar y etiquetar los registros sospechosos, un honeypot en el formulario de Elementor, y finalmente CAPTCHA.
Spoiler: Ninguna de las capas lo detuvo, lo que viene siendo una m*. Los registros seguían entrando y las métricas del lanzamiento seguían contaminadas.
Me parecía raro que tres acciones distintas, aunque superficiales, no frenaran nada. Eso me sugería que el problema no venía por donde se estaba mirando, por lo que desplegar más capas de protección sin saber el origen, solo añadiría capas sobre una teoría equivocada.
Así que empecé a mirar a nivel de servidor.
La investigación en tres capas
Capa 1: AWStats
Revisé los robots, los hosts y la actividad general, pero no veía nada raro. Aparecían los bots habituales: Googlebot, AhrefsBot, SemrushBot, YandexBot, y algunos genéricos con user-agent vacío o Go-http-client. Se lo pasé a la IA por si se me había escapado algo, pero solo había actividad de bots, nada que explicara el volumen de registros falsos por sí solo.
Conclusión provisional: aquí no podía estar la respuesta.
Capa 2: Access logs (raw)
Descargué el log sin procesar y encontré muchos accesos legítimos desde Facebook, Instagram y móviles reales, lo normal porque estabamos en campaña.
También había un volumen alto de peticiones POST /wp-admin/admin-ajax.php (el endpoint que usa Elementor para enviar formularios), lo que confirmaba actividad sobre los formularios, pero no identificaba quién generaba el spam.
Capa 3: Los registros del formulario
Ya con la mosca detrás de la oreja, si no había nada llamativo en la actividad general del servidor, había que tirar por otro lado, así que empecé a investigar los registros que habían llegado a Activecampaign.
Exporté en CSV con los registros del formulario clasificados como spam, y ¡premio!
Al agrupar los registros por IP, el resultado fue:
- 403 registros falsos totales
- 396 procedían de una única IP:
146.19.XXX.XX
¡Aquí está! La causa raíz.
Al volver a AWStats con esa IP concreta, ya aparecía entre las más activas del sitio, por lo que no era una coincidencia: era tráfico real, continuado, desde el 22 de mayo hasta el 1 de junio.
La solución
Una vez identificado la causa raíz, la solución fue directamente el bloqueo de la IP desde el panel del hosting.
Además, revisé Imunify360, que ya estaba activo en modo eliminador y bloqueando otras IPs sospechosas. El hosting tenía protección a nivel servidor que ya funcionaba y solo faltaba actuar sobre esta IP concreta.
El resumen de los pasos para llegar hasta aquí fueron:
- Exportar los registros del formulario identificados como spam, NO los usuarios reales.
- Analizar el contenido con una IA para confirmar que era spam.
- Agrupar por IP.
- Correlacionar con los logs del servidor.
- Bloquear el origen.
El estado actual y la incógnita pendiente
A día de hoy la IP principal está bloqueada, Imunify360 activo y los registros se monitorizaron durante 24h.
La verdad es que tuvimos la suerte de que con el bloqueo de la IP, finalmente los registros falsos dejaron de entrar. Sin embargo, no dejo de preguntarme ¿cambiará el atacante su IP para seguir dando por saco?
Lo que esto me dejó claro
El problema parecía que no teníamos las capas de protección suficiente para evitar el spam en WordPress y resultó ser un problema de identificación de origen: una sola IP generando el 98% del spam.
Habíamos asumido lo obvio. Sin embargo, cuando nada funcionó el siguiente paso era cuestionar nuestra hipótesis e investigar realmente el origen.
Cuando algo no funciona después de varios intentos, el problema rara vez es que faltan más herramientas. Casi siempre es que la hipótesis inicial estaba mal planteada. Parar, cambiar la pregunta y mirar los datos desde otro ángulo es, en la mayoría de los casos, más efectivo que seguir apilando soluciones sobre un diagnóstico equivocado.
El proceso es replicable en cualquier instalación con acceso a cPanel y exportación de registros.