Todo empezó con un mensaje que no encajaba. Hace unas horas, una clienta me escribió por WhatsApp bastante preocupada porque estaba recibiendo una gran cantidad de correos en muy poco tiempo. Todos dirigidos a una cuenta que, en teoría, nadie conocía.

No era una cuenta pública ni visible en la web. Era simplemente la dirección que configuré en su momento en el hosting, para el envío de correos mediante SMTP desde el formulario de contacto y las notificaciones de la web. Una cuenta técnica que no debería recibir tráfico externo.

Ahí ya había algo que no encajaba.

El primer indicio: un exceso de envíos desde el servidor

Decidí revisar el hosting y encontré el primer dato relevante. En determinados momentos de días anteriores, esa cuenta había superado el límite diario de envíos permitido. No era un pico aislado, era un patrón repetido en varias franjas horarias.

Al acceder a la bandeja de entrada, la situación se volvió aún más clara. Todos los mensajes eran correos de rebote con asuntos del tipo “Mail delivery failed” o “Undelivered Mail Returned to Sender”, y el contenido apuntaba siempre al mismo problema: direcciones inexistentes o buzones que no podían recibir mensajes.

Descartando el factor humano

La siguiente pregunta era obligada. Le pregunté a la clienta si había realizado algún envío masivo desde esa cuenta y la respuesta fue inmediata: no.

En ese momento, descarté el factor humano y empecé a pensar que aquello se estaba generando desde la propia web.

La primera sospecha dentro del panel

Al acceder al panel de administración de WordPress, para revisar lo que estaba ocurriendo, me encontré con un detalle que me hizo detenerme un segundo. Aparecía un aviso de seguridad de WooCommerce relacionado con una vulnerabilidad reciente en su Store API y posibles implicaciones de tipo CSRF.

No era una alerta alarmante, pero sí lo suficientemente relevante como para hacerme pensar si aquello podía estar conectado con el problema que estaba investigando. No tenía pruebas, solo una sospecha, así que decidí no sacar conclusiones precipitadas y seguir revisando.

Y fue entonces cuando apareció el verdadero problema.

El hallazgo: más de 1.000 usuarios falsos en pocos días

En la sección de usuarios había más de mil nuevas cuentas registradas en apenas tres días, todas con direcciones de correo inexistentes y asignadas automáticamente con el rol de cliente.

No había nombres coherentes, ni patrones humanos y no había ninguna acción legítima que justificara ese volumen de registros.

Qué estaba ocurriendo realmente

Cada vez que WooCommerce registra un nuevo usuario, envía automáticamente un correo de confirmación. En este caso, esos correos se estaban enviando a direcciones falsas, lo que provocaba un rebote constante que terminaba saturando la cuenta de correo y superando los límites del servidor.

La web estaba enviando correos de forma masiva, pero no porque alguien estuviera utilizando el sistema de manera legítima, sino porque un bot estaba generando registros falsos de forma automatizada.

Un detalle importante: no era una tienda activa

Conviene aclarar un punto clave. Esta web no tenía la tienda activa, ya que desde hacía meses funcionaba únicamente como catálogo, sin pasarelas de pago ni procesos de compra.

Eso significa que no había tarjetas, no había pedidos y no había transacciones en curso.

Y aun así, estaba siendo atacada.

Qué tipo de ataque parece

El comportamiento encaja con un ataque automatizado de creación masiva de cuentas falsas, una práctica relativamente común cuando un sitio permite el registro de usuarios sin mecanismos adicionales de protección como CAPTCHA o validaciones más estrictas.

Este tipo de automatización no busca necesariamente acceder a la web, sino aprovechar sus funcionalidades internas para generar carga, enviar correos o detectar posibles debilidades.

Cómo solucioné el problema

Una vez identificado el origen, el siguiente paso fue aplicar una serie de medidas para frenar el ataque y evitar que se repitiera.

Actualicé el núcleo de WordPress, el tema activo y todos los plugins relacionados, incluyendo WooCommerce y sus extensiones como PayPal Payments. Implementé Google reCAPTCHA en el plugin Paypal Payments, tal como sugería hace unos días la plataforma Paypal y desactivé la posibilidad de crear cuentas de usuario, ya que en modo catálogo no era necesario.

También revisé las medidas de seguridad del hosting, en este caso Profesional Hosting, que cuenta con herramientas específicas para detectar vulnerabilidades y reforzar la seguridad en instalaciones WordPress. Este sistema me indicó una vulnerabilidad en un plugin de YITH, que en el modo catálogo tampoco sería necesario. Así que también lo desactivé, de forma preventiva.

Conclusión: no hace falta vender para ser un objetivo

Este caso deja una conclusión bastante clara. Una web no necesita vender, ni procesar pagos, ni tener un tráfico elevado para convertirse en un objetivo.

Los ataques automatizados no buscan negocios concretos, buscan sitios vulnerables. Cuando encuentran uno, actúan sin necesidad de intervención humana.

¿Necesitas revisar la seguridad de tu web?

Si gestionas una web con WooCommerce o cualquier sistema que permita registros de usuarios y no tienes claro si está protegida frente a este tipo de situaciones, puedo ayudarte a revisarla antes de que el problema aparezca. Escríbeme sin compromiso.