Hace unos días entré al panel de mi blog y encontré algo raro: la lista de suscriptores había crecido de golpe. Cientos de correos que yo no reconocía, muchos de empresas que jamás habrían oído hablar de mi blog, lo que realmente me preocupaba era la confirmación de algunas cuentas. ¿Alguien estaba confirmando suscripciones en nombre de otras personas? ¿Tenían acceso a esos buzones?
Exporté la tabla completa y me puse a analizarla. Este artículo documenta lo que encontré: una campaña automatizada de list-bombing ejecutada desde una pequeña red de proxies alquilados. Spoiler: nadie tiene acceso a nada, pero el mecanismo es interesante y las conclusiones sirven para cualquiera que tenga un formulario de suscripción en internet.
Los números
Entre el 4 y el 11 de julio de 2026 el formulario de suscripción recibió 249 altas falsas. Los datos crudos ya contaban una historia:
| Métrica | Valor |
|---|---|
| Altas de spam | 249 |
| IPs de origen distintas | 18 |
| Redes (ASN) involucradas | 4 |
| Altas que quedaron "Confirmadas" | 66 |
| Tiempo típíco entre alta y "confirmación" | 14 a 55 segundos |
Doscientas cuarenta y nueve altas repartidas en solo 18 direcciones IP no es tráfico orgánico: es un script probablemente en python corriendo en un en un servidor Ruso. La actividad además fue sostenida ocho días seguidos, a toda hora lo que descarta a un humano aburrido y apunta a un scriptcito autmatizado.
Quiénes son las 18 IPs?
Consulté cada IP contra ip-api.com (identidad de red y flags de proxy/hosting) y Scamalytics (puntaje de fraude). El resultado confirmó mi sospecha :
- Las 18 IPs están marcadas como proxy: Ninguna es la conexión doméstica de un lector real.
- 17 de 18 viven en datacenters: de proveedores de VPS baratos; la restante es una IP de operador móvil estadounidense actuando como proxy residencial (una técnica común para que el tráfico de bots parezca doméstico).
- 15 de 18 tienen puntaje de fraude medio o alto en Scamalytics. Las tres restantes puntúan "bajo" solo porque no aparecen en los sensores recientes de ese servicio — siguen siendo VPS anónimos en redes con historial de abuso.
Las cuatro redes:
| Red (ASN) | IPs | Altas | Perfil |
|---|---|---|---|
| ColoCrossing / HostPapa (AS36352) | 9 | 136 | Hosting barato con larga reputación de abuso |
| White Label / Fiba Cloud (AS44382) | 5 | 81 | VPS anónimos (Nueva York y Estambul) |
| Sparked Host (AS397032/397283) | 3 | 18 | Hosting de bajo costo, fraude alto (62/100) |
| Sprint / T-Mobile (AS1239) | 1 | 14 | Proxy residencial sobre red móvil |
El misterio de los "confirmados"
Mi blog usa double opt-in: al suscribirte se envía un correo con un enlace único, y solo quien abre ese enlace queda confirmado. Entonces, ¿cómo había 66 confirmados falsos? ¿El bot tenía acceso a los buzones de las víctimas? No. La pista estaba en los tiempos: la mayoría de las confirmaciones ocurrieron entre 14 y 55 segundos después del alta, a cualquier hora del día. Ningún humano revisa su correo y hace clic en medio minuto a las 4 de la madrugada, todas las veces. Los responsables son los escáneres de seguridad del correo corporativo (Microsoft Defender for Office 365, Barracuda, Mimecast y similares). Estos sistemas abren automáticamente todos los enlaces de los correos entrantes para detectar phishing y como mi página de confirmación validaba el token con una simple visita (una petición GET), el robot de seguridad de la empresa víctima confirmaba la suscripción sin que nadie lo pidiera o los atacantes tienen acceso a esas cuentas, posiblemente para validad si la cuenta sirve y utilizara para SPAM, que es lo mas probable, o es lo que haria yo si fuera un Threat Actor , jajajaj
Dos lecciones acá:
- Un suscriptor "confirmado" no tiene acceso a nada. En un sistema de newsletter, confirmar solo significa "este buzón recibió el enlace y alguien (o algo) lo abrió". No hay cuenta, ni contraseña, ni permisos.
- Nunca ejecutes acciones con efectos secundarios en un GET. La confirmación debe requerir un clic explícito en la página de destino (un POST). Si no, cualquier robot que "mire" el enlace la dispara.
Mi blog no era "el objetivo": era uno de los miles de formularios usados como munición contra las verdaderas víctimas, que son los dueños de esos buzones.
Qué voy a cambiar (y qué deberías revisar en tu formulario)
En orden de impacto:
- Confirmación con POST. El enlace del correo lleva a una página con un botón "Confirmar suscripción"; solo el envío de ese formulario marca la confirmación. Esto neutraliza a los escáneres automáticos.
- Honeypot + fricción invisible. Un campo oculto que los humanos no completan (y los bots sí) filtra la mayoría de las herramientas de spam sin molestar a los lectores. Un desafío ligero (proof-of-work en JS o un CAPTCHA discreto) suma otra capa.
- Reputación de IP en el alta. Rechazar o encolar para revisión las altas provenientes de IPs marcadas como proxy/hosting en los ASN reincidentes.
- Higiene de lista. Purga periódica de pendientes con más de 30 días y monitoreo de picos de altas por IP. Una lista inflada con direcciones ajenas termina en quejas de spam y en la reputación de envío por el piso.
El rate limiting por IP y por correo que ya tenía el formulario ayudó a contener el volumen (ninguna IP superó ~27 altas), pero contra una red distribuida no alcanza por sí solo.
Conclusión
Lo que a primera vista parecía "gente extraña con acceso a cuentas confirmadas" resultó ser una campaña de list-bombing completamente automatizada: 18 proxies alquilados, listas B2B robadas, y escáneres de seguridad corporativos confirmando suscripciones sin querer. Nadie accedió a nada — pero el episodio deja una moraleja de diseño que vale para cualquier aplicación web: toda acción que cambia estado debe exigir una intención explícita. Un GET nunca es una intención.