La primera respuesta debe reducir el daño sin borrar la información necesaria para conocer acceso, alcance y recuperación. Eliminar archivos sospechosos puede quitar síntomas mientras destruye fechas y deja al atacante activo.
Trabaja con una cronología escrita y cambios reversibles siempre que sea posible.
Minuto 0–5: confirma el riesgo
Registra quién informó, hora y zona, URL afectada y síntomas. Comprueba si checkout, login, descargas o administración pueden exponer clientes.
No visites páginas sospechosas autenticado a WordPress, hosting o email en el mismo perfil. Usa dispositivo limpio o navegador aislado y no descargues archivos desconocidos.
Si pudiera haber datos de tarjeta, activa de inmediato el proceso del proveedor de pago y la organización.
Minuto 5–10: conserva una instantánea
Solicita al host una copia de archivos, base y logs antes de limpiar. Registra identificador del servidor y horas. Guarda todo protegido y con acceso limitado.
No restaures todavía sobre la web: eliminaría evidencias y quizá devolvería una versión vulnerable. No envíes el archivo por email ni lo dejes dentro del directorio público.
Confirma que la copia terminó y cuándo rotarán los logs. Calcula un hash del archivo o guarda el checksum ofrecido por el proveedor.
Minuto 10–15: contiene el daño público
Elige la medida más estrecha que proteja: desactivar checkout, servir mantenimiento controlado, bloquear una ruta maliciosa o suspender la cuenta comprometida.
Cuando WordPress no sea confiable, usa una página estática fuera de la aplicación, no un plugin de mantenimiento. Conserva acceso para respondedores mediante controles del hosting sin publicar la IP de origen.
Documenta qué URL y funciones quedaron bloqueadas para que negocio y soporte sepan el impacto.
Minuto 15–20: asegura el plano de control
Desde un equipo limpio rota hosting/panel, administradores WordPress, claves SSH/deploy y base potencialmente expuestos. Protege primero el email principal y activa MFA.
No cambies todos los secretos a ciegas antes de registrar dependencias: podrías romper servicios y logs. Prioriza cuentas capaces de modificar archivos, base, DNS y copias.
Revoca sesiones desconocidas y anota cada acción. Si varias webs comparten credencial, amplía el alcance.
Minuto 20–25: recoge evidencia volátil
Preserva access/error logs, PHP, eventos de seguridad, cola de correo, procesos/tareas y lista de administradores. Registra archivos modificados sin ejecutar PHP sospechoso.
Captura DNS, redirects y configuración relacionada. Identifica los archivos mediante hashes para comparar copias. Minimiza datos del cliente y usa el repositorio de evidencias aprobado.
No instales un scanner nuevo en producción si altera miles de fechas o consume el servidor antes de tomar la copia.
Minuto 25–30: define recuperación limpia
Lista fuentes confiables de core, plugins y temas; backups conocidos; PHP; propietario del código y servicios externos. Decide si conviene reconstruir componentes y importar contenido validado en vez de «limpiar en sitio».
Asigna responsables de contención, investigación, comunicación y conciliación. Define qué debe verificarse antes de abrir. No prometas una hora hasta entender vector y persistencia.
Evita reacciones destructivas
No borres todo lo reciente, sobrescribas la base, ejecutes scripts desconocidos ni des acceso ilimitado a terceros. Un atacante puede cambiar timestamps y archivos legítimos también son recientes.
No pagues rescate ni contactes al supuesto atacante sin responsable autorizado y asesoramiento jurídico. Comunica a clientes por canales aprobados cuando el riesgo lo exija.
Define la primera puerta de verificación
La contención funciona cuando cesa el comportamiento malicioso público, las cuentas de control están protegidas y la evidencia conservada. No prueba que la web esté limpia.
La recuperación exige identificar persistencia, reemplazar código, revisar base/usuarios, cerrar entrada, rotar secretos y probar la reconstrucción.
Solicita rescate urgente si afecta checkout, administración, correo o varias webs. Comparte acceso gestionado y logs redactados, nunca contraseñas, backups o datos públicos.