10 cosas que puedes hacer si detectas una intrusión en WordPress

Encontrar un archivo PHP que nadie reconoce, descubrir un usuario administrador desconocido o ver cambios extraños en una web de WordPress son señales que conviene tomar en serio.

No todas las anomalías demuestran por sí solas que haya existido una intrusión. Un plugin puede crear archivos legítimos, una agencia puede haber dejado un usuario de soporte o una tarea programada puede pertenecer a una integración. Pero cuando aparece algo que nadie puede explicar, lo prudente es investigar antes de borrar o modificarlo.

Estas son diez acciones que pueden ayudarte a conservar información, limitar el problema y orientar la revisión.

1. No borres inmediatamente el archivo o el usuario sospechoso

La primera reacción suele ser eliminar aquello que parece malicioso. A veces es necesario, pero hacerlo demasiado pronto puede destruir información útil.

Antes de borrar un archivo, usuario o tarea programada, intenta registrar:

• Su nombre exacto.
• Su ubicación.
• La fecha de modificación o creación, si está disponible.
• El propietario y los permisos.
• El contenido o la configuración relacionada.
• La fecha en la que se detectó.
• Quién ha confirmado que no es legítimo.

Un usuario administrador desconocido puede ser una persistencia, pero también puede haber sido creado por una persona autorizada. Un archivo con un nombre extraño puede formar parte de un plugin o ser una puerta trasera. El contexto es importante.

Si necesitas actuar de inmediato para reducir el riesgo, conserva antes una copia segura de la evidencia o anota los datos relevantes.

2. Limita temporalmente los accesos que no sean necesarios

Si existe una cuenta comprometida o un acceso que ya no debería estar activo, reduce la superficie de entrada. Puedes ampliar esta revisión con la guía sobre cómo retirar accesos de WordPress al cambiar de agencia, desarrollador o proveedor.

Según el caso, puedes:

• Desactivar temporalmente un usuario de WordPress.
• Suspender una cuenta FTP o SFTP que nadie reconozca.
• Retirar una clave SSH no identificada.
• Desactivar el acceso de una persona que ya no trabaja en el proyecto.
• Aplicar restricciones temporales desde el hosting.
• Cambiar el acceso al panel si sospechas que la contraseña se ha filtrado.

Hazlo de forma controlada y registra qué has cambiado. Si existe una investigación en curso, no conviene cerrar todos los accesos sin saber cómo se estaba produciendo la actividad o sin conservar la información necesaria.

3. Comprueba si hay más administradores desconocidos

Encontrar un usuario administrador que no reconoces puede indicar que alguien ha creado una cuenta con privilegios elevados. Pero revisar solo ese usuario no es suficiente.

Comprueba todos los usuarios de WordPress y anota:

• Nombre de usuario.
• Correo electrónico.
• Rol asignado.
• Fecha de registro, si está disponible.
• Último acceso, cuando WordPress o una herramienta lo registre.
• Cambios recientes en el perfil.

Busca también cuentas con otros roles que puedan modificar contenido, instalar plugins o acceder a funciones sensibles.

Después revisa los usuarios del hosting, FTP, SFTP, SSH, la base de datos y los servicios relacionados. Una cuenta sospechosa en WordPress no demuestra que sea el único punto de acceso.

4. Cambia las credenciales desde un equipo confiable

Si sospechas que alguien ha tenido acceso, cambia las contraseñas afectadas desde un equipo actualizado y que no presente indicios de compromiso. Si quieres revisar el problema de forma más amplia, consulta también la información sobre qué hacer ante un WordPress hackeado.

Considera, como mínimo:

• Administradores de WordPress.
• Cuenta de Plesk o del hosting.
• FTP, SFTP y SSH.
• Base de datos.
• Correo utilizado para recuperar cuentas.
• Cuenta del registrador del dominio.
• CDN, herramientas de analítica o servicios externos.
• Claves de aplicaciones y tokens.

Las contraseñas deben ser únicas. Cambiar solo la contraseña de WordPress puede no servir si la misma credencial se utilizaba también en el hosting o en el correo.

Si una aplicación externa utiliza claves o tokens, revócalos y genera otros. También conviene revisar las sesiones activas y cerrar las que no puedas identificar.

