Sitio web hackeado: qué hacer ahora, paso a paso

Descubrir que tienes un sitio web hackeado es uno de esos momentos en los que se acelera el pulso: redirecciones a páginas sospechosas, un aviso rojo de Google que asusta a los visitantes, correos de clientes preocupados. La buena noticia es que casi siempre se recupera todo, si actúas con método y en el orden correcto. Esta es una guía de emergencia operativa: sin pánico, solo pasos concretos.

En este artículo vemos cómo saber si el sitio está realmente comprometido, las primeras acciones para limitar el daño, cómo identificar y eliminar el problema, la restauración desde una copia limpia, la recuperación de la reputación en Google y —si hay datos personales implicados— qué exige el RGPD. Cerramos con la parte más importante: cómo no volver a caer en lo mismo.

Tómate dos minutos para leerlo entero antes de tocar nada. Moverse con un plan es la diferencia entre una hora de trabajo y un fin de semana perdido.

Cómo saber si el sitio está realmente hackeado

Antes de alarmarte, comprueba. Una lentitud o un error no significan automáticamente un ataque. Pero si detectas una o varias de estas señales, es muy probable que tengas un sitio web hackeado.

Las señales más habituales de un sitio comprometido

• Redirecciones extrañas: quien abre tu dominio acaba en sitios de apuestas, farmacias online, contenido para adultos o páginas de estafa. A menudo la redirección solo se activa desde el móvil o solo llegando desde Google, para escapar de tus comprobaciones.
• Avisos de Google: la típica pantalla roja "El sitio web que aparece a continuación contiene software malicioso" o la etiqueta "Es posible que este sitio esté comprometido" en los resultados de búsqueda.
• Spam en los contenidos: páginas nuevas que no has creado, enlaces en japonés o chino (el llamado "Japanese SEO spam"), banners publicitarios que aparecen de la nada.
• Correos salientes no autorizados: tu dominio empieza a enviar spam y acabas en listas negras. Sueles darte cuenta cuando tus correos legítimos dejan de llegar.
• Picos de tráfico anómalos: subidas repentinas hacia URLs que no existen, casi siempre señal de escaneos o de bots que explotan un fallo.
• Archivos modificados hace poco: fechas de modificación en archivos de sistema que no has tocado, o archivos con nombres aleatorios (x7f2a.php, wp-conflg.php) en las carpetas del sitio.
• Nuevos usuarios administradores que no has creado, o accesos desde países en los que no operas.
• El sitio va lento o se cae sin motivo, porque los recursos del servidor están desviados a la actividad del atacante.

Comprobaciones rápidas que puedes hacer ya

1. Abre el sitio en navegación privada y desde un móvil con datos (no tu wifi): muchos ataques solo se muestran a quien no está "reconocido" como propietario.
2. Busca en Google site:tudominio.com y mira si aparecen páginas basura entre los resultados.
3. Revisa el estado de seguridad en Google Search Console, en la sección "Problemas de seguridad".
4. Mira la fecha de última modificación de los archivos por FTP o desde el gestor de archivos del hosting: ordena por fecha y busca lo que ha cambiado sin tu intervención.

Si aunque sea una sola de estas comprobaciones confirma la sospecha, pasa a la acción. A partir de aquí tienes la secuencia de qué hacer con un sitio hackeado, sin saltarte pasos.

Los primeros pasos para limitar el daño

El objetivo de los primeros minutos no es "arreglarlo todo", sino detener la hemorragia: impedir que el atacante siga actuando y que el daño se extienda a los visitantes o a tu reputación.

1. Pon el sitio en mantenimiento (o fuera de línea)

Activar una página de mantenimiento protege a los visitantes del malware y te da margen para trabajar con calma. No hace falta borrar nada: basta con redirigir el tráfico a una página estática de "Volvemos pronto". Si no sabes cómo, el hosting casi siempre ofrece un modo mantenimiento con un clic.

Evita dejar el sitio comprometido online y visible: cada hora de más aumenta el riesgo de acabar en listas negras y empeora la recuperación SEO.

2. Cambia todas las contraseñas y claves

Parte de la base de que todas las credenciales están comprometidas. Por orden de prioridad:

1. Contraseña del panel de hosting y de la cuenta FTP/SFTP.
2. Contraseña de la base de datos.
3. Credenciales de administración del sitio (CMS, backend, área de administración).
4. Claves API y tokens (pagos, correo transaccional, servicios externos): si estaban escritas en texto plano en el código o en un archivo de configuración, dalas por quemadas y regenéralas.
5. Contraseñas de correo asociadas al dominio.

Usa contraseñas largas y únicas y, cuando sea posible, activa la autenticación en dos pasos. Si repetías las mismas credenciales en varios servicios, cámbialas en todos.

3. Aísla y haz una copia del estado actual

Antes de borrar nada, haz una copia "sucia" del sitio tal y como está ahora (archivos + base de datos). Parece contraintuitivo, pero esa copia sirve para dos cosas: entender cómo te han atacado y tener vía de vuelta si durante la limpieza rompes algo. Etiquétala claramente como "comprometida – no restaurar".

Si tienes otros sitios en la misma cuenta de hosting, revísalos: las infecciones se propagan a menudo entre sitios que comparten el mismo espacio.

Identificar y eliminar el problema

Ahora que la hemorragia está detenida, llega la parte de investigación: entender qué se ha modificado y eliminar el malware del sitio.

Escaneo de malware y búsqueda de archivos infectados

Empieza por un escaneo automático. La mayoría de hostings ofrece un escáner integrado (a menudo basado en ImunifyAV o similares); como alternativa existen escáneres específicos para tu CMS. El escaneo te devuelve la lista de archivos sospechosos o modificados.

Qué buscar a mano, si quieres confirmar:

• Archivos con funciones ofuscadas como eval(base64_decode(...)), gzinflate, str_rot13.
• Archivos .php en carpetas donde no deberían estar (por ejemplo en la carpeta de subidas o de imágenes).
• Líneas de código inyectadas al principio o al final de archivos legítimos.
• Tareas programadas (cron jobs) que no has creado y que restauran la infección.

Revisión de usuarios, permisos y accesos

Abre la lista de usuarios administradores y elimina los que no reconozcas. Revisa los registros de acceso del hosting para identificar desde qué IP y en qué momento se produjo la intrusión: suelen revelar el punto de entrada (un endpoint vulnerable, un plugin desactualizado, un formulario sin protección).

Comprueba también los permisos de los archivos: carpetas a 777 o archivos de configuración escribibles por cualquiera son una invitación abierta. Los valores seguros habituales son 644 para archivos y 755 para carpetas.

El caso concreto de un sitio WordPress hackeado

Si tienes un sitio WordPress hackeado, la lógica es la misma pero con algún cuidado extra, porque WordPress es el objetivo más atacado del mundo precisamente por su difusión:

• Sustituye los archivos del core por una copia limpia descargada del sitio oficial: el core nunca se modifica, así que cualquier diferencia es sospechosa.
• Actualiza, o mejor reinstala, temas y plugins desde fuentes oficiales. Los plugins abandonados o "nulled" (versiones pirateadas de pago) son la causa número uno de las infecciones.
• Revisa los archivos wp-config.php, .htaccess e index.php: son los favoritos de los atacantes para inyectar redirecciones y puertas traseras.
• Regenera las claves de seguridad (salt keys) en wp-config.php para invalidar todas las sesiones activas.

¿Quieres un método sistemático para revisar el estado de tu sitio? En la guía sobre cómo comprobar la seguridad de un sitio web tienes una checklist ordenada que sirve también con el incidente ya cerrado.

Restaurar el sitio desde una copia de seguridad limpia

A menudo el camino más rápido y seguro para recuperar un sitio hackeado no es perseguir cada archivo infectado, sino partir de una copia de seguridad anterior al ataque.

Cómo elegir la copia correcta

No cojas simplemente la última copia disponible: puede que ya contenga el malware. Tienes que localizar la última copia anterior a las señales de compromiso. Si viste las primeras redirecciones el día 10 del mes, busca una copia del día 5 o anterior, y verifícala.

Después de la restauración, no reactives todo de golpe: actualiza CMS, temas y plugins, comprueba que no queden puertas traseras y solo entonces vuelve a publicar el sitio.

¿Y si no tienes copia de seguridad?

