Guías de seguridad

#respuesta a incidentes #WordPress #hosting compartido #servidor #desfiguración de sitios web

Cómo saber si han hackeado tu sitio web o tu servidor: comprobaciones paso a paso para hosting compartido, WordPress y un VPS, y qué hacer primero si encuentras algo

Cómo revisar tu propio sitio o servidor en busca de intrusiones: hosting compartido, WordPress, un VPS Linux y Search Console. Administradores, wp core verify-checksums, inicios de sesión, authorized_keys, cron, puertos a la escucha y qué hacer primero.

Publicado 2026-10-11 Actualizado 2026-10-11 Última verificación 2026-10-11 18 min de lectura

Para quién es: particulares y pequeñas empresas que tienen un sitio en un hosting compartido, en WordPress o en un VPS y ahora se preguntan «¿me han hackeado?». Esta guía explica cómo revisar tú mismo tu propio sitio y servidor. Se basa en la documentación oficial de WordPress.org, WP-CLI y Google Search Central, en las páginas de manual de cada comando, en la IPA y JPCERT/CC de Japón y en el RGPD. No se tratan técnicas de ataque.

Si ahora mismo algo parece ir mal, haz solo esto

Antes de borrar o sobrescribir ningún archivo del sitio, haz una copia de los registros y de todo el sitio (archivos y base de datos). Cuando desaparecen, ya no puedes averiguar cómo entró el atacante. Cambia las contraseñas desde otro dispositivo limpio que hayas analizado con un antivirus.

Señales que deben hacerte sospechar una intrusión

Si se cumple alguna de estas, pasa a las comprobaciones por entorno de abajo. La página «FAQ My site was hacked» de WordPress.org también enumera señales claras de un hackeo, como que los buscadores incluyan el sitio en una lista de bloqueo, que tu hosting desactive el sitio o comportamientos no autorizados como la creación de usuarios nuevos.

Señal	Dónde la notas
Search Console muestra un problema de seguridad, o Google te envía un correo	Google Search Console
Los resultados de búsqueda muestran "This site may be hacked" (puede que este sitio esté hackeado)	Búsqueda de Google
Los navegadores avisan de que el sitio es peligroso, o el antivirus de los visitantes lo marca	Mensajes de los visitantes
Tu hosting avisa de desfiguración, spam o carga excesiva, o suspende el sitio	Correo de tu hosting
Usuarios administradores que nunca creaste	Escritorio de WordPress
Aparecen en el buscador páginas que nunca creaste (fármacos, artículos de marca, páginas masivas en japonés)	Una búsqueda `site:`
Redirecciones a otro sitio solo en el móvil, o solo al llegar desde el buscador	Comprobación en el móvil
Tu servidor envía spam o alcanza el límite de envío	Avisos del hosting, correos rebotados
La CPU o el tráfico se disparan sin motivo	La monitorización de tu servidor

«En mi ordenador se ve bien» no demuestra nada

Google (web.dev) explica que algunos sitios hackeados muestran contenido distinto a distintos tipos de usuarios (cloaking): una página puede verse vacía cuando la abres, mientras Google ve en ella palabras y enlaces de spam. Una entrada del blog de Google Search Central también señala que un sitio hackeado puede redirigir solo a los usuarios de móvil a dominios de spam, y recomienda abrir tu sitio desde los resultados de búsqueda de Google en un smartphone para comprobarlo.

Comprobaciones por entorno

Revisa las filas que corresponden a tu configuración. Si usas WordPress en un hosting compartido, se aplican las dos primeras filas.