Después de cambiar las credenciales, regenera las claves y salts de WordPress en wp-config.php. Estas cadenas ayudan a invalidar cookies y sesiones existentes. Hazlo de forma controlada y conserva una copia segura de la configuración anterior antes de modificarla.

5. Comprueba si el problema afecta a otros dominios o instalaciones

Cuando varias webs comparten cuenta de hosting, el problema no tiene por qué estar limitado al dominio donde encontraste la primera señal.

Revisa:

• Otros dominios de la misma suscripción.
• Subdominios.
• Instalaciones antiguas.
• Entornos de pruebas.
• Directorios olvidados.
• Copias de WordPress.
• Scripts accesibles desde Internet.
• Tareas programadas comunes.

Una cuenta FTP, una clave SSH o una tarea del sistema puede tener acceso a más de una instalación. También puede ocurrir que una web antigua y sin mantenimiento haya servido como punto de entrada para modificar otra más reciente.

No des por limpia una instalación solo porque la portada se vea normal.

6. Revisa los archivos modificados y las ubicaciones habituales de persistencia

Un archivo sospechoso puede ser la parte visible de un problema más amplio. Busca cambios recientes y presta atención a ubicaciones como:

• wp-content/uploads.
• Plugins y temas.
• mu-plugins.
• wp-includes y wp-admin.
• Archivos de configuración.
• .htaccess.
• Archivos de inicio de PHP.
• Directorios temporales.
• Tareas programadas.
• Configuraciones del hosting.

Revisa de forma específica functions.php y wp-config.php. Son archivos legítimos, pero también son ubicaciones habituales para añadir código que se ejecuta en cada petición o para modificar la configuración de WordPress. Comprueba los cambios frente a una copia conocida y busca fragmentos que nadie pueda explicar.

La presencia de código ofuscado, funciones de ejecución dinámica o nombres parecidos a archivos legítimos merece una revisión, pero no permite concluir por sí sola que un archivo sea malicioso.

Compara los archivos con una copia conocida, una versión oficial del plugin o tema y los cambios legítimos registrados. Un análisis correcto debe distinguir entre archivos añadidos, archivos modificados y archivos que forman parte de la instalación original.

Puedes complementar la revisión manual con un escáner de malware como Wordfence u otra herramienta equivalente. El resultado de un escáner es una señal para investigar, no una prueba absoluta de que la web esté limpia o comprometida. Revisa los archivos marcados, contrástalos con versiones oficiales y documenta los falsos positivos antes de eliminarlos.

7. Comprueba la base de datos y la configuración de WordPress

Una intrusión puede modificar la base de datos sin dejar un archivo nuevo evidente.

Revisa, entre otros elementos:

• Usuarios y perfiles.
• Opciones relacionadas con la URL de la web.
• Plugins activos.
• Tareas pendientes o eventos programados.
• Widgets y menús.
• Fragmentos de código insertados en contenidos.
• Redirecciones.
• Correos de administración.
• Claves y valores de configuración que no reconozcas.

También comprueba si han aparecido entradas, páginas, comentarios o bloques de contenido que no pertenecen al sitio.

No modifiques directamente la base de datos sin una copia y sin saber qué efecto tendrá cada cambio. Una corrección apresurada puede romper la web y hacer más difícil reconstruir lo ocurrido.

8. Revisa los registros antes de que desaparezcan

Los registros pueden ayudar a relacionar una modificación con un acceso, aunque no siempre permitan identificar al responsable. Esta revisión forma parte de una auditoría de seguridad de WordPress y debe interpretarse junto con los archivos, las cuentas y la configuración del sitio.

Conserva, si están disponibles:

• Registros de peticiones web.
• Errores de PHP.
• Accesos al panel de WordPress.
• Accesos FTP, SFTP y SSH.
• Cambios registrados por Plesk.
• Logs del firewall o CDN.
• Actividad de cuentas de correo.
• Historial de tareas programadas.

Busca fechas y horas relacionadas con la creación del usuario, la modificación del archivo o la aparición del contenido extraño.

Una dirección IP no es una identidad. Puede pertenecer a una red compartida, una VPN, un proxy o un servicio legítimo. Los registros aportan indicios y deben interpretarse junto con los demás datos.

9. Comprueba si la web está siendo utilizada para acciones visibles o silenciosas

