«El malware todavía no ha vuelto» no es una prueba. Una puerta trasera puede esperar a cron, un visitante concreto, un inicio administrativo o un controlador externo. La verificación debe probar la ruta identificada y observar la web más allá del intervalo anterior de recurrencia.
Define qué evidencias necesitas antes de declarar terminada la limpieza.
Describe con precisión la ruta sospechosa
Escribe una causa breve: un endpoint de subida vulnerable creó un cargador PHP; una cuenta SFTP robada modificó tres webs; un cron malicioso restauró una opción inyectada.
Separa hechos confirmados, inferencias y logs no disponibles. Si la ruta continúa desconocida, indícalo y amplía la monitorización en lugar de afirmar que está cerrada.
Registra el periodo afectado, los componentes y las cuentas implicadas.
Verifica el control del punto de entrada
Confirma, mediante comprobaciones admitidas por el desarrollador, que el componente vulnerable está parcheado, eliminado o restringido. No reproduzcas exploits destructivos contra una web pública.
Si se robaron credenciales, demuestra que sesiones y tokens están revocados y que se aseguró el dispositivo o almacén de origen. Si el problema era el aislamiento, verifica con comprobaciones autorizadas que el usuario de una web no puede escribir en las rutas de otra.
Conserva evidencias anteriores y posteriores con los secretos censurados.
Elimina la persistencia establecida
Compara núcleo, plugins y temas con fuentes limpias. Revisa código propio, uploads, inyecciones en base, administradores, contraseñas de aplicación, cron de WordPress y del servidor y capas de hosting, DNS y CDN.
Busca hashes, rutas, dominios y cadenas conocidos del incidente. La ausencia de un solo indicador no cubre sus variantes; combínala con comprobaciones de procedencia y comportamiento.
Documenta cada elemento puesto en cuarentena o eliminado y la fuente usada para sustituirlo.
Reproduce los ciclos normales
Ejecuta WP-Cron, Action Scheduler, copias, regeneración de caché, despliegues y actualizaciones autorizadas. Guarda primero en staging los ajustes que antes provocaban la regeneración de archivos.
Repite las condiciones originales del visitante —móvil, referencia de buscador, primera visita o ruta afectada— dentro de un perfil de navegador seguro.
No contactes con infraestructura del atacante ni ejecutes payloads antiguos para demostrar el cierre.
Monitoriza cambios que tengan significado
Crea una referencia de hashes posterior a la limpieza para el código de confianza y alertas ante ejecutables en uploads, administradores desconocidos, cron nuevo y cambios de configuración sensible.
Excluye el movimiento normal de cachés y medios. Si cada miniatura genera una alerta, el equipo acabará ignorándolas.
Conserva logs web, de autenticación y de cambios durante suficiente tiempo para cubrir la recurrencia previa y los ciclos programados.
Busca evidencias fuera del servidor comprometido
Usa registros independientes que el atacante no pudiera modificar con facilidad: solicitudes del CDN, historial de autenticación del hosting, monitorización externa, logs del proveedor de correo e historial del repositorio o despliegue.
Compáralos con la cronología del servidor limpio. Si los logs locales desaparecieron, las fuentes externas aún pueden mostrar la última redirección, un acceso desconocido al panel o el despliegue que introdujo un archivo.
Documenta las lagunas de conservación; la ausencia de eventos locales no demuestra que no hubo acceso.
Verifica los límites de cuenta y entorno
Comprueba cada instalación bajo el usuario de hosting afectado. Confirma que staging y webs antiguas retiradas son inaccesibles y que los artefactos de despliegue están limpios.
Revisa usuarios de panel, SFTP y SSH, cuentas de correo usadas para restablecer accesos, claves API, DNS y CDN. Aplica cuentas individuales, privilegio mínimo y MFA donde se admita.
Un directorio WordPress limpio no compensa una sesión activa del panel.
Prueba la funcionalidad del negocio
Envía formularios, verifica el correo, prueba inicio y restablecimiento de contraseña y completa un checkout WooCommerce autorizado en sandbox. Confirma que los cambios de seguridad no rompieron pagos, webhooks o pedidos programados.
Inspecciona el HTML público y las conexiones salientes buscando los dominios maliciosos anteriores. Comprueba que las URL spam retiradas devuelven correctamente 404 o 410.
Define observación y respuesta
Elige la duración según las evidencias: intervalo de retorno anterior, horario de cron, desencadenante de tráfico y riesgo de credenciales. Define quién recibe cada alerta y qué contención está previamente autorizada.
Entrega al propietario los hallazgos, limitaciones, acciones sobre credenciales y un registro fechado de la verificación.
Cuándo conviene una verificación independiente
Solicita una segunda revisión si la ruta de entrada es incierta, el checkout estuvo afectado o varias webs compartían accesos. La evaluación puede partir de la cronología y los indicadores saneados.
La confianza procede de pruebas específicas de la ruta y evidencias estables, no de un único resultado verde del escáner.