Sitio WordPress de un cliente hackeado: procedimiento de agencia

Suena el teléfono: lo que se sabe y lo que se ignora

Seis reglas que fijar desde la llamada

• Un responsable del incidente — una sola persona decide, escribe en el diario y habla con el cliente; los demás ejecutan.
• Una sola voz hacia el cliente — el cliente no recibe dos versiones de los hechos.
• Un diario fechado — cada acción se anota con la hora UTC, el autor, el comando lanzado y su resultado.
• Nada se borra antes de copiarse — un archivo borrado ya no dice por dónde entró el atacante.
• Ninguna corrección en caliente — se aísla, se analiza y después se decide.
• Ninguna promesa sobre la causa o la duración — «reparado» solo se dice tras los controles de reapertura.

Aislar sin destruir las pruebas

1. 01

   Abrir el diario de incidente (5 min)

   date -u +%Y-%m-%dT%H:%M:%SZ
   Anote esta hora, el síntoma comunicado, el nombre del sitio, el alojamiento y las personas que intervienen. Cada línea siguiente indica la hora UTC, la acción y su resultado. El archivo se entregará al cliente, así que se mantiene factual.

2. 02

   Cortar el acceso público (10 min)

   Sirva una página de mantenimiento con el código HTTP 503 desde el servidor web o la CDN, o limite el acceso a la IP del equipo. No renombre aún carpetas de plugins o temas: cambiaría las fechas de modificación que querrá leer. Si el sitio difunde malware, el corte va antes de la copia.

3. 03

   Copiar archivos y base de datos (15 min)

   mkdir -p ~/incidents/client-a/AAAA-MM-DD
rsync -a /var/www/client-a/ ~/incidents/client-a/AAAA-MM-DD/archivos/
wp db export ~/incidents/client-a/AAAA-MM-DD/base.sql --skip-plugins --skip-themes
find ~/incidents/client-a/AAAA-MM-DD -type f -exec sha256sum {} + > ~/incidents/client-a/hashes-AAAA-MM-DD.txt
chmod -R a-w ~/incidents/client-a/AAAA-MM-DD
   Las opciones --skip-plugins --skip-themes evitan cargar plugins y tema, pero el código del sitio sigue siendo sospechoso. Las huellas y la retirada de permisos de escritura permiten demostrar después que la copia no ha cambiado.

4. 04

   Copiar los registros (5 min)

   Recupere los registros de acceso y de errores del servidor web y los del panel de alojamiento. Su conservación es corta en muchas ofertas: es la prueba que desaparece más rápido y la que permite fechar la intrusión.

5. 05

   Cerrar los accesos no esenciales (10 min)

   Cambie las contraseñas del panel, de SFTP y de SSH, retire los accesos de los proveedores y sustituya las claves de sal de wp-config.php para invalidar las sesiones. Esta rotación es provisional: una puerta trasera puede devolver el control al atacante, así que se repite tras la limpieza.

6. 06

   Avisar al alojamiento (5 min)

   En un servidor compartido, la infección puede ir más allá del sitio. Informe al soporte, pida que se conserven los registros y, si la cuenta está suspendida, un acceso de lectura en lugar de la reactivación. Pregunte si la IP del servidor figura en una lista de bloqueo de correo.

Comprobar la integridad, comando a comando

1. 07

   Archivos del núcleo (5 min)

   wp core verify-checksums --include-root
   Compara los archivos instalados con las sumas de comprobación de WordPress.org. Un mensaje «File doesn't verify against checksum» señala un archivo modificado y «File should not exist» uno añadido; --include-root extiende el control a la raíz.

2. 08

   Plugins (5 min)

   wp plugin verify-checksums --all
   Mismo principio para los plugins del repositorio de WordPress.org. Un plugin premium o un tema a medida no tienen suma publicada: compárelos con una copia limpia del editor.

3. 09

   PHP donde no debe haberlo (10 min)

   find wp-content/uploads -name '*.php'
