# Qué hacer cuando tu web ha sido hackeada (guía de primeros auxilios) Source: https://baqueiro.es/seguridad-y-juridico/que-hacer-web-hackeada/ Published: 2026-08-26T07:03:00+00:00 Updated: 2026-08-26T07:03:00+00:00 Author: Baqueiro Desarrollo Web Language: es Usage: Atribución requerida: se permiten citas con un enlace visible hacia atrás --- **TL;DR** - Lo primero es parar la hemorragia: aislar el sitio para evitar más daño y proteger a las visitas. - Recuperarse exige saber qué pasó, reconstruir desde una base limpia y cerrar la puerta por la que entraron. - Documentar todo durante el incidente es clave, tanto para la recuperación como para tus obligaciones legales. La llamada llegó a las 9:30 de la mañana: «Mi web redirige a una página que descarga malware». Nuestro cliente se había enterado porque uno de sus propios clientes se había quejado. Según los logs, la web llevaba así al menos 18 horas. Nadie lo había notado. Es el escenario típico: descubres el hackeo tarde, cuando ya ha hecho daño. Lo que hagas en las primeras horas determina la gravedad final del incidente. Este es el protocolo que seguimos, por orden de prioridad (y aquí tienes [un caso completo de principio a fin](https://baqueiro.es/cyberseguridad/caso-de-estudo-de-hackeado-a-100-seguro-en-12-horas-la-anatomia-de-un-rescate-digital/)). ## Fase 1: contención inmediata (primeros 30 minutos) El objetivo es evitar más daño. No pienses todavía en arreglar; piensa en parar la hemorragia. **1. Pon el sitio en modo mantenimiento o desconéctalo.** Si tienes acceso al escritorio de WordPress o al panel del hosting, activa el modo mantenimiento; si no, pide a tu hosting que suspenda temporalmente la cuenta. Así proteges a las visitas y evitas que el atacante siga usando tu servidor. Otra opción es apuntar el DNS a una página estática de mantenimiento en otro servidor, dejando aislado el comprometido. **2. Guarda una copia del sitio comprometido.** Antes de borrar o restaurar nada, descarga archivos, base de datos y logs, y guárdalos aparte. Son la prueba de lo ocurrido: los necesitarás para encontrar el punto de entrada y para justificar lo que hiciste. Muchos hostings borran los logs al cabo de pocos días. **3. Cambia todas las contraseñas.** Administrador de WordPress, hosting, FTP, base de datos y correo asociado al dominio. Da por hecho que todas están comprometidas. Hazlo desde un ordenador que sepas limpio y usa contraseñas aleatorias de 20 caracteres o más, generadas con un gestor. Si tu equipo flojea aquí, repasa [lo mínimo sobre contraseñas, 2FA y gestores](https://baqueiro.es/seguridad-y-juridico/contrasenas-2fa-gestores-seguridad-equipo/). **4. Cierra las sesiones activas.** En WordPress, cierra las sesiones desde el perfil de cada usuario y regenera las claves de seguridad (salts) de wp-config.php, lo que obliga a todos a volver a iniciar sesión. Así expulsas a cualquier atacante que siga dentro. **5. Avisa a las personas clave.** Dirección, el delegado de protección de datos o responsable legal (si hay datos personales en juego) y, si procede, los clientes clave expuestos. Comunicar pronto, aunque sea de forma incompleta, es mejor que el silencio. ## Fase 2: evaluación del daño (primeras 4 horas) Con el sitio aislado, toca averiguar qué ha pasado y hasta dónde llega el problema. **Analiza los logs de acceso.** Busca peticiones sospechosas: POST a archivos que no deberían recibir subidas, accesos a wp-admin desde IP extrañas, peticiones con patrones de inyección SQL o XSS. Busca especialmente: - Archivos PHP subidos a la carpeta de uploads. - Peticiones a archivos que antes no existían (puertas traseras con nombres aleatorios). - Accesos correctos a wp-admin desde lugares en los que tu equipo no puede estar. **Identifica el vector de entrada.** ¿Por dónde entraron? Las vías más habituales son: - Un plugin o tema desactualizado con una vulnerabilidad conocida. - Una contraseña débil, o reutilizada y filtrada en otro servicio. - Credenciales de FTP comprometidas. - Inyección SQL en un formulario vulnerable. - Un ataque a la cadena de suministro: un plugin legítimo comprometido en origen. Identificar el vector es crítico, porque determina qué hay que corregir para evitar una reinfección, y te dice desde cuándo estás comprometido, algo clave para elegir qué copia restaurar. **Evalúa qué datos han quedado expuestos.** ¿Accedieron a la base de datos de clientes? ¿La exportaron? ¿Instalaron algo para capturar lo que se escribe en los formularios? ¿Modificaron archivos del núcleo? Las respuestas determinan si tienes obligaciones de notificación según el RGPD y qué debes comunicar a los afectados. Revisa también los servicios conectados (CRM, email, pasarela de pago) y [dónde se guardan realmente los datos de tus clientes](https://baqueiro.es/seguridad-y-juridico/donde-se-guardan-datos-clientes-proveedor-web/). ## Fase 3: limpieza y recuperación (del día 1 al 3) No intentes «limpiar» el sitio comprometido y seguir usándolo. Los atacantes suelen dejar varias puertas traseras y es muy difícil garantizar que las has encontrado todas. **La regla de oro: reconstruir, no limpiar.** **1. Parte de una copia limpia.** Restaura una copia anterior a la intrusión (no a la detección: el atacante puede llevar semanas dentro) y corrige la vulnerabilidad antes de publicarla. Si no tienes ninguna copia limpia, el problema es mayor, pero se puede reconstruir a mano: - Instalación limpia de WordPress (o del CMS que uses). - Plugins recién descargados de los repositorios oficiales, nunca copiados del servidor comprometido. - Lo mismo con los temas. - Base de datos revisada tabla por tabla antes de importarla. **2. Audita la base de datos.** En WordPress, busca: - Usuarios con rol de administrador que no reconoces. - Registros de la tabla wp_options con nombres sospechosos o valores codificados en base64. - Borradores o entradas privadas que contienen código (scripts, iframes). - Tablas adicionales que no pertenecen al núcleo ni a plugins conocidos. **3. Verifica los archivos.** Compara los archivos del núcleo con los originales de wordpress.org: cualquier diferencia es sospechosa. Con WP-CLI, el comando «wp core verify-checksums» lo hace en segundos, y plugins de seguridad como Wordfence o Sucuri también lo hacen de forma automática. **4. Mantén el sitio offline hasta verificarlo todo.** No vuelvas a abrirlo al público hasta estar seguro de que está limpio. Un sitio que vuelve a caer nada más publicarse es peor que unas horas más offline. ## Fase 4: cerrar la puerta (del día 3 al 7) El sitio está limpio. Ahora toca evitar que vuelva a pasar. **1. Actualízalo todo.** Núcleo, plugins y temas. Elimina los plugins que no necesites: cada plugin es una posible superficie de ataque. **2. Refuerza el acceso.** - Verificación en 2 pasos obligatoria para todos los administradores. - Límite de intentos de inicio de sesión (con plugins como Limit Login Attempts Reloaded). - Cambiar la URL de acceso a wp-admin: es seguridad por ocultación, pero reduce el ruido de los bots. - Restringir el acceso al panel a IP concretas si tu equipo es pequeño y trabaja desde ubicaciones fijas. **3. Firewall y monitorización.** Instala un WAF (firewall de aplicaciones web) como Cloudflare, Sucuri o Wordfence. Y activa alertas que te avisen si cambian archivos del núcleo. **4. Copias de seguridad automáticas y fuera del servidor.** Programa copias diarias fuera del servidor (Google Drive, Dropbox, Amazon S3) y prueba a restaurarlas de vez en cuando: una copia corrupta es tan inútil como no tener ninguna. **5. Analiza y documenta.** Redacta un informe del incidente: qué pasó, cómo entraron, cómo se detectó, cuánto se tardó en responder y qué lecciones has sacado. Sirve para prevenir futuros incidentes y forma parte de lo que el RGPD te exige documentar. ## Implicaciones legales y de notificación Si el incidente afecta a datos personales de clientes o visitantes: **RGPD.** La brecha debe notificarse a la Agencia Española de Protección de Datos (AEPD) sin dilación indebida y, a ser posible, en un máximo de 72 horas desde que tienes constancia de ella (si se notifica más tarde, hay que justificar el retraso), salvo que sea improbable que suponga un riesgo para las personas afectadas. Si el riesgo es alto, también debes comunicárselo a ellas. Y aunque concluyas que no hay que notificar, tienes que dejar registrada la brecha y el motivo de esa decisión. **Clientes corporativos.** Si tu web es B2B, avisa a los clientes que puedan haber estado expuestos: la transparencia temprana protege la relación más que ocultarlo. **Asesoramiento y ayuda.** En incidentes importantes, busca asesoramiento legal especializado. El INCIBE ofrece además ayuda gratuita en ciberseguridad en el 017, y si hay extorsión o robo de datos, valora denunciar. ## Preguntas frecuentes **¿Cómo sé si mi web ha sido hackeada?** Señales habituales: redirecciones a sitios extraños, contenido que no has creado, lentitud extrema, archivos desconocidos, avisos de Google Safe Browsing o alertas de tu hosting. Para detectarlo a tiempo, revisa el informe de problemas de seguridad de Search Console y pasa un escáner de malware. **¿Debería pagar si me piden un rescate?** En general, no. No hay garantía de que recibas la clave para recuperar tus datos, y pagar puede marcarte como objetivo de futuros ataques. Restaura desde una copia de seguridad. Si no la tienes, esa es la lección para la próxima vez. **¿Cuánto se tarda en recuperarse de un hackeo?** Con una copia limpia, de unas horas a un día. Sin copia, de días a semanas reconstruyendo a mano, más el tiempo de comprobar que todo está limpio. La prevención sale muchísimo más barata. **¿Es responsable mi hosting?** Normalmente no, salvo que la vulnerabilidad estuviera en su infraestructura. La mayoría de los hackeos son responsabilidad del propietario del sitio (plugins desactualizados, contraseñas débiles). Revisa tu contrato y, si vas a firmar uno, incluye estas [cláusulas técnicas](https://baqueiro.es/seguridad-y-juridico/clausulas-tecnicas-contrato-desarrollo-web/). ## Conclusión Un hackeo es estresante, pero no tiene por qué ser catastrófico. La diferencia entre un incidente menor y un desastre es la preparación: copias de seguridad que funcionan, un plan de respuesta y rapidez de reacción. El momento de pensar en seguridad es antes del hackeo. Pero si ya estás en medio de uno, este protocolo te ayuda a actuar con método y no con pánico. Si tu web ha sido comprometida y necesitas ayuda urgente para recuperarla, en Baqueiro podemos ayudarte. Eso sí: una vez recuperada, dediquemos tiempo a evitar que vuelva a pasar. Un hackeo puede ser mala suerte; que se repita suele ser falta de prevención. [Escríbenos y lo vemos cuanto antes](https://baqueiro.es/contacto/).