WordPress hackeado: primeras 24 horas

Guía práctica sobre qué hacer cuando descubres que tu WordPress ha sido hackeado: aislar el sitio, hacer backup forense, limpiar y aplicar hardening mínimo en las primeras 24 horas.

WordPress hackeado: cómo reaccionar antes de empeorar las cosas

Descubrir que tienes un WordPress hackeado provoca una reacción instintiva: borrar todo, reinstalar y olvidarte del tema. Ese impulso es comprensible, pero es exactamente lo que puede convertir un incidente controlable en un desastre irreversible. Las primeras 24 horas después de detectar una intrusión son las más importantes, y lo que hagas —o dejes de hacer— en ese margen determinará si recuperas el sitio con garantías o si el atacante vuelve a entrar en cuestión de días.

Este artículo cubre el protocolo completo: desde el aislamiento inicial del sitio hasta el hardening mínimo que debería estar funcionando antes de que pasen esas primeras 24 horas. No es una guía teórica: es el proceso real que aplico cuando un cliente me avisa de que algo no va bien en su web.

Señales reales de que tu WordPress ha sido hackeado

Antes de actuar, necesitas confirmar. Muchos propietarios confunden un error de plugin con un hackeo, y viceversa. Estas son las señales que indican una intrusión real, no un fallo técnico:

• Redirecciones a sitios externos: la web redirige a páginas de spam, farmacéuticas o de apuestas. A veces solo ocurre cuando el visitante llega desde Google, no cuando escribes la URL directamente.
• Usuarios administradores desconocidos: aparecen cuentas con rol de administrador que nadie del equipo creó.
• Archivos modificados recientemente: archivos del core de WordPress (como wp-config.php, index.php o .htaccess) con fechas de modificación recientes sin que nadie haya tocado nada.
• Google Search Console lanza alertas: notificaciones de «problemas de seguridad detectados» o páginas indexadas con contenido que no reconoces (japonés, cirílico, enlaces farmacéuticos).
• Caída de rendimiento sin explicación: el servidor consume recursos desproporcionados porque hay procesos en segundo plano — típicamente scripts de criptominería o envío masivo de spam.
• Correos rebotados: tu dominio aparece en listas negras de spam porque el servidor envía miles de correos no solicitados.

Si identificas una o más de estas señales, es momento de pasar al modo incidente. No sigas navegando por el panel de WordPress como si nada.

Paso 1: Aislar el sitio hackeado inmediatamente

El primer movimiento no es limpiar. Es aislar. El objetivo es doble: evitar que los visitantes se vean afectados y evitar que el atacante siga operando mientras tú investigas.

Cómo aislar correctamente

• Activar modo mantenimiento a nivel de servidor: no uses un plugin de mantenimiento de WordPress para esto (el propio WordPress podría estar comprometido). Pide a tu proveedor de hosting que bloquee el tráfico HTTP al sitio o, si tienes acceso, crea un archivo .maintenance en la raíz o configura una regla en el .htaccess que devuelva un 503 a todas las peticiones excepto tu IP.
• Cambiar inmediatamente las contraseñas: FTP/SFTP, panel de hosting, base de datos y todas las cuentas de administrador de WordPress. Hazlo desde un dispositivo que no sea el que usaste para acceder al panel comprometido.
• Revocar sesiones activas: si todavía puedes acceder a wp-admin, ve a «Usuarios» → tu perfil → «Cerrar sesión en todas las demás ubicaciones». Repite para cada usuario administrador.
• Desconectar integraciones externas: si el sitio conecta con APIs de terceros, pasarelas de pago o CRMs, revoca temporalmente los tokens de acceso. Un atacante con acceso al servidor puede leer las claves API almacenadas en wp-config.php o en la base de datos.

Este paso debería llevarte entre 15 y 30 minutos. No avances al siguiente hasta que el sitio esté completamente aislado del tráfico público.

Paso 2: Backup forense — documentar antes de tocar nada

Aquí es donde la mayoría comete el error crítico. El instinto dice «borra el malware ya», pero si borras archivos antes de documentar, pierdes la capacidad de entender qué pasó, por dónde entraron y si hay puertas traseras ocultas que sobrevivirán a tu limpieza.

Qué es un backup forense y por qué difiere de uno normal

Un backup convencional guarda tu sitio para poder restaurarlo. Un backup forense guarda el estado comprometido para poder analizarlo. La diferencia es clave: no vas a restaurar desde este backup, vas a estudiarlo.

Cómo crear el backup forense

