Restaurar WordPress no es limpiarlo

El trabajo de “devolver el sitio a línea” y el trabajo de “dejarlo seguro” no son el mismo. Mezclarlos es la forma más cara de repetir el incidente.

Lo que suele quedar abierto

• El respaldo se restauró sin verificar integridad. Si el archivo es posterior al compromiso, el malware volvió con el contenido.
• Hay un plugin de “activación” no oficial. Ejecuta código de origen no verificable. Es el candidato más frecuente de entrada.
• Productos comerciales sin licencia: no hay canal de parches. Cada CVE nuevo queda abierto indefinidamente.
• Decenas de actualizaciones pendientes, incluido el e-commerce.
• Sin WAF ni escáner. La próxima infección se descubre igual que esta: cuando el sitio ya no carga.
• Backups en el mismo servidor, en versión gratuita, sin programación. Por eso el incidente duró lo que duró.
• El correo de administrador es una casilla personal. Toda recuperación de contraseña depende de algo que la empresa no controla.

Orden de cierre (si saltas el 1 y el 2, el resto no sirve)

1. Asumir compromiso persistente hasta el escaneo de integridad y la rotación de credenciales.
2. No actualizar plugins sobre una instalación infectada: no la limpia y un respaldo de hoy replica el código.
3. Quitar activadores no oficiales y productos sin canal de parches.
4. WAF + escáner + respaldo automatizado fuera del servidor.
5. Recién ahí: actualizaciones, caché único, memoria PHP, pasarela en modo producción.

Qué pedirnos

Un informe técnico post-incidente —hallazgos con evidencia, severidad y dueño de cada cierre— o el webmaster de mantenimiento si el sitio todavía no se ha caído y quieres que no llegue a eso.

No publicamos casos. El patrón, sí: se repite.

Si el sitio volvió a línea pero no sabes si quedó limpio, la auditoría técnica de plataforma abre código, motor, servidores y controles y los cruza en un solo informe.