Los sitios WordPress reciben ataques solo por estar en línea: 356 ataques en 7 horas
Un sitio WordPress no necesita visitas, contenido ni backlinks para recibir ataques. El 6 de septiembre de 2026, 21 honeypots WordPress nuevos que nadie conocía recibieron 356 ataques de 84 direcciones IP en siete horas, y el primer ataque llegó 15 minutos después de la puesta en marcha.
Aviso para todos los propietarios de sitios: nadie sabía que estos 21 sitios existían. Ningún enlace, ningún buscador, ninguna visita. Aun así, los 21 recibieron ataques, unos 17 cada uno en una sola tarde. Tu sitio recibe el mismo tráfico desde el día en que se publica. Protege wp-login.php, xmlrpc.php y la API REST el mismo día de la instalación.
Ninguno de los 21 dominios estaba enlazado, enviado a un buscador ni mencionado en ningún sitio. La única huella pública era un certificado TLS recién emitido. Si quieres observar el mismo tráfico en tu propio servidor, sigue la guía del Honeypot Server.
¿Cuánto tardan los atacantes en encontrar un sitio WordPress nuevo?
Los atacantes encontraron los sitios nuevos en 15 minutos. La flota se puso en marcha entre las 12:30 y las 12:45 UTC, y la primera detección en uno de los hosts nuevos se registró a las 12:49:57 UTC. En la hora de las 13:00 UTC llegó una primera oleada. La hora con más actividad del día fue la de las 16:00 UTC, con 150 ataques.
¿Cómo podía alguien saber que los hosts existían? Cada certificado emitido por Let’s Encrypt se publica en segundos en los registros de Certificate Transparency públicos. Los escáneres se suscriben a esos flujos y sondean cada nombre de host nuevo en cuanto aparece. Es la vía más probable en este caso: sin backlinks, sin ping de sitemap, sin visitas de rastreadores antes de emitirse el certificado y con un escaneo completo 15 minutos después.
¿Cómo son 356 ataques contra un sitio WordPress nuevo?
Todas las cifras cubren el 6 de septiembre de 2026, de 00:00 a 19:30 UTC, en los 21 hosts. Veinte hosts se pusieron en marcha a mediodía; otro llevaba meses funcionando y se unió a la flota ese día. Las IP de nuestra propia monitorización y puesta en marcha están excluidas.
| Ruta | Peticiones | Qué busca la petición |
|---|---|---|
/?rest_route=/batch/v1 | 64 | Exploit REST batch wp2shell (CVE-2026-63030) |
/xmlrpc.php | 28 | Abuso de XML-RPC e intentos de inicio de sesión multicall |
/author/admin/ | 23 | Enumeración de usuarios |
/wp-login.php?action=lostpassword | 22 | Abuso del restablecimiento de contraseña |
/wp-config.php.bak | 15 | Copia de seguridad de la configuración de WordPress |
/.git/config | 11 | Repositorio Git expuesto |
/wp-content/debug.log | 11 | Registro de depuración con rutas y trazas de pila |
El archivo de entorno /.env se solicitó más de 40 veces, y tres variantes (.env.local, .env.example, .env.production) sumaron 10 peticiones más. Las cifras proceden de los registros de los propios honeypots. La base de datos central de ReportedIP muestra el mismo día como 116 reportes de 76 direcciones, porque las peticiones repetidas de una misma dirección en un intervalo corto se agrupan en un solo reporte.
Como referencia: nuestro primer honeypot reporta desde finales de febrero de 2026 y había enviado 36 206 reportes cuando se unió a la flota. Las cifras trimestrales de toda la red están en el informe de ataques a WordPress.
¿Por qué wp2shell es el ataque más frecuente contra sitios WordPress nuevos?
El exploit REST batch de wp2shell fue la detección más frecuente: 69 detecciones en siete horas, en hosts que existían desde hacía menos de un día. WordPress corrigió el fallo el 17 de julio de 2026, y aun así los escáneres lo prueban en cada sitio nuevo que encuentran. Quedó por delante de la búsqueda clásica de .env, el abuso de XML-RPC (27 detecciones) y la fuerza bruta contra wp-login (24). La cadena de ataque y las reglas de firewall que la bloquean están en el artículo sobre wp2shell.
Según las categorías de amenazas de ReportedIP, el día se reparte así:
- WP REST API Abuse + WP Core Exploit (34, 37): 58 reportes
- Port Scan + Hacking + WP Config Exposure (14, 15, 58): 53 reportes
- Port Scan + Hacking (14, 15): 30 reportes
- Brute-Force + WP Login Brute Force (18, 31): 24 reportes
- Bad Web Bot (categoría 19): escáneres reconocidos por su user agent
¿A cuántos sitios llega un solo escáner?
33 de las 84 IP atacantes (39 por ciento) alcanzaron más de un host. Una dirección, 157.143.67.218, llegó a 20 de los 21 hosts. 130.12.180.117 cubrió 17 hosts, y tres direcciones de un mismo rango de OVH (158.69.55.148, 158.69.117.45, 158.69.55.82) sumaron 46 peticiones entre las tres.
- 51 IP alcanzaron exactamente un host
- 15 IP alcanzaron dos hosts
- 7 IP alcanzaron tres hosts
- 11 IP alcanzaron entre 4 y 20 hosts
Un sitio aislado ve una sonda y no puede distinguir una petición perdida de una campaña. Muchos sitios que ven la misma dirección en pocos minutos sí pueden. En toda la red, el Confidence Score premia justo eso: una dirección reportada por varias fuentes independientes sube más rápido que una reportada muchas veces por una sola fuente.
¿Cómo desenmascara una spider trap a los bots de escaneo?
Una spider trap es una dirección cebo que una persona nunca ve y que un rastreador respetuoso nunca solicita. Solo llega a ella un bot que extrae todos los enlaces del HTML y los sigue todos. El primer día ocurrió 16 veces, y cada petición se reportó con la categoría Spider Trap. Hive aplica el mismo principio en sitios en producción con rutas señuelo.
Los user agents confirman el cuadro. 192 peticiones llevaban una cadena de Chrome falsa y recortada (Windows NT 10.0 sin el token de Chrome), la mayor flota de escáneres del día. 28 vinieron de una cadena de Android Nexus 5 (un móvil de 2013), 5 de l9scan (leakix.net). 32 peticiones llevaban ClaudeBot/1.0, un rastreador de IA que siguió enlaces a xmlrpc.php y a la página de inicio de sesión y activó los mismos analizadores que un escáner.
¿Qué significa esto para tu propio sitio WordPress?
Los 21 honeypots son frontales WordPress corrientes detrás de dominios corrientes. Nada en ellos atrajo a los escáneres, salvo que estaban accesibles. Los escáneres que leen los registros de certificados tratan tu sitio de la misma manera. Tres consecuencias:
- Protege el sitio antes de que tenga tráfico. Los ataques empiezan antes de que llegue la primera visita. El inicio de sesión, XML-RPC y el endpoint REST batch necesitan protección desde el día de la instalación.
- Bloquea a los atacantes conocidos por su reputación. El 39 por ciento de las IP atacantes alcanzó varios hosts. Una dirección que otros sitios ya han reportado se puede bloquear antes de que llegue a tu formulario de acceso. ReportedIP Hive lo hace con los datos de la comunidad.
- Añade tu propia monitorización a la lista blanca. Una comprobación de disponibilidad con curl se parece exactamente a un escáner. Añade sus IP antes de que se ejecute, o te reportarás a ti mismo.
¿Cómo pones en marcha tu propio honeypot WordPress?
Los 21 hosts usan el ReportedIP Honeypot Server, en la versión 1.3.10 el día de la medición; la versión actual es la 1.4.1. Es una aplicación PHP independiente que imita una instalación de WordPress, Drupal o Joomla. Necesita PHP 8.2 con pdo_sqlite y curl, no tiene dependencias de Composer, guarda todo en SQLite e incluye un Dockerfile. El código fuente está disponible bajo la Business Source License 1.1: puedes usarlo en producción siempre que no lo vendas ni lo ofrezcas como servicio alojado para terceros, y la licencia pasa a Apache 2.0 el 1 de marzo de 2030.
- 40 Threat Analyzers para inyección SQL, path traversal, fuerza bruta, credential stuffing, abuso de XML-RPC, exploits de plugins, acceso a archivos de configuración, sondas de webshell y el exploit REST batch wp2shell
- Honeytokens: las filtraciones de configuración falsas incluyen credenciales canario por IP; quien reutiliza una es malicioso con certeza
- Trampas: una spider trap, un tarpit para inyecciones SQL a ciegas y un área de administración falsa que guarda las cargas de plugins subidas
- Reporte automático a la API de ReportedIP con limitación de frecuencia y backoff exponencial, además de webhooks para tu SIEM, Slack o AbuseIPDB
- Panel de administración para ataques, cargas, honeytokens activados y listas blancas
Para reportar necesitas una Community Access Key. Toda cuenta de ReportedIP incluye una: crea una cuenta gratuita y copia la clave desde tu Dashboard. Hay un detalle de la instalación que importa más que el resto: envía todas las peticiones, incluidos los archivos ocultos y robots.txt, a public/index.php. Los paneles de hosting gestionado suelen responder a /.env con un 403 del servidor web, y entonces las trampas nunca se activan.
Los reportes de los honeypots entran en el mismo conjunto de datos que los de los sitios protegidos por Hive: el Confidence Score de cada IP y la Dynamic Blacklist que descargan las instalaciones de Hive, fail2ban y los firewalls.
Preguntas frecuentes
¿Cómo encontraron los escáneres dominios que nunca se publicaron?
Los escáneres los encontraron muy probablemente a través de los registros de Certificate Transparency. Todo certificado TLS de confianza pública queda registrado allí, y esos registros se pueden leer en tiempo real. Un nombre de host nuevo con un certificado reciente es visible para cualquiera que vigile el flujo; por eso la primera sonda llegó 15 minutos después de la puesta en marcha.
¿Es un ataque una petición a /.env en mi sitio WordPress?
Una petición a /.env es siempre hostil. Ningún navegador, plugin o buscador tiene motivos para pedir ese archivo. El 6 de septiembre de 2026 se solicitó más de 40 veces en la flota, más 10 veces en variantes. Asegúrate de que tu servidor web no devuelva nada aprovechable.
¿Reportará el honeypot mis propias comprobaciones de disponibilidad?
El honeypot reporta tus comprobaciones de disponibilidad mientras no las añadas a la lista blanca. Añade las direcciones IPv4 e IPv6 de tus sistemas de monitorización y administración durante la instalación, antes de que se ejecute la primera comprobación. Una sonda de disponibilidad con curl parece un escáner para los analizadores y se reporta como tal.