find . -type f -name '*.php' -mtime -30
   La carpeta de medios no contiene código: cualquier PHP allí es sospechoso. El segundo comando lista los PHP modificados en los últimos treinta días; sustituya 30 por la antigüedad estimada de la intrusión. Una fecha de modificación puede falsificarse: orienta, no prueba.

4. 10

   Patrones de código sospechosos (10 min)

   grep -rEl 'eval\(|base64_decode\(|gzinflate\(' wp-content
eval, base64_decode y gzinflate sirven para ocultar código, pero plugins legítimos también los usan: lea cada resultado. Una búsqueda sin resultados no prueba la ausencia de compromiso.

5. 11

   Cuentas y ajustes (10 min)

   wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp option get siteurl
wp option get home
wp option get users_can_register
wp option get default_role
   Busque un administrador desconocido, una fecha de creación cercana a la intrusión, un siteurl o un home modificados (causa frecuente de redirecciones), un registro abierto con un rol por defecto demasiado alto. Estos datos están en las tablas wp_users, wp_usermeta y wp_options; el prefijo puede diferir.

6. 12

   Tareas programadas y archivos de arranque (10 min)

   wp cron event list
crontab -l
ls -la wp-content/mu-plugins
find . -name '.htaccess'
   Una tarea programada desconocida puede recrear el archivo malicioso cada noche. Los plugins de uso obligatorio (mu-plugins) se cargan sin activación. El .htaccess se modifica a menudo: reglas reservadas a móviles o a visitantes procedentes de un buscador explican por qué el cliente no ve nada desde su puesto. Puede haber otros en subcarpetas.

7. 13

   Contenido de la base de datos (10 min)

   wp db search '<script' --all-tables-with-prefix
wp option get active_plugins --format=json
   Busque etiquetas de script inyectadas en entradas, widgets y opciones, y relea la lista de plugins activos: una entrada desconocida salta a la vista.

Fechar la intrusión antes de elegir

Limpiar, restaurar o reconstruir: la tabla de decisión

Desplace la tabla

Reabrir: actualización y rotación de secretos, en orden

1. 14

   Actualizar el núcleo y los plugins

   wp core update
wp plugin update --all
   Hágalo en un sitio limpio, tras la restauración o la limpieza. Retire también los temas y plugins sin uso.

2. 15

   Panel de alojamiento, SFTP y SSH

   Contraseñas nuevas, largas y únicas, guardadas en una bóveda compartida. Elimine las claves desconocidas de ~/.ssh/authorized_keys. Se empieza por estos accesos: permiten reescribir los archivos, así que el resto no sirve de nada mientras estén comprometidos.

3. 16

   Base de datos

   Contraseña nueva para el usuario de la base de datos y actualización en wp-config.php. La documentación oficial sugiere cambiar también el nombre de ese usuario.

4. 17

   Claves de sal de wp-config.php

   Genere un juego nuevo en https://api.wordpress.org/secret-key/1.1/salt/ y sustituya los valores: las sesiones abiertas se cierran. Repítala ahora: la rotación inicial pudo haber sido eludida.

5. 18

   Cuentas de WordPress

   Restablezca las contraseñas de todos los administradores y editores, elimine las cuentas no reconocidas, active la doble autenticación y revise los roles con el comando wp user list --role=administrator.

6. 19

   Claves de API y servicios de terceros

   Pagos, SMTP, CDN, almacenamiento de objetos, antispam: regenere cada clave en el proveedor, no solo en el sitio.

7. 20

   Tokens de gestión remota

   Herramientas de gestión multisitio, copia en línea, supervisión: revoque los tokens antiguos y vuelva a conectar el sitio con otros nuevos.

Comprobar antes de abrir al público

