Esta guía supone que ya has confirmado la infección. Si no es así, empieza por la comprobación de cinco minutos. Si acabas de encontrar el problema, haz primero los pasos de la primera hora en Cómo reparar un sitio WordPress hackeado. Cubren la copia de seguridad, la decisión de poner el sitio fuera de línea y el cambio de todas las credenciales, y no debes saltártelos.

Antes de ejecutar nada: necesitas la copia de seguridad infectada de la guía de reparación, acceso SSH o SFTP y, idealmente, WP-CLI (la mayoría de los hostings gestionados lo incluyen). Ejecuta los comandos desde la carpeta de WordPress, a menudo public_html. Pruébalos en una copia de pruebas si puedes y pon el sitio en modo mantenimiento mientras trabajas.

Paso 1: crea una carpeta de cuarentena

Mueve los archivos sospechosos fuera del sitio en lugar de borrarlos. Un falso positivo se restaura fácilmente, un archivo borrado no. Pon la carpeta fuera de la raíz web:

mkdir -p ~/quarantine

Paso 2: reemplaza el núcleo de WordPress

Las carpetas del núcleo nunca deben contener código editado a mano, así que reemplazarlas es seguro. Guarda primero el número de versión, porque vas a eliminar el archivo que lo almacena:

VERSION=$(wp core version)
rm -rf wp-admin wp-includes
wp core download --force --skip-content --version=$VERSION
wp core verify-checksums

La descarga restaura copias limpias de las carpetas del núcleo y de los archivos de la raíz, como index.php y wp-login.php. El último comando debe informar de que todo se verifica. Cualquier línea «File should not exist» es un archivo ajeno escondido entre los del núcleo. Muévelo a cuarentena.

wp-config.php no forma parte de la descarga, así que ábrelo y léelo. Busca código por encima de las primeras líneas o por debajo de la última, y cualquier eval, base64_decode o include que apunte a un archivo que no reconozcas.

Paso 3: reinstala plugins y temas

Reinstala cada plugin y tema desde su fuente original en lugar de limpiar una copia infectada. Es más rápido y no se te escapará ningún archivo modificado sutilmente.

wp plugin list
wp plugin install PLUGIN-SLUG --force
wp theme install THEME-SLUG --force
wp plugin verify-checksums --all

Los plugins y temas premium no están en wordpress.org, así que descarga una copia nueva del proveedor y súbela. Elimina todo lo que no uses o no reconozcas, y bórralo en lugar de solo desactivarlo. Los archivos de un plugin desactivado todavía pueden ejecutarse directamente por cualquiera que conozca la ruta:

wp plugin deactivate PLUGIN-SLUG
wp plugin delete PLUGIN-SLUG

Paso 4: revisa los escondites habituales

El malware rara vez se queda en un solo archivo. Revisa estos lugares incluso después de reemplazar el núcleo y los plugins, porque quedan fuera de lo que acabas de reinstalar.

grep -RIl --include="*.php" -E "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" wp-content
find wp-content/uploads -name "*.php"
ls -la wp-content/mu-plugins
cat .htaccess
wp cron event list
  • Los resultados de grep. Estas funciones también aparecen en código legítimo, así que una coincidencia es una pista, no una prueba. Abre cada archivo y léelo. No borres el archivo de un plugin solo porque coincida.
  • wp-content/uploads. Solo debería contener medios. Cualquier archivo PHP aquí va a cuarentena.
  • wp-content/mu-plugins. Los plugins de uso obligatorio se cargan automáticamente y no aparecen en la lista normal de plugins. Un archivo aquí que no añadiste es una señal de alerta fuerte.
  • .htaccess. Compáralo con las reglas por defecto de WordPress. Las reglas de redirección inyectadas, sobre todo las que dependen del referente o del dispositivo del visitante, son un clásico del hackeo.
  • .user.ini y php.ini. Busca una línea auto_prepend_file. Ejecuta un archivo antes de cada página y es un lugar favorito para guardar una puerta trasera.
  • Archivos del tema. Abre functions.php, header.php y footer.php de tu tema activo y busca código que no escribiste.
  • Tareas programadas. Un evento cron que llama a una función desconocida puede recrear una puerta trasera después de que la borres. Elimínalo con wp cron event delete HOOK-NAME.

Para más información sobre accesos ocultos, consulta Cómo encontrar una puerta trasera en WordPress.

Paso 5: limpia la base de datos

El malware suele vivir en la base de datos, donde un análisis de archivos nunca mira. Haz primero una copia con wp db export. Tu prefijo de tabla puede no ser wp_, así que compruébalo:

wp db prefix
wp db query "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"
wp db query "SELECT ID, user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 20;"
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' OR post_content LIKE '%display:none%';"
wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%' LIMIT 50;"
  • siteurl y home. Ambos deben ser tu propio dominio. Un valor distinto redirige todo el sitio sin cambiar ningún archivo.
  • Usuarios recientes. Cualquier administrador que no creaste se puede eliminar con wp user delete ID --reassign=ADMIN-ID.
  • Entradas y opciones con etiquetas script. Algunas contienen código legítimo de analítica o de inserción. Revisa cada resultado y limpia solo la parte inyectada.

Paso 6: cierra el acceso que usó el atacante

Si aún no has cambiado todas las credenciales, hazlo ahora. El orden completo, desde el acceso al hosting hasta los accesos de WordPress, está en el paso 5 de la guía de reparación. Regenera las claves de seguridad con wp config shuffle-salts para que terminen las sesiones existentes.

Paso 7: verifica y sigue vigilando

wp core verify-checksums
wp plugin verify-checksums --all
find wp-content/uploads -name "*.php"

Vacía cualquier caché. Después visita el sitio desde tu teléfono con datos móviles, llegando desde un resultado de Google, porque las redirecciones maliciosas suelen esconderse de las visitas directas. Si Google marcó el sitio, solicita una revisión en Problemas de seguridad de Search Console. Repite las comprobaciones a las 24 horas y a la semana. Un archivo o una cuenta de administrador que reaparece significa que se pasó por alto una puerta trasera o el punto de entrada.

Si el malware vuelve

Una reinfección casi siempre tiene una de dos causas: una puerta trasera que nunca se encontró o un punto de entrada que nunca se cerró. Revisa de nuevo mu-plugins, .htaccess, .user.ini y las tareas programadas. Luego sigue el paso 7 de la guía de reparación para descubrir cómo entró el atacante: plugins desactualizados o pirateados, credenciales de hosting robadas y registros del servidor.

Cómo ayuda SiftWP

SiftWP realiza cada semana por SSH comprobaciones como estas de integridad de archivos, base de datos y malware, sin ningún plugin en tu sitio. Los archivos marcados se ponen en cuarentena, nunca se borran de golpe. Las correcciones de bajo riesgo se aplican automáticamente, y todo lo ambiguo se detiene y te pregunta primero.

Empieza con créditos gratis, sin tarjeta

Cómo saber si tu sitio ha sido hackeado → Cómo reparar un sitio WordPress hackeado → Cómo encontrar una puerta trasera en WordPress → Comprobación de integridad de archivos del núcleo de WordPress → Cómo proteger wp-config.php → Con qué frecuencia escanear en busca de malware →