Entorno	Dónde mirar	Qué buscar
Hosting compartido	Registros de acceso y de errores en el panel de control, el gestor de archivos, el historial de envío de correo	Peticiones a URLs desconocidas o avalanchas de POST, archivos modificados recientemente, archivos `.htaccess` o PHP desconocidos, un aumento del correo saliente
WordPress	Todos los usuarios y Plugins instalados en el escritorio, WP-CLI	Administradores desconocidos, plugins o temas que no instalaste, archivos del núcleo modificados
VPS (Linux)	Registros de SSH, `authorized_keys`, cron, la lista de usuarios, puertos a la escucha, verificación de paquetes	Inicios de sesión desde orígenes desconocidos, claves públicas desconocidas, tareas programadas desconocidas, usuarios nuevos, programas desconocidos a la escucha
Google Search Console	Problemas de seguridad, la herramienta de inspección de URLs, una búsqueda `site:`	Los problemas y las URL de ejemplo que encontró Google, y lo que ve Google en una página

Hosting compartido

Incluso sin SSH, el panel de control suele permitirte revisar estas tres cosas (los nombres varían según el hosting).

Abre la carpeta pública en el gestor de archivos y ordénala por fecha de modificación. Fíjate en archivos cambiados en días en que no tocaste nada, archivos PHP con nombres sin sentido y archivos PHP dentro de carpetas de imágenes como uploads
Descarga los registros de acceso y de errores y comprueba desde dónde y cuándo llegaron las peticiones al área de administración (en WordPress, /wp-login.php y /wp-admin/), y cualquier petición a URLs que no reconozcas
Si puedes ver el número o el historial de correos enviados, busca grandes volúmenes que no enviaste tú

Revisa también .htaccess. WordPress.org menciona .htaccess como uno de los archivos que más a menudo se modifican y se abusan, sea cual sea el tipo de infección, y señala que index.php, header.php y footer.php son objetivos muy valiosos porque afectan a cada petición de página.

WordPress

En el escritorio, revisa dos sitios.

Usuarios > Todos los usuarios: ¿hay alguien con el perfil de Administrador que no creaste?
Plugins > Plugins instalados: ¿hay algún plugin que no instalaste? Revisa Apariencia > Temas de la misma forma

Si WP-CLI (la herramienta oficial de línea de comandos de WordPress) está disponible en el servidor, puedes comparar automáticamente los archivos con la versión oficial.

# Check WordPress core files against WordPress.org checksums
wp core verify-checksums
# Also warn about non-WordPress files in the WordPress root directory
wp core verify-checksums --include-root
# Verify plugins distributed on WordPress.org
wp plugin verify-checksums --all
# List administrator accounts with their registration dates
wp user list --role=administrator

Un resultado limpio muestra Success: WordPress installation verifies against checksums. Un archivo que no coincide muestra Warning: File doesn't verify against checksum: seguido de su nombre. La verificación de plugins compara con las sumas de comprobación de WordPress.org, así que los plugins premium y los temas a medida no se pueden comprobar de esta forma. Para esos, vuelve a descargar la misma versión del proveedor y compara.

VPS (Linux)

En un VPS, busca lo que deja un intruso para poder volver: claves públicas, tareas programadas, usuarios nuevos y programas a la escucha de conexiones. Ejecuta todo esto en tu propio servidor, como administrador.

# SSH login records (the unit is ssh on Debian/Ubuntu, sshd on RHEL-family)
sudo journalctl -u ssh --since "2026-10-01"
# Recent logins (on Debian 13, use wtmpdb last instead; install the wtmpdb and libpam-wtmpdb packages)
last -a
# Each user's last login (on Debian 13, use lastlog2 instead; install the lastlog2 and libpam-lastlog2 packages)
lastlog
# SSH public keys: the current user's (other users: /home/*/.ssh/authorized_keys) and root's
cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys
# Scheduled jobs (per user and system-wide)
crontab -l
sudo crontab -l -u root
sudo cat /etc/crontab
sudo ls -la /etc/cron.d
# Users, and the group with admin rights (wheel on RHEL-family)
getent passwd
getent group sudo
# Listening TCP ports and the programs behind them
sudo ss -tlnp
# Files in the web root whose contents changed in the last 7 days
sudo find /var/www -type f -mtime -7
# Have package files changed since they were installed?
sudo debsums -s      # Debian/Ubuntu (needs the debsums package)
sudo rpm -Va         # RHEL-family

