Un host puede suspender para detener phishing, malware, spam, abuso de recursos o ataques a otros clientes. Pedir reapertura sin plan retrasa la recuperación y permite repetir el comportamiento.
Trata el informe como evidencia y construye una copia limpia offline o aislada.
Obtén detalles
Solicita URLs/archivos detectados, horas, tipo de abuso, evidencia del scanner, actividad mail/red y requisitos de revisión. Guarda ticket y persona.
No pidas ejecutar archivos ni enviar malware por email. Solicita acceso seguro a la cuarentena cuando la política lo permita. Aclara si está suspendida la cuenta o un dominio.
Pregunta qué indicador activa automáticamente una nueva suspensión y qué formato debe tener la solicitud. Diferencia una detección por firma de una observación de tráfico o abuso de recursos. Eso define las pruebas necesarias y evita discutir solo el nombre de un archivo.
Conserva copias y logs
Pide snapshot de archivos/base y logs access, error, PHP, correo y panel antes de que expiren. Guarda fuera del document root con acceso limitado.
No restaures directamente a producción ni subas a otro host público. La copia es evidencia y fuente para reconstrucción, no prueba de limpieza. Registra fecha, tamaño y origen.
Verifica que el archivo incluya dotfiles, mu-plugins, cron/export del panel y todas las tablas correctas. Calcula checksum y prueba que pueda abrirse en aislamiento. Una copia incompleta puede omitir precisamente el mecanismo de persistencia.
Asegura la propiedad
Desde equipo limpio rota hosting, registrar/DNS, email y deploy. Revoca usuarios, sesiones, tokens y SSH/SFTP desconocidos y activa MFA.
Confirma contactos de facturación y cuenta. Usa el proceso de identidad del proveedor, no contraseñas en tickets. Revisa reseller y antiguos desarrolladores.
Crea una copia aislada
Usa local/staging aislado sin SMTP, pagos o keys de producción. Impide indexación y callbacks.
Importa base/uploads para analizar, pero instala core/plugins/temas desde fuentes confiables. Trata custom code/uploads como no confiables. No publiques la copia infectada en un subdominio adivinable.
Bloquea salida de correo, pagos y callbacks y limita también la navegación saliente del entorno. Un script activo en staging podría seguir enviando spam, atacando terceros o notificando al atacante. Usa datos sanitizados cuando no sea necesaria la base completa.
Identifica causa y alcance
Revisa indicadores del host, archivos, usuarios, tareas, inyecciones, versiones vulnerables y credenciales. Inspecciona webs hermanas si comparten cuenta.
Determina si spam/phishing/recursos procedían de WordPress, otra aplicación o credencial del hosting. Quitar el archivo nombrado sin encontrar persistencia no basta.
Construye una tabla por indicador con ruta, hash, propietario, primera/última hora y mecanismo de ejecución. Busca coincidencias en cron, logs y otras webs. Documenta qué evidencia demuestra el vector y qué queda como hipótesis.
Reconstruye limpio
Sustituye componentes mantenidos, valida código, importa contenido evaluado y recrea configuración conocida. Cierra la ruta vulnerable y rota base, salts, SMTP/API y pagos.
Aplica PHP/WordPress soportados, permisos mínimos y administradores controlados. Mantén inventario de cada componente conservado.
Define la puerta de reapertura
Antes de pedir reactivación confirma que cesó el comportamiento en la copia, la entrada está corregida, acceso privilegiado conocido y correo no puede reanudar abuso.
Acorda qué hostname/document root activará el host. No apuntes producción a un archivo no revisado para que lo escanee. Prepara rollback y contacto de contención para la primera ventana.
Define criterios de fallo tras abrir: nuevo correo abusivo, modificación inesperada, pico de CPU o redirect. Si aparece alguno, el proveedor debe poder suspender solo el root limpio o devolver mantenimiento mientras se preservan nuevos logs.
Prepara evidencia para el host
Entrega resumen: sitio, causa si se conoce, componentes reemplazados, credenciales rotadas, updates, contención de spam y pruebas.
No adjuntes toda la base, clientes o secretos. Responde las preguntas exactas e identifica el root limpio. Solicita ventana controlada si validar requiere tráfico público.
Incluye versiones soportadas, componente vulnerable retirado y cómo verificaste usuarios, cron y correo. Evita afirmar «100 % limpio»; describe acciones y resultados reproducibles que el host pueda revisar.
Verifica tras la reapertura
Prueba inicio, login, formularios, checkout, cron, correo y redirects desde sesiones limpias. Monitoriza recursos, salida, archivos y cuentas.
Mantén el root antiguo aislado/no ejecutable durante la retención aprobada. Concilia pedidos/leads y comunica mediante el responsable.
Solicita recuperación urgente si el host da indicadores parciales o varias webs comparten cuenta. Proporciona acceso gestionado y ticket, nunca backups o credenciales públicamente.