Restaurar un WordPress desde cero tras un incidente (paso a paso)

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Restaurar WordPress tras un hackeo no consiste en «limpiar los ficheros infectados»: consiste en reconstruir el sitio desde una base de confianza para no dejar ninguna puerta trasera abierta. La limpieza en caliente es la causa número uno de recaídas, porque casi siempre queda un fichero, un usuario o una tarea programada que el atacante vuelve a usar. Esta guía forma parte de nuestra serie sobre respuesta a incidentes DFIR cuando una web ha sido hackeada y describe la reconstrucción paso a paso.

Antes de empezar, una premisa: no restaures encima del sistema comprometido y no borres nada sin una copia previa. Necesitas conservar la evidencia por si el incidente escala a peritaje o notificación regulatoria.

Restaurar WordPress tras un hackeo: reconstrucción en 8 pasos

1. Aislar y congelar la evidencia

Saca el sitio de producción (página de mantenimiento) y haz una copia forense completa de ficheros y base de datos antes de tocar nada. El orden de adquisición correcto lo marca el NIST SP 800-86.

2. Inventariar antes de reconstruir

Anota la versión de WordPress, la lista real de plugins y temas, y el contenido a conservar. Descarta de entrada cualquier plugin nulled, abandonado o de origen dudoso: no volverá al sitio nuevo.

3. Núcleo limpio desde origen

Instala WordPress descargando el core desde wordpress.org, nunca reutilizando los ficheros del sitio comprometido. Haz lo mismo con temas y plugins: siempre desde el repositorio oficial o la fuente legítima del desarrollador.

4. Migrar solo contenido, tras escanearlo

De wp-content/uploads traslada únicamente los ficheros de medios legítimos, revisados uno a uno. Ningún .php debería vivir en uploads: si aparece, es una webshell. No copies wp-content/plugins ni wp-content/themes del sitio viejo.

5. Depurar la base de datos

La base de datos es el escondite favorito de la persistencia. Revisa:

• Usuarios administradores no reconocidos en wp_users / wp_usermeta.
• Valores manipulados de siteurl y home en wp_options.
• active_plugins con entradas fantasma y opciones con código ofuscado o base64.
• Inyecciones de spam o redirecciones en wp_posts y en el pie/cabecera del tema.

6. Rotar todas las credenciales

Da por comprometido todo lo que el atacante pudo ver. Cambia: contraseña y usuario de base de datos, todos los administradores del CMS, FTP/SFTP, panel de hosting y correo asociado. Regenera los salts del wp-config.php para invalidar las sesiones activas.

7. Endurecer la configuración

• Permisos correctos de ficheros y directorios; wp-config.php fuera del alcance web cuando sea posible.
• Revisar .htaccess en busca de reglas de redirección maliciosas.
• Eliminar tareas de wp-cron sospechosas y desactivar la edición de ficheros desde el panel.
• Actualizar core, plugins y temas a la última versión antes de volver a publicar.

8. Vigilancia post-restauración

Un sitio recién restaurado sigue siendo objetivo. Activa un WAF, monitoriza integridad de ficheros y revisa los logs los primeros días. El ciclo completo de recuperación y lecciones aprendidas está alineado con el NIST SP 800-61, y la CISA ofrece guías de hardening útiles como referencia.

Antes de restaurar: entiende cómo entraron

Reconstruir sin conocer el vector de entrada garantiza una recaída. Si el incidente afectó a una tienda o a datos de pago, el orden cambia: primero peritaje, luego limpieza. Lo vemos en robaron tarjetas en mi PrestaShop, y para tiendas comprometidas detallamos la limpieza y el hardening en limpiar una tienda PrestaShop hackeada. En PathSentinel restauramos entornos que van de la pyme a escenarios exigentes como banca y comercios con datos de tarjeta, donde una recaída no es una molestia sino un problema de cumplimiento. Si prefieres que lo hagamos contigo, escríbenos en contacto.