Un lunes el navegador deja de abrir el sitio de la empresa y muestra una advertencia a pantalla completa: sitio engañoso más adelante. El proveedor de alojamiento responde que el problema está en la web del cliente. Al entrar al panel aparece lo que nadie había mirado en años: en esa cuenta no hay un sitio, hay veintidós. El de la empresa, dos marcas que ya no operan, tres instalaciones de prueba y una docena de proyectos antiguos.
La pregunta que sigue es siempre la misma: ¿se limpia el que está marcado y se cierra el caso? No. En un alojamiento compartido los sitios hackeados no son casos independientes: comparten el mismo espacio de archivos y el mismo usuario del sistema. Limpiar uno y dejar los otros equivale a cerrar la puerta y dejar la ventana abierta.
¿Por qué aparecen varios sitios hackeados en la misma cuenta?
Porque en un plan compartido todos los sitios corren bajo el mismo usuario del sistema y en la misma carpeta raíz. El código de un sitio lee y escribe en las carpetas del vecino sin pedir permiso, porque para el servidor es el mismo dueño. Basta una instalación abandonada con un complemento sin actualizar para dejar el resto al alcance.
Tres hábitos multiplican el problema: la misma contraseña en el panel, la base de datos y el correo; instalaciones clonadas que heredan la misma versión vulnerable; y proyectos de prueba que nunca se dieron de baja.
En junio de 2026 intervenimos una cuenta compartida con 22 sitios y se eliminaron 9 puertas traseras repartidas entre varias instalaciones. Ninguna estaba en el sitio que el navegador había marcado.
Las señales que llegan antes
El aviso rara vez lo da el propio sitio. Llega de afuera:
- El navegador o el buscador marca el dominio como peligroso.
- El correo del dominio rebota o cae en no deseados: la dirección del servidor quedó en listas de bloqueo por envío masivo.
- El proveedor avisa de un consumo de procesador anormal, o suspende la cuenta sin explicación.
- Aparecen en el buscador direcciones del dominio que nadie creó.
Cualquiera de las cuatro obliga a revisar la cuenta completa.
Dónde se esconde la reinfección
Lo difícil no es borrar el archivo que inyecta la publicidad: es encontrar lo que vuelve a ponerlo. Eso se llama persistencia y casi nunca está donde se mira primero.
| Dónde se esconde | Cómo se detecta | Qué se hace |
|---|---|---|
| Archivos de arranque obligatorio del gestor | Se cargan solos y no se desactivan desde el panel: hay que listar la carpeta por consola | Comparar contra el origen oficial y retirar lo que no tenga procedencia |
| Tareas programadas | Una tarea que descarga y ejecuta un archivo remoto cada pocos minutos | Listar las del sistema y las del gestor, no solo las del panel |
| Claves de acceso remoto | Claves públicas que nadie reconoce en el archivo de claves autorizadas | Vaciar el archivo y cargar solo las vigentes |
| Usuarios administradores nuevos | Un administrador creado fuera de horario, con correo en un dominio ajeno | Dar de baja y forzar el cambio de clave a todos |
| Configuración del servidor | Reglas que redirigen según el navegador o según de dónde venga la visita | Restaurar desde copia limpia y reaplicar solo lo propio |
| Plantillas del tema | Cambios en cabecera, pie y archivo de funciones, que afectan a todas las páginas | Reinstalar tema y gestor copiando los archivos del origen oficial |
Un detalle que cuesta casos repetidos: bloquear la ejecución de código en la carpeta de subidas conviene, pero no cierra el caso. Los archivos de arranque obligatorio están en otra carpeta y el gestor los carga antes, sin pasar por esa regla. Si la revisión se detiene en subidas, el sitio se reinfecta.
El orden correcto de respuesta
El orden importa tanto como el trabajo técnico. Invertir dos pasos obliga a repetir todo.
- Aislar. Los sitios salen de línea o quedan detrás de una página de mantenimiento. Limpiar con el sitio expuesto permite que lo comprometan de nuevo en plena limpieza.
- Respaldar la evidencia. Copia completa de archivos y base de datos, con fecha y hora, aunque esté infectada. Es lo único que después permite saber por dónde entraron.
- Barrer todos los sitios a la vez. Las 22 instalaciones, no la marcada, en la misma ventana de trabajo, y dar de baja las que ya no se usan.
- Rotar todas las claves. Panel, acceso remoto, base de datos, administradores de cada sitio y buzones del dominio. Las anteriores hay que darlas por conocidas por el atacante.
- Reponer. El contenido vuelve desde un respaldo anterior a la infección. Si es posterior, restaurarlo reinstala el problema: primero se comparan fechas.
- Vigilar. Treinta días de revisión de accesos y de archivos que cambian, más la solicitud de revisión al buscador para que retire la advertencia.
Cuándo se limpia y cuándo se reconstruye
| Situación | Limpiar | Reconstruir |
|---|---|---|
| Una puerta trasera en un sitio, el resto limpio | Sí | No |
| Varias puertas traseras en varios sitios de la misma cuenta | Sí, todos a la vez | No, si el servidor no es propio |
| Dos o más persistencias con permisos de administrador | No | Sí |
| Librería enganchada al arranque que oculta archivos y procesos | No | Sí |
| Sin registros ni respaldos previos a la infección | Se trabaja a ciegas | Recomendado |
Las dos últimas filas vienen de un caso en servidor propio: una librería enganchada al arranque del sistema que oculta archivos, procesos y conexiones. El efecto práctico es que las herramientas normales mienten: el listado de archivos no muestra el archivo que sí está cargado. La salida es investigar con utilidades estáticas, que no dependen de esa librería.
De ahí la regla con la que trabajamos: con dos persistencias de nivel administrador en un servidor, lo honesto es reconstruir, no limpiar. Si además se perdió el acceso administrativo, el orden cambia y conviene empezar por qué hacer si perdió el acceso al servidor.
Qué significa esto para su negocio
Una importadora de Quito con cuatro sitios de marca en una sola cuenta tiene un solo perímetro: el más descuidado define la seguridad de los otros tres. Una operadora de turismo con el dominio marcado en temporada alta pierde reservas mientras siga la advertencia.
El caso más delicado es el de quien aloja sitios de terceros en su propia cuenta. Si entre los datos expuestos hay información personal, corresponde revisar las obligaciones de notificación ante la autoridad de protección de datos. Separar cada sitio en su propia cuenta es la medida más barata de todas, y entra en la decisión entre hosting gestionado y hosting barato.
Cuánto cuesta salir del incidente
| Servicio | Inversión | Cuándo aplica |
|---|---|---|
| Diagnóstico de ciberseguridad | USD 850, precio cerrado | Medir el alcance real antes de tocar nada |
| Intervención de servidor | Mínimo USD 500 | Limpieza, cierre de persistencias y rotación de claves |
| Monitoreo de ciberseguridad | Se define en el diagnóstico | Vigilancia continua tras el incidente |
| Mantenimiento web Esencial | USD 190 al mes | Un sitio: respaldos, actualizaciones y revisión |
| Mantenimiento web Profesional | USD 280 al mes | Varias instalaciones o integraciones |
| Mantenimiento de tienda en línea | USD 420 al mes | Con pedidos, pagos y datos de compradores |
| Hosting administrado | Desde USD 150 al año | Separar cada sitio en su propia cuenta |
Todos los valores excluyen el IVA del 15%. El orden es diagnóstico primero e intervención después, porque el diagnóstico dice si el caso se limpia o se reconstruye: antes del monitoreo va el diagnóstico de ciberseguridad. Contratar vigilancia sobre un servidor que todavía tiene una puerta trasera abierta solo documenta el siguiente incidente.
Plazos: qué esperar
Con una cuenta compartida de veinte sitios, el aislamiento y el respaldo de evidencia ocupan el primer día. El barrido completo y la rotación de claves toman entre dos y cinco días. La reposición depende de que exista un respaldo anterior a la infección: si hay que reconstruir desde cero, el plazo se cuenta en semanas.
El retiro de la advertencia del navegador no depende del proveedor. Cerrado el hueco se solicita la revisión al buscador y la respuesta llega en días. Mientras tanto el sitio sigue mostrando el aviso aunque ya esté limpio.
Preguntas frecuentes
¿Por qué hay que limpiar todos los sitios y no solo el infectado?
Porque todos corren bajo el mismo usuario del sistema y comparten el espacio de archivos: un archivo malicioso en un sitio escribe en las carpetas del vecino. Al limpiar uno solo, la reinfección llega desde el que quedó sucio, en horas.
¿Sirve bloquear la ejecución de código en la carpeta de subidas?
Sirve y conviene dejarlo puesto, pero no cierra el caso: los archivos de arranque obligatorio del gestor están en otra carpeta y se cargan antes.
¿Puedo restaurar un respaldo y seguir trabajando?
Solo si es anterior a la infección. Un respaldo posterior contiene la puerta trasera y restaurarlo reinstala el problema. Hay que comparar la fecha del respaldo con la del primer indicio antes de tocar nada.
¿Cuándo conviene reconstruir el servidor en vez de limpiarlo?
Con dos o más persistencias de nivel administrador, o cuando una librería enganchada al arranque oculta archivos y procesos. Ahí las herramientas del propio servidor dejan de ser confiables y ninguna limpieza se puede dar por completa.
¿Qué claves hay que cambiar después de limpiar?
Todas: panel de alojamiento, acceso remoto, base de datos, administradores de cada sitio y buzones del dominio, más las claves de sesión del gestor.
¿Cuánto cuesta salir de varios sitios hackeados en el mismo hosting?
El diagnóstico tiene precio cerrado de USD 850 e incluye el alcance real del incidente. La intervención del servidor parte de USD 500 según cuántas instalaciones haya que barrer. Ambos valores excluyen el IVA del 15%.
Artículos relacionados
- Heredar un sitio web de otra agencia sin perderlo todo: qué pedir por escrito antes de cambiar de proveedor digital.
- Mis formularios no llegan: qué revisar hoy en la web: si los formularios no llegan.
- Página web para courier y encomiendas: qué debe tener: página web para courier con rastreo por número de guía.
Fuentes consultadas
- WordPress, mi sitio fue comprometido: advierte que en alojamiento compartido el problema puede afectar a más de un sitio.
- WordPress, complementos de uso obligatorio: se activan solos en toda la instalación y no se desactivan desde el panel.
- Google Search Central, software malicioso: el informe de seguridad y la solicitud de revisión.
- Google Search Central, prevenir una infección: revisión del archivo de configuración del servidor.
- Superintendencia de Protección de Datos Personales: autoridad competente si hay datos personales de terceros.
Documentación verificada en octubre de 2026.
El siguiente paso
Si el navegador marcó su dominio y al abrir el panel vio más sitios de los que recordaba, el primer movimiento no es borrar archivos: es medir el alcance. Conviene saber cuántas instalaciones hay, cuáles están infectadas y si el caso se limpia o se reconstruye.
En Blue Nova ese diagnóstico tiene precio cerrado y entrega el inventario de la cuenta, las persistencias encontradas y el plan de respuesta con su orden. Los valores están en nuestra página de precios. Para revisar su caso, escríbanos con el dominio marcado y el nombre de su proveedor de alojamiento.
Blue Nova Consulting
¿Lo tiene caído en este momento?
Escríbanos y revisamos su caso. El WhatsApp y el formulario llegan al mismo equipo técnico.
Los valores que aparecen en este artículo son referenciales y no incluyen el IVA del 15 por ciento.
Sigue leyendo
Comentarios y opiniones
0 comentarios · Moderación previa
Cuéntanos tu experiencia, dudas o casos similares. Revisamos cada comentario antes de publicarlo para mantener conversaciones de calidad. También puedes suscribirte para recibir nuevos artículos.