Web hackeada: qué hacer ahora, cómo limpiarla y cómo evitar que vuelva a pasar

Si has llegado hasta aquí es porque tu web está haciendo algo que no debería: te lleva a otra página, Google la ha marcado, el hosting te ha escrito o directamente no puedes entrar en el panel. Empecemos por lo importante: esto se arregla, y normalmente en horas, no en semanas. Lo que de verdad marca la diferencia no es la prisa, es el orden. El error más caro de las primeras horas es borrar cosas antes de mirarlas, porque te quedas sin saber por dónde entraron y la web vuelve a caer a los pocos días.

Aquí tienes el proceso completo: confirmar el ataque, contener sin destruir pruebas, identificar tu síntoma, limpiar, quitar los avisos de Google, cumplir con la normativa española y dejar la web vigilada. Con una línea clara sobre cuándo no hace falta que pagues a nadie y cuándo sí conviene.

Cómo confirmar que tu web está hackeada y no es otra cosa

No todo lo que parece un ataque lo es. Antes de entrar en modo emergencia, descarta lo que se arregla en dos minutos:

Caché. Abre la web en incógnito y, además, desde el móvil con datos móviles, no con tu wifi. Si así se ve bien, es caché y no seguridad.
Certificado caducado. Si el navegador habla de «la conexión no es privada», eso es HTTPS, no malware. Se renueva desde el panel del hosting.
Caída del hosting. Un error 500, 502 o 503 en toda la web y para todo el mundo puede ser simplemente el servidor: en mi web da error 500 tienes cómo distinguirlo de un ataque.
Un cambio de alguien de tu equipo o tu agencia. Pregunta antes de asumir. Pasa más de lo que parece.

Si nada de eso encaja, haz estas cuatro comprobaciones. Son rápidas y no tocan nada:

Mira el código fuente. Abre tu web, pulsa Ctrl+U y busca con Ctrl+F la palabra script. Fíjate en si aparece algún <script src="..."> apuntando a un dominio que no reconoces y que no es Google, tu CDN ni tu pasarela de pago.
Búscate en Google. Escribe en el buscador site:tudominio.es. Si aparecen páginas que tú no has creado, con títulos en otro idioma o con palabras de casino, farmacia o réplicas, tienes contenido inyectado.
Mira las fechas de los archivos. Entra por FTP o por el gestor de archivos del hosting a la carpeta public_html y ordena por fecha de modificación. Si index.php, .htaccess o wp-config.php se modificaron un día en el que tú no tocaste nada, malo.
Consulta Search Console. En Seguridad y acciones manuales > Problemas de seguridad Google te dice si ha detectado algo y de qué tipo. Es la fuente más fiable que tienes gratis.

Un detalle que despista mucho: muchos ataques solo se muestran a ciertos visitantes, así que tú puedes ver la web perfecta y tus clientes no. El caso más típico está en webs que solo fallan en el móvil.

Las dos primeras horas: qué hacer y qué no hacer nunca

Este es el bloque que más gente se salta y el que más dinero cuesta saltarse.

Lo que sí hay que hacer

Haz una copia completa del estado infectado y guárdala aparte. Archivos y base de datos, etiquetada del tipo copia-INFECTADA-2026-09-04. No la vas a restaurar: la necesitas para saber qué pasó y, si hay datos personales, como prueba.
Descarga los registros de acceso antes de que roten. En cPanel, Métricas > Accesos sin procesar; en servidor propio, /var/log/apache2/ o /var/log/nginx/. Muchos hostings guardan pocos días.
Apunta la cronología. Cuándo lo notaste, quién te avisó, qué síntoma exacto y qué versiones tenías. Media hoja te ahorra discusiones después.
Cambia contraseñas desde un ordenador que sepas limpio. Panel de hosting, FTP y SSH, base de datos, administradores de WordPress y correo del dominio, en ese orden.
Baja la web si el daño es visible. Si está sirviendo phishing o redirigiendo a tus clientes, mejor una página de mantenimiento unas horas que seguir repartiendo el problema.

Lo que no hay que hacer bajo ningún concepto

