Abres el correo y tienes un aviso de tu proveedor de alojamiento: han suspendido tu cuenta por malware. La web no carga, el correo del dominio tampoco funciona y tus clientes ven una página de error. Lo primero: no está todo perdido y tus ficheros siguen ahí. Una suspensión no es un borrado, es un candado. Lo segundo, y más importante: la forma de salir rápido no es discutir con el hosting, sino darles exactamente lo que necesitan para levantar el candado. Aquí tienes qué pedirles, cómo trabajar con la cuenta apagada y qué informe hay que mandar para que la reactiven a la primera y no a la cuarta.
Qué te está diciendo el aviso del hosting y qué se está callando
Los avisos de suspensión suelen ser genéricos: «se ha detectado contenido malicioso en su cuenta» y poco más. Antes de responder, identifica de cuál de estos tres casos se trata, porque el trabajo es distinto:
- Ficheros maliciosos detectados. El antivirus del servidor ha encontrado código sospechoso en tu espacio. Es el caso más frecuente.
- Envío de correo no deseado. Tu cuenta está mandando miles de correos. Aquí lo que les preocupa no eres tú, es que la IP del servidor entre en listas negras y afecte a todos sus clientes. Suele ir acompañado de problemas de entregabilidad que tardan en irse; si ya te está pasando, el proceso está en qué hacer cuando tu dominio entra en una lista negra de correo.
- Consumo de recursos. Te suspenden por saturar CPU o procesos. A veces es un ataque, a veces es un plugin mal hecho. No es lo mismo y no se soluciona igual.
Lo que el aviso normalmente no dice, y tú necesitas: qué ficheros concretos, con qué firma se detectaron, en qué fecha, y si te han puesto la cuenta en solo lectura o el bloqueo es total. Eso hay que preguntarlo.
Pedir el listado de archivos detectados: el dato que lo cambia todo
Responde al aviso —normalmente a una dirección de tipo abuse@ del proveedor— pidiendo esto, tal cual, en una lista corta:
- La ruta completa de cada fichero detectado, desde
/home/. - El nombre de la firma o detección de cada uno (los antivirus de servidor devuelven identificadores concretos, no un genérico).
- La fecha y hora de la detección y, si la tienen, la fecha de creación del fichero.
- Si hay ficheros en cuarentena y si te los pueden devolver o al menos listar.
- Las líneas de registro relacionadas: si fue correo, la cabecera de un mensaje de muestra; si fue una intrusión web, las peticiones POST asociadas.
- El procedimiento exacto de reactivación: a quién se manda el informe y qué quieren ver en él.
Este listado es oro. Te da las fechas con las que buscar el resto de ficheros infectados, te dice qué familia de malware es y, sobre todo, te dice qué van a volver a escanear cuando pidas la reactivación.
Un detalle que ahorra días: pregunta explícitamente si el escaneo se relanza automáticamente cada X horas o si hay que solicitarlo. Muchos proveedores repiten el análisis por su cuenta y la cuenta se reactiva sola cuando el resultado sale limpio.
Acceso en modo lectura: cómo trabajar con la cuenta suspendida
Aunque la web esté apagada de cara al público, casi siempre conservas alguna vía de acceso. Comprueba en este orden:
- El panel de hosting. En muchas suspensiones se bloquea el sitio web pero el panel sigue accesible, con su gestor de archivos y phpMyAdmin.
- SFTP o SSH, que a menudo siguen funcionando aunque el servidor web no sirva páginas.
- Si no tienes nada, pide al proveedor acceso temporal para limpiar. Es una petición razonable y habitualmente la conceden: les interesa que limpies.
Lo primero que debes hacer con ese acceso, antes de borrar un solo fichero, es bajarte una copia completa: todo el directorio del sitio y un volcado de la base de datos. Sí, una copia que contiene malware. Precisamente por eso: es tu única prueba de lo que había, y si te equivocas borrando algo del núcleo la necesitarás. Guárdala comprimida, fuera del servidor y en una carpeta que no se sincronice sola con nada.
mysqldump -u usuario -p basededatos > copia_forense.sql
tar -czf copia_forense_web.tar.gz public_html/
Anota también la fecha de modificación de los ficheros que te han señalado, con ls -la sobre cada ruta. Esa marca de tiempo es el punto de partida para encontrar lo demás.
Limpiar con la web apagada: ventajas y trampas
Que la cuenta esté suspendida tiene una ventaja: nadie puede volver a entrar mientras trabajas. En una limpieza con la web en marcha es normal ir por la mitad y encontrar ficheros nuevos. Aquí no.
La secuencia razonable, aprovechando el parón:
- Borra los ficheros que te han listado, después de comprobar que efectivamente no son tuyos.
- Sustituye el núcleo de WordPress entero por una descarga oficial de
wordpress.org, conservando solowp-config.phpywp-content. - Reinstala cada plugin y cada tema desde su origen oficial, en lugar de intentar reparar los que hay.
- Busca lo que no se puede sustituir: ficheros PHP dentro de
wp-content/uploads/, la carpetawp-content/mu-plugins/, y cualquier.phpen la raíz que no forme parte de WordPress. - Revisa la base de datos, los usuarios administradores y las tareas programadas.
El detalle completo, paso a paso, está en la guía de limpieza de un WordPress hackeado. Y la parte que realmente decide si esto vuelve a pasar es encontrar las puertas traseras, porque el antivirus del hosting detecta lo que tiene firma conocida, no lo que está bien escondido.
Las dos trampas de limpiar en esta situación:
La prisa. Con la web caída, la tentación es borrar los cuatro ficheros de la lista y pedir la reactivación inmediatamente. Si quedó una puerta trasera, en 48 horas te vuelven a suspender y la segunda vez son bastante menos comprensivos.
Restaurar una copia sin más. Si la copia de seguridad es posterior a la intrusión, estás restaurando el malware. Y si es anterior pero entraron por un plugin desactualizado, vuelven a entrar por el mismo sitio en cuanto la web esté viva. Restaurar sirve para recuperar contenido, no para desinfectar.
Falsos positivos: cuándo el hosting se equivoca y cómo demostrarlo
Ocurre y no es raro. Los antivirus de servidor marcan por patrones, y hay código legítimo que se parece bastante al malicioso: minificadores de JavaScript, plugins de caché que generan ficheros PHP dinámicos, herramientas de licencia que ofuscan parte de su código, o instaladores de temas comerciales.
Cómo demostrar que un fichero es legítimo, con pruebas y no con opiniones:
- Compáralo con el original. Descarga la misma versión del plugin de su fuente oficial y compara el fichero:
md5sum ruta/al/fichero.php diff -u original.php sospechoso.phpSi el hash coincide con el del paquete oficial, es el fichero original y punto. Ese es el argumento definitivo.
- Fecha de modificación coherente con la fecha de instalación del plugin, no con la del incidente.
- Está donde debe estar: dentro de la carpeta de su plugin, no en
uploadsni en la raíz.
Manda esa comparación al soporte y pídeles que añadan una exclusión para esa ruta. Ahora bien, sé honesto: si el fichero está en wp-content/uploads/2024/07/, no es un falso positivo por muy legítimo que parezca. Ahí no va código PHP nunca.
El informe que hay que enviar para que la reactiven a la primera
Un correo de «ya está limpio, reactívenme» recibe un escaneo rápido y, si aparece cualquier cosa, una negativa. Un informe concreto suele acelerar bastante el proceso porque le ahorra trabajo al técnico que lo lee. Cinco apartados, media página:
- Qué había. Los ficheros que te listaron y lo que encontraste tú por tu cuenta, con rutas completas.
- Cómo entraron, si lo sabes: plugin sin actualizar, contraseña comprometida, credenciales de FTP filtradas. Si no lo sabes con certeza, dilo así, con la hipótesis más probable y en qué te basas.
- Qué has hecho, en lista: núcleo sustituido, plugins reinstalados desde origen, X ficheros eliminados con sus rutas, usuarios falsos borrados, contraseñas rotadas, claves de
wp-config.phpregeneradas, tareas programadas revisadas. - Qué has cambiado para que no se repita. Plugin vulnerable retirado o actualizado, verificación en dos pasos activada, FTP plano desactivado, accesos antiguos eliminados.
- Qué pides: que relancen el escaneo y reactiven la cuenta; y, si puede ser, que te pasen el resultado del escaneo aunque salga limpio.
Si tienes un análisis externo del dominio, adjúntalo. No sustituye al escaneo del servidor, pero demuestra que has hecho una verificación independiente y no solo un borrado a ojo.
Si te suspenden dos veces seguidas, algo se ha quedado dentro
Una reinfección a los pocos días no es mala suerte. Significa una de estas cuatro cosas, y merece la pena descartarlas en este orden:
- Quedó una puerta trasera que el antivirus no detecta porque no tiene firma conocida. Es la causa más frecuente.
- Hay otro sitio infectado en la misma cuenta. Si tienes varios dominios bajo el mismo usuario del servidor, se contagian entre ellos sin necesidad de volver a entrar desde fuera. Hay que limpiarlos todos a la vez, no de uno en uno.
- Una tarea programada del panel o del cron interno de WordPress vuelve a descargar el código cada noche.
- Tu ordenador está infectado y les está entregando las credenciales otra vez cada vez que las cambias.
Llegado a este punto, y sobre todo si la web es la que te trae clientes, deja de intentarlo por tu cuenta. Una limpieza profesional en España ronda los 500 euros e incluye la búsqueda de la vía de entrada, que es justo la parte que no se resuelve borrando ficheros. Comparado con un negocio parado una semana y un hosting que ya no se fía de ti, la cuenta sale sola. Si quieres el panorama completo de todo lo que hay que revisar tras un incidente, el manual de qué hacer cuando te hackean la web lo ordena de principio a fin.
Pide el informe gratuito y adjúntaselo a tu hosting como prueba de la limpieza. Es un análisis externo de tu dominio, sin registro y sin tocar tu servidor, que documenta en qué estado se ve tu web desde fuera. Enviarlo junto con tu informe de limpieza le da al técnico de soporte algo objetivo con lo que trabajar, y eso suele traducirse en una reactivación más rápida.