Cómo leer los resultados:

En la salida de journalctl, revisa la IP de origen de los inicios de sesión correctos (Accepted) en busca de direcciones que no sean tuyas. Si no aparece nada, puede que el nombre de la unidad sea otro; comprueba el nombre del servicio SSH con systemctl list-units --type=service
En authorized_keys, busca claves públicas que nunca añadiste. Cómo gestionar las claves que pueden entrar en un servidor se explica en mínimo privilegio para las claves SSH
En cron, busca líneas que descarguen y ejecuten algo desde una URL desconocida
En la lista de ss, busca programas a la escucha que no iniciaste tú
debsums -s solo informa de los archivos con problemas; rpm -Va marca los archivos cambiados con códigos como tamaño (S), resumen (5) y hora de modificación (T)

No te apoyes demasiado en los registros ni en la salida de los comandos

find -mtime mira la hora de modificación de un archivo, que se puede cambiar. El propio manual de debsums dice que la herramienta tiene una utilidad limitada como herramienta de seguridad. Los registros desaparecen cuando termina su periodo de conservación. Y en Debian 13, last, lastb y lastlog ya no se incluyen por el problema del año 2038. Cada comprobación puede darte pruebas de una intrusión, pero no encontrar nada no demuestra que estés limpio.

Google Search Console

Si tu sitio aún no está registrado en Search Console, añádelo y verifica la propiedad primero.

En el informe de problemas de seguridad, mira si aparece algún problema. Los problemas se dividen en tres grandes categorías: contenido hackeado, malware y software no deseado, e ingeniería social, normalmente con URL de ejemplo. Algunos problemas no traen URL de ejemplo; Google indica que eso no significa que no haya páginas afectadas
Busca en Google site:tudominio y busca páginas que nunca creaste. Google indica que así se listan las páginas de tu sitio, incluidas las que haya podido añadir un hacker
Introduce las páginas sospechosas en la herramienta de inspección de URLs para ver cómo las ve Google

Sobre la terminología: los rastros de un compromiso que ya ha ocurrido, como los de arriba, se llaman IOC (indicadores de compromiso). Consulta qué es un IOC y, para detectar un ataque por su comportamiento mientras todavía está en curso, qué es un IOA.

Qué hacer primero si encuentras algo

Si te equivocas de orden, o destruyes las pruebas o restauras el sitio con la vía de entrada del atacante todavía abierta. Trabaja de arriba abajo.

1 — Contener

Desconecta el sitio o pon una página de mantenimiento

2 — Conservar las pruebas

Copia los registros, los archivos y la base de datos fuera del servidor

3 — Cambiar todas las credenciales

Escritorio, FTP, claves SSH, base de datos, claves de API (desde un dispositivo limpio)

4 — Volver a un estado limpio

Restaura una copia anterior a la intrusión, o reconstruye

5 — Cerrar la vía de entrada

Actualiza, elimina los plugins que no uses, encuentra la causa

6 — Revisión y notificación

Solicita una revisión en Search Console; notifica la filtración de datos si es obligatorio

El orden de respuesta. No limpies antes de conservar las pruebas. No solicites una revisión antes de cerrar la vía de entrada.

Contener: desconecta el sitio por ahora

Para que a los visitantes no se les sirva malware ni páginas de estafa, desconecta el sitio o muestra una página de mantenimiento. En un VPS, restringe el tráfico externo manteniendo el acceso que necesitas para investigar. En un hosting compartido, contacta con el soporte de tu hosting para acordar cómo retirarlo y qué harán ellos por su parte. WordPress.org también aconseja consultar a tu hosting, porque en un hosting compartido el hackeo puede afectar a algo más que a tu sitio.

Conservar las pruebas: copia antes de limpiar