No restaures la copia de ayer y des el tema por cerrado. Si la puerta trasera lleva tres semanas dentro, esa copia también la lleva. Antes de restaurar, lee cómo restaurar sin volver a meter el problema.
No borres el archivo raro que acabas de encontrar. Cópialo fuera primero: es la pista que te dice cómo entraron.
No instales tres plugins de seguridad encima. Un plugin instalado sobre una web comprometida corre en el mismo suelo que el atacante.
No contestes ni pagues a quien te escriba diciendo que te ha hackeado. Casi siempre es extorsión automática de alguien que ni ha mirado tu web.

Identifica tu síntoma: los avisos más frecuentes y qué significa cada uno

El síntoma te dice bastante sobre qué tipo de ataque tienes y, sobre todo, por dónde empezar. Estos son los que más aparecen:

Redirige a otra página

Entras en tu dominio y acabas en una web de apuestas, en una tienda extraña o en una pantalla que te pide instalar algo. Suele ser una inyección en .htaccess, en index.php, en un <script> del tema o en el campo siteurl de la base de datos. Con frecuencia la redirección solo salta en móvil, o solo la primera vez que un visitante llega desde Google, precisamente para que tú no la veas. Tienes el rastreo completo, con las cuatro ubicaciones donde se esconde, en cómo encontrar y quitar una redirección maliciosa.

Google la marca como comprometida o Chrome la bloquea

Son dos avisos distintos y no se quitan igual. Uno es la línea gris «Este sitio puede estar comprometido» debajo de tu resultado en el buscador; el otro es la pantalla roja a página completa antes de entrar. El primero lo pone el índice de búsqueda, el segundo lo pone Safe Browsing y también aparece en Firefox y en Safari. Distínguelos en qué significa cada aviso de Google y, si lo tuyo es la pantalla roja, ve directo a cómo quitar el aviso de sitio engañoso de Chrome.

Aparecen páginas, enlaces o textos en japonés que tú no has puesto

Tu web se ve perfecta, pero al buscarte en Google salen títulos en japonés o cientos de URLs que no existen en tu menú. Es un ataque de generación masiva de páginas para posicionar contenido ajeno usando la autoridad de tu dominio. Casi siempre viene acompañado de un administrador falso y de un archivo que regenera las páginas por la noche. Lo explicamos entero en el ataque de palabras en japonés, y si lo que ves son páginas propias que no recuerdas haber creado, mira de dónde salen las páginas que no has creado.

Va lentísima, el hosting te ha suspendido o tus correos no llegan

Cuando una web comprometida se usa para enviar spam o para minar, el servidor se satura y el hosting acaba suspendiendo la cuenta. Si has recibido un aviso de abuso, no discutas todavía: pide el listado de archivos detectados, que es el dato que te ahorra medio trabajo. El procedimiento está en cómo reactivar una cuenta suspendida por malware. Si el síntoma es que tus correos rebotan o caen en spam, tu dominio probablemente esté en alguna lista negra: así se comprueba y así se sale.

No puedes entrar al panel o hay administradores que no reconoces

Contraseña que ya no funciona, correo de administrador cambiado, o un usuario llamado algo como admin2, wpsupport o una cadena aleatoria. Es el escenario más urgente porque el atacante tiene control total. Lo primero es recuperar el acceso desde el hosting, no desde WordPress: cómo recuperar el control cuando te han cambiado la contraseña de administrador.

Otros avisos que cuentan

El antivirus de tus clientes bloquea la web. Es un aviso distinto al de Google y se retira en otro sitio: qué hacer si un antivirus marca tu dominio.
Ventanas emergentes o anuncios que tú no has contratado, por código inyectado en el tema o en un plugin.
Un aviso genérico de «tu web tiene virus». Ojo, porque muchos son publicidad de quien quiere venderte una limpieza: contrasta antes de pagar en cómo saber si tu web tiene un virus.

Por dónde entró: las cinco vías reales en una pyme española

Casi todos los casos que vemos entran por una de estas cinco puertas. Ninguna es exótica.