Pasa, sobre todo con proyectos hechos con prisa. En ese caso la limpieza es manual: partiendo del escaneo, elimina los archivos inyectados, restaura los archivos de sistema desde copias oficiales y reconstruye la parte dañada. Es más largo, pero factible. Y es también el momento de configurar por fin copias automáticas diarias guardadas fuera del servidor: la próxima vez te salvarán.

Limpiar la reputación: Google y listas negras

Eliminar el malware no basta: si Google o los antivirus ya han marcado tu dominio, el sitio seguirá mostrando avisos hasta que pidas una nueva revisión.

1. Google Search Console – En la sección "Problemas de seguridad", una vez limpiado todo, envía una solicitud de revisión. Google vuelve a escanear el sitio y, si está limpio, retira el aviso normalmente en pocos días.
2. Salida de las listas negras – Comprueba si el dominio o la IP han acabado en listas negras antispam. Si tu dominio enviaba spam, pide la retirada a los principales servicios de reputación una vez resuelta la causa.
3. Google Safe Browsing – Es la base de datos que alimenta los avisos rojos en Chrome y Firefox. Se actualiza automáticamente tras la revisión de Search Console.
4. Reindexación – Pide a Google que revise de nuevo las páginas limpias y vigila que las páginas de spam desaparezcan de los resultados.

En los días siguientes vigila los registros y el tráfico: que vuelva la actividad sospechosa indica que una puerta trasera ha sobrevivido a la limpieza.

¿Datos personales implicados? Las obligaciones del RGPD

Aquí se añade una capa que muchos olvidan. Si el sitio comprometido trataba datos personales —aunque solo sean correos de suscriptores a la newsletter, nombres de clientes o datos de pedidos— el ataque puede constituir una violación de datos personales (data breach), y el RGPD establece obligaciones concretas.

• Evaluación del riesgo: debes determinar si la violación supone un riesgo para los derechos y libertades de las personas afectadas.
• Notificación a la autoridad: si existe riesgo, la violación debe notificarse a la autoridad de control (en España la AEPD) por regla general en 72 horas desde que tienes conocimiento de ella.
• Comunicación a los interesados: si el riesgo es alto (por ejemplo se han filtrado contraseñas o datos de pago), debes informar también a las personas afectadas, con un lenguaje claro.
• Registro de violaciones: cada brecha se documenta internamente, incluso cuando decides no notificarla, motivando la decisión.

No es burocracia por la burocracia: gestionar bien la comunicación protege la confianza de tus usuarios y te resguarda de sanciones. Si no sabes por dónde empezar con la documentación, tenlo presente para la fase de prevención de aquí abajo.

Prevención: cómo no volver a tener un sitio hackeado

Superada la emergencia, llega el trabajo que de verdad cuenta: conseguir que no vuelva a pasar. La mayoría de los ataques no son dirigidos: son bots que escanean la web buscando fallos conocidos. Cerrar esos fallos te saca del punto de mira.

Los buenos hábitos básicos

• Actualizaciones constantes: CMS, temas, plugins y librerías siempre en la última versión. La inmensa mayoría de los compromisos aprovecha vulnerabilidades corregidas hace tiempo.
• Contraseñas únicas y 2FA en todos los accesos críticos.
• Copias de seguridad automáticas diarias, guardadas fuera del servidor y probadas (una copia que nunca has intentado restaurar no es una copia).
• Menos superficie de ataque: desinstala plugins y temas que no usas, elimina usuarios innecesarios.
• Permisos de archivo correctos y archivos de configuración no accesibles públicamente.

Para una panorámica completa de las medidas a aplicar, la guía sobre cómo tener un sitio web seguro lo reúne todo en un recorrido ordenado.

El punto ciego de quien ha construido el sitio "con IA"

Cada vez más sitios y aplicaciones nacen con vibe coding: describes a un asistente de IA lo que quieres y el código aparece, a menudo sin que quien lo publica tenga formación técnica. Es potentísimo, pero introduce clases de vulnerabilidad que pasan desapercibidas: claves API escritas en texto plano en el código, endpoints sin autenticación, ausencia de rate limiting, identificadores manipulables en la URL que exponen los datos de otros usuarios, cabeceras de seguridad ausentes, cookies e información de privacidad no conformes.