WordPress.org recomienda hacer una instantánea más del entorno antes de empezar a limpiar, aunque esté infectado. Google también aconseja hacer una copia de todo el sitio y de la base de datos en un lugar fuera del servidor antes de limpiar. Los registros de acceso, de errores y de SSH desaparecen según un calendario, así que guárdalos primero. El enfoque de los fundamentos de las copias de seguridad se aplica directamente.

Cambiar todas las credenciales, desde un dispositivo limpio

WordPress.org pide cambiar las contraseñas de todos los puntos de acceso —FTP/SFTP, el escritorio de WordPress, el panel de control del hosting y MySQL— e incluir a todos los usuarios con acceso al entorno, no solo a ti. Regenerar las claves secretas (salts) de wp-config.php también cierra la sesión de cualquiera que siga conectado. En un VPS, genera claves SSH nuevas y deja solo las tuyas en authorized_keys. Vuelve a emitir las claves de API de terceros guardadas en archivos como .env.

WordPress.org señala que los ataques a menudo empiezan en el propio ordenador del propietario, y recomienda analizarlo también. Haz los cambios desde un dispositivo limpio que hayas analizado y activa la autenticación multifactor.

Volver a un estado limpio: una copia anterior a la intrusión, o reconstruir

Si tienes una copia de seguridad que sabes que es anterior a la intrusión, restáurala. Si no sabes cuándo entró el atacante, cuanto más reciente sea la copia, más probable es que esté contaminada. En WordPress, sustituye wp-admin y wp-includes por la misma versión de la descarga oficial, y vuelve a obtener de sus fuentes los temas y plugins de wp-content. En un VPS donde root puede haber sido comprometido, crear un servidor nuevo y trasladar solo los datos revisados es más fiable que limpiar.

Cerrar la vía de entrada para que no vuelvan por el mismo camino

Actualiza el núcleo de WordPress, los plugins y los temas, y borra todo lo que no uses. Las causas habituales son vulnerabilidades en plugins desactualizados, contraseñas reutilizadas y archivos de configuración filtrados desde carpetas públicas. Google advierte que, si no corriges la vulnerabilidad por la que entró la infección, el sitio puede volver a infectarse. El refuerzo de WordPress se explica en seguridad de WordPress, y dónde guardar los archivos de configuración en ¿has dejado un archivo secreto en un directorio público? WordPress.org también recomienda volver a cambiar las contraseñas una vez que el sitio esté limpio.

Revisión y notificación: Search Console y datos personales filtrados

Si Search Console mostraba problemas, corrige todos los problemas en todo el sitio y luego selecciona "Request Review" (solicitar revisión) en el informe de problemas de seguridad. En la solicitud, describe el problema, las correcciones que hiciste y el resultado. Google indica que una revisión tarda de unos días a unas semanas y que recibirás correos cuando se reciba y cuando se complete. Volver a enviarla antes de una decisión puede alargar la revisión.

Si pueden haberse filtrado datos personales, como envíos del formulario de contacto o registros de miembros, consulta «Si pueden haberse filtrado datos personales» más abajo.

Días a semanas

Tiempo de revisión de Search Console (Google)

72 horas

Plazo del RGPD para notificar a la autoridad de control, siempre que sea posible

3–5 días

Japón: informe preliminar a la PPC, desde el descubrimiento

La opinión de este sitio: el objetivo de revisar no es declararte limpio, sino decidir cuánto puedes fiarte

Un error habitual en los sitios pequeños es encontrar un archivo sospechoso, borrarlo y darlo por terminado. Pero el archivo que encontraste es el resultado de la intrusión, no la vía de entrada. Si no cierras la vía de entrada y los caminos de vuelta que dejó el atacante (claves públicas, usuarios administradores, tareas programadas), volverá a ocurrir.

Por eso proponemos juzgar lo que encuentres según cuánto puedes seguir fiándote. Si solo se modificaron archivos del núcleo de WordPress, sustituir el núcleo y cambiar las credenciales probablemente te devolverá a la normalidad. Si pueden haber obtenido root en el servidor, no puedes fiarte ni de sus registros ni de la salida de sus comandos, así que reconstruye. Trazar esa línea pronto te evita pasar días limpiando para acabar reconstruyendo al final.