• Sumas de comprobación limpias — wp core verify-checksums y wp plugin verify-checksums --all ya no devuelven avisos; los plugins ajenos al repositorio se comparan con una copia reciente del editor.
• Cuentas inventariadas — la lista de administradores se revisa con el cliente, línea por línea, y cada cuenta se asocia a una persona.
• Ningún PHP en la carpeta de medios — find wp-content/uploads -name '*.php' no devuelve nada.
• Análisis complementario — un escáner de plugin y un escáner remoto, porque la documentación oficial recuerda que ninguna herramienta ve por sí sola todos los casos.
• Vigilancia reforzada durante un periodo fijado — por ejemplo catorce días, con los controles de integridad repetidos a diario y la lectura de los registros de conexión; la fecha de fin se escribe en el diario de incidente.
• Una copia sana fechada — la copia hecha justo tras la reapertura pasa a ser el nuevo punto de referencia para la próxima decisión.

El mensaje al cliente, en tres tiempos y con una sola voz

1. 21

   La constatación, en la hora siguiente

   Escribe la agencia, no el alojamiento ni el equipo técnico. Modelo: «Su sitio presenta signos de compromiso: [síntoma observado]. Lo hemos puesto fuera de línea a las [hora UTC] para proteger a sus visitantes. La causa aún no se conoce.» Ninguna causa supuesta, ningún plazo prometido.

2. 22

   La acción, una vez hecho el aislamiento

   Modelo: «Se ha conservado una copia completa. Estamos verificando los archivos, las cuentas y la base de datos. Antes de las [hora], le diremos si limpiamos, restauramos o reconstruimos, y por qué.» Si hay pedidos recientes en juego, dígalo: el cliente decide lo que acepta perder.

3. 23

   El seguimiento, en la reapertura

   Modelo: «El sitio está reabierto desde el [fecha]. Los accesos se han renovado y lo vigilamos durante [duración]. Le pedimos que cambie la contraseña de sus cuentas y que nos señale cualquier comportamiento inusual.» Escriba «corregido» solo para lo que los controles han verificado de verdad.

4. 24

   El diario de incidente, entregado al cliente

   Adjunte el diario con marcas de tiempo: constatación, acciones, decisión y motivo, reapertura, periodo de vigilancia. Se mantiene factual y no atribuye ninguna culpa.

Salir de la advertencia de Google tras la reapertura

Cuando la salida no dice lo que parece decir

• «File should not exist» en la raíz — el archivo no figura en la lista oficial, así que se añadió. No todos son hostiles (un archivo de verificación de propiedad, por ejemplo), pero cada uno debe explicarse.
• «File doesn't verify against checksum» en readme.html o wp-config-sample.php — a menudo inofensivo si el idioma o la versión difieren. Compare --locale y --version con lo que muestra la pantalla Actualizaciones del escritorio antes de concluir.
• Falla la descarga de las sumas de comprobación — quizá el servidor no tenga acceso saliente. No añada --insecure en una máquina sospechosa: la opción desactiva la validación del certificado y expone a una interceptación.
• Plugin ausente del control — no está en el repositorio oficial. Compare sus archivos con una copia limpia del editor en lugar de declararlo sano.
• El sitio sigue redirigiendo tras la limpieza — pruebe como un visitante: curl -sI -A 'Mozilla/5.0 (iPhone)' https://your-domain.com/ y después curl -sI -e https://www.google.com/ https://your-domain.com/. Una redirección visible solo así procede de una regla .htaccess, de una caché del servidor o de la CDN: liste todos los .htaccess y purgue las cachés.

Para ir más lejos

• Un incidente fechado de un plugin de copias — /blog/updraftcentral-cles-volees-backdoors-wordpress-sauvegarde describe una restauración limpia en un caso concreto; esta guía da el procedimiento general.
• Demostrar la restauración antes de necesitarla — /blog/tester-restauration-sauvegarde-vps-client-agence-procedure explica cómo probar una copia fuera de cualquier incidente.
• Revisar el parque cada mes — /blog/checklist-audit-securite-mensuel-vps-clients-agence previene parte de las situaciones descritas aquí.

La documentación oficial