1. Copia completa de archivos por SFTP: descarga toda la carpeta del sitio, incluyendo wp-content/, archivos del core, .htaccess y wp-config.php. Usa SFTP (nunca FTP plano) y guarda todo en una carpeta local etiquetada con la fecha y hora.
2. Exporta la base de datos completa: accede a phpMyAdmin o usa mysqldump y exporta todas las tablas. No solo las de WordPress — si compartes base de datos con otras aplicaciones, expórtalo todo.
3. Captura los logs del servidor: los archivos access.log y error.log de Apache o Nginx contienen las peticiones HTTP que el atacante hizo. Estos logs son oro puro para el análisis posterior. Muchos hostings rotan los logs cada 24-48 horas, así que descárgalos cuanto antes.
4. Captura de Google Search Console: haz capturas de pantalla de las alertas de seguridad, las páginas indexadas sospechosas y cualquier acción manual aplicada.

Todo este material se guarda en un disco local o en un almacenamiento en la nube separado del hosting. Nunca en el propio servidor comprometido.

Paso 3: Identificar el vector de entrada

Con el backup forense en mano, toca entender cómo entró el atacante. Según datos de Wordfence, en más del 50% de los WordPress hackeados la puerta de entrada es un plugin o tema con vulnerabilidades conocidas. Las otras vías habituales son:

• Credenciales débiles o filtradas: contraseñas reutilizadas que aparecen en bases de datos de filtraciones públicas.
• Versiones desactualizadas de PHP o del core de WordPress: versiones de PHP sin soporte de seguridad (por debajo de 8.1 en noviembre de 2026) o versiones de WordPress con CVEs conocidos.
• Permisos de archivo incorrectos: archivos con permisos 777 o directorios uploads con ejecución de PHP habilitada.
• Hosting compartido comprometido: en hostings compartidos baratos, un sitio vecino hackeado puede escalar al tuyo si el aislamiento entre cuentas es deficiente.

Cómo rastrear el vector

Revisa los logs de acceso buscando peticiones POST a archivos inusuales dentro de wp-content/plugins/ o wp-content/uploads/. Los atacantes suelen subir un archivo PHP (un webshell) a la carpeta de uploads y luego lo ejecutan remotamente. Busca archivos con nombres aleatorios (xk4j2.php, cache-loader.php) en ubicaciones donde no deberían existir archivos PHP ejecutables.

Compara los archivos del core descargados en el backup forense con los archivos originales de WordPress usando diff o herramientas como WP-CLI (wp core verify-checksums). Cualquier diferencia indica modificación maliciosa.

Paso 4: Limpieza real del sitio WordPress hackeado

Solo después de aislar, documentar e identificar el vector es momento de limpiar. El orden importa.

Reinstalar el core de WordPress

Descarga una copia fresca de WordPress desde wordpress.org y sustituye todos los archivos del core (carpetas wp-admin/ y wp-includes/, más los archivos raíz excepto wp-config.php y .htaccess). No uses la función «Reinstalar» del panel de WordPress — hazlo manualmente por SFTP para asegurarte de que los archivos originales quedan completamente reemplazados.

Limpiar wp-config.php

Abre el archivo wp-config.php del backup forense y compáralo línea a línea con uno limpio. Busca código inyectado al principio o al final del archivo (típicamente funciones eval(), base64_decode() o inclusiones de archivos remotos). Regenera las claves de seguridad (salts) — esto invalida todas las sesiones activas, incluidas las del atacante.

Revisar y reinstalar plugins y temas

No te limites a actualizar. Elimina todos los plugins y temas, y reinstálalos desde cero descargándolos del repositorio oficial o del proveedor original. Esto garantiza que cualquier archivo inyectado dentro de las carpetas de plugins desaparezca. Los plugins que ya no uses, elimínalos — un plugin desactivado pero presente en el servidor sigue siendo un vector de ataque.

Limpiar la base de datos

Busca en la tabla wp_options entradas con valores sospechosos (URLs externas, código codificado en base64). Revisa la tabla wp_users y elimina cualquier usuario que no reconozcas. Comprueba la tabla wp_posts buscando contenido inyectado — es habitual encontrar páginas de spam en japonés o turco publicadas como entradas ocultas.

Paso 5: Hardening mínimo antes de las 24 horas

La limpieza sin hardening es como cerrar la puerta sin echar la llave. Antes de que pasen las primeras 24 horas, estas medidas deben estar activas:

Medidas obligatorias de hardening

• Deshabilitar ejecución de PHP en wp-content/uploads/: añade un archivo .htaccess en esa carpeta con la directiva php_flag engine off (Apache) o la regla equivalente en Nginx. El 90% de los webshells se suben a esta carpeta.
• Deshabilitar el editor de archivos integrado: añade define('DISALLOW_FILE_EDIT', true); en wp-config.php. Esto impide que un atacante con acceso al panel edite archivos PHP directamente.
• Limitar intentos de login: implementa un sistema de rate-limiting para wp-login.php y xmlrpc.php. Si no vas a usar XML-RPC (la mayoría de sitios modernos no lo necesitan), bloquéalo completamente.
• Forzar HTTPS en todo el sitio: si no lo tenías, actívalo ahora. Redirige todo el tráfico HTTP a HTTPS desde el .htaccess o la configuración del servidor.
• Actualizar PHP: asegúrate de que el servidor ejecuta una versión de PHP con soporte de seguridad activo.
• Permisos de archivo correctos: archivos a 644, directorios a 755, wp-config.php a 440 o 400.