Si pueden haberse filtrado datos personales

Si tratas datos personales como empresa y pueden haberse filtrado envíos del formulario de contacto o registros de miembros, consulta las normas del lugar donde operas.

UE y Reino Unido (RGPD, artículo 33): notifica a la autoridad de control sin dilación indebida y, siempre que sea posible, en un plazo de 72 horas desde que tengas constancia de una violación de datos personales, salvo que sea improbable que suponga un riesgo para los derechos y libertades de las personas. El artículo 34 regula cuándo también debes informar a las personas afectadas
Japón: la Comisión de Protección de Información Personal (PPC) enumera cuatro categorías que hay que notificar: datos sensibles, riesgo de perjuicio económico, sospecha de un fin ilícito y más de 1.000 personas. Una filtración causada por un acceso no autorizado se pone como ejemplo de la categoría de fin ilícito. El informe preliminar debe presentarse en un plazo de 3 a 5 días desde el descubrimiento y el informe final en 30 días (60 días para la categoría de fin ilícito), y también hay que avisar a las personas afectadas
En otros países: consulta la autoridad nacional de protección de datos

Dónde pedir ayuda

Quién	Qué puede hacer
Tu proveedor de hosting o de VPS	Suspender el sitio, revisar los registros del lado del proveedor, investigar el impacto en el mismo servidor
Solicitud de respuesta a incidentes de JPCERT/CC (Japón)	Acepta informes de incidentes del público general; en el caso de sitios web desfigurados, contacta con el administrador del sitio para pedir que lo corrija. Se informa mediante formulario web o correo electrónico
Notificación a la IPA sobre virus informáticos y accesos no autorizados (Japón)	Acepta notificaciones de daños por accesos no autorizados, incluidos intentos sin daño real
El CERT nacional o la autoridad de protección de datos de tu país	Informes de incidentes y notificaciones de violaciones de datos fuera de Japón
Foros de soporte de WordPress.org	Describe tus síntomas con detalle y recibe ayuda de la comunidad

Fuentes (oficiales)

WordPress.org: FAQ My site was hacked — wordpress.org
WordPress.org: Administration Screens — wordpress.org
WP-CLI: wp core verify-checksums — developer.wordpress.org
WP-CLI: wp plugin verify-checksums — developer.wordpress.org
WP-CLI: wp user list — developer.wordpress.org
Google: Security issues report (Ayuda de Search Console) — support.google.com
Google: How do I know if my site was hacked? (web.dev) — web.dev
Google: Fix the cloaked keywords and links hack (web.dev) — web.dev
Blog de Google Search Central: Detect and get rid of unwanted sneaky mobile redirects (octubre de 2015) — developers.google.com
Ayuda de la Búsqueda de Google: Report a problem with Google Search (sobre la etiqueta "This site may be hacked") — support.google.com
Páginas de manual de Debian: journalctl(1), last(1), lastlog(8), sshd(8), crontab(1), cron(8), ss(8), find(1), debsums(1) — manpages.debian.org
RPM: rpm(8) (cómo leer la salida de --verify) — rpm.org
Notas de la versión de Debian 13 (trixie): se han sustituido los comandos last, lastb y lastlog — debian.org
RGPD (Reglamento (UE) 2016/679), artículos 33 y 34 — eur-lex.europa.eu
Comisión de Protección de Información Personal de Japón: obligación de notificar filtraciones y de avisar a las personas (en japonés) — ppc.go.jp
Comisión de Protección de Información Personal de Japón: cómo responder a las filtraciones de datos (en japonés) — ppc.go.jp
JPCERT/CC: solicitud de respuesta a incidentes (en japonés) — jpcert.or.jp
IPA: notificación de virus informáticos y accesos no autorizados (en japonés) — ipa.go.jp

Sigue leyendo

