Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Encontrar Entrada Persistencia

Cómo distinguir una cuenta de hosting comprometida de un WordPress comprometido

Separa ataques de hosting y WordPress usando propietarios, logs del panel, webs hermanas, bases y evidencias del plano de control.

La ejecución de código en WordPress suele escribir como su usuario PHP, mientras que un cPanel, Plesk o SFTP robado puede cambiar varias raíces, bases, correo y DNS. La diferencia decide qué reconstruir y qué credenciales priorizar.

Empieza considerando toda la cuenta y reduce el alcance solo con evidencia.

Mapea permisos y propietarios

Documenta usuario del sistema, handler PHP, raíz WordPress, webs hermanas, usuarios MySQL y directorios escribibles. Anota si varias webs comparten usuario del sistema.

En cPanel compartido, un PHP comprometido puede cruzar raíces si lo permiten los permisos. En suscripciones Plesk separadas, los cambios cruzados apuntan a acceso más amplio. No alteres propietarios antes de conservarlos.

Revisa accesos del panel

Inspecciona logins cPanel/Plesk, gestor de archivos, tokens API, usuarios de equipo o cliente y cambios del correo de recuperación. Correlaciónalos con archivos y base.

Una sesión desconocida correcta es evidencia fuerte de hosting. Su ausencia no prueba alcance WordPress si la retención es corta. Conserva IDs antes de revocar.

Inspecciona SFTP, SSH y despliegues

Revisa usuarios y claves FTP/SFTP/SSH, despliegues y restauraciones. Compara comandos o rutas subidas con los cambios maliciosos.

Una credencial de desarrollador robada puede parecer actividad normal. Confirma con el propietario en vez de confiar en el nombre. Rota claves desde un dispositivo limpio después de capturar.

Compara webs hermanas

Busca payloads, administradores, hooks cron, dominios de redirección y horas iguales en toda la cuenta. Un patrón simultáneo entre raíces sugiere acceso compartido o permisos inseguros.

Fechas distintas también pueden indicar propagación lateral. Examina staging abandonado y backups. No limpies solo el dominio principal visible.

Examina indicadores de WordPress

Busca en logs endpoints vulnerables de plugins o temas, acciones autenticadas y subidas. Revisa usuarios, contraseñas de aplicación, mu-plugins, cron y opciones.

Si los cambios quedan en una instalación y coinciden con un exploit público, la entrada WordPress es más probable; aun así, después pudieron leerse secretos del hosting. Registra escalada y primera persistencia.

Interpreta propietarios con cautela

Los archivos del usuario PHP o del sistema pueden proceder de WordPress, actualizaciones legítimas o gestor del panel según el hosting. Propietario y fecha apoyan, pero no atribuyen.

Compara con despliegues y auditoría. Conserva metadatos antes de cambiar permisos o copiar. En hosting gestionado, pregunta cómo representan escrituras web y del panel.

Revisa elementos externos a WordPress

Cron de servidor desconocido, reenvíos alterados, DNS cambiado, configuración PHP o archivos fuera de cualquier raíz apuntan más allá de la aplicación.

Revisa herramientas MySQL y auto_prepend_file del servidor sin ejecutar archivos sospechosos. Eleva cambios root o de paquetes al responsable de infraestructura.

Considera secretos legibles por PHP

Incluso un ataque solo a la aplicación puede exponer MySQL, salts y claves SMTP/API de configuración. Después podría comprometer base, correo o terceros sin robar el panel.

Inventaría secretos accesibles al proceso PHP y rótalos ordenadamente. Limita en el futuro cada credencial al servicio y web necesarios.

Elige el alcance de recuperación

Con evidencia solo WordPress, reconstruye esa web y rota secretos que podía leer. Con evidencia de cuenta, protege correo, panel, todos los usuarios y claves, bases, correo, copias y DNS.

Si hay dudas, contiene con el alcance amplio mientras analizas. La comodidad no debe dejar accesos compartidos activos. Separa webs y usuarios cuando sea viable.

Verifica el límite después

Monitoriza logins del panel, archivos entre raíces, acciones privilegiadas, cron y correo saliente. Prueba las funciones comerciales de cada web afectada.

Documenta evidencia, incertidumbre y por qué el alcance basta. Conserva capturas y logs según política. Si cambiaron webs hermanas o configuración del servidor, solicita recuperación multicapa compartiendo topología y eventos censurados, nunca claves maestras o backups completos.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia↗