Credential stuffing en WordPress: protege el login

Cuando se habla de ataques de fuerza bruta contra WordPress, es fácil imaginar un programa probando admin, 123456 y miles de combinaciones evidentes. Ese ataque sigue existiendo, pero no es el único problema.

En muchos intentos actuales, el atacante no está adivinando una contraseña: prueba una que ya se filtró en otro servicio. Si esa misma combinación de correo o usuario y contraseña se reutilizó en WordPress, puede funcionar al primer intento.

Esto se llama credential stuffing. Es una amenaza especialmente incómoda porque una contraseña compleja no protege por sí sola si ya se usó en otro sitio, acabó en una filtración y sigue siendo válida. La defensa debe combinar contraseñas únicas, segundo factor, control de intentos y revisión de accesos, no depender de una sola medida.

Como contexto específico de WordPress, el informe 2025 de Limit Login Attempts Reloaded registró en su muestra de usuarios premium y micro-cloud un aumento de más del 120% en ataques por dominio entre febrero y diciembre de 2024. Es una métrica de su propia base de clientes, no una estimación de todo el ecosistema, pero confirma que proteger el acceso no es una tarea secundaria.[4]

Qué es credential stuffing y por qué no es fuerza bruta tradicional

No todos los ataques contra una pantalla de acceso funcionan igual. Distinguirlos ayuda a elegir defensas que realmente cubran el problema.

Fuerza bruta: Prueba muchas contraseñas contra una cuenta concreta.
Password spraying: Prueba una contraseña débil y frecuente contra muchas cuentas distintas.
Credential stuffing: Prueba pares de usuario y contraseña obtenidos de filtraciones de otros servicios.

En el último caso, la contraseña puede ser perfectamente válida. El atacante no busca acertarla por probabilidad: comprueba de forma automatizada si la persona la ha reutilizado. Por eso limitar intentos por IP ayuda, pero no basta. Un ataque distribuido puede probar una única vez cada cuenta desde muchas direcciones distintas y parecer tráfico normal.[1][3]

Verizon describe estas listas como ComboLists: colecciones de pares de usuario o correo y contraseña comprometidos que se comparten o venden. Sus datos de 2025 sitúan el uso de credenciales comprometidas como vector inicial de acceso en el 22% de las brechas analizadas.[1]

La consecuencia práctica para una web WordPress es clara: no importa que el sitio nunca haya sufrido una filtración propia. Una contraseña reutilizada en un foro, una tienda, una red social o un servicio SaaS que sí fue comprometido puede acabar probándose contra el administrador de WordPress meses o años después.

De dónde salen las listas de credenciales reales

Las credenciales pueden proceder de filtraciones históricas, campañas de phishing, malware que roba contraseñas guardadas en el navegador o equipos infectados por infostealers. Una vez recogidas, no caducan por sí solas: siguen teniendo valor mientras una parte de las combinaciones continúe funcionando.

Los infostealers merecen atención porque no buscan solo una cuenta. Pueden recopilar credenciales de múltiples servicios guardadas en el mismo navegador o dispositivo. En el análisis de Verizon sobre registros de equipos afectados por este tipo de malware, la mediana de contraseñas distintas por usuario entre servicios fue del 49%. Es decir, la reutilización no es una excepción anecdótica: amplía el número de puertas que puede abrir una sola filtración.[1]

Cloudflare observó entre septiembre y noviembre de 2024 que el 41% de los inicios de sesión humanos exitosos en propiedades analizadas incluía contraseñas comprometidas. Al incluir tráfico de bots, el 52% de las solicitudes de autenticación detectadas contenía contraseñas presentes en su base de credenciales filtradas.[2]

Estos datos no significan que cada login con una contraseña filtrada sea un ataque ni que todas las webs tengan el mismo porcentaje. Sí muestran por qué la política de “cada persona se ocupa de sus contraseñas” no es suficiente para una empresa, una agencia o una web con varios usuarios.

Por qué reutilizar una contraseña multiplica el riesgo

La reutilización transforma una incidencia externa en un problema propio.

Imagina que una persona usa la misma contraseña para su correo personal, una herramienta de diseño, una tienda y el WordPress de su empresa. Si cualquiera de esos servicios expone las credenciales, un atacante puede probarlas en los demás. No necesita saber dónde trabaja esa persona ni preparar un ataque específico: la automatización permite probar grandes listas a bajo coste.[1]

