Los sitios WordPress reciben ataques solo por estar en línea: 422 ataques en 7 horas
Una página web de WordPress no necesita visitantes, contenido ni enlaces entrantes para ser objeto de un ataque. Basta con que exista. El 6 de septiembre de 2026 pusimos en línea 21 Honeypots vacíos de WordPress; en siete horas recibieron 422 ataques procedentes de 85 direcciones IP, el primero de ellos tan solo 15 minutos después de su puesta en marcha.
Advertencia para todos los propietarios de sitios web: nadie sabía que existían estos 21 sitios. Ni un enlace, ni un motor de búsqueda, ni un visitante. Aun así, recibieron unos 20 ataques cada uno en una sola tarde, y los 21 resultaron afectados. Tu sitio web recibe el mismo tráfico desde el día en que se publica, no cuando se hace popular. Protege wp-login.php, xmlrpc.php y la REST API antes del lanzamiento, no después del primer incidente.
Ninguno de los 21 dominios estaba enlazado, registrado en un motor de búsqueda ni mencionado en ningún sitio. El único rastro público era un certificado TLS recién emitido. Para verlo en tu propio servidor, sigue la guía de configuración del Honeypot Server; una instancia estará en funcionamiento en unos diez minutos.
¿En cuánto tiempo encuentran los atacantes una nueva página web de WordPress?
La flota entró en funcionamiento entre las 12:30 y las 12:45 UTC. La primera detección en un servidor totalmente nuevo (web00) se registró a las 12:49:57 UTC. Durante la hora de las 13:00 UTC, los 21 servidores registraron 120 ataques, la mayor oleada del día hasta que se produjo un segundo pico de 150 ataques en la hora de las 16:00 UTC.
¿Cómo se supo de la existencia de esos servidores? Todos los certificados emitidos por Let’s Encrypt se publican en los registros públicos de Certificate Transparency en cuestión de segundos. Los escáneres se suscriben a esos feeds de registros y analizan cada nuevo nombre de host a medida que aparece. Esa es la vía más probable en este caso: sin enlaces entrantes, sin ping al mapa del sitio, sin solicitud del rastreador antes de que se emitiera el certificado y un escaneo completo 15 minutos después.
Así son 422 ataques a un sitio web nuevo de WordPress
Todas las cifras corresponden al 6 de septiembre de 2026, desde las 00:00 hasta las 19:30 UTC, en los 21 servidores. Se excluyen nuestras propias direcciones IP de monitorización. La distribución de las solicitudes fue la siguiente: 335 GET, 80 POST, 4 HEAD y 3 PROPFIND.
| Ruta | Visitas | A qué se refiere la solicitud |
|---|---|---|
/ | 91 | Recuperación de la página de inicio mediante un escáner, identificada a través del agente de usuario y el comportamiento |
/?rest_route=/batch/v1 | 64 | wp2shell, exploit por lotes REST CVE-2026-63030 |
/.env | 47 | Archivo de configuración con las credenciales de la base de datos y de la API (más 10 resultados en .env.local, .env.example, .env.production) |
/xmlrpc.php | 28 | Uso indebido de XML-RPC, intentos de Login con múltiples llamadas |
/author/admin/ | 23 | User Enumeration |
/wp-login.php?action=lostpassword | 22 | Uso indebido del restablecimiento de contraseña |
/secure-vault-q4m8/ | 16 | Trampa para arañas: un enlace invisible para los humanos (véase más abajo) |
/wp-config.php.bak | 15 | Copia de seguridad de la configuración de WordPress |
/.git/config | 11 | Repositorio de Git público |
/wp-content/debug.log | 11 | Registro de depuración con rutas y trazas de pila |
wp2shell es el ataque más frecuente, por delante del robo de archivos .env
La detección más frecuente fue el exploit por lotes REST detrás de wp2shell: 69 detecciones en siete horas, en servidores que llevaban menos de un día en funcionamiento. Esto sitúa a una vulnerabilidad fundamental revelada en julio por delante de el clásico sondeo de .env (40 detecciones; la propia ruta se solicitó 47 veces), el abuso de XML-RPC (27) y el ataque de Brute Force a wp-login (24). En el artículo sobre wp2shell tratamos la cadena de ataque y las Firewall Rules que la bloquean.
Según las Threat Categories de ReportedIP, el desglose diario es el siguiente:
- Bad Web Bot (categoría 19): 82 informes
- WP REST API Abuse + WP Core Exploit (34, 37): 58 informes
- Port Scan + Hacking + Exposición del archivo wp-config (14, 15, 58): 53 informes
- Port Scan + Hacking (14, 15): 30 informes
- Brute Force + WP Login Brute Force (18, 31): 24 informes
Un escáner, 21 objetivos: por qué es importante la correlación en toda la flota
34 de las 85 direcciones IP de los atacantes (el 40 %) afectaron a más de un host. Una dirección IP, la 159.69.198.144, perteneciente a un rango de Hetzner, escaneó los 21 hosts con un total de 66 solicitudes. Una segunda, la 157.143.67.218, llegó a 20 de los 21. La 130.12.180.117 abarcó 17 hosts, y tres direcciones de un rango de OVH (158.69.55.148, 158.69.117.45, 158.69.55.82) obtuvieron 46 aciertos entre todas ellas.
- 51 direcciones IP llegaron exactamente a un host
- 15 direcciones IP llegaron a dos hosts
- 7 direcciones IP llegaron a tres hosts
- 12 direcciones IP llegaron a entre 4 y 21 hosts
Un solo sitio web detecta una sola sonda y no puede distinguir entre una solicitud aislada y una campaña. Sin embargo, veintiún sitios web que detectan la misma dirección IP en el plazo de unos minutos sí pueden hacerlo. El Confidence Score recompensa esto a través de su parámetro de diversidad de fuentes: una dirección señalada por varias fuentes independientes sube más rápido en la clasificación que una señalada muchas veces por una sola fuente.
La trampa de la araña: 16 visitas a un enlace que ningún humano puede ver
Cada página de inicio de un Honeypot contiene un enlace a /secure-vault-q4m8/ que está oculto con display:none. Una persona que navegue por el sitio nunca lo ve. Un motor de búsqueda que analice la página lo ignora. El único cliente que lo solicita es un bot que extrae todos los href en el código HTML y los sigue todos. Eso ocurrió 16 veces el primer día, y cada visita se registró con la categoría «honeytoken». El mecanismo se describe en el artículo sobre Decoy Paths.
Los agentes de usuario lo confirman. 192 solicitudes incluían una cadena de Chrome falsa y truncada (Windows NT 10.0 sin el token de Chrome), lo que supuso la mayor flota de escáneres de un solo día. 66 solicitudes procedían de curl/7.74.0, 28 de una cadena de Android Nexus 5 (un dispositivo de 2015) y 5 de l9scan (leakix.net). 32 solicitudes contenían ClaudeBot/1.0, que el clasificador de bots archiva como agentes de IA en lugar de como atacantes.
Contexto: un solo servidor ha registrado 12 357 ataques
Uno de los 21 servidores, web05, ya llevaba funcionando como un único Honeypot desde principios de septiembre y suma 12 357 ataques registrados. Los otros 20 están en su primer día. Volveremos a publicar las cifras de la flota cuando hayan cubierto un mes completo; las cifras trimestrales se pueden consultar en el WordPress Attack Report.
Qué significa esto para tu propio sitio web de WordPress
Los 21 Honeypots son interfaces de WordPress normales y corrientes detrás de dominios normales y corrientes. No había nada en ellos que llamara la atención de los escáneres, salvo el hecho de que eran accesibles. Las mismas 85 direcciones que los exploraron exploran cualquier otro sitio de WordPress que encuentran en los registros de certificados, incluido el tuyo. Tres consecuencias para tu propio sitio:
- Asegúrate de que el sitio web esté protegido antes de que reciba tráfico. Los ataques comienzan antes de que llegue el primer visitante. El Login, el XML-RPC y el Endpoint de REST por lotes deben estar protegidos desde el mismo día de la instalación.
- Bloquea por reputación, no por incidentes. El 40 % de las direcciones IP de los atacantes afectan a varios servidores. Una dirección que ya haya sido notificada por otros sitios web puede bloquearse antes de que llegue a tu formulario de Login. Eso es lo que hace ReportedIP Hive con los datos de la comunidad.
- Añade tu propio sistema de monitorización a la lista blanca. Una comprobación de disponibilidad realizada con curl se ve exactamente igual que un escáner. Añade sus direcciones IP antes de que se ejecute, o acabarás denunciándote a ti mismo.
Pon en marcha tu propio honeypot con el ReportedIP Honeypot Server
Los 21 servidores ejecutan el ReportedIP Honeypot Server 1.3.10, una aplicación PHP independiente que emula una instalación de WordPress, Drupal o Joomla. Requiere PHP 8.2 con pdo_sqlite y curl, no tiene dependencias de Composer, almacena todo en SQLite y se suministra con un archivo Dockerfile.
- 39 Threat Analyzers para SQL Injection, recorrido de rutas, Brute Force, Credential Stuffing, abuso de XML-RPC, vulnerabilidades en plugins, acceso a archivos de configuración y pruebas de webshell
- Honeytokens: los falsos
.env,.git/configy phpMyAdmin contienen credenciales «canary» específicas por IP; reutilizarlas es un indicio malicioso confirmado - Trampa de araña y tarpit: enlaces ocultos, una ruta trampa en el archivo robots.txt, un tarpit de SQLi ciego y un falso panel de administración «sticky» que captura los payloads de plugins subidos
- Envío automático de informes a la ReportedIP API con Rate Limiting y retroceso exponencial, además de Webhooks para tu SIEM, Slack o AbuseIPDB
- Dashboard de administración para ataques, Payloads, honeytokens activados y Whitelists
Para enviar informes se necesita una Community Access Key. Cada cuenta de ReportedIP incluye una: regístrate y, a continuación, copia la clave de tu Dashboard. Hay un detalle de configuración que es más importante que el resto: redirige todas las solicitudes, incluidos los archivos «dotfiles» y robots.txt, a public/index.php. Los paneles de alojamiento gestionado suelen responder a /.env con un 403 directamente desde el servidor web, y entonces la trampa de detección de fuente nunca se activa. curl -s https://your-honeypot/.env debería devolver el archivo falso, no una página de error.
Los informes de Honeypot se añaden al mismo conjunto que los informes de los sitios protegidos por Hive: el Confidence Score por IP y la Dynamic Blacklist de la que se nutren las instalaciones de Hive, fail2ban y los cortafuegos.
Preguntas frecuentes
¿Cómo han encontrado los escáneres dominios que nunca se han publicado?
A través de los registros de Certificate Transparency. Todos los certificados TLS de confianza pública se registran allí, y los registros se pueden consultar en tiempo real. Cualquier nombre de host con un certificado nuevo es visible para quien siga el flujo de datos, razón por la cual la primera prueba se recibió 15 minutos después de la puesta en marcha.
¿Una solicitud del archivo /.env en mi sitio de WordPress constituye un ataque?
Sí. Ningún navegador, complemento ni motor de búsqueda tiene motivos para solicitar ese archivo. El 6 de septiembre fue la tercera ruta más habitual en toda la flota, con 47 accesos, además de 10 para las variantes de .env. Asegúrate de que tu servidor web no devuelva nada útil para esa ruta.
¿El honeypot registrará mis propias comprobaciones de tiempo de actividad?
Sí, si no las incluyes en la Whitelist. Añade las direcciones IPv4 e IPv6 de tus sistemas de monitorización y administración a la Whitelist durante la instalación, antes de que se ejecute la primera comprobación de estado. Una prueba de disponibilidad basada en «curl» parece un escáner para los analizadores.