Un plugin o un tema sin actualizar con un fallo ya conocido y publicado. Es, de largo, la vía número uno. El atacante no elige tu web: rastrea internet buscando quien tenga esa versión.
Una contraseña reutilizada o robada del ordenador de alguien. Incluye el ordenador de tu diseñador, de tu agencia o del becario. Un programa que roba credenciales guardadas en el navegador entrega el usuario y la contraseña correctos, y entonces no hay firewall que valga: la entrada es legítima.
Un plugin o un tema «nulled», descargado gratis de una web de piratería. Suelen venir con el código añadido de fábrica.
El vecindario. Si en la misma cuenta de hosting conviven varias webs y una está infectada, el resto suele caer detrás. Es muy habitual en agencias que meten diez clientes en un solo alojamiento.
Fuerza bruta contra wp-login.php, contra XML-RPC o contra FTP sin cifrar. Miles de intentos automáticos al día hasta que uno acierta.

Sé honesto con esto: a veces no vas a poder determinar la vía con certeza, sobre todo si los registros ya han rotado. En ese caso se cierra todo: se actualiza todo, se cambian todas las credenciales y se asume que cualquiera de las cinco pudo ser. Lo que no vale es no mirar.

Limpieza paso a paso: de la copia de seguridad a la desinfección manual

Este es el resumen del procedimiento. Si vas a hacerlo tú, ten al lado la versión larga con cada comando y cada carpeta en cómo limpiar un WordPress hackeado paso a paso.

1. Sustituye lo que se puede sustituir

El núcleo de WordPress, los plugins y los temas no se limpian: se reemplazan. Descarga WordPress de es.wordpress.org, borra por completo las carpetas wp-admin y wp-includes y sube las nuevas. No toques wp-content ni wp-config.php en este paso. Después reinstala cada plugin y cada tema desde su origen oficial, y borra los que no uses: un plugin desactivado se explota exactamente igual que uno activo, porque sus archivos siguen ahí.

2. Peina `wp-content`, que es lo que no puedes sustituir

En la carpeta de subidas no debería haber ni un solo archivo PHP. Compruébalo por SSH:

find ./wp-content/uploads -type f -name "*.php"

Cualquier resultado ahí es sospechoso por definición. Busca también archivos modificados en los últimos días:

find . -type f -name "*.php" -mtime -15 -ls

Y los patrones que aparecen en casi todas las puertas traseras:

grep -rn --include="*.php" -E "eval(|base64_decode(|gzinflate(|str_rot13(|assert(" .

Aviso para que no te vuelvas loco: estas funciones también aparecen en código legítimo. El criterio no es que aparezcan, sino el conjunto: archivo con nombre extraño, en una carpeta donde no pinta nada, modificado hace poco y con una única línea de miles de caracteres ilegibles.

3. Revisa los archivos de configuración uno por uno

En .htaccess, lo que no debería estar: reglas RewriteRule hacia un dominio ajeno, condiciones RewriteCond %{HTTP_USER_AGENT} que traten distinto a Googlebot, un php_value auto_prepend_file que tú no pusiste, o un AddHandler que ejecute las imágenes como PHP. En wp-config.php, mira las primeras y las últimas líneas: ahí se cuelan los include añadidos.

4. Limpia la base de datos sin cargarte el contenido

Comprueba que siteurl y home en la tabla wp_options son tu dominio y nada más. Busca inyecciones en las entradas y en las opciones que se cargan siempre:

SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%' AND autoload = 'yes';

Y revisa los administradores, incluidos los que se ocultan del listado manipulando wp_usermeta. Con WP-CLI:

wp user list --role=administrator
wp core verify-checksums
wp plugin verify-checksums --all

5. Cierra las llaves

Regenera las claves de seguridad de wp-config.php con las que genera api.wordpress.org/secret-key/1.1/salt/. Eso invalida todas las sesiones abiertas de golpe, incluida la del atacante. Revisa después las tareas programadas, tanto las de WordPress (wp cron event list) como las del sistema (crontab -l) y las del panel del hosting, que son las que más se olvidan.

Las puertas traseras: por qué una web limpiada vuelve a caer a las pocas semanas

Limpiar el síntoma es la parte fácil. Lo que hace que un ataque vuelva es lo que se quedó dentro para reabrir la puerta. Estos son los escondites habituales, por orden de frecuencia:

Un archivo PHP suelto en wp-content/uploads, a veces con nombre de imagen.
La carpeta wp-content/mu-plugins, que ejecuta lo que haya dentro sin aparecer en la lista de plugins y sin poder desactivarse desde el panel. Si no la creaste tú, no debería existir.
Un usuario administrador oculto o un usuario con rol de suscriptor al que se le han añadido permisos por debajo.
Una tarea programada que descarga y vuelve a escribir los archivos cada noche.
Un plugin falso con nombre creíble, del estilo wp-cache-manager o wp-security-core, que no existe en el repositorio oficial.
Código en functions.php o en footer.php del tema, que sobrevive a la actualización de WordPress porque el tema no se toca.
Un archivo fuera de public_html, en el directorio del usuario, al que llega una tarea del sistema.

La forma sistemática de barrer los siete sitios está en cómo buscar puertas traseras en tu web. Y una advertencia: los plugins de seguridad detectan bastante, pero no todo, y no sustituyen a esta revisión. Lo que hacen y lo que no, sin marketing, en ¿limpian de verdad los plugins de seguridad una web hackeada?.

Qué hacer con Google: avisos, Search Console y solicitud de revisión

El orden aquí no es negociable: primero limpias, después verificas, y solo entonces pides la revisión. Si la pides con restos dentro, Google te la deniega y la siguiente tarda más.

Verifica tu dominio en Search Console y entra en Seguridad y acciones manuales > Problemas de seguridad: ahí ves la categoría exacta y URLs de ejemplo.
Comprueba desde fuera que la web ya no sirve nada raro, incluido lo que ve quien llega desde el buscador y no directamente.
Pide la revisión en ese mismo panel, explicando en dos líneas qué encontraste y qué hiciste. Eso se revisa antes que un «ya está arreglado».
Retira las URLs basura si el ataque generó páginas, y deja que devuelvan un 404 o un 410 real.

Los plazos varían según el tipo de aviso, así que desconfía de quien te prometa una hora exacta. El proceso completo está en el informe de problemas de seguridad de Search Console. Y cuando el aviso desaparezca, todavía queda recuperar el tráfico: eso va aparte, en cómo recuperar el posicionamiento después de un hackeo.

Obligaciones en España: RGPD, AEPD, denuncia y seguro

Aquí hay una pregunta que decide casi todo lo demás: ¿ha habido acceso a datos personales? Si tu web tiene formulario de contacto, área de clientes, pedidos o una lista de correo, la respuesta por defecto es que hay datos personales en juego y tienes que valorarlo, no descartarlo de entrada.

El plazo de 72 horas del artículo 33 del RGPD empieza a contar desde que tienes constancia de la brecha, no desde que terminas de limpiar. Si hay riesgo para los afectados, se notifica a la AEPD por su sede electrónica.
El registro interno de brechas se hace siempre, notifiques o no. Aunque concluyas que no era notificable, tienes que poder enseñar el razonamiento.
Si el riesgo es alto, hay además que comunicárselo a los afectados, no solo a la Agencia.
La denuncia ante Policía Nacional o Guardia Civil suele ser voluntaria, pero es la que abre la puerta a reclamar al seguro y la que te da un atestado si hay consecuencias económicas. Cuándo aporta algo, en cómo denunciar un ataque a tu web en España.
Guarda las evidencias. La copia infectada, los registros y la cronología son lo que sostiene tu versión si alguien reclama.

Esto es orientación práctica, no asesoramiento jurídico. Si hay datos sensibles o muchos afectados, que lo mire alguien con criterio legal.

Cuánto cuesta arreglarlo y cuándo compensa un profesional

Vamos a ser claros, porque en este sector se vende mucho miedo.

No necesitas pagar a nadie si tienes una web sencilla e informativa, una copia claramente anterior al ataque, un síntoma único y evidente, y no manejas datos de clientes más allá de un formulario. Una tarde siguiendo el procedimiento de arriba lo resuelve.

Sí conviene un profesional si es una tienda con pedidos y datos de pago, hay varias webs en el mismo hosting, ya te limpiaron una vez y ha vuelto, el hosting te ha suspendido dos veces, no tienes copias fiables, o hay indicios de acceso a datos personales y vas a tener que sostener un informe ante alguien.