Cambiar una contraseña después de una filtración ayuda, pero hay que cambiarla en todos los servicios donde se hubiera reutilizado. Cambiarla solo en la web que sufrió la brecha deja abiertas las demás cuentas.

Una contraseña fuerte tampoco debe reciclarse. Añadir un número, un signo o el año actual a una clave conocida no evita que se prueben variaciones previsibles. La opción más realista para la mayoría de equipos es un gestor de contraseñas que genere una contraseña aleatoria y diferente para cada servicio.

Qué cambia en WordPress

WordPress es un objetivo cómodo para la automatización porque su flujo de acceso es conocido y hay muchas instalaciones expuestas. Cloudflare indica que, en su muestra, el 76% de los intentos de inicio de sesión con contraseñas filtradas en sitios WordPress tuvo éxito; el 48% de esos accesos exitosos fue atribuido a bots.[2]

No conviene interpretar esa cifra como una tasa universal de intrusiones en WordPress. Es una observación de la red y el conjunto de propiedades de Cloudflare. Pero ilustra un punto importante: un login protegido únicamente por contraseña depende también de cómo gestione cada usuario sus claves fuera de esa web.

Un acceso exitoso a una cuenta con privilegios altos puede permitir modificar contenido, instalar extensiones, crear usuarios, insertar código o acceder a datos disponibles en el administrador. El impacto real depende del rol comprometido, los plugins instalados, la configuración del hosting y los permisos que tenga esa cuenta.

Por eso, en una auditoría de seguridad WordPress no basta con comprobar si existe un plugin de firewall. También hay que revisar qué usuarios pueden administrar el sitio, cómo se autentican, si hay cuentas antiguas y qué registros permiten detectar una sesión anómala.

Por qué 2FA es importante, pero no una solución aislada

La autenticación en dos factores, también llamada 2FA o MFA, añade una comprobación adicional además de la contraseña. Si un atacante conoce una clave reutilizada, todavía debería superar el segundo factor para entrar.

Conviene precisar qué resuelve. 2FA no evita que los bots sigan enviando intentos contra wp-login.php ni reduce por sí sola la carga que generan. Su función es impedir que un usuario y una contraseña correctos sean suficientes para iniciar sesión. El firewall, la limitación de intentos y las restricciones de acceso contienen la automatización; 2FA actúa cuando la contraseña ya ha sido adivinada, reutilizada, filtrada o robada.

OWASP considera MFA la defensa más eficaz frente a la mayoría de ataques basados en contraseñas, incluidos credential stuffing y password spraying. Recomienda, como mínimo, exigirla a administradores cuando no sea viable imponerla a todos los usuarios.[3]

No obstante, 2FA no sustituye el resto de controles. Puede haber phishing que robe códigos, fatiga de notificaciones, sesiones ya iniciadas o dispositivos infectados. Por ello, el objetivo no es decir “tenemos 2FA y ya está”, sino hacer que una contraseña filtrada sea insuficiente y reducir las oportunidades de automatización.

Cuando sea posible, los métodos resistentes al phishing, como passkeys o llaves de seguridad compatibles, reducen la dependencia de contraseñas reutilizables. La elección debe ajustarse al tipo de usuarios, al proceso de recuperación de acceso y a los plugins o proveedores disponibles.

Códigos temporales y pérdida del teléfono

El método más habitual en WordPress es TOTP, compatible con aplicaciones como Google Authenticator, Microsoft Authenticator, Authy o gestores de contraseñas que admitan códigos temporales. Al configurarlo, WordPress y la aplicación guardan el mismo secreto y calculan localmente un código nuevo cada pocos segundos. El servicio no envía el código al teléfono.

Esto tiene una consecuencia importante: cambiar o perder el móvil puede dejar al usuario sin ese segundo factor. Algunas aplicaciones sincronizan las cuentas o permiten transferirlas al nuevo dispositivo, pero no conviene depender exclusivamente de ello. Cada usuario debe conservar sus códigos de recuperación fuera del teléfono, preferiblemente en un gestor de contraseñas bien protegido. Tampoco es aconsejable guardar una captura sin protección del QR inicial: quien obtenga ese secreto podrá generar los mismos códigos.

Si un usuario pierde el teléfono y también los códigos de recuperación, un administrador puede reiniciar su 2FA. Antes de hacerlo debe verificar su identidad por otro canal; una petición de restablecimiento también puede formar parte de un intento de apropiación de la cuenta.

