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

Encontrar Entrada Persistencia

Una contraseña WordPress robada parece una vulnerabilidad de plugin

Distingue credenciales robadas de explotación de plugins mediante logins, sesiones, peticiones, versiones y evidencia de cuentas.

Un plugin vulnerable y una contraseña administradora robada pueden coexistir. Culpar solo al plugin por estar desactualizado deja el robo sin resolver; culpar solo a las credenciales puede mantener abierto un endpoint anónimo.

Construye dos cronologías y determina cuál explica la primera acción privilegiada.

Conserva ambos conjuntos de evidencias

Registra versiones y fuentes de plugins o temas, usuarios, roles, contraseñas de aplicación, sesiones, logins y peticiones relevantes. Captura archivos, base y logs antes de actualizar o restablecer si es seguro.

No exportes hashes ni cuerpos completos a un ticket. Usa IDs, horas y rutas. Separa el primer indicio de las acciones posteriores del atacante.

Busca actividad autenticada

Revisa logins correctos, restablecimientos, creación de sesiones y acciones administrativas anteriores a los cambios. Comprueba variaciones de navegador o dispositivo, considerando VPN e IP compartidas.

Una sesión robada puede no generar un login nuevo. La API con contraseña de aplicación aparece bajo su usuario principal. Correlaciona evidencia de cuenta con la acción exacta.

Busca actividad en endpoints públicos

Investiga peticiones a la ruta del plugin, AJAX, REST o gestor de subida. Compara versión y configuración con el aviso del fabricante.

Determina autenticación necesaria e impacto. Una vulnerabilidad que solo cambia contenido básico no explica escritura general de archivos sin otro paso. No reproduzcas payloads contra producción.

Considera el camuflaje posterior

Después de entrar por una vía, el atacante puede iniciar sesión, subir un plugin o crear otra cuenta. La evidencia posterior puede parecer el vector contrario.

Concéntrate en el primer evento fiable y los permisos que proporcionó. Documenta explicaciones alternativas. La ausencia de logs antiguos debe reducir la confianza, no aumentarla.

Construye la cadena del ataque

Ordena petición o login inicial, cambio de privilegio, subida, cron, spam y síntoma público. Anota qué capacidad exige cada paso.

Si la primera acción requería administrador, hizo falta robar credencial o sesión salvo que una vulnerabilidad anterior concediera ese rol. Si un endpoint anónimo escribió PHP antes de cualquier login, gana fuerza la hipótesis del plugin. Mantén visibles los periodos sin datos.

Protege las credenciales igualmente

Rota correo propietario, WordPress, hosting, base y credenciales de aplicaciones según exposición. Revoca sesiones, tokens y cuentas desconocidas desde un dispositivo limpio.

Activa MFA y accesos individuales. Comprueba contraseñas repetidas en correo, cPanel/Plesk y webs hermanas. No envíes nuevos secretos por correo ni los guardes en el tema.

Cierra el código vulnerable igualmente

Actualiza o elimina el plugin desde una fuente fiable, incluidas copias inactivas y otras instalaciones. Sustituye núcleo, plugins y temas no fiables y valida desarrollo propio.

Si está abandonado, migra su función. Rotar cuentas no corrige explotación anónima. Mantén la ruta contenida hasta validar la compilación limpia.

Revisa posibles robos de credenciales

Comprueba phishing, malware del dispositivo mediante el proceso autorizado, extensiones, filtraciones, cuentas compartidas y copias o configuraciones públicas.

No analices invasivamente equipos personales sin autorización. Protege canales de recuperación y sesiones del proveedor. Registra evidencias sin atribuir intención al usuario.

Comprueba otros servicios

Busca el mismo usuario, exposición, versión e indicadores en webs hermanas. Revisa correo y hosting porque ambos pueden restablecer WordPress o desplegar código.

No reutilices contraseñas ni asumas que MFA de WordPress protege cPanel. Separa los planos y rota según exposición demostrada.

Informa sobre confianza, no una historia

Expón hechos, huecos, vector probable y alternativas. Por ejemplo: «Una sesión administradora precedió a la subida; el plugin era vulnerable, pero no quedan registros de su ruta».

Usa la conclusión para mejorar parches, MFA, cuentas, retención y alertas. Si la incertidumbre afecta varias webs, solicita evaluación urgente compartiendo cronologías y versiones censuradas, nunca contraseñas o exploit.

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