Para tus cuentas personales: Cómo saber si alguien ha accedido a tu cuenta
Cuando el propio hosting sufre una brecha: qué deben hacer los clientes cuando su proveedor de hosting web sufre una brecha (en inglés; prepararse para lo que tu propia configuración no puede evitar)
Comprobar dónde están los archivos: ¿Has dejado un archivo secreto en un directorio público? / Mantener el .env fuera de la web pública en un hosting compartido
WordPress: Seguridad de WordPress: referencia de refuerzo para producción / una vía de entrada habitual: vulnerabilidades en la subida de archivos (en inglés)
Términos: ¿Qué es un IOC? / ¿Qué es un IOA? / ¿Qué es una puerta trasera? (en inglés) / ¿Qué es el malware?
Recuperación: Fundamentos de las copias de seguridad

FAQ

Q¿Cómo compruebo si han hackeado mi sitio web?

Empieza por el informe de problemas de seguridad de Google Search Console y mira si aparece algún problema. Después busca en Google site:tudominio y busca páginas que nunca creaste. Por último, abre tu sitio en un smartphone desde los resultados de búsqueda de Google y comprueba si te redirige a otro sitio. El contenido hackeado a veces está hecho para no verse cuando el propietario visita el sitio directamente.

Q¿Cómo compruebo si se han apoderado de mi sitio WordPress?

En el escritorio, abre Usuarios > Todos los usuarios y busca administradores que no creaste, y luego Plugins > Plugins instalados para ver plugins que no instalaste. Si tienes WP-CLI, wp core verify-checksums compara los archivos del núcleo de WordPress con la versión oficial. Los plugins distribuidos en WordPress.org se pueden comprobar con wp plugin verify-checksums --all.

QMi sitio se ve normal cuando lo abro, pero los resultados de búsqueda dicen que puede estar hackeado.

Puede que se esté usando cloaking (mostrar contenido distinto a distintos visitantes). Las páginas hackeadas a veces muestran spam o redirecciones solo a los buscadores, o solo a quienes llegan desde los resultados de búsqueda en un móvil. Google indica que la etiqueta se mantiene hasta que el propietario corrige los problemas de seguridad en Search Console y solicita una revisión. Revisa las URL de ejemplo del informe de problemas de seguridad y usa la herramienta de inspección de URLs para ver lo que ve Google.

QEstoy en un hosting compartido sin SSH. ¿Cómo lo compruebo?

Usa el gestor de archivos del panel de control para ordenar los archivos por fecha de modificación, y descarga los registros de acceso y de errores para buscar peticiones a URLs desconocidas o inicios de sesión en el área de administración. En WordPress, revisa los usuarios y los plugins en el escritorio. Si no lo tienes claro, contacta con el soporte de tu hosting. En un hosting compartido, a veces el proveedor puede comprobar el impacto en todo el servidor, incluidos otros clientes.

QSi no encuentro nada, ¿estoy a salvo?

No. Las marcas de tiempo de los archivos se pueden cambiar, los registros desaparecen cuando termina su periodo de conservación y, en un servidor donde un atacante obtuvo root, ya no puedes fiarte de la salida de los propios comandos del servidor. Si tienes pruebas externas, como un aviso de Search Console o de tu hosting, trata el sitio como comprometido aunque no encuentres nada, y planifica cambiar las credenciales y reconstruir.

QPuede que se hayan filtrado datos personales desde mi sitio. ¿A quién se lo comunico?

Depende de dónde operes. En Japón, la Comisión de Protección de Información Personal pone las filtraciones causadas por accesos no autorizados como ejemplo de caso que hay que notificar, con un informe preliminar en un plazo de 3 a 5 días desde el descubrimiento y un informe final en 30 días (60 días si se sospecha un fin ilícito). En la UE y el Reino Unido, el RGPD exige notificar a la autoridad de control en 72 horas siempre que sea posible, salvo que sea improbable que la violación suponga un riesgo para las personas. Consulta la autoridad de protección de datos de tu país.