Passkeys: una alternativa a contraseña más código

Una passkey o clave de acceso no es simplemente otro código 2FA. Utiliza criptografía de clave pública y permite entrar aprobando la operación mediante el PIN, la huella o el reconocimiento facial del dispositivo, un gestor compatible o una llave física. El servidor conserva la clave pública, no el secreto necesario para autenticarse.

Además de resultar cómoda, queda vinculada al dominio para el que fue creada. Esto dificulta que una página falsa pueda reutilizarla, por lo que ofrece mejor resistencia al phishing que una contraseña acompañada de un código TOTP. Si se usa una passkey válida para iniciar sesión, no tiene sentido solicitar después un código 2FA independiente: la propia passkey sustituye ese flujo.

La recuperación sigue necesitando planificación. Antes de depender exclusivamente de passkeys conviene registrar más de una, utilizar un gestor que las sincronice de forma segura entre dispositivos o mantener temporalmente un método alternativo probado.

2FA y passkeys con Wordfence

Wordfence Free incluye códigos TOTP, códigos de recuperación y passkeys. Permite dejar estos métodos como opcionales o exigirlos según el rol, además de establecer un periodo de gracia para que cada usuario complete la configuración.[5]

Hay un comportamiento poco evidente cuando se exige 2FA a los administradores. Wordfence no aplica la obligación hasta que al menos uno de ellos haya configurado su segundo factor, evitando así un bloqueo inicial de todos los responsables. Sin embargo, el periodo de gracia general no se concede automáticamente a los demás administradores. En cuanto el primero activa 2FA, los restantes pueden quedar bloqueados si todavía no lo han configurado.

En un sitio con varios administradores, el responsable del mantenimiento debería revisar primero todas las cuentas y conceder manualmente un periodo de gracia a las que lo necesiten. Después puede activar su propio 2FA y pedir a cada administrador que vincule su aplicación. No corresponde al mantenedor escanear y guardar los códigos de los demás: cada persona debe controlar su propio secreto y sus códigos de recuperación.

Wordfence permite exigir 2FA también a editores, pero no siempre conviene extenderlo indiscriminadamente a clientes de una tienda o usuarios sin privilegios. La política debería ajustarse al daño que permitiría causar cada cuenta.

El plugin Two Factor como alternativa específica

Two Factor es un plugin comunitario publicado por WordPress.org y centrado únicamente en el segundo factor. Ofrece TOTP, códigos de recuperación y códigos enviados por correo, y permite ampliar los proveedores mediante extensiones. Las passkeys o WebAuthn requieren un complemento adicional.[6]

Su planteamiento es más sencillo y cada usuario configura sus métodos desde el perfil. Sin embargo, no incorpora de forma nativa la misma política de obligatoriedad por rol, control de periodos de gracia y seguimiento de usuarios pendientes que Wordfence. Por ello encaja bien cuando el 2FA es voluntario o solo se quiere proteger una cuenta concreta; Wordfence resulta más práctico cuando el responsable del sitio debe imponerlo y supervisarlo en varias cuentas con privilegios.

No es recomendable activar simultáneamente los dos sistemas de 2FA. Hay que elegir uno, configurarlo, probar el acceso y documentar su procedimiento de recuperación.

Una protección razonable no obliga a instalar diez plugins. Empieza por aplicar capas que se complementen y comprobar que funcionan en el sitio real.

1. Exigir contraseñas únicas y gestionadas

Las cuentas administrativas, editoriales, de soporte y de hosting deben tener contraseñas distintas entre sí y distintas de las cuentas personales. Un gestor de contraseñas facilita generar claves aleatorias y evita que el equipo dependa de recordar patrones.

No conviene pedir contraseñas por correo, formulario o mensajería. Si hay que compartir acceso temporal, debe hacerse mediante un canal acordado y retirar o cambiar el acceso cuando termine el trabajo.

2. Activar 2FA para las cuentas con privilegios

El mínimo recomendable es exigir 2FA a administradores. Según el tipo de web, también conviene aplicarlo a editores, responsables de tienda, usuarios con acceso a datos personales y cuentas de soporte.

Antes de activarlo para todo el equipo, hay que revisar cuántas cuentas administrativas existen, eliminar o rebajar de rol las que ya no necesiten esos permisos y preparar el despliegue. En Wordfence, esto incluye conceder manualmente gracia a los demás administradores antes o inmediatamente después de que el primer administrador active 2FA, sin cerrar la sesión desde la que se gestionará el proceso.