No todas las intrusiones muestran una página de aviso. La web puede seguir cargando con normalidad mientras realiza otras acciones.

Comprueba si existen:

• Redirecciones para determinados dispositivos o procedencias.
• Páginas de spam que solo aparecen en buscadores.
• Formularios que envían datos a destinos desconocidos.
• Correos enviados desde la cuenta sin autorización.
• Nuevos propietarios o cambios en herramientas externas.
• Peticiones anómalas.
• Consumo elevado de CPU o memoria.
• Tareas que se ejecutan repetidamente.
• Cambios en el sitemap o en robots.txt.

Comprueba también cómo ve Google la web. Revisa Search Console, los propietarios y usuarios verificados, las acciones de seguridad, los problemas de indexación, las páginas excluidas y las consultas o URLs que no reconozcas. La guía sobre una infección de WordPress que añadía propietarios en Search Console muestra por qué esta comprobación no debe quedarse en el panel de WordPress. Busca en Google el dominio y consultas como site:ejemplo.com para detectar páginas spam que no aparecen en la navegación normal.

Si encuentras propietarios desconocidos en Search Console, no los elimines sin conservar antes la información disponible. Registra el usuario, la fecha y el método de verificación, y revisa también los archivos o registros que pudieron utilizarse para demostrar la propiedad del sitio.

Prueba la web desde una sesión privada y desde distintos dispositivos, pero no confundas que no veas el problema con que la web esté limpia. Algunas modificaciones se activan solo bajo determinadas condiciones.

10. Planifica una limpieza y una verificación completa

Eliminar el archivo sospechoso o el usuario desconocido puede cerrar una parte del problema, pero no demuestra que la instalación esté limpia.

Una revisión completa debería incluir. Si la limpieza requiere intervención técnica, puedes consultar el servicio de desinfección web y las opciones de mantenimiento y seguridad de WordPress:

1. Conservación de la información disponible.
2. Identificación de las cuentas y accesos afectados.
3. Cambio y revocación de credenciales.
4. Regeneración de las claves y salts de WordPress.
5. Revisión de archivos, incluyendo functions.php, wp-config.php y .htaccess.
6. Escaneo con una herramienta de malware y revisión manual de los resultados.
7. Revisión de base de datos, usuarios, Search Console y configuración.
8. Comprobación de tareas programadas y persistencias.
9. Revisión de las instalaciones relacionadas.
10. Restauración solo desde una copia conocida y verificada, si procede.
11. Actualización de WordPress, plugins, temas y PHP.
12. Eliminación de componentes que ya no se utilicen.
13. Pruebas posteriores de la web, formularios, correo, redirecciones, indexación y accesos.

Si no puedes determinar cuándo comenzó el problema o qué archivos se han modificado, una limpieza selectiva puede dejar elementos activos. En ese caso conviene hacer una revisión técnica del conjunto, no solo del archivo que llamó la atención.

Qué no conviene hacer

Ante una posible intrusión, hay algunas reacciones que pueden empeorar la situación:

• Borrar todos los archivos sin conservar información.
• Restaurar la copia más reciente sin comprobarla.
• Cambiar solo la contraseña de WordPress.
• Reinstalar WordPress sin revisar la base de datos y el hosting.
• Desactivar todos los plugins sin registrar el estado anterior.
• Dar por resuelto el problema porque la portada carga.
• Acusar a una persona basándose únicamente en una dirección IP.
• Publicar capturas o credenciales durante la investigación.

La rapidez es importante, pero también lo es no destruir las pistas que pueden explicar lo ocurrido.

Una señal no siempre explica toda la intrusión

Un archivo sospechoso, un administrador desconocido o una redirección extraña son señales que deben investigarse. Ninguna de ellas explica necesariamente por sí sola cómo se produjo el acceso, cuánto tiempo estuvo activo o qué partes de la instalación se vieron afectadas.

La respuesta más segura combina contención, conservación de evidencias, revisión del entorno completo y verificación posterior.

Si una web presenta indicios de intrusión, el objetivo no debería ser únicamente volver a mostrar la portada. También hay que averiguar qué accesos existían, qué se modificó, si queda alguna persistencia y qué medidas evitarán que el problema vuelva a aparecer.