En precios, la horquilla habitual en España para una limpieza puntual bien hecha gira en torno a los 500 euros, y el mantenimiento con vigilancia continua alrededor de los 69 euros al mes. Qué debe incluir un presupuesto serio está en cuánto cuesta limpiar una web hackeada, y a quién corresponde el trabajo —hosting, agencia o empresa de seguridad— lo aclaramos en quién limpia una web hackeada.

Después de la limpieza: cómo dejar la web vigilada sin gastarte una fortuna

Una web limpia el lunes puede estar sucia el viernes si no cambia nada más. Lo mínimo razonable:

Copias con retención larga y restauración probada. Siete días de retención no valen frente a un ataque que llevaba tres semanas dentro. Y una copia que nunca has restaurado no es una copia, es una intención.
Actualizaciones con rutina fija: un rato al mes, con un orden y con posibilidad de volver atrás.
Contraseñas únicas y verificación en dos pasos en WordPress, hosting y correo del dominio. Es lo que corta en seco la vía de la contraseña robada.
Menos superficie. Borra plugins y temas que no uses, quita usuarios antiguos y baja el rol de quien no necesita ser administrador.
Limita los intentos de acceso a wp-login.php y desactiva XML-RPC si no lo usas.
Vigilancia desde fuera, que compruebe a diario si aparecen archivos o administradores nuevos. Enterarte tú antes que tu cliente es la diferencia entre un susto y una crisis.
Revisa el ordenador de quien administra la web. Si la credencial se filtró desde ahí, puedes limpiar diez veces y volverán a entrar con la llave buena.

Checklist de las primeras 24 horas

Confirmar que es un ataque y no caché, certificado o caída del servidor.
Copia completa del estado infectado, guardada aparte y etiquetada.
Descargar los registros de acceso antes de que roten.
Cambiar contraseñas de hosting, FTP/SSH, base de datos, WordPress y correo, desde un equipo limpio.
Poner la web en mantenimiento si está dañando a visitantes.
Identificar el síntoma y localizar el punto de inyección.
Sustituir núcleo, plugins y temas por copias oficiales; borrar lo que no se use.
Peinar wp-content, .htaccess, wp-config.php y la base de datos.
Revisar administradores, mu-plugins y tareas programadas.
Regenerar las claves de seguridad y cerrar todas las sesiones.
Verificar desde fuera, pedir la revisión en Search Console y retirar las URLs generadas.
Valorar si hay brecha de datos y activar copias, doble factor y vigilancia.

Preguntas frecuentes

¿Puedo restaurar una copia y ya está?

Solo si estás seguro de que esa copia es anterior a la entrada, y normalmente no lo estás. Restaurar sin investigar es la causa número uno de reinfección en dos días.

¿Un plugin de seguridad me lo arregla?

Ayuda a detectar y a prevenir, pero no limpia bien lo que ya está dentro, y menos si el atacante tiene permisos de administrador. Sirve mucho más después de la limpieza que durante.

¿Tengo que avisar a mis clientes?

Depende del riesgo real para ellos. Si hubo acceso a datos personales con riesgo alto, sí y por obligación. Si no lo hubo, no tienes que alarmar a nadie, pero deja documentado por qué concluiste eso.

La web la lleva una agencia. ¿Es cosa suya?

Depende de lo que firmaste, y ahí está el problema: casi nadie lo tiene por escrito. Pídeles el listado de archivos infectados, la fecha del primer indicio y qué copias tienen. Esas tres respuestas te dicen si te están llevando bien la web.

¿Me van a volver a atacar?

Lo van a volver a intentar, eso es seguro y es automático: no es personal contra ti. Que lo consigan depende de que hayas cerrado la vía de entrada y de que alguien esté mirando.

Antes de dar nada por cerrado, comprueba cómo se ve tu web desde fuera, que es exactamente lo que ven Google y tus clientes. Puedes analizar tu web gratis con PathScan: sin registro, sin tocar tu instalación y en un minuto te dice si quedan señales de compromiso. Si sale limpio, ya tienes tu confirmación; si no, sabrás por dónde seguir.

Back to Blog Open Radar CTI