También hay que definir una recuperación segura: códigos de respaldo, un procedimiento para cambiar de dispositivo, verificación de identidad y una persona responsable. El objetivo es no acabar desactivando la medida durante una urgencia porque nadie puede recuperar el acceso.

3. Limitar y detectar intentos de acceso

Un límite simple por IP frena ataques poco sofisticados, pero debe acompañarse de detección de patrones: muchos usuarios desde una IP, intentos lentos y repartidos, cambios de país, agentes de usuario extraños o accesos desde redes de hosting y proxies.

OWASP recomienda combinar respuestas graduadas, inteligencia de IP, métricas y revisiones de volumen. Bloquear direcciones IP de forma permanente como única medida es fácil de rodear y puede afectar a visitantes legítimos.[3]

4. Comprobar contraseñas expuestas

Es útil impedir que una contraseña nueva coincida con bases de contraseñas filtradas. OWASP recomienda validar las claves nuevas frente a conjuntos de contraseñas comprometidas y cita Pwned Passwords como una alternativa conocida.[3]

Esta comprobación no implica guardar contraseñas en texto plano ni enviarlas a terceros sin revisar cómo funciona la integración. Debe aplicarse mediante un mecanismo que use hashes o consultas parciales diseñadas para este fin.

5. Revisar XML-RPC y los puntos reales de acceso

wp-login.php no es el único punto que merece revisión. Según el uso del sitio, XML-RPC, las APIs, los formularios de recuperación de contraseña y los accesos de proveedores pueden ampliar la superficie de autenticación.

No se trata de desactivar funciones a ciegas. Primero hay que verificar si se usan aplicaciones móviles, integraciones o servicios que dependan de ellas. Después se decide qué proteger, limitar o desactivar sin romper una función necesaria.

6. Mantener registros que sirvan para investigar

Registrar intentos fallidos es útil, pero los accesos exitosos anómalos son más importantes. Conviene conservar datos suficientes para saber qué cuenta entró, cuándo, desde qué origen aproximado y qué cambios realizó después.

Un servicio de mantenimiento de seguridad WordPress puede convertir estas comprobaciones en una rutina: actualizar, revisar usuarios, comprobar registros y detectar desviaciones antes de que una incidencia escale.

Qué revisar si sospechas de un acceso no autorizado

No basta con cambiar la contraseña del administrador y dar el caso por cerrado. Si una cuenta entró, hay que comprobar qué pudo haber hecho durante la sesión.

Revisar Usuarios y Roles. Confirmar que no se hayan creado administradores, editores o cuentas de servicio desconocidas.
Cambiar Contraseñas Reutilizadas. Cambiar las credenciales afectadas y cualquier otra cuenta donde se hubiera usado la misma clave.
Invalidar Sesiones Activas. Forzar el cierre de sesiones y renovar credenciales de aplicación, claves API o tokens si procede.
Revisar Plugins, Temas y Archivos. Buscar extensiones nuevas, cambios no previstos y código añadido fuera del proceso habitual.
Consultar Registros del Hosting y WordPress. Correlacionar accesos, cambios y peticiones sospechosas antes de borrar evidencias.
Comprobar Copias de Seguridad. Verificar que existe una copia anterior al incidente y que se puede restaurar en un entorno seguro.

Si no puedes acceder al administrador, la guía No puedo entrar en WordPress: causas habituales y cómo recuperar el acceso puede ayudarte a separar un problema de credenciales de una incidencia técnica. Si hay indicios de cambios no autorizados, malware o cuentas desconocidas, conviene tratarlo como una posible intrusión y revisar el sitio completo.

La contraseña ya no es el único control

La lección no es que las contraseñas hayan dejado de importar. Siguen siendo necesarias, pero ya no pueden ser la única barrera entre un atacante y el administrador de WordPress.

Una contraseña única evita que una filtración ajena se convierta automáticamente en un acceso propio. 2FA añade una barrera cuando la contraseña ha sido robada. Los límites de acceso, la detección de automatización y la revisión de registros reducen la eficacia de los bots. Y un proceso de mantenimiento permite comprobar que esas capas siguen activas cuando se actualiza el sitio, cambia el equipo o se añade una integración.

Si quieres revisar cómo están protegidos los accesos de tu WordPress, una auditoría de seguridad permite priorizar usuarios, roles, 2FA, puntos de entrada, plugins y registros según el riesgo real de tu web.