Verificar con Google

Si Google marcó tu sitio como peligroso, entra en Google Search Console → «Problemas de seguridad» y solicita una revisión después de la limpieza. Este proceso puede tardar entre 24 horas y varias semanas. Mientras tanto, los usuarios verán la advertencia roja de «Este sitio puede dañar tu equipo».

Errores frecuentes durante las primeras 24 horas

Después de gestionar múltiples incidentes de sitios comprometidos, estos son los patrones que se repiten:

1. Restaurar un backup sin verificar que está limpio: si el atacante lleva semanas dentro (y no te habías dado cuenta), tus backups recientes también están comprometidos. Necesitas encontrar un backup anterior a la fecha de la primera intrusión, no al momento en que la detectaste.
2. Cambiar contraseñas desde el propio WordPress: si el atacante tiene un webshell activo, puede capturar la nueva contraseña en tiempo real. Cambia las credenciales de base de datos y hosting desde el panel del proveedor, no desde WordPress.
3. Enfocarse solo en lo visible: el malware visible (redirecciones, spam) es solo la carga útil. La puerta trasera suele ser un archivo discreto con un nombre inocente escondido en una subcarpeta de un plugin legítimo.
4. No revisar otros sitios en el mismo servidor: en un hosting compartido o con múltiples instalaciones de WordPress en la misma cuenta, la infección puede haberse extendido lateralmente.
5. Asumir que el hosting se encarga: la mayoría de hostings compartidos notifican la infección pero no la limpian. Suspenden tu cuenta y te dan un plazo para resolverlo tú.

Cronología realista: qué debería estar hecho en cada hora

Una referencia temporal para organizar la respuesta:

• Hora 0-1: Confirmación de la intrusión. Aislamiento del sitio. Cambio de contraseñas de hosting, FTP y base de datos.
• Hora 1-3: Backup forense completo (archivos + base de datos + logs). Revocación de tokens API externos.
• Hora 3-8: Análisis del vector de entrada. Identificación de archivos modificados y puertas traseras.
• Hora 8-16: Limpieza: reinstalación del core, plugins y temas limpios, limpieza de base de datos.
• Hora 16-24: Hardening mínimo. Verificación funcional del sitio. Solicitud de revisión en Google Search Console si aplica. Reapertura controlada al tráfico.

Este cronograma asume que una persona con experiencia trabaja dedicada al incidente. Si el sitio es una tienda WooCommerce con datos de clientes, añade tiempo para evaluar si se han exfiltrado datos personales — lo que podría activar la obligación de notificación bajo el RGPD en un plazo de 72 horas.

Preguntas frecuentes sobre un WordPress hackeado

¿Puedo limpiar un WordPress hackeado yo mismo?

Depende de tu nivel técnico. Si sabes moverte por SFTP, puedes leer logs del servidor y entiendes la estructura de archivos de WordPress, puedes abordar la limpieza siguiendo este protocolo. Si la web es un e-commerce con datos sensibles o no tienes experiencia con la línea de comandos, es mejor contar con alguien que haya gestionado este tipo de incidentes antes.

¿Cuánto tarda Google en quitar la advertencia de sitio peligroso?

Una vez solicitas la revisión en Search Console, Google tarda entre 24 horas y 2-3 semanas en verificar que el sitio está limpio. Si la revisión falla (porque quedó malware residual), puedes volver a solicitarla, pero cada intento fallido puede alargar los plazos.

¿Mis backups automáticos sirven para restaurar?

Solo si el backup es anterior a la fecha real de la intrusión, no a la fecha en que la detectaste. En muchos casos, el atacante lleva semanas o meses dentro antes de activar la carga visible. Necesitas revisar los logs para determinar cuándo se produjo el acceso inicial y buscar un backup previo a esa fecha.

¿Debo avisar a mis clientes o usuarios?

Si el sitio almacena datos personales (formularios, cuentas de usuario, pedidos de WooCommerce) y hay indicios de que esos datos pudieron ser accedidos, el RGPD te obliga a notificar a la autoridad de protección de datos en 72 horas y, en algunos casos, a los propios afectados.

Si gestionas un sitio WordPress y prefieres tener un profesional que supervise su seguridad de forma continua, puedes consultar mi servicio de mantenimiento WordPress para entender qué cubre y cómo funciona.

// Sobre el autor

fernandodomecq

Desarrollador WordPress freelance especializado en WooCommerce, integraciones e IA. Escribo sobre proyectos web, agencias y buenas prácticas técnicas.

Ver todos los artículos →