El problema es que estos defectos no dan errores: el sitio "funciona". Se quedan ahí, en silencio, hasta que un bot los encuentra. Si tu proyecto nació así, profundiza en los riesgos típicos en la guía dedicada al vibe coding: reconocerlos es el primer paso para cerrarlos.

Comprobar las vulnerabilidades antes

La lección más importante de cualquier incidente es esta: sale mucho más barato encontrar un fallo antes que el atacante que limpiar después. Una revisión periódica de vulnerabilidades debería entrar en tu rutina igual que las copias de seguridad.

Aquí es donde una herramienta como Appurai resulta útil tanto tras el incidente como en prevención: ejecuta un escaneo automático de seguridad y conformidad con el RGPD y te dice, en lenguaje comprensible, dónde están los agujeros: claves expuestas, endpoints abiertos, cabeceras que faltan, identificadores manipulables, aspectos de privacidad fuera de norma. Pasar revista al sitio recién limpiado te confirma que la puerta por la que entró el atacante está realmente cerrada.

¿Quieres establecer un control recurrente? En la guía sobre cómo hacer un test de seguridad del sitio web tienes el método para convertir la verificación en un hábito y no en una intervención de emergencia.

Preguntas frecuentes

¿Cómo sé con certeza si mi sitio está hackeado?

Cruza varias señales: redirecciones a páginas sospechosas, avisos de Google, páginas de spam en los resultados de búsqueda (site:tudominio.com), archivos modificados sin tu intervención, envíos de correo no autorizados. Abre siempre el sitio en incógnito y desde el móvil con datos, porque muchas infecciones solo se muestran a visitantes "no reconocidos". Si aunque sea una de estas comprobaciones es positiva, trata el sitio como comprometido.

¿Cuánto se tarda en recuperar un sitio hackeado?

Depende de la situación. Con una copia limpia reciente se puede volver a estar online en pocas horas. Sin copia, con limpieza manual, hacen falta de medio día a varios días. La retirada de los avisos de Google, tras la solicitud de revisión, suele tardar de uno a pocos días.

Tengo un sitio WordPress hackeado: ¿por dónde empiezo?

Pon el sitio en mantenimiento, cambia todas las contraseñas y las salt keys, y sustituye después los archivos del core por una copia oficial limpia. Reinstala temas y plugins desde fuentes oficiales eliminando los abandonados o pirateados, revisa wp-config.php y .htaccess, y elimina los usuarios administradores desconocidos. Por último, restaura desde una copia anterior al ataque si la tienes.

¿Debo avisar a alguien si se han expuesto datos personales?

Sí. Si el sitio trataba datos personales y hay riesgo para las personas afectadas, el RGPD exige notificar la violación a la autoridad de control por regla general en 72 horas, e informar a los interesados cuando el riesgo es alto. Documenta en cualquier caso lo ocurrido en el registro de violaciones, aunque decidas no notificar.

¿Basta con eliminar el malware para volver a estar seguro?

No. La limpieza elimina el efecto, no la causa. Si no cierras el fallo que permitió la entrada —un plugin vulnerable, un endpoint abierto, una clave API expuesta— volverás a infectarte. Después de la limpieza actualiza todo, cambia las credenciales y haz una revisión de vulnerabilidades para confirmar que el punto de entrada está cerrado.

¿Cómo evito que vuelvan a hackear mi sitio?

Actualiza siempre CMS, temas y plugins, usa contraseñas únicas con autenticación en dos pasos, configura copias automáticas probadas, reduce plugins y usuarios innecesarios y revisa periódicamente las vulnerabilidades. La prevención cuesta una fracción del tiempo que exige recuperar un sitio comprometido.

Conclusión

Un sitio web hackeado es un susto, pero rara vez una catástrofe si actúas en el orden correcto: verifica las señales, detén la hemorragia, elimina el problema, restaura desde una copia limpia, recupera la reputación y, si hay datos personales, gestiona las obligaciones del RGPD. Después —la parte que marca la verdadera diferencia— cierra la puerta por la que entraron.

Porque la seguridad no es una intervención puntual: es una comprobación que se repite. Revisar las vulnerabilidades antes, con regularidad, es lo que convierte una emergencia en un episodio aislado en vez de en un problema recurrente.